revi-archive/phorge-phorge
1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-23 15:22:41 +01:00
Code Issues Releases Wiki Activity
phorge-phorge/src/__phutil_library_map__.php

8985 lines
718 KiB
PHP
Raw Normal View History

Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
<?php
/**
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
* This file is automatically generated. Use 'arc liberate' to rebuild it.
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
*
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
* @generated
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
* @phutil-library-version 2
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
*/
phutil_register_library_map(array(
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'__library_version__' => 2,
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'class' => array(
Build AlmanacInterface Summary: Ref T5833. An interface is an IP (maybe v4, maybe v6) and port on a specified network (public internet, VPN, NAT block, etc). Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10718
2014-10-17 14:04:24 +02:00
'AlmanacAddress' => 'applications/almanac/util/AlmanacAddress.php',
Add AlmanacBinding, to bind a service to an interface Summary: Ref T5833. Allows you to bind a service (like `db.example.com`) to one or more interfaces (for example, to specify a pool with one read/write host and two read-only hosts). You can't configure which hosts have which properties yet, but you can add all the relevant interfaces to the service. Next diff will start supporting service, binding, and device properties like "is writable", "is active", etc., so that Almanac will be able to express operations like "change which database is writable", "disable writes", "bring a device down", etc. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10745
2014-10-27 21:39:36 +01:00
'AlmanacBinding' => 'applications/almanac/storage/AlmanacBinding.php',
Allow Almanac bindings to be disabled and unused interfaces to be removed Summary: Fixes T9762. Ref T10246. **Disabling Bindings**: Previously, there was no formal way to disable bindings. The internal callers sometimes check some informal property on the binding, but this is a common need and deserves first-class support in the UI. Allow bindings to be disabled. **Deleting Interfaces**: Previously, you could not delete interfaces. Now, you can delete unused interfaces. Also some minor cleanup and slightly less mysterious documentation. Test Plan: Disabled bindings and deleted interfaces. Reviewers: chad Reviewed By: chad Subscribers: yelirekim Maniphest Tasks: T9762, T10246 Differential Revision: https://secure.phabricator.com/D15345
2016-02-25 12:52:41 +01:00
'AlmanacBindingDisableController' => 'applications/almanac/controller/AlmanacBindingDisableController.php',
Add AlmanacBinding, to bind a service to an interface Summary: Ref T5833. Allows you to bind a service (like `db.example.com`) to one or more interfaces (for example, to specify a pool with one read/write host and two read-only hosts). You can't configure which hosts have which properties yet, but you can add all the relevant interfaces to the service. Next diff will start supporting service, binding, and device properties like "is writable", "is active", etc., so that Almanac will be able to express operations like "change which database is writable", "disable writes", "bring a device down", etc. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10745
2014-10-27 21:39:36 +01:00
'AlmanacBindingEditController' => 'applications/almanac/controller/AlmanacBindingEditController.php',
'AlmanacBindingEditor' => 'applications/almanac/editor/AlmanacBindingEditor.php',
'AlmanacBindingPHIDType' => 'applications/almanac/phid/AlmanacBindingPHIDType.php',
Allow Almanac properties to be deleted, use EditEngine instead of CustomField Summary: Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings. The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff). Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks. This also makes the internal storage for properties JSON instead of raw text. Test Plan: - Created, edited and deleted properties on services, devices and bindings. - Edited and reset builtin properties on repository services. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10410 Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 15:35:30 +01:00
'AlmanacBindingPropertyEditEngine' => 'applications/almanac/editor/AlmanacBindingPropertyEditEngine.php',
Add AlmanacBinding, to bind a service to an interface Summary: Ref T5833. Allows you to bind a service (like `db.example.com`) to one or more interfaces (for example, to specify a pool with one read/write host and two read-only hosts). You can't configure which hosts have which properties yet, but you can add all the relevant interfaces to the service. Next diff will start supporting service, binding, and device properties like "is writable", "is active", etc., so that Almanac will be able to express operations like "change which database is writable", "disable writes", "bring a device down", etc. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10745
2014-10-27 21:39:36 +01:00
'AlmanacBindingQuery' => 'applications/almanac/query/AlmanacBindingQuery.php',
'AlmanacBindingTableView' => 'applications/almanac/view/AlmanacBindingTableView.php',
'AlmanacBindingTransaction' => 'applications/almanac/storage/AlmanacBindingTransaction.php',
'AlmanacBindingTransactionQuery' => 'applications/almanac/query/AlmanacBindingTransactionQuery.php',
'AlmanacBindingViewController' => 'applications/almanac/controller/AlmanacBindingViewController.php',
Expose modern `*.search` Conduit endpoints in Almanac Summary: Fixes T10411. Ref T10246. There are probably still some rough edges with this, but replace the old-school endpoints with modern ones so we don't unprototype with deprecated stuff. Test Plan: - Made a bunch of calls to the new endpoints with various constraints/attachments. - Created and edited services, devices, interfaces, bindings, and properties on everything. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10246, T10411 Differential Revision: https://secure.phabricator.com/D15329
2016-02-22 21:53:40 +01:00
'AlmanacBindingsSearchEngineAttachment' => 'applications/almanac/engineextension/AlmanacBindingsSearchEngineAttachment.php',
Add a "ClusterDatabase" Almanac service type Summary: Ref T5833. This doesn't do anything yet, but will allow new instances to automaticaly bind to an open database without anything too hacky. Test Plan: Created a service of this type. {F267059} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D11372
2015-01-13 20:59:23 +01:00
'AlmanacClusterDatabaseServiceType' => 'applications/almanac/servicetype/AlmanacClusterDatabaseServiceType.php',
Give AlmanacServices a service type Summary: Ref T5833. This allows services to be typed, to distinguish between different kinds of services. This makes a few things easier: - It's easier for clients to select the services they're interested in (see note in T5873 about Phacility). This isn't a full-power solution, but gets is some of the way there. - It's easier to set appropriate permissions around when modifications to the Phabricator cluster are allowed. These service nodes need to be demarcated as special in some way no matter what (see T6741). This also defines a new policy for users who are permitted to create services. - It's easier to browse/review/understand services. - Future diffs will allow ServiceTypes to specify more service structure (for example, default properties) to make it easier to configure services correctly. Instead of a free-for-all, you'll get a useful list of things that consumers of the service expect to read. The "custom" service type allows unstructured/freeform services to be created. Test Plan: - Created a new service (and hit error cases). - Edited an existing service. - Saw service types on list and detail views. - Poked around new permission stuff. - Ran `almanac.queryservices` with service class specification. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10995
2014-12-17 20:10:27 +01:00
'AlmanacClusterRepositoryServiceType' => 'applications/almanac/servicetype/AlmanacClusterRepositoryServiceType.php',
'AlmanacClusterServiceType' => 'applications/almanac/servicetype/AlmanacClusterServiceType.php',
Build AlmanacService Summary: Ref T5833. See that task for functional goals and some discussion of design. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 14:01:57 +02:00
'AlmanacConsoleController' => 'applications/almanac/controller/AlmanacConsoleController.php',
'AlmanacController' => 'applications/almanac/controller/AlmanacController.php',
Build AlmanacDevice UI Summary: Ref T5833. The "uninteresting" part of this object is virtually identical to AlmanacService. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10714
2014-10-17 14:02:14 +02:00
'AlmanacCreateDevicesCapability' => 'applications/almanac/capability/AlmanacCreateDevicesCapability.php',
Rough-in Almanac namespaces Summary: Ref T6741. Ref T10246. Root problem: to provide Drydock in the cluster, we need to expose Almanac, and doing so would let users accidentally or intentionally create a bunch of `repo006.phacility.net` devices/services which could conflict with the real ones we manage. There's currently no way to say "you can't create anything named `*.blah.net`". This adds "namespaces", which let you do that (well, not yet, but they will after the next diff). After the next diff, if you try to create `repo003.phacility.net`, but the namespace `phacility.net` already exists and you don't have permission to edit it, you'll be asked to choose a different name. Also various modernizations and some new docs. Test Plan: - Created cool namespaces like `this.computer`. - Almanac namespaces don't actually enforce policies yet. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6741, T10246 Differential Revision: https://secure.phabricator.com/D15324
2016-02-21 21:15:57 +01:00
'AlmanacCreateNamespacesCapability' => 'applications/almanac/capability/AlmanacCreateNamespacesCapability.php',
Build AlmanacNetwork Summary: Ref T5833. This differentiates address spaces like the public internet from VPNs, so when a service is available at `192.168.0.1`, we'll know it's on some specific NAT block or whatever. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10715
2014-10-17 14:04:02 +02:00
'AlmanacCreateNetworksCapability' => 'applications/almanac/capability/AlmanacCreateNetworksCapability.php',
Build AlmanacService Summary: Ref T5833. See that task for functional goals and some discussion of design. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 14:01:57 +02:00
'AlmanacCreateServicesCapability' => 'applications/almanac/capability/AlmanacCreateServicesCapability.php',
Give AlmanacServices a service type Summary: Ref T5833. This allows services to be typed, to distinguish between different kinds of services. This makes a few things easier: - It's easier for clients to select the services they're interested in (see note in T5873 about Phacility). This isn't a full-power solution, but gets is some of the way there. - It's easier to set appropriate permissions around when modifications to the Phabricator cluster are allowed. These service nodes need to be demarcated as special in some way no matter what (see T6741). This also defines a new policy for users who are permitted to create services. - It's easier to browse/review/understand services. - Future diffs will allow ServiceTypes to specify more service structure (for example, default properties) to make it easier to configure services correctly. Instead of a free-for-all, you'll get a useful list of things that consumers of the service expect to read. The "custom" service type allows unstructured/freeform services to be created. Test Plan: - Created a new service (and hit error cases). - Edited an existing service. - Saw service types on list and detail views. - Poked around new permission stuff. - Ran `almanac.queryservices` with service class specification. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10995
2014-12-17 20:10:27 +01:00
'AlmanacCustomServiceType' => 'applications/almanac/servicetype/AlmanacCustomServiceType.php',
Implement storage of a host ID and a public key for authorizing Conduit between servers Summary: Ref T4209. This creates storage for public keys against authorized hosts, such that servers can be authorized to make Conduit calls as the omnipotent user. Servers are registered into this system by running the following command once: ``` bin/almanac register ``` NOTE: This doesn't implement authorization between servers, just the storage of public keys. Placing this against Almanac seemed like the most sensible place, since I'm imagining in future that the `register` command will accept more information (like the hostname of the server so it can be found in the service directory). Test Plan: Ran `bin/almanac register` and saw the host (and public key information) appear in the database. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4209 Differential Revision: https://secure.phabricator.com/D10400
2014-10-03 14:52:41 +02:00
'AlmanacDAO' => 'applications/almanac/storage/AlmanacDAO.php',
'AlmanacDevice' => 'applications/almanac/storage/AlmanacDevice.php',
Build AlmanacDevice UI Summary: Ref T5833. The "uninteresting" part of this object is virtually identical to AlmanacService. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10714
2014-10-17 14:02:14 +02:00
'AlmanacDeviceController' => 'applications/almanac/controller/AlmanacDeviceController.php',
'AlmanacDeviceEditController' => 'applications/almanac/controller/AlmanacDeviceEditController.php',
Use EditEngine for AlmanacDevice Summary: Ref T10449. Modernize the AlmanacDevice code a bit. Test Plan: - Created a device. - Edited a device. - Listed devices. - Viewed a device. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10449 Differential Revision: https://secure.phabricator.com/D15399
2016-03-05 01:14:27 +01:00
'AlmanacDeviceEditEngine' => 'applications/almanac/editor/AlmanacDeviceEditEngine.php',
Build AlmanacDevice UI Summary: Ref T5833. The "uninteresting" part of this object is virtually identical to AlmanacService. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10714
2014-10-17 14:02:14 +02:00
'AlmanacDeviceEditor' => 'applications/almanac/editor/AlmanacDeviceEditor.php',
'AlmanacDeviceListController' => 'applications/almanac/controller/AlmanacDeviceListController.php',
Allow Almanac devices to be queried and sorted by name Summary: Ref T10205. Ref T10246. This is general modernization, but also supports fixing the interface datasource in T10205. - Update Query. - Update SearchEngine. - Use an ngrams index for searching names efficiently. Test Plan: - Ran migrations. - Searched Almanac devices by name. - Created a new device, searched for it by name. {F1121303} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10205, T10246 Differential Revision: https://secure.phabricator.com/D15319
2016-02-21 11:48:10 +01:00
'AlmanacDeviceNameNgrams' => 'applications/almanac/storage/AlmanacDeviceNameNgrams.php',
Implement storage of a host ID and a public key for authorizing Conduit between servers Summary: Ref T4209. This creates storage for public keys against authorized hosts, such that servers can be authorized to make Conduit calls as the omnipotent user. Servers are registered into this system by running the following command once: ``` bin/almanac register ``` NOTE: This doesn't implement authorization between servers, just the storage of public keys. Placing this against Almanac seemed like the most sensible place, since I'm imagining in future that the `register` command will accept more information (like the hostname of the server so it can be found in the service directory). Test Plan: Ran `bin/almanac register` and saw the host (and public key information) appear in the database. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4209 Differential Revision: https://secure.phabricator.com/D10400
2014-10-03 14:52:41 +02:00
'AlmanacDevicePHIDType' => 'applications/almanac/phid/AlmanacDevicePHIDType.php',
Allow Almanac properties to be deleted, use EditEngine instead of CustomField Summary: Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings. The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff). Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks. This also makes the internal storage for properties JSON instead of raw text. Test Plan: - Created, edited and deleted properties on services, devices and bindings. - Edited and reset builtin properties on repository services. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10410 Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 15:35:30 +01:00
'AlmanacDevicePropertyEditEngine' => 'applications/almanac/editor/AlmanacDevicePropertyEditEngine.php',
Implement storage of a host ID and a public key for authorizing Conduit between servers Summary: Ref T4209. This creates storage for public keys against authorized hosts, such that servers can be authorized to make Conduit calls as the omnipotent user. Servers are registered into this system by running the following command once: ``` bin/almanac register ``` NOTE: This doesn't implement authorization between servers, just the storage of public keys. Placing this against Almanac seemed like the most sensible place, since I'm imagining in future that the `register` command will accept more information (like the hostname of the server so it can be found in the service directory). Test Plan: Ran `bin/almanac register` and saw the host (and public key information) appear in the database. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4209 Differential Revision: https://secure.phabricator.com/D10400
2014-10-03 14:52:41 +02:00
'AlmanacDeviceQuery' => 'applications/almanac/query/AlmanacDeviceQuery.php',
Expose modern `*.search` Conduit endpoints in Almanac Summary: Fixes T10411. Ref T10246. There are probably still some rough edges with this, but replace the old-school endpoints with modern ones so we don't unprototype with deprecated stuff. Test Plan: - Made a bunch of calls to the new endpoints with various constraints/attachments. - Created and edited services, devices, interfaces, bindings, and properties on everything. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10246, T10411 Differential Revision: https://secure.phabricator.com/D15329
2016-02-22 21:53:40 +01:00
'AlmanacDeviceSearchConduitAPIMethod' => 'applications/almanac/conduit/AlmanacDeviceSearchConduitAPIMethod.php',
Build AlmanacDevice UI Summary: Ref T5833. The "uninteresting" part of this object is virtually identical to AlmanacService. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10714
2014-10-17 14:02:14 +02:00
'AlmanacDeviceSearchEngine' => 'applications/almanac/query/AlmanacDeviceSearchEngine.php',
'AlmanacDeviceTransaction' => 'applications/almanac/storage/AlmanacDeviceTransaction.php',
'AlmanacDeviceTransactionQuery' => 'applications/almanac/query/AlmanacDeviceTransactionQuery.php',
'AlmanacDeviceViewController' => 'applications/almanac/controller/AlmanacDeviceViewController.php',
Add an Almanac service type for Drydock to lease against Summary: Ref T9253. See D13843 for some discussion. This is very bare-bones for now since I believe that almost all interesting configuration (e.g., credentials) should live in Drydock, although I imagine it getting some configuration eventually. Test Plan: Used {nav Almanac > Services > Create Service} to create a new service of this type. Reviewers: hach-que, chad Reviewed By: hach-que, chad Maniphest Tasks: T9253 Differential Revision: https://secure.phabricator.com/D14109
2015-09-21 13:41:23 +02:00
'AlmanacDrydockPoolServiceType' => 'applications/almanac/servicetype/AlmanacDrydockPoolServiceType.php',
Allow Almanac properties to be deleted, use EditEngine instead of CustomField Summary: Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings. The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff). Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks. This also makes the internal storage for properties JSON instead of raw text. Test Plan: - Created, edited and deleted properties on services, devices and bindings. - Edited and reset builtin properties on repository services. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10410 Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 15:35:30 +01:00
'AlmanacEditor' => 'applications/almanac/editor/AlmanacEditor.php',
Build AlmanacInterface Summary: Ref T5833. An interface is an IP (maybe v4, maybe v6) and port on a specified network (public internet, VPN, NAT block, etc). Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10718
2014-10-17 14:04:24 +02:00
'AlmanacInterface' => 'applications/almanac/storage/AlmanacInterface.php',
Add AlmanacBinding, to bind a service to an interface Summary: Ref T5833. Allows you to bind a service (like `db.example.com`) to one or more interfaces (for example, to specify a pool with one read/write host and two read-only hosts). You can't configure which hosts have which properties yet, but you can add all the relevant interfaces to the service. Next diff will start supporting service, binding, and device properties like "is writable", "is active", etc., so that Almanac will be able to express operations like "change which database is writable", "disable writes", "bring a device down", etc. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10745
2014-10-27 21:39:36 +01:00
'AlmanacInterfaceDatasource' => 'applications/almanac/typeahead/AlmanacInterfaceDatasource.php',
Allow Almanac bindings to be disabled and unused interfaces to be removed Summary: Fixes T9762. Ref T10246. **Disabling Bindings**: Previously, there was no formal way to disable bindings. The internal callers sometimes check some informal property on the binding, but this is a common need and deserves first-class support in the UI. Allow bindings to be disabled. **Deleting Interfaces**: Previously, you could not delete interfaces. Now, you can delete unused interfaces. Also some minor cleanup and slightly less mysterious documentation. Test Plan: Disabled bindings and deleted interfaces. Reviewers: chad Reviewed By: chad Subscribers: yelirekim Maniphest Tasks: T9762, T10246 Differential Revision: https://secure.phabricator.com/D15345
2016-02-25 12:52:41 +01:00
'AlmanacInterfaceDeleteController' => 'applications/almanac/controller/AlmanacInterfaceDeleteController.php',
Build AlmanacInterface Summary: Ref T5833. An interface is an IP (maybe v4, maybe v6) and port on a specified network (public internet, VPN, NAT block, etc). Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10718
2014-10-17 14:04:24 +02:00
'AlmanacInterfaceEditController' => 'applications/almanac/controller/AlmanacInterfaceEditController.php',
'AlmanacInterfacePHIDType' => 'applications/almanac/phid/AlmanacInterfacePHIDType.php',
'AlmanacInterfaceQuery' => 'applications/almanac/query/AlmanacInterfaceQuery.php',
'AlmanacInterfaceTableView' => 'applications/almanac/view/AlmanacInterfaceTableView.php',
Add `bin/almanac register` to associate a host with an Almanac device and trust it Summary: Ref T2783. This is basically a more refined version of D10400, which churned a bit on things like SSH key storage, the actual way the signing protocol shook out, etc. - When Phabricator tries to make an intra-cluster service call as the omnipotent user, sign it with the host's device key. - Add `bin/almanac register` to say "this host is X device, identified by private key Y". This stores the keypair locally, adds the public key to Almanac, and trusts it. Net effect is that once a host has been registered, the daemons can make calls to other nodes as the omnipotent user. This is primarily necessary so they can access repository API methods on remote hosts. Test Plan: - Ran `bin/almanac register` with various valid and invalid inputs. - Verified keys get generated/added/stored properly. - Made a device-signed cluster Conduit call. - Made a normal old user-signed cluster Conduit call. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2783 Differential Revision: https://secure.phabricator.com/D11158
2015-01-03 00:13:30 +01:00
'AlmanacKeys' => 'applications/almanac/util/AlmanacKeys.php',
Library Map Update Summary: Our of date, failed harbormaster build Test Plan: run `arc liberate` Reviewers: epriestley, nickz Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15351
2016-02-26 18:42:23 +01:00
'AlmanacManageClusterServicesCapability' => 'applications/almanac/capability/AlmanacManageClusterServicesCapability.php',
Add `bin/almanac register` to associate a host with an Almanac device and trust it Summary: Ref T2783. This is basically a more refined version of D10400, which churned a bit on things like SSH key storage, the actual way the signing protocol shook out, etc. - When Phabricator tries to make an intra-cluster service call as the omnipotent user, sign it with the host's device key. - Add `bin/almanac register` to say "this host is X device, identified by private key Y". This stores the keypair locally, adds the public key to Almanac, and trusts it. Net effect is that once a host has been registered, the daemons can make calls to other nodes as the omnipotent user. This is primarily necessary so they can access repository API methods on remote hosts. Test Plan: - Ran `bin/almanac register` with various valid and invalid inputs. - Verified keys get generated/added/stored properly. - Made a device-signed cluster Conduit call. - Made a normal old user-signed cluster Conduit call. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2783 Differential Revision: https://secure.phabricator.com/D11158
2015-01-03 00:13:30 +01:00
'AlmanacManagementRegisterWorkflow' => 'applications/almanac/management/AlmanacManagementRegisterWorkflow.php',
Allow device SSH keys to be trusted Summary: Ref T6240. Some discussion in that task. In instance/cluster environments, daemons need to make Conduit calls that bypass policy checks. We can't just let anyone add SSH keys with this capability to the web directly, because then an adminstrator could just add a key they own and start signing requests with it, bypassing policy checks. Add a `bin/almanac trust-key --id <x>` workflow for trusting keys. Only trusted keys can sign requests. Test Plan: - Generated a user key. - Generated a device key. - Trusted a device key. - Untrusted a device key. - Hit the various errors on trust/untrust. - Tried to edit a trusted key. {F236010} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6240 Differential Revision: https://secure.phabricator.com/D10878
2014-11-21 02:33:30 +01:00
'AlmanacManagementTrustKeyWorkflow' => 'applications/almanac/management/AlmanacManagementTrustKeyWorkflow.php',
'AlmanacManagementUntrustKeyWorkflow' => 'applications/almanac/management/AlmanacManagementUntrustKeyWorkflow.php',
Implement storage of a host ID and a public key for authorizing Conduit between servers Summary: Ref T4209. This creates storage for public keys against authorized hosts, such that servers can be authorized to make Conduit calls as the omnipotent user. Servers are registered into this system by running the following command once: ``` bin/almanac register ``` NOTE: This doesn't implement authorization between servers, just the storage of public keys. Placing this against Almanac seemed like the most sensible place, since I'm imagining in future that the `register` command will accept more information (like the hostname of the server so it can be found in the service directory). Test Plan: Ran `bin/almanac register` and saw the host (and public key information) appear in the database. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4209 Differential Revision: https://secure.phabricator.com/D10400
2014-10-03 14:52:41 +02:00
'AlmanacManagementWorkflow' => 'applications/almanac/management/AlmanacManagementWorkflow.php',
Build AlmanacDevice UI Summary: Ref T5833. The "uninteresting" part of this object is virtually identical to AlmanacService. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10714
2014-10-17 14:02:14 +02:00
'AlmanacNames' => 'applications/almanac/util/AlmanacNames.php',
'AlmanacNamesTestCase' => 'applications/almanac/util/__tests__/AlmanacNamesTestCase.php',
Rough-in Almanac namespaces Summary: Ref T6741. Ref T10246. Root problem: to provide Drydock in the cluster, we need to expose Almanac, and doing so would let users accidentally or intentionally create a bunch of `repo006.phacility.net` devices/services which could conflict with the real ones we manage. There's currently no way to say "you can't create anything named `*.blah.net`". This adds "namespaces", which let you do that (well, not yet, but they will after the next diff). After the next diff, if you try to create `repo003.phacility.net`, but the namespace `phacility.net` already exists and you don't have permission to edit it, you'll be asked to choose a different name. Also various modernizations and some new docs. Test Plan: - Created cool namespaces like `this.computer`. - Almanac namespaces don't actually enforce policies yet. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6741, T10246 Differential Revision: https://secure.phabricator.com/D15324
2016-02-21 21:15:57 +01:00
'AlmanacNamespace' => 'applications/almanac/storage/AlmanacNamespace.php',
'AlmanacNamespaceController' => 'applications/almanac/controller/AlmanacNamespaceController.php',
'AlmanacNamespaceEditController' => 'applications/almanac/controller/AlmanacNamespaceEditController.php',
'AlmanacNamespaceEditEngine' => 'applications/almanac/editor/AlmanacNamespaceEditEngine.php',
'AlmanacNamespaceEditor' => 'applications/almanac/editor/AlmanacNamespaceEditor.php',
'AlmanacNamespaceListController' => 'applications/almanac/controller/AlmanacNamespaceListController.php',
'AlmanacNamespaceNameNgrams' => 'applications/almanac/storage/AlmanacNamespaceNameNgrams.php',
'AlmanacNamespacePHIDType' => 'applications/almanac/phid/AlmanacNamespacePHIDType.php',
'AlmanacNamespaceQuery' => 'applications/almanac/query/AlmanacNamespaceQuery.php',
'AlmanacNamespaceSearchEngine' => 'applications/almanac/query/AlmanacNamespaceSearchEngine.php',
'AlmanacNamespaceTransaction' => 'applications/almanac/storage/AlmanacNamespaceTransaction.php',
'AlmanacNamespaceTransactionQuery' => 'applications/almanac/query/AlmanacNamespaceTransactionQuery.php',
'AlmanacNamespaceViewController' => 'applications/almanac/controller/AlmanacNamespaceViewController.php',
Build AlmanacNetwork Summary: Ref T5833. This differentiates address spaces like the public internet from VPNs, so when a service is available at `192.168.0.1`, we'll know it's on some specific NAT block or whatever. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10715
2014-10-17 14:04:02 +02:00
'AlmanacNetwork' => 'applications/almanac/storage/AlmanacNetwork.php',
'AlmanacNetworkController' => 'applications/almanac/controller/AlmanacNetworkController.php',
'AlmanacNetworkEditController' => 'applications/almanac/controller/AlmanacNetworkEditController.php',
Use EditEngine for Almanac Services, Devices, and Networks Summary: Ref T10411. This cleans up / modernizes things and lets me get an `almanac.network.edit` API in the future. This is mostly straightforward, except that Services have an extra "choose type" screen in front of them. Test Plan: - Created and edited Almanac networks, services, and devices. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10411 Differential Revision: https://secure.phabricator.com/D15326
2016-02-22 14:11:02 +01:00
'AlmanacNetworkEditEngine' => 'applications/almanac/editor/AlmanacNetworkEditEngine.php',
Build AlmanacNetwork Summary: Ref T5833. This differentiates address spaces like the public internet from VPNs, so when a service is available at `192.168.0.1`, we'll know it's on some specific NAT block or whatever. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10715
2014-10-17 14:04:02 +02:00
'AlmanacNetworkEditor' => 'applications/almanac/editor/AlmanacNetworkEditor.php',
'AlmanacNetworkListController' => 'applications/almanac/controller/AlmanacNetworkListController.php',
Allow Almanac namespaces to be searched by ngram index Summary: Ref T6741. Ref T10246. This is largely modernization, but will partially support namespace locking in Almanac. Test Plan: Searched for Almanac networks by name substring. {F1121740} Reviewers: chad Reviewed By: chad Maniphest Tasks: T6741, T10246 Differential Revision: https://secure.phabricator.com/D15322
2016-02-21 20:13:08 +01:00
'AlmanacNetworkNameNgrams' => 'applications/almanac/storage/AlmanacNetworkNameNgrams.php',
Build AlmanacNetwork Summary: Ref T5833. This differentiates address spaces like the public internet from VPNs, so when a service is available at `192.168.0.1`, we'll know it's on some specific NAT block or whatever. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10715
2014-10-17 14:04:02 +02:00
'AlmanacNetworkPHIDType' => 'applications/almanac/phid/AlmanacNetworkPHIDType.php',
'AlmanacNetworkQuery' => 'applications/almanac/query/AlmanacNetworkQuery.php',
'AlmanacNetworkSearchEngine' => 'applications/almanac/query/AlmanacNetworkSearchEngine.php',
'AlmanacNetworkTransaction' => 'applications/almanac/storage/AlmanacNetworkTransaction.php',
'AlmanacNetworkTransactionQuery' => 'applications/almanac/query/AlmanacNetworkTransactionQuery.php',
'AlmanacNetworkViewController' => 'applications/almanac/controller/AlmanacNetworkViewController.php',
Prepare DestructionEngine to be modularized Summary: Ref T9979. The general shape of "engine" code feels pretty good, and I plan to move indexing to be more in line with other modern engines, with the ultimate goal of supporting subprojects (T10010) and several intermediate goals. Before moving indexing, clean up Destruction, since some of the new indexes will need destruction hooks and destruction currently has a lot of `instanceof` stuff that should be easy to fix by applying more modern approaches. Test Plan: - Used `bin/remove destroy` to destory an Almanac device. - Verified that properties for the device were destroyed. - Viewed module panel in UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14831
2015-12-20 16:44:03 +01:00
'AlmanacPropertiesDestructionEngineExtension' => 'applications/almanac/engineextension/AlmanacPropertiesDestructionEngineExtension.php',
Expose modern `*.search` Conduit endpoints in Almanac Summary: Fixes T10411. Ref T10246. There are probably still some rough edges with this, but replace the old-school endpoints with modern ones so we don't unprototype with deprecated stuff. Test Plan: - Made a bunch of calls to the new endpoints with various constraints/attachments. - Created and edited services, devices, interfaces, bindings, and properties on everything. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10246, T10411 Differential Revision: https://secure.phabricator.com/D15329
2016-02-22 21:53:40 +01:00
'AlmanacPropertiesSearchEngineAttachment' => 'applications/almanac/engineextension/AlmanacPropertiesSearchEngineAttachment.php',
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
'AlmanacProperty' => 'applications/almanac/storage/AlmanacProperty.php',
'AlmanacPropertyController' => 'applications/almanac/controller/AlmanacPropertyController.php',
Allow Almanac service types to define default properties Summary: Ref T5833. This allows Almanac ServiceTypes to define default properties for a service, which show up in the UI and are more easily editable. Overall, this makes it much easier to make structured/usable/consistent service records: you can check a checkbox that says "prevent new allocations" instead of needing to know the meaning of a key. Test Plan: {F251593} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10996
2014-12-17 20:10:50 +01:00
'AlmanacPropertyDeleteController' => 'applications/almanac/controller/AlmanacPropertyDeleteController.php',
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
'AlmanacPropertyEditController' => 'applications/almanac/controller/AlmanacPropertyEditController.php',
Allow Almanac properties to be deleted, use EditEngine instead of CustomField Summary: Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings. The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff). Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks. This also makes the internal storage for properties JSON instead of raw text. Test Plan: - Created, edited and deleted properties on services, devices and bindings. - Edited and reset builtin properties on repository services. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10410 Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 15:35:30 +01:00
'AlmanacPropertyEditEngine' => 'applications/almanac/editor/AlmanacPropertyEditEngine.php',
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
'AlmanacPropertyInterface' => 'applications/almanac/property/AlmanacPropertyInterface.php',
'AlmanacPropertyQuery' => 'applications/almanac/query/AlmanacPropertyQuery.php',
Allow Almanac Devices and Bindings to have properties Summary: Ref T5833. Adds support for arbitrary properites to Almanac devices and bindings. - For Devices, this allows you to maybe mark what `rack` a server is on, the `serial` number of a router, etc. - For Bindings, this allows you to maybe mark that a bound device is `active`, provide `credentials`, expose it as `readonly`, etc. Test Plan: Added properties to Devices and Bindings. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10781
2014-11-06 00:28:36 +01:00
'AlmanacQuery' => 'applications/almanac/query/AlmanacQuery.php',
Implement PhabricatorProjectInterface on Almanac Services and Devices Summary: Ref T5833. Allow services and devices to be tagged with projects. (These fluff apply implementations are a good example of the issue discussed in T6403.) Test Plan: {F229569} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10782
2014-11-06 00:30:00 +01:00
'AlmanacSchemaSpec' => 'applications/almanac/storage/AlmanacSchemaSpec.php',
Expose modern `*.search` Conduit endpoints in Almanac Summary: Fixes T10411. Ref T10246. There are probably still some rough edges with this, but replace the old-school endpoints with modern ones so we don't unprototype with deprecated stuff. Test Plan: - Made a bunch of calls to the new endpoints with various constraints/attachments. - Created and edited services, devices, interfaces, bindings, and properties on everything. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10246, T10411 Differential Revision: https://secure.phabricator.com/D15329
2016-02-22 21:53:40 +01:00
'AlmanacSearchEngineAttachment' => 'applications/almanac/engineextension/AlmanacSearchEngineAttachment.php',
Build AlmanacService Summary: Ref T5833. See that task for functional goals and some discussion of design. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 14:01:57 +02:00
'AlmanacService' => 'applications/almanac/storage/AlmanacService.php',
'AlmanacServiceController' => 'applications/almanac/controller/AlmanacServiceController.php',
Add an Almanac service typeahead datasource Summary: Ref T5833. Ref T6238. This will probably be useful somewhere in the upstream eventually, and is materially useful in the Instances application right now. Test Plan: tippy typey typey Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6238, T5833 Differential Revision: https://secure.phabricator.com/D11016
2014-12-19 21:36:14 +01:00
'AlmanacServiceDatasource' => 'applications/almanac/typeahead/AlmanacServiceDatasource.php',
Build AlmanacService Summary: Ref T5833. See that task for functional goals and some discussion of design. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 14:01:57 +02:00
'AlmanacServiceEditController' => 'applications/almanac/controller/AlmanacServiceEditController.php',
Move Almanac Services to EditEngine Summary: Ref T10449. This modernizes the service creation/editing flow and updates the list view code a little bit. Test Plan: - Created a service. - Edited a service. - Browsed services. - Hit policy exception for editing cluster services with no permission. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10449 Differential Revision: https://secure.phabricator.com/D15398
2016-03-05 01:08:38 +01:00
'AlmanacServiceEditEngine' => 'applications/almanac/editor/AlmanacServiceEditEngine.php',
Build AlmanacService Summary: Ref T5833. See that task for functional goals and some discussion of design. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 14:01:57 +02:00
'AlmanacServiceEditor' => 'applications/almanac/editor/AlmanacServiceEditor.php',
'AlmanacServiceListController' => 'applications/almanac/controller/AlmanacServiceListController.php',
Allow Almanac services to be searched by substring Summary: Ref T10246. Build an ngram index for Almanac services, and use it to support improved search. Test Plan: {F1121725} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10246 Differential Revision: https://secure.phabricator.com/D15321
2016-02-21 19:52:19 +01:00
'AlmanacServiceNameNgrams' => 'applications/almanac/storage/AlmanacServiceNameNgrams.php',
Build AlmanacService Summary: Ref T5833. See that task for functional goals and some discussion of design. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 14:01:57 +02:00
'AlmanacServicePHIDType' => 'applications/almanac/phid/AlmanacServicePHIDType.php',
Allow Almanac properties to be deleted, use EditEngine instead of CustomField Summary: Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings. The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff). Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks. This also makes the internal storage for properties JSON instead of raw text. Test Plan: - Created, edited and deleted properties on services, devices and bindings. - Edited and reset builtin properties on repository services. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10410 Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 15:35:30 +01:00
'AlmanacServicePropertyEditEngine' => 'applications/almanac/editor/AlmanacServicePropertyEditEngine.php',
Build AlmanacService Summary: Ref T5833. See that task for functional goals and some discussion of design. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 14:01:57 +02:00
'AlmanacServiceQuery' => 'applications/almanac/query/AlmanacServiceQuery.php',
Expose modern `*.search` Conduit endpoints in Almanac Summary: Fixes T10411. Ref T10246. There are probably still some rough edges with this, but replace the old-school endpoints with modern ones so we don't unprototype with deprecated stuff. Test Plan: - Made a bunch of calls to the new endpoints with various constraints/attachments. - Created and edited services, devices, interfaces, bindings, and properties on everything. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10246, T10411 Differential Revision: https://secure.phabricator.com/D15329
2016-02-22 21:53:40 +01:00
'AlmanacServiceSearchConduitAPIMethod' => 'applications/almanac/conduit/AlmanacServiceSearchConduitAPIMethod.php',
Build AlmanacService Summary: Ref T5833. See that task for functional goals and some discussion of design. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 14:01:57 +02:00
'AlmanacServiceSearchEngine' => 'applications/almanac/query/AlmanacServiceSearchEngine.php',
'AlmanacServiceTransaction' => 'applications/almanac/storage/AlmanacServiceTransaction.php',
'AlmanacServiceTransactionQuery' => 'applications/almanac/query/AlmanacServiceTransactionQuery.php',
Give AlmanacServices a service type Summary: Ref T5833. This allows services to be typed, to distinguish between different kinds of services. This makes a few things easier: - It's easier for clients to select the services they're interested in (see note in T5873 about Phacility). This isn't a full-power solution, but gets is some of the way there. - It's easier to set appropriate permissions around when modifications to the Phabricator cluster are allowed. These service nodes need to be demarcated as special in some way no matter what (see T6741). This also defines a new policy for users who are permitted to create services. - It's easier to browse/review/understand services. - Future diffs will allow ServiceTypes to specify more service structure (for example, default properties) to make it easier to configure services correctly. Instead of a free-for-all, you'll get a useful list of things that consumers of the service expect to read. The "custom" service type allows unstructured/freeform services to be created. Test Plan: - Created a new service (and hit error cases). - Edited an existing service. - Saw service types on list and detail views. - Poked around new permission stuff. - Ran `almanac.queryservices` with service class specification. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10995
2014-12-17 20:10:27 +01:00
'AlmanacServiceType' => 'applications/almanac/servicetype/AlmanacServiceType.php',
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
'AlmanacServiceTypeDatasource' => 'applications/almanac/typeahead/AlmanacServiceTypeDatasource.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'AlmanacServiceTypeTestCase' => 'applications/almanac/servicetype/__tests__/AlmanacServiceTypeTestCase.php',
Build AlmanacService Summary: Ref T5833. See that task for functional goals and some discussion of design. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 14:01:57 +02:00
'AlmanacServiceViewController' => 'applications/almanac/controller/AlmanacServiceViewController.php',
Allow Almanac properties to be deleted, use EditEngine instead of CustomField Summary: Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings. The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff). Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks. This also makes the internal storage for properties JSON instead of raw text. Test Plan: - Created, edited and deleted properties on services, devices and bindings. - Edited and reset builtin properties on repository services. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10410 Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 15:35:30 +01:00
'AlmanacTransaction' => 'applications/almanac/storage/AlmanacTransaction.php',
Quicksand - make notification and message counts update as you navigate around Summary: Ref T7573. Unify code to fetch these counts and do some light formatting since we're going to need to do the same thing for some conpherence-specific ajax in the durable column (See T7708). Test Plan: loaded up two tabs, one with a durable column on and one without. in the without browser, i read some messages, decrementing my unread count. when i navigated again in the durable column browser, the count updated correctly. with no notifications, commented on a task with another user to get a notification and it showed up properly. visited the task by clicking not the notification and the bubble count decremented correctly Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7573 Differential Revision: https://secure.phabricator.com/D12498
2015-04-22 00:46:36 +02:00
'AphlictDropdownDataQuery' => 'applications/aphlict/query/AphlictDropdownDataQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'Aphront304Response' => 'aphront/response/Aphront304Response.php',
'Aphront400Response' => 'aphront/response/Aphront400Response.php',
'Aphront403Response' => 'aphront/response/Aphront403Response.php',
'Aphront404Response' => 'aphront/response/Aphront404Response.php',
'AphrontAjaxResponse' => 'aphront/response/AphrontAjaxResponse.php',
Move some aprhont/ stuff around a little bit Summary: "configuration/default" moved to "default". Rename it to "configuration" and put config stuff back there. Put writeguard into writeguard/. Test Plan: tools Reviewers: vrana Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2639
2012-06-01 21:46:28 +02:00
'AphrontApplicationConfiguration' => 'aphront/configuration/AphrontApplicationConfiguration.php',
AphrontBars Summary: Aphront widgets that render the either a discrete or continuous value as a horizontal shape. Like a progress bar, or a five-star rating bar. Test Plan: `/uiexample/view/PhabricatorAphrontBarExample/` ...which shows this, amongst other things: {F33898} Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5122
2013-03-05 17:46:09 +01:00
'AphrontBarView' => 'view/widget/bars/AphrontBarView.php',
Support HTTP parameter prefilling in EditEngine forms for CustomFields Summary: Ref T9132. This allows you to prefill custom fields with `?custom.x.y=value`, for most types of custom fields. Dates (which are substantially more complicated) aren't supported. I'll just do those once the dust settles. Other types should work, I think. Test Plan: - Verified custom fields appear on "HTTP Parameters" help UI. - Used `?x=y` to prefill custom fields on edit form. - Performed various normal edits. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14634
2015-12-02 14:55:31 +01:00
'AphrontBoolHTTPParameterType' => 'aphront/httpparametertype/AphrontBoolHTTPParameterType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontCSRFException' => 'aphront/exception/AphrontCSRFException.php',
'AphrontCalendarEventView' => 'applications/calendar/view/AphrontCalendarEventView.php',
'AphrontController' => 'aphront/AphrontController.php',
Rename "IDPaged" to "CursorPaged", "executeWithPager" to "executeWith[Cursor|Offset]Pager" Summary: I'm trying to make progress on the policy/visibility stuff since it's a blocker for Wikimedia. First, I want to improve Projects so they can serve as policy groups (e.g., an object can have a visibility policy like "Visible to: members of project 'security'"). However, doing this without breaking anything or snowballing into a bigger change is a bit awkward because Projects are name-ordered and we have a Conduit API which does offset paging. Rather than breaking or rewriting this stuff, I want to just continue offset paging them for now. So I'm going to make PhabricatorPolicyQuery extend PhabricatorOffsetPagedQuery, but can't currently since the `executeWithPager` methods would clash. These methods do different things anyway and are probably better with different names. This also generally improves the names of these classes, since cursors are not necessarily IDs (in the feed case, they're "chronlogicalKeys", for example). I did leave some of the interals as "ID" since calling them "Cursor"s (e.g., `setAfterCursor()`) seemed a little wrong -- it should maybe be `setAfterCursorPosition()`. These APIs have very limited use and can easily be made more consistent later. Test Plan: Browsed around various affected tools; any issues here should throw/fail in a loud/obvious way. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3177
2012-08-07 20:54:06 +02:00
'AphrontCursorPagerView' => 'view/control/AphrontCursorPagerView.php',
Move some aprhont/ stuff around a little bit Summary: "configuration/default" moved to "default". Rename it to "configuration" and put config stuff back there. Put writeguard into writeguard/. Test Plan: tools Reviewers: vrana Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2639
2012-06-01 21:46:28 +02:00
'AphrontDefaultApplicationConfiguration' => 'aphront/configuration/AphrontDefaultApplicationConfiguration.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontDialogResponse' => 'aphront/response/AphrontDialogResponse.php',
'AphrontDialogView' => 'view/AphrontDialogView.php',
Convert Countdown to EditEngine Summary: Fixes T10684. Fixes T10520. This primarily implements a date/epoch field, and then does a bunch of standard plumbing. Test Plan: - Created countdowns. - Edited countdowns. - Used HTTP prefilling. - Created a countdown ending on "Christmas Morning", etc. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10520, T10684 Differential Revision: https://secure.phabricator.com/D15655
2016-04-07 20:06:26 +02:00
'AphrontEpochHTTPParameterType' => 'aphront/httpparametertype/AphrontEpochHTTPParameterType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontException' => 'aphront/exception/AphrontException.php',
'AphrontFileResponse' => 'aphront/response/AphrontFileResponse.php',
'AphrontFormCheckboxControl' => 'view/form/control/AphrontFormCheckboxControl.php',
'AphrontFormControl' => 'view/form/control/AphrontFormControl.php',
'AphrontFormDateControl' => 'view/form/control/AphrontFormDateControl.php',
Fix datepicker to show correct error messages on Calendar event edit view Summary: Ref T8024, Fix datepicker to show correct error messages on Calendar event edit view. Test Plan: Edit Calendar event, set blank title, and valid new end time, error page should correctly point out invalid title, but reflec the updated time. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T8024 Differential Revision: https://secure.phabricator.com/D12647
2015-05-02 01:07:57 +02:00
'AphrontFormDateControlValue' => 'view/form/control/AphrontFormDateControlValue.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontFormDividerControl' => 'view/form/control/AphrontFormDividerControl.php',
'AphrontFormFileControl' => 'view/form/control/AphrontFormFileControl.php',
Make "Create Subtask" work properly in EditEngine Summary: Ref T9908. This fixes "Create Subtask" so it works with the new stuff. Mostly straightforward. Test Plan: Created some subtasks. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9908 Differential Revision: https://secure.phabricator.com/D14706
2015-12-08 16:54:01 +01:00
'AphrontFormHandlesControl' => 'view/form/control/AphrontFormHandlesControl.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontFormMarkupControl' => 'view/form/control/AphrontFormMarkupControl.php',
'AphrontFormPasswordControl' => 'view/form/control/AphrontFormPasswordControl.php',
'AphrontFormPolicyControl' => 'view/form/control/AphrontFormPolicyControl.php',
'AphrontFormRadioButtonControl' => 'view/form/control/AphrontFormRadioButtonControl.php',
'AphrontFormRecaptchaControl' => 'view/form/control/AphrontFormRecaptchaControl.php',
'AphrontFormSelectControl' => 'view/form/control/AphrontFormSelectControl.php',
'AphrontFormStaticControl' => 'view/form/control/AphrontFormStaticControl.php',
'AphrontFormSubmitControl' => 'view/form/control/AphrontFormSubmitControl.php',
'AphrontFormTextAreaControl' => 'view/form/control/AphrontFormTextAreaControl.php',
'AphrontFormTextControl' => 'view/form/control/AphrontFormTextControl.php',
Clean up the Diffusion search UI a little bit Summary: Ref T156. @vlada recently implemented filename search in Diffusion, this cleans up the UI a little bit: - Instead of showing one search box with two different buttons, let the submit buttons appear to the right of the text boxes and separate the search modes. - Clean up the results a little bit (don't show columns which don't exist). Test Plan: {F107260} Reviewers: vlada, btrahan, chad Reviewed By: chad CC: vlada, chad, aran Maniphest Tasks: T156 Differential Revision: https://secure.phabricator.com/D8125
2014-02-01 20:48:28 +01:00
'AphrontFormTextWithSubmitControl' => 'view/form/control/AphrontFormTextWithSubmitControl.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontFormTokenizerControl' => 'view/form/control/AphrontFormTokenizerControl.php',
Add a SublimeText-style repository typeahead Summary: Allows you to quickly search for files within a repository. Roughly: - We build a big tree of everything and ship it to the client. - The client implements a bunch of Sublime-ish magic to find paths. Test Plan: {F154007} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley, zeeg Differential Revision: https://secure.phabricator.com/D9087
2014-05-13 23:08:21 +02:00
'AphrontFormTypeaheadControl' => 'view/form/control/AphrontFormTypeaheadControl.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontFormView' => 'view/form/AphrontFormView.php',
AphrontBars Summary: Aphront widgets that render the either a discrete or continuous value as a horizontal shape. Like a progress bar, or a five-star rating bar. Test Plan: `/uiexample/view/PhabricatorAphrontBarExample/` ...which shows this, amongst other things: {F33898} Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5122
2013-03-05 17:46:09 +01:00
'AphrontGlyphBarView' => 'view/widget/bars/AphrontGlyphBarView.php',
Make webpage response final
2012-11-29 08:57:13 +01:00
'AphrontHTMLResponse' => 'aphront/response/AphrontHTMLResponse.php',
Modularize complex HTTP parameter types Summary: Ref T9132. We have several places in the code that sometimes need to parse complex types. For example, we accept all of these in ApplicationSearch and now in ApplicationEditor: > /?subscribers=cat,dog > /?subscribers=PHID-USER-1111 > /?subscribers[]=cat&subscribers[]=PHID-USER-2222 ..etc. The logic to parse this stuff isn't too complex, but it isn't trivial either. Right now it lives in some odd places. Notably, `PhabricatorApplicationSearchEngine` has some weird helper methods for this stuff. Rather than give `EditEngine` the same set of weird helper methods, pull all this stuff out into "HTTPParameterTypes". Future diffs will add "Projects" and "Users" types where all the custom parsing/lookup logic can live. Then eventually the Search stuff can reuse these. Generally, this just breaks the code up into smaller pieces that have more specific responsibilities. Test Plan: {F944142} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14402
2015-11-04 14:05:10 +01:00
'AphrontHTTPParameterType' => 'aphront/httpparametertype/AphrontHTTPParameterType.php',
Add an AphrontHTTPProxyResponse Summary: Ref T7019. Adds a new response which can proxy an HTTP request and pass the result through. This is grossly inefficient for the same reasons as HTTP hosting is generally inefficient right now (T4369). This stuff is fixable but not trivial. Test Plan: Replaced home page with a proxy to `example.org`, used Charles to view headers, saw the page headers and content proxy with an X-Phabricator-Proxied header. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7019 Differential Revision: https://secure.phabricator.com/D11492
2015-01-27 23:50:52 +01:00
'AphrontHTTPProxyResponse' => 'aphront/response/AphrontHTTPProxyResponse.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontHTTPSink' => 'aphront/sink/AphrontHTTPSink.php',
'AphrontHTTPSinkTestCase' => 'aphront/sink/__tests__/AphrontHTTPSinkTestCase.php',
Support HTTP parameter prefilling in EditEngine forms for CustomFields Summary: Ref T9132. This allows you to prefill custom fields with `?custom.x.y=value`, for most types of custom fields. Dates (which are substantially more complicated) aren't supported. I'll just do those once the dust settles. Other types should work, I think. Test Plan: - Verified custom fields appear on "HTTP Parameters" help UI. - Used `?x=y` to prefill custom fields on edit form. - Performed various normal edits. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14634
2015-12-02 14:55:31 +01:00
'AphrontIntHTTPParameterType' => 'aphront/httpparametertype/AphrontIntHTTPParameterType.php',
Move qsprintf() test cases from libphutil to Phabricator Summary: Also move the other tests up so they'll trigger when this stuff is touched. Test Plan: liberate Reviewers: nh, btrahan, vrana Reviewed By: nh CC: aran Maniphest Tasks: T1283 Differential Revision: https://secure.phabricator.com/D3074
2012-07-26 21:01:47 +02:00
'AphrontIsolatedDatabaseConnectionTestCase' => 'infrastructure/storage/__tests__/AphrontIsolatedDatabaseConnectionTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontIsolatedHTTPSink' => 'aphront/sink/AphrontIsolatedHTTPSink.php',
'AphrontJSONResponse' => 'aphront/response/AphrontJSONResponse.php',
'AphrontJavelinView' => 'view/AphrontJavelinView.php',
'AphrontKeyboardShortcutsAvailableView' => 'view/widget/AphrontKeyboardShortcutsAvailableView.php',
'AphrontListFilterView' => 'view/layout/AphrontListFilterView.php',
Improve code structure of PHID fields in EditEngine Summary: Ref T9132. I had some hacks in place for dealing with Edge/Subscribers stuff. Clean that up so it's structured a little better. Test Plan: - Edited subscribers and projects. - Verified things still show up in Conduit. - Made concurrent edits (added a project in one window, removed it in another window, got a clean result with a correct merge of the two edits). Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14601
2015-11-29 22:24:47 +01:00
'AphrontListHTTPParameterType' => 'aphront/httpparametertype/AphrontListHTTPParameterType.php',
Replace AphrontUsageException with AphrontMalformedRequestException Summary: Ref T1806. Ref T7173. Context here is that I want to fix "you can not log in to this instance" being a confusing mess with an opaque error. To do this without hacks, I want to: - clean up some exception handling behavior (this diff); - modularize exception handling (next diff); - replace confusing, over-general exceptions with tailored ones in the Phacility cluster, using the new modular stuff. This cleans up an awkward "AphrontUsageException" which does some weird stuff right now. In particular, it is extensible and extended in one place in Diffusion, but that extension is meaningless. Realign this as "AphrontMalformedRequestException", which is a better description of what it is and does: raises errors before we can get as far as normal routing and site handling. Test Plan: Hit some of these exceptions, saw the expected "abandon all hope" error page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14047
2015-09-03 19:04:17 +02:00
'AphrontMalformedRequestException' => 'aphront/exception/AphrontMalformedRequestException.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontMoreView' => 'view/layout/AphrontMoreView.php',
Build an AphrontMultiColumnView, use on workboards. Summary: Abstract out the multi-column code from workboards and have it be available separately. I feel like there will be some benefit here especially for custom developers in how they present infromation (like releeph). It also scales back to tablet and mobile fairly well, so they get those things for free. Test Plan: Tested mobile, tablet and chrome layouts. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5529
2013-04-02 20:23:24 +02:00
'AphrontMultiColumnView' => 'view/layout/AphrontMultiColumnView.php',
Move qsprintf() test cases from libphutil to Phabricator Summary: Also move the other tests up so they'll trigger when this stuff is touched. Test Plan: liberate Reviewers: nh, btrahan, vrana Reviewed By: nh CC: aran Maniphest Tasks: T1283 Differential Revision: https://secure.phabricator.com/D3074
2012-07-26 21:01:47 +02:00
'AphrontMySQLDatabaseConnectionTestCase' => 'infrastructure/storage/__tests__/AphrontMySQLDatabaseConnectionTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontNullView' => 'view/AphrontNullView.php',
Modularize complex HTTP parameter types Summary: Ref T9132. We have several places in the code that sometimes need to parse complex types. For example, we accept all of these in ApplicationSearch and now in ApplicationEditor: > /?subscribers=cat,dog > /?subscribers=PHID-USER-1111 > /?subscribers[]=cat&subscribers[]=PHID-USER-2222 ..etc. The logic to parse this stuff isn't too complex, but it isn't trivial either. Right now it lives in some odd places. Notably, `PhabricatorApplicationSearchEngine` has some weird helper methods for this stuff. Rather than give `EditEngine` the same set of weird helper methods, pull all this stuff out into "HTTPParameterTypes". Future diffs will add "Projects" and "Users" types where all the custom parsing/lookup logic can live. Then eventually the Search stuff can reuse these. Generally, this just breaks the code up into smaller pieces that have more specific responsibilities. Test Plan: {F944142} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14402
2015-11-04 14:05:10 +01:00
'AphrontPHIDHTTPParameterType' => 'aphront/httpparametertype/AphrontPHIDHTTPParameterType.php',
'AphrontPHIDListHTTPParameterType' => 'aphront/httpparametertype/AphrontPHIDListHTTPParameterType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontPHPHTTPSink' => 'aphront/sink/AphrontPHPHTTPSink.php',
'AphrontPageView' => 'view/page/AphrontPageView.php',
'AphrontPlainTextResponse' => 'aphront/response/AphrontPlainTextResponse.php',
AphrontBars Summary: Aphront widgets that render the either a discrete or continuous value as a horizontal shape. Like a progress bar, or a five-star rating bar. Test Plan: `/uiexample/view/PhabricatorAphrontBarExample/` ...which shows this, amongst other things: {F33898} Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5122
2013-03-05 17:46:09 +01:00
'AphrontProgressBarView' => 'view/widget/bars/AphrontProgressBarView.php',
Provide formal Users/Projects/Mailable fields for EditEngine Summary: Ref T9132. This allows you to prefill EditEngine forms with stuff like `?subscribers=epriestley`, and we'll figure out what you mean. Test Plan: - Did `/?subscribers=...` with various values (good, bad, mis-capitalized). - Did `/?projects=...` with various values (good, bad, mis-capitalized). - Reviewed documentation. - Reviewed {nav Config > HTTP Parameter Types}. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14404
2015-11-04 19:20:38 +01:00
'AphrontProjectListHTTPParameterType' => 'aphront/httpparametertype/AphrontProjectListHTTPParameterType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontProxyResponse' => 'aphront/response/AphrontProxyResponse.php',
'AphrontRedirectResponse' => 'aphront/response/AphrontRedirectResponse.php',
Be more strict about "Location:" redirects Summary: Via HackerOne. Chrome (at least) interprets backslashes like forward slashes, so a redirect to "/\evil.com" is the same as a redirect to "//evil.com". - Reject local URIs with backslashes (we never generate these). - Fully-qualify all "Location:" redirects. - Require external redirects to be marked explicitly. Test Plan: - Expanded existing test coverage. - Verified that neither Diffusion nor Phriction can generate URIs with backslashes (they are escaped in Diffusion, and removed by slugging in Phriction). - Logged in with Facebook (OAuth2 submits a form to the external site, and isn't affected) and Twitter (OAuth1 redirects, and is affected). - Went through some local redirects (login, save-an-object). - Verified file still work. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D10291
2014-08-18 23:11:06 +02:00
'AphrontRedirectResponseTestCase' => 'aphront/response/__tests__/AphrontRedirectResponseTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontReloadResponse' => 'aphront/response/AphrontReloadResponse.php',
'AphrontRequest' => 'aphront/AphrontRequest.php',
Modularize Aphront exception handling Summary: Ref T1806. Ref T7173. Depends on D14047. Currently, all exception handling is in this big messy clump in `AphrontDefaultApplicationConfiguration`. Split it out into modular classes. This will let a future change add new classes in the Phacility cluster which intercept particular exceptions we care about and replaces the default, generic responses with more useful, tailored responses. Test Plan: {F777391} - Hit a Conduit error (made a method throw). - Hit an Ajax error (made comment preview throw). - Hit a high security error (tried to edit TOTP). - Hit a rate limiting error (added a bunch of email addresses). - Hit a policy error (tried to look at something with no permission). - Hit an arbitrary exception (made a randomc ontroller throw). Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14049
2015-09-03 19:04:42 +02:00
'AphrontRequestExceptionHandler' => 'aphront/handler/AphrontRequestExceptionHandler.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontRequestTestCase' => 'aphront/__tests__/AphrontRequestTestCase.php',
'AphrontResponse' => 'aphront/response/AphrontResponse.php',
Allow Controllers to return a wider range of "response-like" objects Summary: Ref T1806. Ref T5752. Currently, `handleRequest()` needs to return an `AphrontResponse`, but sometimes it's really convenient to return some other object, like a Dialog, and let that convert into a response elsewhere. Formalize this and clean up some of the existing hacks for it so there's less custom/magical code in Phabricator-specific classes and more general code in Aphront classes. More broadly, I want to clean up T5752 before pursuing T9132, since I'm generally happy with how `SearchEngine` works except for how it interacts with side navs / application menus. I want to fix that first so a new Editor (which will have a lot in common with SearchEngine in terms of how controllers interact with it) doesn't make the problem twice as bad. Test Plan: - Loaded a bunch of normal pages. - Loaded dialogs. - Loaded proxy responses (submitted empty comments in Maniphest). Reviewers: chad Reviewed By: chad Subscribers: joshuaspence Maniphest Tasks: T1806, T5752 Differential Revision: https://secure.phabricator.com/D14032
2015-09-02 00:52:52 +02:00
'AphrontResponseProducerInterface' => 'aphront/interface/AphrontResponseProducerInterface.php',
Push construction of routing maps into Sites Summary: This enables CORGI. Currently, `AphrontSite` subclasses can't really have their own routes. They can do this sort of hacky rewriting of paths, but that's a mess and not desirable in the long run. Instead, let subclasses build their own routing maps. This will let CORP and ORG have their own routing maps. I was able to get rid of the `PhameBlogResourcesSite` since it can really just share the standard resources site. Test Plan: - With no base URI set, and a base URI set, loaded main page and resources (from main site). - With file domain set, loaded resources from main site and file site. - Loaded a skinned blog from a domain. - Loaded a skinned blog from the main site. - Viewed "Request" tab of DarkConsole to see site/controller info. Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D14008
2015-08-31 13:01:01 +02:00
'AphrontRoutingMap' => 'aphront/site/AphrontRoutingMap.php',
'AphrontRoutingResult' => 'aphront/site/AphrontRoutingResult.php',
Modularize complex HTTP parameter types Summary: Ref T9132. We have several places in the code that sometimes need to parse complex types. For example, we accept all of these in ApplicationSearch and now in ApplicationEditor: > /?subscribers=cat,dog > /?subscribers=PHID-USER-1111 > /?subscribers[]=cat&subscribers[]=PHID-USER-2222 ..etc. The logic to parse this stuff isn't too complex, but it isn't trivial either. Right now it lives in some odd places. Notably, `PhabricatorApplicationSearchEngine` has some weird helper methods for this stuff. Rather than give `EditEngine` the same set of weird helper methods, pull all this stuff out into "HTTPParameterTypes". Future diffs will add "Projects" and "Users" types where all the custom parsing/lookup logic can live. Then eventually the Search stuff can reuse these. Generally, this just breaks the code up into smaller pieces that have more specific responsibilities. Test Plan: {F944142} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14402
2015-11-04 14:05:10 +01:00
'AphrontSelectHTTPParameterType' => 'aphront/httpparametertype/AphrontSelectHTTPParameterType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontSideNavFilterView' => 'view/layout/AphrontSideNavFilterView.php',
Modularize Aphront "sites" Summary: Fixes T5702. The path here is long and windy: - I want to move `blog.phacility.com` to the new `secure` host. - That host has `security.require-https` set, which I want to keep set (before, this was handled in a sort of hacky way at the nginx/preamble level, but I've cleaned up everything else now). - Currently, that setting forces blogs to HTTPS too, which won't work. - To let blogs be individually configurable, we need to either modularize site config or make things hackier. - Modularize rather than increasing hackiness. - Also add a little "modules" panel in Config. See T6859. This feels like a reasonable middle ground between putting this stuff in Applications and burying it in `bin/somewhere`. Test Plan: - Visited normal site. - Visited phame on-domain site. - Visited phame off-domain site. - Viewed static resources. {F561897} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D13474
2015-06-29 23:04:48 +02:00
'AphrontSite' => 'aphront/site/AphrontSite.php',
When stopping on redirect, show a full stack trace Summary: Ref T4140. Provide more debugging information so we can figure out what's going on with redirect loops. Test Plan: {F83868} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4140 Differential Revision: https://secure.phabricator.com/D7620
2013-11-21 23:38:29 +01:00
'AphrontStackTraceView' => 'view/widget/AphrontStackTraceView.php',
Improve top-level exception handling Summary: Fixes T6692. Addresses two main issues: - The write guard would sometimes not get disposed of on exception pathways, generating an unnecessary secondary error which was just a symptom of the original root error. - This was generally confusing and reduced the quality of reports we received because users would report the symptomatic error sometimes instead of the real error. - Instead, reflow the handling so that we always dispose of the write guard if we create one. - If we missed the Controller-level error page generation (normally, a nice page with full CSS, etc), we'd jump straight to Startup-level error page generation (very basic plain text). - A large class of errors occur too early or too late to be handled by Controller-level pages, but many of these errors are not fundamental, and the plain text page is excessively severe. - Provide a mid-level simple HTML error page for errors which can't get full CSS, but also aren't so fundamental that we have no recourse but plain text. Test Plan: Mid-level errors now produce an intentional-looking error page: {F259885} Verified that setup errors still render properly. @chad, feel free to tweak the exception page -- I just did a rough pass on it. Like the setup error stuff, it doesn't have Celerity, so we can't use `{$colors}` and no other CSS will be loaded. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley, chad Maniphest Tasks: T6692 Differential Revision: https://secure.phabricator.com/D11126
2015-01-02 19:49:27 +01:00
'AphrontStandaloneHTMLResponse' => 'aphront/response/AphrontStandaloneHTMLResponse.php',
Modularize complex HTTP parameter types Summary: Ref T9132. We have several places in the code that sometimes need to parse complex types. For example, we accept all of these in ApplicationSearch and now in ApplicationEditor: > /?subscribers=cat,dog > /?subscribers=PHID-USER-1111 > /?subscribers[]=cat&subscribers[]=PHID-USER-2222 ..etc. The logic to parse this stuff isn't too complex, but it isn't trivial either. Right now it lives in some odd places. Notably, `PhabricatorApplicationSearchEngine` has some weird helper methods for this stuff. Rather than give `EditEngine` the same set of weird helper methods, pull all this stuff out into "HTTPParameterTypes". Future diffs will add "Projects" and "Users" types where all the custom parsing/lookup logic can live. Then eventually the Search stuff can reuse these. Generally, this just breaks the code up into smaller pieces that have more specific responsibilities. Test Plan: {F944142} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14402
2015-11-04 14:05:10 +01:00
'AphrontStringHTTPParameterType' => 'aphront/httpparametertype/AphrontStringHTTPParameterType.php',
'AphrontStringListHTTPParameterType' => 'aphront/httpparametertype/AphrontStringListHTTPParameterType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontTableView' => 'view/control/AphrontTableView.php',
Genericize implementing views which expose common attributes Summary: Some views expose some/most/all of the basics (id, class, sigil, metadata, etc); let them extend a dedicated view to get it for free. Test Plan: Viewed home page, paste, mobile dropdown, etc. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D4440
2013-01-16 19:50:41 +01:00
'AphrontTagView' => 'view/AphrontTagView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontTokenizerTemplateView' => 'view/control/AphrontTokenizerTemplateView.php',
'AphrontTypeaheadTemplateView' => 'view/control/AphrontTypeaheadTemplateView.php',
Improve top-level exception handling Summary: Fixes T6692. Addresses two main issues: - The write guard would sometimes not get disposed of on exception pathways, generating an unnecessary secondary error which was just a symptom of the original root error. - This was generally confusing and reduced the quality of reports we received because users would report the symptomatic error sometimes instead of the real error. - Instead, reflow the handling so that we always dispose of the write guard if we create one. - If we missed the Controller-level error page generation (normally, a nice page with full CSS, etc), we'd jump straight to Startup-level error page generation (very basic plain text). - A large class of errors occur too early or too late to be handled by Controller-level pages, but many of these errors are not fundamental, and the plain text page is excessively severe. - Provide a mid-level simple HTML error page for errors which can't get full CSS, but also aren't so fundamental that we have no recourse but plain text. Test Plan: Mid-level errors now produce an intentional-looking error page: {F259885} Verified that setup errors still render properly. @chad, feel free to tweak the exception page -- I just did a rough pass on it. Like the setup error stuff, it doesn't have Celerity, so we can't use `{$colors}` and no other CSS will be loaded. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley, chad Maniphest Tasks: T6692 Differential Revision: https://secure.phabricator.com/D11126
2015-01-02 19:49:27 +01:00
'AphrontUnhandledExceptionResponse' => 'aphront/response/AphrontUnhandledExceptionResponse.php',
Provide formal Users/Projects/Mailable fields for EditEngine Summary: Ref T9132. This allows you to prefill EditEngine forms with stuff like `?subscribers=epriestley`, and we'll figure out what you mean. Test Plan: - Did `/?subscribers=...` with various values (good, bad, mis-capitalized). - Did `/?projects=...` with various values (good, bad, mis-capitalized). - Reviewed documentation. - Reviewed {nav Config > HTTP Parameter Types}. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14404
2015-11-04 19:20:38 +01:00
'AphrontUserListHTTPParameterType' => 'aphront/httpparametertype/AphrontUserListHTTPParameterType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontView' => 'view/AphrontView.php',
'AphrontWebpageResponse' => 'aphront/response/AphrontWebpageResponse.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ArcanistConduitAPIMethod' => 'applications/arcanist/conduit/ArcanistConduitAPIMethod.php',
'AuditConduitAPIMethod' => 'applications/audit/conduit/AuditConduitAPIMethod.php',
'AuditQueryConduitAPIMethod' => 'applications/audit/conduit/AuditQueryConduitAPIMethod.php',
Auth - add "manage providers" capability Summary: Ref T6947. Test Plan: toggled setting in application settings and changes stuck. set policy to admin user a only and could not add a provider as a admin user b. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6947 Differential Revision: https://secure.phabricator.com/D11356
2015-01-12 23:37:58 +01:00
'AuthManageProvidersCapability' => 'applications/auth/capability/AuthManageProvidersCapability.php',
Fix calendar display on profile. Summary: ...maybe anyway because I can't reproduce it live. This diff does two things that should help with bugginess though - uses $viewer rather than $user (...$user is who we are looking at...) *AND* upgrades a Conpherence util class to Calendar, and said util class has unit tests and came about from fixing a similar bug in Conpherence back in the day. Wrote some comments in the util class because I think it has a tendency to trip people up. These comments are not partciularly good however. Test Plan: viewed user profile - looked good. viewed conpherence - looked good. ran unit tests - they passed. (note I would also like to push this live and verify Chad's profile is fixed on secure.phabricator.com) Reviewers: epriestley, chad Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D8341
2014-02-25 22:43:31 +01:00
'CalendarTimeUtil' => 'applications/calendar/util/CalendarTimeUtil.php',
'CalendarTimeUtilTestCase' => 'applications/calendar/__tests__/CalendarTimeUtilTestCase.php',
Make Celerity a real application Summary: Ref T5702. This primarily gets URI routing out of Aphront and into an Application, for consistency. Test Plan: Loaded some pages, got static resources. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D10696
2014-10-13 20:17:23 +02:00
'CelerityAPI' => 'applications/celerity/CelerityAPI.php',
Modularize Celerity postprocessors Summary: Not sure if we want this, but it seems to work fine. Test Plan: {F516736} Reviewers: joshuaspence, chad Reviewed By: joshuaspence, chad Subscribers: joshuaspence, epriestley Differential Revision: https://secure.phabricator.com/D13363
2015-06-20 15:10:42 +02:00
'CelerityDefaultPostprocessor' => 'applications/celerity/postprocessor/CelerityDefaultPostprocessor.php',
'CelerityHighContrastPostprocessor' => 'applications/celerity/postprocessor/CelerityHighContrastPostprocessor.php',
[Redesign] Larger Font PostProcessor Summary: Ref T8099, Ref T8614. Reasonable attempt at a larger font size PostProcessor, will need additional UI cleanup (places where we fix height) but overall very decent. Test Plan: Use lots of the UI elements with new font sizes. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T8099, T8614 Differential Revision: https://secure.phabricator.com/D13457
2015-06-26 18:33:03 +02:00
'CelerityLargeFontPostprocessor' => 'applications/celerity/postprocessor/CelerityLargeFontPostprocessor.php',
Make Celerity a real application Summary: Ref T5702. This primarily gets URI routing out of Aphront and into an Application, for consistency. Test Plan: Loaded some pages, got static resources. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D10696
2014-10-13 20:17:23 +02:00
'CelerityManagementMapWorkflow' => 'applications/celerity/management/CelerityManagementMapWorkflow.php',
Generate syntax highlighting CSS from a reusable map Summary: Ref T9790. This prepares the syntax color rules to be reused in mail. This goes about halfway toward T5701 by sort-of supporting different styles but not really. Test Plan: - Ran `bin/celerity syntax` to regenerate syntax map. - Viewed some highlighted code, didn't see any differences. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9790 Differential Revision: https://secure.phabricator.com/D15846
2016-05-05 03:24:59 +02:00
'CelerityManagementSyntaxWorkflow' => 'applications/celerity/management/CelerityManagementSyntaxWorkflow.php',
Make Celerity a real application Summary: Ref T5702. This primarily gets URI routing out of Aphront and into an Application, for consistency. Test Plan: Loaded some pages, got static resources. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D10696
2014-10-13 20:17:23 +02:00
'CelerityManagementWorkflow' => 'applications/celerity/management/CelerityManagementWorkflow.php',
'CelerityPhabricatorResourceController' => 'applications/celerity/controller/CelerityPhabricatorResourceController.php',
'CelerityPhabricatorResources' => 'applications/celerity/resources/CelerityPhabricatorResources.php',
'CelerityPhysicalResources' => 'applications/celerity/resources/CelerityPhysicalResources.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'CelerityPhysicalResourcesTestCase' => 'applications/celerity/resources/__tests__/CelerityPhysicalResourcesTestCase.php',
Modularize Celerity postprocessors Summary: Not sure if we want this, but it seems to work fine. Test Plan: {F516736} Reviewers: joshuaspence, chad Reviewed By: joshuaspence, chad Subscribers: joshuaspence, epriestley Differential Revision: https://secure.phabricator.com/D13363
2015-06-20 15:10:42 +02:00
'CelerityPostprocessor' => 'applications/celerity/postprocessor/CelerityPostprocessor.php',
'CelerityPostprocessorTestCase' => 'applications/celerity/__tests__/CelerityPostprocessorTestCase.php',
Make Celerity a real application Summary: Ref T5702. This primarily gets URI routing out of Aphront and into an Application, for consistency. Test Plan: Loaded some pages, got static resources. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D10696
2014-10-13 20:17:23 +02:00
'CelerityResourceController' => 'applications/celerity/controller/CelerityResourceController.php',
'CelerityResourceGraph' => 'applications/celerity/CelerityResourceGraph.php',
'CelerityResourceMap' => 'applications/celerity/CelerityResourceMap.php',
'CelerityResourceMapGenerator' => 'applications/celerity/CelerityResourceMapGenerator.php',
'CelerityResourceTransformer' => 'applications/celerity/CelerityResourceTransformer.php',
'CelerityResourceTransformerTestCase' => 'applications/celerity/__tests__/CelerityResourceTransformerTestCase.php',
'CelerityResources' => 'applications/celerity/resources/CelerityResources.php',
'CelerityResourcesOnDisk' => 'applications/celerity/resources/CelerityResourcesOnDisk.php',
'CeleritySpriteGenerator' => 'applications/celerity/CeleritySpriteGenerator.php',
'CelerityStaticResourceResponse' => 'applications/celerity/CelerityStaticResourceResponse.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ChatLogConduitAPIMethod' => 'applications/chatlog/conduit/ChatLogConduitAPIMethod.php',
'ChatLogQueryConduitAPIMethod' => 'applications/chatlog/conduit/ChatLogQueryConduitAPIMethod.php',
'ChatLogRecordConduitAPIMethod' => 'applications/chatlog/conduit/ChatLogRecordConduitAPIMethod.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ConduitAPIMethod' => 'applications/conduit/method/ConduitAPIMethod.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'ConduitAPIMethodTestCase' => 'applications/conduit/method/__tests__/ConduitAPIMethodTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ConduitAPIRequest' => 'applications/conduit/protocol/ConduitAPIRequest.php',
'ConduitAPIResponse' => 'applications/conduit/protocol/ConduitAPIResponse.php',
Don't log Conduit 404s as errors Summary: Fixes T5695. A Conduit "method does not exist" exception is somewhat expected... there is no need to `phlog` the exception. Test Plan: Called a non-existent Conduit method. Saw no exceptions in the error logs. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5695 Differential Revision: https://secure.phabricator.com/D10042
2014-07-25 03:24:31 +02:00
'ConduitApplicationNotInstalledException' => 'applications/conduit/protocol/exception/ConduitApplicationNotInstalledException.php',
Flesh out Conduit parameter types for Owners + CustomFields Summary: Ref T9964. Fill in more parameter types and descriptions. (No date support yet since it's a bit more involved.) Test Plan: {F1024022} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14766
2015-12-13 16:29:05 +01:00
'ConduitBoolParameterType' => 'applications/conduit/parametertype/ConduitBoolParameterType.php',
Allow applications to call Conduit directly Summary: Sorry this took so long, had a bunch of stuff going on today. Separate the actual core part of making conduit calls from the controller, so the application can make conduit calls without needing to invoke HTTP or redo auth. Generally, this lets us build more parts of the application on top of Conduit, as appropriate. This diff can be simplified, but I wanted to unblock you guys first. I'll followup with a cleanup patch once I have a chance. Test Plan: Ran unit tests, ran calls from the conduit API console, and ran calls over arc. Reviewers: nodren, 20after4, btrahan, vrana Reviewed By: 20after4 CC: aran, svemir Maniphest Tasks: T945 Differential Revision: https://secure.phabricator.com/D2718
2012-06-17 17:47:09 +02:00
'ConduitCall' => 'applications/conduit/call/ConduitCall.php',
'ConduitCallTestCase' => 'applications/conduit/call/__tests__/ConduitCallTestCase.php',
Expose column positions via maniphest.edit Summary: Ref T5214. Fixes T10486. Ref T6027. This exposes the `TYPE_COLUMNS` transaction in a usable way via API, and fixes the interactions via prefilling. Test Plan: - Created tasks directly into columns via API. - Moved tasks between columns via API. - Used `?column=...` to try to create a template task with valid and bogus column PHIDs. Reviewers: chad Reviewed By: chad Subscribers: AmyLewis Maniphest Tasks: T5214, T6027, T10486 Differential Revision: https://secure.phabricator.com/D15636
2016-04-06 13:37:01 +02:00
'ConduitColumnsParameterType' => 'applications/conduit/parametertype/ConduitColumnsParameterType.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ConduitConnectConduitAPIMethod' => 'applications/conduit/method/ConduitConnectConduitAPIMethod.php',
Flesh out Conduit types for Paste search fields Summary: Ref T9964. This fills in types and descriptions for ApplicationSearch fields in Paste. Test Plan: Got this nice table now: {F1023999} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14765
2015-12-13 15:52:37 +01:00
'ConduitEpochParameterType' => 'applications/conduit/parametertype/ConduitEpochParameterType.php',
Don't log Conduit 404s as errors Summary: Fixes T5695. A Conduit "method does not exist" exception is somewhat expected... there is no need to `phlog` the exception. Test Plan: Called a non-existent Conduit method. Saw no exceptions in the error logs. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5695 Differential Revision: https://secure.phabricator.com/D10042
2014-07-25 03:24:31 +02:00
'ConduitException' => 'applications/conduit/protocol/exception/ConduitException.php',
Add conduit.getcapabilities and a modern CLI handshake workflow Summary: Ref T5955. - Add `conduit.getcapabilities` to help arc (and other clients) determine formats, protocols, etc., the server supports. - Fixes T3117. Add a more modern version of the handshake workflow that allows all generated tokens to remain valid for an hour. - Generally, add a CLI token type. This token type expires after an hour when generated, then becomes permanent if used. Test Plan: - See D10988. - Ran `conduit.getcapabilities` and inspected output. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3117, T5955 Differential Revision: https://secure.phabricator.com/D10989
2014-12-15 20:14:53 +01:00
'ConduitGetCapabilitiesConduitAPIMethod' => 'applications/conduit/method/ConduitGetCapabilitiesConduitAPIMethod.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ConduitGetCertificateConduitAPIMethod' => 'applications/conduit/method/ConduitGetCertificateConduitAPIMethod.php',
Flesh out Conduit parmeter types for maniphest.search Summary: Ref T9964. I left a couple of these unsupported for now since they're weird in some way. Test Plan: {F1024031} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14767
2015-12-13 16:43:02 +01:00
'ConduitIntListParameterType' => 'applications/conduit/parametertype/ConduitIntListParameterType.php',
Flesh out Conduit parameter types for Owners + CustomFields Summary: Ref T9964. Fill in more parameter types and descriptions. (No date support yet since it's a bit more involved.) Test Plan: {F1024022} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14766
2015-12-13 16:29:05 +01:00
'ConduitIntParameterType' => 'applications/conduit/parametertype/ConduitIntParameterType.php',
Add basic typechecking support to Conduit Summary: Ref T9964. I want to show users what we're expecting in "constraints", and let constraints like "authors=epriestley" work to make things easier. I'm generally very happy with the "HTTPParameterType" stuff from EditEngine, so add a parallel set of "ConduitParameterType" classes. These are a little simpler than the HTTP ones, but have a little more validation logic. Test Plan: This is really just a proof of concept; some of these fields are now filled in: {F1023845} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14763
2015-12-13 12:53:15 +01:00
'ConduitListParameterType' => 'applications/conduit/parametertype/ConduitListParameterType.php',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'ConduitLogGarbageCollector' => 'applications/conduit/garbagecollector/ConduitLogGarbageCollector.php',
Fix string construction in Conduit exceptions Summary: Fixes T5838. - We currently try to use a `ConduitAPIMethod` object as a string. - We then pass that string to the parent's `__construct()` method as `$message`. Test Plan: Uninstalled Maniphest, then tried to execute `maniphest.createtask`. Got a useful exception message instead of an error during message construction. Reviewers: joshuaspence, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5838 Differential Revision: https://secure.phabricator.com/D10211
2014-08-11 21:08:06 +02:00
'ConduitMethodDoesNotExistException' => 'applications/conduit/protocol/exception/ConduitMethodDoesNotExistException.php',
Don't log Conduit 404s as errors Summary: Fixes T5695. A Conduit "method does not exist" exception is somewhat expected... there is no need to `phlog` the exception. Test Plan: Called a non-existent Conduit method. Saw no exceptions in the error logs. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5695 Differential Revision: https://secure.phabricator.com/D10042
2014-07-25 03:24:31 +02:00
'ConduitMethodNotFoundException' => 'applications/conduit/protocol/exception/ConduitMethodNotFoundException.php',
Flesh out Conduit types for Paste search fields Summary: Ref T9964. This fills in types and descriptions for ApplicationSearch fields in Paste. Test Plan: Got this nice table now: {F1023999} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14765
2015-12-13 15:52:37 +01:00
'ConduitPHIDListParameterType' => 'applications/conduit/parametertype/ConduitPHIDListParameterType.php',
Improve Conduit type handling for `*.edit` endpoints Summary: Ref T9964. Three goals here: - Make it easier to supply Conduit documentation. - Make automatic documentation for `*.edit` endpoints more complete, particularly for custom fields. - Allow type resolution via Conduit types, so you can pass `["alincoln"]` to "subscribers" instead of needing to use PHIDs. Test Plan: - Viewed and used all search and edit endpoints, including custom fields. - Used parameter type resolution to set subscribers to user "dog" instead of "PHID-USER-whatever". - Viewed HTTP parameter documentation. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14796
2015-12-16 14:09:21 +01:00
'ConduitPHIDParameterType' => 'applications/conduit/parametertype/ConduitPHIDParameterType.php',
Add basic typechecking support to Conduit Summary: Ref T9964. I want to show users what we're expecting in "constraints", and let constraints like "authors=epriestley" work to make things easier. I'm generally very happy with the "HTTPParameterType" stuff from EditEngine, so add a parallel set of "ConduitParameterType" classes. These are a little simpler than the HTTP ones, but have a little more validation logic. Test Plan: This is really just a proof of concept; some of these fields are now filled in: {F1023845} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14763
2015-12-13 12:53:15 +01:00
'ConduitParameterType' => 'applications/conduit/parametertype/ConduitParameterType.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ConduitPingConduitAPIMethod' => 'applications/conduit/method/ConduitPingConduitAPIMethod.php',
Support enabling a formal points field in Maniphest Summary: Ref T4427. - New config option for labels, enabling, etc., but no UI/niceness yet. - When enabled, add a field. - Allow nonnegative values, including fractional values. - EditEngine is nice and Conduit / actions basically just work with a tiny bit of extra support code. Test Plan: - Edited points via "Edit". - Edited points via Conduit. - Edited points via stacked actions. - Tried to set "zebra" points. - Tried to set -1 points. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4427 Differential Revision: https://secure.phabricator.com/D15220
2016-02-09 00:24:52 +01:00
'ConduitPointsParameterType' => 'applications/conduit/parametertype/ConduitPointsParameterType.php',
Flesh out Conduit types for Paste search fields Summary: Ref T9964. This fills in types and descriptions for ApplicationSearch fields in Paste. Test Plan: Got this nice table now: {F1023999} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14765
2015-12-13 15:52:37 +01:00
'ConduitProjectListParameterType' => 'applications/conduit/parametertype/ConduitProjectListParameterType.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ConduitQueryConduitAPIMethod' => 'applications/conduit/method/ConduitQueryConduitAPIMethod.php',
Implement a rough initial version of ApplicationSearch-driven Conduit read endpoints Summary: Ref T9964. See that task for some context and discussion. Ref T7715, which has the bigger picture here. Basically, I want Conduit read endpoints to be full-power, ApplicationSearch-driven endpoints, so that applications can: - Write one EditEngine and get web + conduit writes for free. - Write one SearchEngine and get web + conduit reads for free. I previously made some steps toward this, but this puts more of the structure in place. Test Plan: Viewed API console endpoint and read 20 pages of docs: {F1021961} Made various calls: with query keys, constraints, pagination, and limits. Viewed new {nav Config > Modules} page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7715, T9964 Differential Revision: https://secure.phabricator.com/D14743
2015-12-11 17:45:56 +01:00
'ConduitResultSearchEngineExtension' => 'applications/conduit/query/ConduitResultSearchEngineExtension.php',
Implement SSHD glue and Conduit SSH endpoint Summary: - Build "sshd-auth" (for authentication) and "sshd-exec" (for command execution) binaries. These are callable by "sshd-vcs", located [[https://github.com/epriestley/sshd-vcs | in my account on GitHub]]. They are based on precursors [[https://github.com/epriestley/sshd-vcs-glue | here on GitHub]] which I deployed for TenXer about a year ago, so I have some confidence they at least basically work. - The problem this solves is that normally every user would need an account on a machine to connect to it, and/or their public keys would all need to be listed in `~/.authorized_keys`. This is a big pain in most installs. Software like Gitosis/Gitolite solve this problem by giving you an easy way to add public keys to `~/.authorized_keys`, but this is pretty gross. - Roughly, instead of looking in `~/.authorized_keys` when a user connects, the patched sshd instead runs `echo <public key> | sshd-auth`. The `sshd-auth` script looks up the public key and authorizes the matching user, if they exist. It also forces sshd to run `sshd-exec` instead of a normal shell. - `sshd-exec` receives the authenticated user and any command which was passed to ssh (like `git receive-pack`) and can route them appropriately. - Overall, this permits a single account to be set up on a server which all Phabricator users can connect to without any extra work, and which can safely execute commands and apply appropriate permissions, and disable users when they are disabled in Phabricator and all that stuff. - Build out "sshd-exec" to do more thorough checks and setup, and delegate command execution to Workflows (they now exist, and did not when I originally built this stuff). - Convert @btrahan's conduit API script into a workflow and slightly simplify it (ConduitCall did not exist at the time it was written). The next steps here on the Repository side are to implement Workflows for Git, SVN and HG wire protocols. These will mostly just proxy the protocols, but also need to enforce permissions. So the approach will basically be: - Implement workflows for stuff like `git receive-pack`. - These workflows will implement enough of the underlying protocol to determine what resource the user is trying to access, and whether they want to read or write it. - They'll then do a permissons check, and kick the user out if they don't have permission to do whatever they are trying to do. - If the user does have permission, we just proxy the rest of the transaction. Next steps on the Conduit side are more simple: - Make ConduitClient understand "ssh://" URLs. Test Plan: Ran `sshd-exec --phabricator-ssh-user epriestley conduit differential.query`, etc. This will get a more comprehensive test once I set up sshd-vcs. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T550 Differential Revision: https://secure.phabricator.com/D4229
2012-12-19 20:08:07 +01:00
'ConduitSSHWorkflow' => 'applications/conduit/ssh/ConduitSSHWorkflow.php',
Add basic typechecking support to Conduit Summary: Ref T9964. I want to show users what we're expecting in "constraints", and let constraints like "authors=epriestley" work to make things easier. I'm generally very happy with the "HTTPParameterType" stuff from EditEngine, so add a parallel set of "ConduitParameterType" classes. These are a little simpler than the HTTP ones, but have a little more validation logic. Test Plan: This is really just a proof of concept; some of these fields are now filled in: {F1023845} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14763
2015-12-13 12:53:15 +01:00
'ConduitStringListParameterType' => 'applications/conduit/parametertype/ConduitStringListParameterType.php',
Flesh out Conduit parameter types for Owners + CustomFields Summary: Ref T9964. Fill in more parameter types and descriptions. (No date support yet since it's a bit more involved.) Test Plan: {F1024022} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14766
2015-12-13 16:29:05 +01:00
'ConduitStringParameterType' => 'applications/conduit/parametertype/ConduitStringParameterType.php',
Add Conduit Tokens to make authentication in Conduit somewhat more sane Summary: Ref T5955. Summary of intended changes: **Improve Granularity of Authorization**: Currently, users have one Conduit Certificate. This isn't very flexible, and means that you can't ever generate an API token with limited permissions or IP block controls (see T6706). This moves toward a world where you can generate multiple tokens, revoke them individually, and assign disparate privileges to them. **Standardize Token Management**: This moves Conduit to work the same way that sessions, OAuth authorizations, and temporary tokens already work, instead of being this crazy bizarre mess. **Make Authentication Faster**: Authentication currently requires a handshake (conduit.connect) to establish a session, like the web UI. This is unnecessary from a security point of view and puts an extra round trip in front of all Conduit activity. Essentially no other API anywhere works like this. **Make Authentication Simpler**: The handshake is complex, and involves deriving hashes. The session is also complex, and creates issues like T4377. Handshake and session management require different inputs. **Make Token Management Simpler**: The certificate is this huge long thing right now, which is not necessary from a security perspective. There are separate Arcanist handshake tokens, but they have a different set of issues. We can move forward to a token management world where neither of these problems exist. **Lower Protocol Barrier**: The simplest possible API client is very complex right now. It should be `curl`. Simplifying authentication is a necessary step toward this. **Unblock T2783**: T2783 is blocked on nodes in the cluster making authenticated API calls to other nodes. This provides a simpler way forward than the handshake mess (or enormous-hack-mess) which would currently be required. Test Plan: - Generated tokens. - Generated tokens for a bot account. - Terminated tokens (and for a bot account). - Terminated all tokens (and for a bot account). - Ran GC and saw it reap all the expired tokens. NOTE: These tokens can not actually be used to authenticate yet! {F249658} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5955 Differential Revision: https://secure.phabricator.com/D10985
2014-12-15 20:14:23 +01:00
'ConduitTokenGarbageCollector' => 'applications/conduit/garbagecollector/ConduitTokenGarbageCollector.php',
Add basic typechecking support to Conduit Summary: Ref T9964. I want to show users what we're expecting in "constraints", and let constraints like "authors=epriestley" work to make things easier. I'm generally very happy with the "HTTPParameterType" stuff from EditEngine, so add a parallel set of "ConduitParameterType" classes. These are a little simpler than the HTTP ones, but have a little more validation logic. Test Plan: This is really just a proof of concept; some of these fields are now filled in: {F1023845} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14763
2015-12-13 12:53:15 +01:00
'ConduitUserListParameterType' => 'applications/conduit/parametertype/ConduitUserListParameterType.php',
Improve behavior of "owner" transaction in "maniphest.edit" endpoint Summary: Fixes T10117. - I accidentally broke setting `null` to unassign tasks at some point when I added richer validation. - Raise a better error if the user passes junk. Test Plan: - Unassigned a task via API and web UI. - Reassigned a task via API and web UI. - Tried to do an invalid assign via API, got a sensible error. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10117 Differential Revision: https://secure.phabricator.com/D14992
2016-01-11 12:24:03 +01:00
'ConduitUserParameterType' => 'applications/conduit/parametertype/ConduitUserParameterType.php',
Improve Conduit type handling for `*.edit` endpoints Summary: Ref T9964. Three goals here: - Make it easier to supply Conduit documentation. - Make automatic documentation for `*.edit` endpoints more complete, particularly for custom fields. - Allow type resolution via Conduit types, so you can pass `["alincoln"]` to "subscribers" instead of needing to use PHIDs. Test Plan: - Viewed and used all search and edit endpoints, including custom fields. - Used parameter type resolution to set subscribers to user "dog" instead of "PHID-USER-whatever". - Viewed HTTP parameter documentation. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14796
2015-12-16 14:09:21 +01:00
'ConduitWildParameterType' => 'applications/conduit/parametertype/ConduitWildParameterType.php',
Conpherence - make the durable column kind of work and stuff Summary: Ref T7014. This hooks up the durable column such that when you open it up it loads your most recent Conpherence. You can then switch amongst the various widgets and stuff and everything works nicely. Except... - scroll bar does not work - also doesn't work at HEAD when I add a ton of text to the UI with no changes? (wrapped $copy in array_fill(0, 1000, $copy)) - "widget selector" does not collapse when you select something else - this part wasn't really specified so I used the aphlict dropdown stuff. didn't want to keep working on that if this was the wrong UI choice - can not edit title - do we still want that to be done by clicking on the title, which pops a dialogue? - can not add participants or calendar events - what should this UI be? maybe just a button on the top for "participants" and a button on the bottom for calendar? both on top? - this is not pixel perfect to the mock or two I've seen around. Aside from generally being bad at that, I definitely didn't get the name + timestamps formatting correctly, because the standard DOM of that has timestamp FIRST which appears second due to a "float right". Seemed like a lot of special-casing for what might not even be that important in the UI so I punted. (And again, there's likely many unknown ways in which this isn't pixel perfect) There's also code quality issues - `ConpherenceWidgetConfigConstants` is hopefully temporary or at least gets more sleek as we keep progressing here - copied some CSS from main Conpherence app - DOM structure is pretty different - there's some minor CSS tweaks too given the different width (not to mention the DOM structure being different) - copied some JS from behavior-pontificate.js to sync threads relative to aphlict updates - JS in general is like a better version of existing JS; these should collapse I'd hope? - maybe the aphlict-behavior-dropdown change was badsauce? ...but all that said, this definitely feels really nice and I feel like adding stuff is going to be really easy compared to how normal Conpherence is. Also includes a bonus bug fix - we now correctly update participation. The user would encounter this issue if they were in a conpherence that got some updates and then they went to a different page; they would have unread status for the messages that were ajax'd in. This patch fixes that by making sure we mark participation up to date with the proper transaction in all cases. Test Plan: hit "\" to invoke the column and saw nice loading UI and my latest conpherence load. sent messages and verified they received A-OK by looking in DOM console. toggled various widges and verified they rendered correctly. opened up a second browser with a second user on the thread, sent a message, and it was received in a nice asynchronous fashion Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7014 Differential Revision: https://secure.phabricator.com/D11968
2015-03-05 19:33:39 +01:00
'ConpherenceColumnViewController' => 'applications/conpherence/controller/ConpherenceColumnViewController.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ConpherenceConduitAPIMethod' => 'applications/conpherence/conduit/ConpherenceConduitAPIMethod.php',
Conpherence - reply handler integration Summary: Added a reply handler. A few problems -- first, I can't seem to get this to actually send me email so I haven't been able to reply (which I would have done by generating a reply, then copying the raw email into scripts/mail_handler.php). Second, the subject is often terrible on these emails -- unless the conpherence is named its something gross like "E4:" Third, on create I am noticing an error on array_combine() which I think is related to the need to write array_combine_not_broken or what have you I saw go by... (PhabricatorTransactionEditor does array_combine(xaction->getOldValue(), xaction->getOldValue()) and complains that the arrays are empty) Test Plan: noted that /mail/ said mails were being sent Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2399 Differential Revision: https://secure.phabricator.com/D4656
2013-01-26 01:03:54 +01:00
'ConpherenceConfigOptions' => 'applications/conpherence/config/ConpherenceConfigOptions.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceConstants' => 'applications/conpherence/constants/ConpherenceConstants.php',
'ConpherenceController' => 'applications/conpherence/controller/ConpherenceController.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ConpherenceCreateThreadConduitAPIMethod' => 'applications/conpherence/conduit/ConpherenceCreateThreadConduitAPIMethod.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceDAO' => 'applications/conpherence/storage/ConpherenceDAO.php',
Shrink side-nav on home when durable column is open Summary: This still needs some fine tuning, but wanted to get opinions. Using it on a laptop feels pretty good. This also moves `durable-column.css` into its own file since it'll likely continue to grow. Minor CSS tweaks to the near perfect rendition of durable column from pixel based mockups. Test Plan: Press \ on my laptop. Having issues with Chrome however, but FF and Safari work as expected. {F322506} Reviewers: epriestley, btrahan Reviewed By: btrahan Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11901
2015-02-27 20:38:33 +01:00
'ConpherenceDurableColumnView' => 'applications/conpherence/view/ConpherenceDurableColumnView.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceEditor' => 'applications/conpherence/editor/ConpherenceEditor.php',
Conpherence - add back in custom images Summary: Fixes T7254. This reverts the previous functionality, but makes pertinent updates like scaling the images to 35 x 35. Codebase had moved on quite a bit so far from a straight revert but nothing too tricky relative to the code that was here before. This does not allow for changing the images from the conpherence durable column view -- that would require some JS trickery, but also doesn't fit into the current notion of the column being "light". Can always modify this later. Test Plan: - from full conpherence, uploaded a square pic and things looked nice - from full conpherence, uploaded a rectangular pic and wasnt happy, so reinvoked edit dialog and used crop control to make it better - noted could not update picture from conpherence durable column - used different user and noted could see custom picture Reviewers: epriestley Reviewed By: epriestley Subscribers: CodeMouse92, Korvin, epriestley Maniphest Tasks: T7254 Differential Revision: https://secure.phabricator.com/D12648
2015-05-04 22:52:22 +02:00
'ConpherenceFormDragAndDropUploadControl' => 'applications/conpherence/view/ConpherenceFormDragAndDropUploadControl.php',
Build a Conpherence thread index Summary: Ref T3165. Builds a dedicated index for Conpherence to avoid scale/policy filtering concerns. - This is pretty one-off but I think it's generally OK. - There's no UI for it. - `ConpherenceFulltextQuery` is very low-level. You would need to do another query on the PHIDs it returns to actually show anything to the user. - The `previousTransactionPHID` is so you can load chat context efficiently. Specifically, if you want to show results like this: > previous line of context > **line of chat that matches the query** > next line of context ...you can read the previous lines out of `previousTransactionPHID` directly, and the next lines by issuing one query with `WHERE previousTransactionPHID IN (...)`. I'm not 100% sure this is useful, but it seemed like a reasonable thing to provide, since there's no way to query this efficiently otherwise and I figure a lot of chat might make way more sense with a couple of lines of context. Test Plan: - Indexed a thread manually (whole thing indexed). - Indexed a thread by updating it (just the new comment indexed). - Wrote a hacky test script and got reasonable-looking query results. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3165 Differential Revision: https://secure.phabricator.com/D11234
2015-01-06 19:24:30 +01:00
'ConpherenceFulltextQuery' => 'applications/conpherence/query/ConpherenceFulltextQuery.php',
Conpherence - add back in custom images Summary: Fixes T7254. This reverts the previous functionality, but makes pertinent updates like scaling the images to 35 x 35. Codebase had moved on quite a bit so far from a straight revert but nothing too tricky relative to the code that was here before. This does not allow for changing the images from the conpherence durable column view -- that would require some JS trickery, but also doesn't fit into the current notion of the column being "light". Can always modify this later. Test Plan: - from full conpherence, uploaded a square pic and things looked nice - from full conpherence, uploaded a rectangular pic and wasnt happy, so reinvoked edit dialog and used crop control to make it better - noted could not update picture from conpherence durable column - used different user and noted could see custom picture Reviewers: epriestley Reviewed By: epriestley Subscribers: CodeMouse92, Korvin, epriestley Maniphest Tasks: T7254 Differential Revision: https://secure.phabricator.com/D12648
2015-05-04 22:52:22 +02:00
'ConpherenceImageData' => 'applications/conpherence/constants/ConpherenceImageData.php',
Build a Conpherence thread index Summary: Ref T3165. Builds a dedicated index for Conpherence to avoid scale/policy filtering concerns. - This is pretty one-off but I think it's generally OK. - There's no UI for it. - `ConpherenceFulltextQuery` is very low-level. You would need to do another query on the PHIDs it returns to actually show anything to the user. - The `previousTransactionPHID` is so you can load chat context efficiently. Specifically, if you want to show results like this: > previous line of context > **line of chat that matches the query** > next line of context ...you can read the previous lines out of `previousTransactionPHID` directly, and the next lines by issuing one query with `WHERE previousTransactionPHID IN (...)`. I'm not 100% sure this is useful, but it seemed like a reasonable thing to provide, since there's no way to query this efficiently otherwise and I figure a lot of chat might make way more sense with a couple of lines of context. Test Plan: - Indexed a thread manually (whole thing indexed). - Indexed a thread by updating it (just the new comment indexed). - Wrote a hacky test script and got reasonable-looking query results. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3165 Differential Revision: https://secure.phabricator.com/D11234
2015-01-06 19:24:30 +01:00
'ConpherenceIndex' => 'applications/conpherence/storage/ConpherenceIndex.php',
Consolidate Conpherence frame rendering Summary: Conpherence frame rendering is spread out a bit across ConpherenceController, ConpherenceListController, and previously ConpherenceNewController. I want to let the Thread and Widget controllers render the frame for mobile. Ref T2421. Test Plan: Viewed conpherences, switched between conpherences. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2421 Differential Revision: https://secure.phabricator.com/D5501
2013-04-01 21:43:07 +02:00
'ConpherenceLayoutView' => 'applications/conpherence/view/ConpherenceLayoutView.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceListController' => 'applications/conpherence/controller/ConpherenceListController.php',
'ConpherenceMenuItemView' => 'applications/conpherence/view/ConpherenceMenuItemView.php',
Conpherence - add "room" search UI and create UI Summary: Ref T7584. This hits all the major bullets there. Next step on T7584 is figuring out how it integrates into the full UI and column UI. That said, this is a bit buggy feeling right now since Conpherence as is assumes you are a participant all over the place and rooms make no such assumption. I'll probably this bit up next. Test Plan: viewed /conpherence/room/ and saw stuff. viewed the "participant" query as two different users and saw different correct result sets. made a room via the button and it worked. tried to view a room I wasn't a participant in and it failed horribly, which is something to fix in a future diff created a thread via "send message" on a user profile and it worked Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7584 Differential Revision: https://secure.phabricator.com/D12113
2015-03-24 21:04:33 +01:00
'ConpherenceNewRoomController' => 'applications/conpherence/controller/ConpherenceNewRoomController.php',
Conpherence - add dropdown menu Summary: Fixes T3641. Probably needs some @chad love though on colors and what have you. Technique was to jam this into the existing notifications stuff as much as possible. I think its "okay" but if we were to add more stuff here (like a 3rd application) this could get a quality pass to consolidate even more code. Test Plan: played with it in Chrome and Safari - looks reasonable Reviewers: chad, epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3641 Differential Revision: https://secure.phabricator.com/D6708
2013-08-08 22:43:33 +02:00
'ConpherenceNotificationPanelController' => 'applications/conpherence/controller/ConpherenceNotificationPanelController.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceParticipant' => 'applications/conpherence/storage/ConpherenceParticipant.php',
Conpherence - paginate thread list Summary: this is D5750 but just the conpherence part. fixes a few random conpherence bugs / quirks as well. Also messes with ApplicationTransactionEditor to expose the xactions so Conpherence doesn't over-update participation rows. Fixes T2429. Test Plan: set LIMIT to 3. verified I could scroll down all conpherences. next, picked a conpherence "in the middle" to load. verified I could page up and down. next, picked a conpherence in the middle then had another user update that conpherence. verified as I paged up the conpherence re-loaded properly selected Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin, vrana Maniphest Tasks: T2429 Differential Revision: https://secure.phabricator.com/D5783
2013-04-26 19:30:41 +02:00
'ConpherenceParticipantCountQuery' => 'applications/conpherence/query/ConpherenceParticipantCountQuery.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceParticipantQuery' => 'applications/conpherence/query/ConpherenceParticipantQuery.php',
'ConpherenceParticipationStatus' => 'applications/conpherence/constants/ConpherenceParticipationStatus.php',
Conpherence - people widget Summary: adds ye olde people widget. Features include - handle-based display, so we get status for free. (Note less pretty than M14 would have it!) - can add a person - can remove a person - can see the people already in the conpherence Test Plan: added and removed people and noted they joined / re-added as appropriate. Tried to add someone already in the conpherence and got a "transaction has no effect" message Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2399 Differential Revision: https://secure.phabricator.com/D5466
2013-04-02 18:32:40 +02:00
'ConpherencePeopleWidgetView' => 'applications/conpherence/view/ConpherencePeopleWidgetView.php',
Conpherence - add back in custom images Summary: Fixes T7254. This reverts the previous functionality, but makes pertinent updates like scaling the images to 35 x 35. Codebase had moved on quite a bit so far from a straight revert but nothing too tricky relative to the code that was here before. This does not allow for changing the images from the conpherence durable column view -- that would require some JS trickery, but also doesn't fit into the current notion of the column being "light". Can always modify this later. Test Plan: - from full conpherence, uploaded a square pic and things looked nice - from full conpherence, uploaded a rectangular pic and wasnt happy, so reinvoked edit dialog and used crop control to make it better - noted could not update picture from conpherence durable column - used different user and noted could see custom picture Reviewers: epriestley Reviewed By: epriestley Subscribers: CodeMouse92, Korvin, epriestley Maniphest Tasks: T7254 Differential Revision: https://secure.phabricator.com/D12648
2015-05-04 22:52:22 +02:00
'ConpherencePicCropControl' => 'applications/conpherence/view/ConpherencePicCropControl.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ConpherenceQueryThreadConduitAPIMethod' => 'applications/conpherence/conduit/ConpherenceQueryThreadConduitAPIMethod.php',
'ConpherenceQueryTransactionConduitAPIMethod' => 'applications/conpherence/conduit/ConpherenceQueryTransactionConduitAPIMethod.php',
Conpherence - reply handler integration Summary: Added a reply handler. A few problems -- first, I can't seem to get this to actually send me email so I haven't been able to reply (which I would have done by generating a reply, then copying the raw email into scripts/mail_handler.php). Second, the subject is often terrible on these emails -- unless the conpherence is named its something gross like "E4:" Third, on create I am noticing an error on array_combine() which I think is related to the need to write array_combine_not_broken or what have you I saw go by... (PhabricatorTransactionEditor does array_combine(xaction->getOldValue(), xaction->getOldValue()) and complains that the arrays are empty) Test Plan: noted that /mail/ said mails were being sent Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2399 Differential Revision: https://secure.phabricator.com/D4656
2013-01-26 01:03:54 +01:00
'ConpherenceReplyHandler' => 'applications/conpherence/mail/ConpherenceReplyHandler.php',
Conpherence - add "room" search UI and create UI Summary: Ref T7584. This hits all the major bullets there. Next step on T7584 is figuring out how it integrates into the full UI and column UI. That said, this is a bit buggy feeling right now since Conpherence as is assumes you are a participant all over the place and rooms make no such assumption. I'll probably this bit up next. Test Plan: viewed /conpherence/room/ and saw stuff. viewed the "participant" query as two different users and saw different correct result sets. made a room via the button and it worked. tried to view a room I wasn't a participant in and it failed horribly, which is something to fix in a future diff created a thread via "send message" on a user profile and it worked Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7584 Differential Revision: https://secure.phabricator.com/D12113
2015-03-24 21:04:33 +01:00
'ConpherenceRoomListController' => 'applications/conpherence/controller/ConpherenceRoomListController.php',
Conpherence - Differentiate audience of Threads/Rooms with icon Summary: Fixes T7629 plus an un filed bug that's breaking creating new threads since we need to add participants EVEN EARLIER than we were doing it now that policy is actually enforced. Back to the main thrust of this, there is one UI corner case - in the main view if you go from 1:1 to 1:1:1 (i.e. add a 3rd recipient, or Nth in a row) the icon only updates on page reload. I figure this will get sorted out at a later refactor as we make the client better / share more code with durable column. One other small behavioral oddity is in the main view sometime we start loading with no conpherence. in that case, rather than show some incorrect icon, we show no icon (and "no title") and then things change at load. Seems okay-ish. Finally, @chad - the CSS is a very work-man-like "use the built in stuff you can specify from PHP" so I'm sure it needs some love. Test Plan: made all sorts of rooms and threads and liked the icons. noted smooth loading action as i switched around Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: Korvin, chad, epriestley Maniphest Tasks: T7629 Differential Revision: https://secure.phabricator.com/D12163
2015-03-26 20:24:29 +01:00
'ConpherenceRoomTestCase' => 'applications/conpherence/__tests__/ConpherenceRoomTestCase.php',
Generate expected schemata for Dashboards and Conpherence Summary: Ref T1191. - Add edge schemata generation. - Hit a couple of mostly-minor issues (T6128, T6129, T6130). Test Plan: Viewed schema in web UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10518
2014-09-18 20:15:38 +02:00
'ConpherenceSchemaSpec' => 'applications/conpherence/storage/ConpherenceSchemaSpec.php',
Conpherence - add per thread notification setting Summary: Introduces a new settings panel for Conpherence specific settings. Test Plan: started a thread with a test user, thus two participants total. Replied to conpherence, toggling notification settings in between. Verified 1 or 2 emails were sent as appropos to the current toggle. Toggled global setting and verified setting was updated in conpherences where nothing was specified. Verified setting conpherence setting overrides global setting. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2521 Differential Revision: https://secure.phabricator.com/D5391
2013-03-26 21:30:35 +01:00
'ConpherenceSettings' => 'applications/conpherence/constants/ConpherenceSettings.php',
Conpherence - Differentiate audience of Threads/Rooms with icon Summary: Fixes T7629 plus an un filed bug that's breaking creating new threads since we need to add participants EVEN EARLIER than we were doing it now that policy is actually enforced. Back to the main thrust of this, there is one UI corner case - in the main view if you go from 1:1 to 1:1:1 (i.e. add a 3rd recipient, or Nth in a row) the icon only updates on page reload. I figure this will get sorted out at a later refactor as we make the client better / share more code with durable column. One other small behavioral oddity is in the main view sometime we start loading with no conpherence. in that case, rather than show some incorrect icon, we show no icon (and "no title") and then things change at load. Seems okay-ish. Finally, @chad - the CSS is a very work-man-like "use the built in stuff you can specify from PHP" so I'm sure it needs some love. Test Plan: made all sorts of rooms and threads and liked the icons. noted smooth loading action as i switched around Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: Korvin, chad, epriestley Maniphest Tasks: T7629 Differential Revision: https://secure.phabricator.com/D12163
2015-03-26 20:24:29 +01:00
'ConpherenceTestCase' => 'applications/conpherence/__tests__/ConpherenceTestCase.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceThread' => 'applications/conpherence/storage/ConpherenceThread.php',
Lift Conpherence indexing up out of the Fulltext index Summary: Ref T9979. There are currently some hacks around Conpherence indexing: it does not really use the fulltext index, but its own specialized index. However, it's kind of hacked up so it can get reindexed by the normal indexing pipeline. Lift it up into IndexEngine, instead of FulltextEngine. Specifically, the new stuff is going to look like this: - IndexEngine: Rebuild all indexes. - ConpherenceIndexExtension: Rebuild thread indexes. - ProjectMemberIndexExtension: Rebuild project membership views. - NgramIndexExtension: Rebuild ngram indexes. - FulltextIndexExtension / FulltextEngine: Rebuild fulltext indexes, a special type of index. - FulltextCommentExtension: Rebuild comment fulltext indexes. - FulltextProjectExtension: Rebuild project fulltext indexes. - etc. Most of this is at least sort-of-in-place as of this diff, although some of the part in the middle is still pretty rough. Test Plan: - Made a unique comment in a Conpherence thread. - Used `bin/search index --force` to rebuild the index. - Searched for the comment. - Found the thread. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14841
2015-12-21 15:07:41 +01:00
'ConpherenceThreadIndexEngineExtension' => 'applications/conpherence/engineextension/ConpherenceThreadIndexEngineExtension.php',
Render Conpherence threads as a separate menu inside the layout, not a side nav Summary: Currently, the thread list is in a standard side nav, but that makes it awkward to render (rendering logic needs to live in the base controller) and gives it some bad beahviors (like autohiding on mobile). Instead, move it into its own view and make it a little more custom. Ref T2421. Test Plan: {F38098} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T2421 Differential Revision: https://secure.phabricator.com/D5504
2013-04-01 21:50:39 +02:00
'ConpherenceThreadListView' => 'applications/conpherence/view/ConpherenceThreadListView.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ConpherenceThreadMailReceiver' => 'applications/conpherence/mail/ConpherenceThreadMailReceiver.php',
Add a "Thread Members" object policy and some unit tests Summary: Ref T8488. Ref T5681. Now you can just use `id(new ConpherenceThreadMembersPolicyRule())->getObjectPolicyFullKey()` as a policy. Added tests for TaskAuthor + ThreadMembers. Test Plan: - Ran tests. - Set a thread policy to "Members of thread'. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5681, T8488 Differential Revision: https://secure.phabricator.com/D13258
2015-06-14 00:44:56 +02:00
'ConpherenceThreadMembersPolicyRule' => 'applications/conpherence/policyrule/ConpherenceThreadMembersPolicyRule.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceThreadQuery' => 'applications/conpherence/query/ConpherenceThreadQuery.php',
Conpherence - make `ZXXX` monograms a bit more useful. Summary: Ref T7756. Now viewing individual threads in Conpherence is `ZXXX` driven. Also adds remarkup support. Test Plan: clicked around on list of conpherences in full view and it worked. selected 'view in conpherence' action from column and loaded correct `ZXXX` uri. Typed `ZXXX` in Maniphest and saw it link to Conpherence room. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7756 Differential Revision: https://secure.phabricator.com/D12397
2015-04-13 21:45:55 +02:00
'ConpherenceThreadRemarkupRule' => 'applications/conpherence/remarkup/ConpherenceThreadRemarkupRule.php',
Conpherence - add "room" search UI and create UI Summary: Ref T7584. This hits all the major bullets there. Next step on T7584 is figuring out how it integrates into the full UI and column UI. That said, this is a bit buggy feeling right now since Conpherence as is assumes you are a participant all over the place and rooms make no such assumption. I'll probably this bit up next. Test Plan: viewed /conpherence/room/ and saw stuff. viewed the "participant" query as two different users and saw different correct result sets. made a room via the button and it worked. tried to view a room I wasn't a participant in and it failed horribly, which is something to fix in a future diff created a thread via "send message" on a user profile and it worked Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7584 Differential Revision: https://secure.phabricator.com/D12113
2015-03-24 21:04:33 +01:00
'ConpherenceThreadSearchEngine' => 'applications/conpherence/query/ConpherenceThreadSearchEngine.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceTransaction' => 'applications/conpherence/storage/ConpherenceTransaction.php',
'ConpherenceTransactionComment' => 'applications/conpherence/storage/ConpherenceTransactionComment.php',
'ConpherenceTransactionQuery' => 'applications/conpherence/query/ConpherenceTransactionQuery.php',
Conpherence - refactor display classes a bit Summary: D12409 made me realize this was a bit janky. `PhabricatorTransactionView` was only being used by Conpherence, so move and rename that class to `ConpherenceTransactionView`. Also, rename the existing `ConpherenceTransactionView` to `ConpherenceTransactionRenderer`, moving the actual view bits into the new `ConpherenceTransactionView`. Resulting code is a bit cleaner IMO. Diff 1 of 2 (second diff has to be written. =D). Diff 2 will take care of the CSS and possibly clean things up further. Test Plan: played around in conpherence full and conpherence column and things looked nice Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D12410
2015-04-14 21:25:35 +02:00
'ConpherenceTransactionRenderer' => 'applications/conpherence/ConpherenceTransactionRenderer.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceTransactionView' => 'applications/conpherence/view/ConpherenceTransactionView.php',
Conpherence - continue the load less quest Summary: basically makes it so we only really load what we need from the server for any particular update action. the javascript thus then has some things deleted from it. made a spot or two ready for when the pertinent UI won't be there as well. also added a feature in javascript -- updating the document title to the current conpherence title. Ref T2867 T2399 Test Plan: played with conpherence for quite a bit. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2867 Differential Revision: https://secure.phabricator.com/D5625
2013-04-10 20:37:04 +02:00
'ConpherenceUpdateActions' => 'applications/conpherence/constants/ConpherenceUpdateActions.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceUpdateController' => 'applications/conpherence/controller/ConpherenceUpdateController.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ConpherenceUpdateThreadConduitAPIMethod' => 'applications/conpherence/conduit/ConpherenceUpdateThreadConduitAPIMethod.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceViewController' => 'applications/conpherence/controller/ConpherenceViewController.php',
Conpherence - make the durable column kind of work and stuff Summary: Ref T7014. This hooks up the durable column such that when you open it up it loads your most recent Conpherence. You can then switch amongst the various widgets and stuff and everything works nicely. Except... - scroll bar does not work - also doesn't work at HEAD when I add a ton of text to the UI with no changes? (wrapped $copy in array_fill(0, 1000, $copy)) - "widget selector" does not collapse when you select something else - this part wasn't really specified so I used the aphlict dropdown stuff. didn't want to keep working on that if this was the wrong UI choice - can not edit title - do we still want that to be done by clicking on the title, which pops a dialogue? - can not add participants or calendar events - what should this UI be? maybe just a button on the top for "participants" and a button on the bottom for calendar? both on top? - this is not pixel perfect to the mock or two I've seen around. Aside from generally being bad at that, I definitely didn't get the name + timestamps formatting correctly, because the standard DOM of that has timestamp FIRST which appears second due to a "float right". Seemed like a lot of special-casing for what might not even be that important in the UI so I punted. (And again, there's likely many unknown ways in which this isn't pixel perfect) There's also code quality issues - `ConpherenceWidgetConfigConstants` is hopefully temporary or at least gets more sleek as we keep progressing here - copied some CSS from main Conpherence app - DOM structure is pretty different - there's some minor CSS tweaks too given the different width (not to mention the DOM structure being different) - copied some JS from behavior-pontificate.js to sync threads relative to aphlict updates - JS in general is like a better version of existing JS; these should collapse I'd hope? - maybe the aphlict-behavior-dropdown change was badsauce? ...but all that said, this definitely feels really nice and I feel like adding stuff is going to be really easy compared to how normal Conpherence is. Also includes a bonus bug fix - we now correctly update participation. The user would encounter this issue if they were in a conpherence that got some updates and then they went to a different page; they would have unread status for the messages that were ajax'd in. This patch fixes that by making sure we mark participation up to date with the proper transaction in all cases. Test Plan: hit "\" to invoke the column and saw nice loading UI and my latest conpherence load. sent messages and verified they received A-OK by looking in DOM console. toggled various widges and verified they rendered correctly. opened up a second browser with a second user on the thread, sent a message, and it was received in a nice asynchronous fashion Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7014 Differential Revision: https://secure.phabricator.com/D11968
2015-03-05 19:33:39 +01:00
'ConpherenceWidgetConfigConstants' => 'applications/conpherence/constants/ConpherenceWidgetConfigConstants.php',
Renders the last 100 conpherence transactions only Summary: Fixed T2428 a little bit Test Plan: On trial, only the last n transactions loaded as hardcoded in ConpherenceViewController.php. Button was rendered. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2428 Differential Revision: https://secure.phabricator.com/D4898
2013-02-15 23:01:27 +01:00
'ConpherenceWidgetController' => 'applications/conpherence/controller/ConpherenceWidgetController.php',
Conpherence - people widget Summary: adds ye olde people widget. Features include - handle-based display, so we get status for free. (Note less pretty than M14 would have it!) - can add a person - can remove a person - can see the people already in the conpherence Test Plan: added and removed people and noted they joined / re-added as appropriate. Tried to add someone already in the conpherence and got a "transaction has no effect" message Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2399 Differential Revision: https://secure.phabricator.com/D5466
2013-04-02 18:32:40 +02:00
'ConpherenceWidgetView' => 'applications/conpherence/view/ConpherenceWidgetView.php',
Move DarkConsole to an application Summary: Ref T5702. Primarily, this gets the custom DarkConsole URI routes out of the Aphront core and into an Application, like almost all other routes. Test Plan: Used DarkConsole. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D10695
2014-10-13 20:17:09 +02:00
'DarkConsoleController' => 'applications/console/controller/DarkConsoleController.php',
'DarkConsoleCore' => 'applications/console/core/DarkConsoleCore.php',
'DarkConsoleDataController' => 'applications/console/controller/DarkConsoleDataController.php',
'DarkConsoleErrorLogPlugin' => 'applications/console/plugin/DarkConsoleErrorLogPlugin.php',
'DarkConsoleErrorLogPluginAPI' => 'applications/console/plugin/errorlog/DarkConsoleErrorLogPluginAPI.php',
'DarkConsoleEventPlugin' => 'applications/console/plugin/DarkConsoleEventPlugin.php',
'DarkConsoleEventPluginAPI' => 'applications/console/plugin/event/DarkConsoleEventPluginAPI.php',
'DarkConsolePlugin' => 'applications/console/plugin/DarkConsolePlugin.php',
'DarkConsoleRequestPlugin' => 'applications/console/plugin/DarkConsoleRequestPlugin.php',
'DarkConsoleServicesPlugin' => 'applications/console/plugin/DarkConsoleServicesPlugin.php',
Add a "Startup" to DarkConsole Summary: Ref T8588. It looks like something slow is happening //before// we start DarkConsole. Add some crude reporting to try to narrow it down. Test Plan: {F743050} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8588 Differential Revision: https://secure.phabricator.com/D13956
2015-08-21 23:53:29 +02:00
'DarkConsoleStartupPlugin' => 'applications/console/plugin/DarkConsoleStartupPlugin.php',
Move DarkConsole to an application Summary: Ref T5702. Primarily, this gets the custom DarkConsole URI routes out of the Aphront core and into an Application, like almost all other routes. Test Plan: Used DarkConsole. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D10695
2014-10-13 20:17:09 +02:00
'DarkConsoleXHProfPlugin' => 'applications/console/plugin/DarkConsoleXHProfPlugin.php',
'DarkConsoleXHProfPluginAPI' => 'applications/console/plugin/xhprof/DarkConsoleXHProfPluginAPI.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'DatabaseConfigurationProvider' => 'infrastructure/storage/configuration/DatabaseConfigurationProvider.php',
'DefaultDatabaseConfigurationProvider' => 'infrastructure/storage/configuration/DefaultDatabaseConfigurationProvider.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialAction' => 'applications/differential/constants/DifferentialAction.php',
Move Differential to modular mail commands Summary: Ref T7199. Convert Differential to modern modular commands. Test Plan: Used `bin/mail receive-test` to send command and comment mail to Differential. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12239
2015-04-01 17:40:12 +02:00
'DifferentialActionEmailCommand' => 'applications/differential/command/DifferentialActionEmailCommand.php',
Make event-triggered actions more aware of application access Summary: Fixes T3675. - Maniphest had a couple of old non-event listeners; move them to events. - Make most of the similar listeners a little more similar. - Add checks for access to the application. Test Plan: - Viewed profile, project, task, revision. - Clicked all the actions. - Blocked access to various applications and verified the actions vanished. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7365
2013-10-22 02:00:50 +02:00
'DifferentialActionMenuEventListener' => 'applications/differential/event/DifferentialActionMenuEventListener.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialAddCommentView' => 'applications/differential/view/DifferentialAddCommentView.php',
Implement rough content-aware inline adjustment rules for ghosts Summary: Ref T7447. Fixes T7600. This likely needs significant adjustment, but implements content-aware comment porting for line changes. Specifically, this moves lines around to adjust their position considering added and removed lines between the diffs and across rebases. It does not try to do any actual content (line against line) matching. Test Plan: - Unit tests. - Poking around in the web UI seems to generate mostly reasonable-ish results? - This may be a huge step backward in some cases that I just haven't hit. Reviewers: btrahan Reviewed By: btrahan Subscribers: yelirekim, epriestley Maniphest Tasks: T7600, T7447 Differential Revision: https://secure.phabricator.com/D12741
2015-05-07 23:09:41 +02:00
'DifferentialAdjustmentMapTestCase' => 'applications/differential/storage/__tests__/DifferentialAdjustmentMapTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialAffectedPath' => 'applications/differential/storage/DifferentialAffectedPath.php',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialApplyPatchField' => 'applications/differential/customfield/DifferentialApplyPatchField.php',
'DifferentialAsanaRepresentationField' => 'applications/differential/customfield/DifferentialAsanaRepresentationField.php',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialAuditorsField' => 'applications/differential/customfield/DifferentialAuditorsField.php',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialAuthorField' => 'applications/differential/customfield/DifferentialAuthorField.php',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialBlameRevisionField' => 'applications/differential/customfield/DifferentialBlameRevisionField.php',
Modularize the Diffusion/Differential "Block" Herald actions Also removes HeraldCustomAction. This completes action modularization. Ref T8726.
2015-08-03 21:54:40 +02:00
'DifferentialBlockHeraldAction' => 'applications/differential/herald/DifferentialBlockHeraldAction.php',
Add Branch and Arcanist Project CustomFields Summary: Ref T2222. These are pretty straightforward. For these fields and a few others, the existing code shows the value for the "current/manual" diff (i.e., the diff selected in the diff selection table), not the "active" diff (i.e., the most recent diff attached to the revision). I'm going to drop that for now (always showing the most recent diff instead) and then reevaluate it once we're switched over. In 95% of cases these are the same, anyway. Test Plan: Looked at fields; this diff changes nothing on its own. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8359
2014-02-27 20:05:48 +01:00
'DifferentialBranchField' => 'applications/differential/customfield/DifferentialBranchField.php',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'DifferentialChangeHeraldFieldGroup' => 'applications/differential/herald/DifferentialChangeHeraldFieldGroup.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialChangeType' => 'applications/differential/constants/DifferentialChangeType.php',
Restore "Branch" and "changes since last update" fields to Differential mail Summary: Ref T418. Fixes T4642. The "changes since last update" and "branch" fields got dropped; restore them in a general, field-driven way. Test Plan: - Created a revision, got relevant sections in mail. - Commented on a revision, got relevant sections in mail. - Updated a revision, got relevant sections in mail. Reviewers: btrahan Reviewed By: btrahan Subscribers: spicyj, epriestley Maniphest Tasks: T418, T4642 Differential Revision: https://secure.phabricator.com/D8657
2014-04-01 17:23:34 +02:00
'DifferentialChangesSinceLastUpdateField' => 'applications/differential/customfield/DifferentialChangesSinceLastUpdateField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialChangeset' => 'applications/differential/storage/DifferentialChangeset.php',
'DifferentialChangesetDetailView' => 'applications/differential/view/DifferentialChangesetDetailView.php',
upgrade diffusion to use modern header UI and fix a few quirks Summary: upgrades are CrumbsView, HeaderView, PropertyListView, and ActionListView. I had to modify CrumbsView stuff a bit to handle the "advanced" diffusion crumbs. Quirks fixed include making file tree view show up in diffusion, the page not have extra space when the file tree is hidden, links no longer breaking once you visit files (since without the change the files always got "/" appended and thus 404'd), and a differential quirk where it read "next step:" and that colon is a no no, Test Plan: played around in diffusion and differential Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2048, T2178 Differential Revision: https://secure.phabricator.com/D4169
2012-12-13 02:50:42 +01:00
'DifferentialChangesetFileTreeSideNavBuilder' => 'applications/differential/view/DifferentialChangesetFileTreeSideNavBuilder.php',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialChangesetHTMLRenderer' => 'applications/differential/render/DifferentialChangesetHTMLRenderer.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialChangesetListView' => 'applications/differential/view/DifferentialChangesetListView.php',
Highlight inline diff context in HTML mail Summary: Ref T10694. Ref T9790. When generating inline diff context, highlight it and then mangle the highlighted output into `style="..."` so it works in HTML. Also try to tighten up some spacing/formatting stuff. Test Plan: Got some output in this vein: {F1259937} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9790, T10694 Differential Revision: https://secure.phabricator.com/D15852
2016-05-05 18:46:44 +02:00
'DifferentialChangesetOneUpMailRenderer' => 'applications/differential/render/DifferentialChangesetOneUpMailRenderer.php',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialChangesetOneUpRenderer' => 'applications/differential/render/DifferentialChangesetOneUpRenderer.php',
'DifferentialChangesetOneUpTestRenderer' => 'applications/differential/render/DifferentialChangesetOneUpTestRenderer.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialChangesetParser' => 'applications/differential/parser/DifferentialChangesetParser.php',
Unhighlight lines modified in rebase Summary: Diff of diffs display changes between new versions of file. This is bad after rebase because there can be many unrelated changes so it is hard to spot the real change. This diff unhighlights the lines that were added or removed in rebase. The changes are still visible (they can be sometimes relevant) but very subtle. Test Plan: # Add, change and delete line. Display diff. # Add and change some lines in parent. Rebase. Display diff. Display diff of diff. # Change and add some lines. Display diff. Display diff to first diff. Display diff to second diff. Reviewers: epriestley, jungejason Reviewed By: jungejason CC: jungejason, aran, Korvin Differential Revision: https://secure.phabricator.com/D2761
2012-06-15 09:53:26 +02:00
'DifferentialChangesetParserTestCase' => 'applications/differential/parser/__tests__/DifferentialChangesetParserTestCase.php',
Introduce DifferentialChangesetQuery and remove loadHunks() Summary: Ref T4045. Ref T5179. This removes all non-Query hunk loads. Test Plan: - Viewed revisions. - Viewed standalone changesets. - Viewed raw old/new files. - Viewed vs diffs. - Enabled inline comments in mail and sent some transactions with inlines. - Called `differential.getrawdiff`. - Grepped for `loadHunks()`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4045, T5179 Differential Revision: https://secure.phabricator.com/D9289
2014-05-25 17:59:31 +02:00
'DifferentialChangesetQuery' => 'applications/differential/query/DifferentialChangesetQuery.php',
Refactor DifferentialChangesetParser -- pass 1 of N Summary: basically did my darnedest to pull out a TwoUp rendering view. Made a base class for the rendering views with "old" and "new" terminology rather than "left" and "right. Future revisions will finish cleaning up the terminology within the DifferentialChangesetParser itself and more of the ideas within T2009. Test Plan: been playing with differential all day Reviewers: epriestley Reviewed By: epriestley CC: vrana, chad, aran, Korvin Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4117
2012-12-08 01:19:57 +01:00
'DifferentialChangesetRenderer' => 'applications/differential/render/DifferentialChangesetRenderer.php',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialChangesetTestRenderer' => 'applications/differential/render/DifferentialChangesetTestRenderer.php',
Refactor DifferentialChangesetParser -- pass 1 of N Summary: basically did my darnedest to pull out a TwoUp rendering view. Made a base class for the rendering views with "old" and "new" terminology rather than "left" and "right. Future revisions will finish cleaning up the terminology within the DifferentialChangesetParser itself and more of the ideas within T2009. Test Plan: been playing with differential all day Reviewers: epriestley Reviewed By: epriestley CC: vrana, chad, aran, Korvin Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4117
2012-12-08 01:19:57 +01:00
'DifferentialChangesetTwoUpRenderer' => 'applications/differential/render/DifferentialChangesetTwoUpRenderer.php',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialChangesetTwoUpTestRenderer' => 'applications/differential/render/DifferentialChangesetTwoUpTestRenderer.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialChangesetViewController' => 'applications/differential/controller/DifferentialChangesetViewController.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DifferentialCloseConduitAPIMethod' => 'applications/differential/conduit/DifferentialCloseConduitAPIMethod.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialCommentPreviewController' => 'applications/differential/controller/DifferentialCommentPreviewController.php',
'DifferentialCommentSaveController' => 'applications/differential/controller/DifferentialCommentSaveController.php',
Move Differential commit message parsing to a separate, tested class Summary: Ref T2222. We have a hunk of logic that purely does text parsing here; separate it and get coverage on it. Test Plan: - Ran new unit tests. - Used `differential.parsecommitmessage`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8444
2014-03-08 02:44:35 +01:00
'DifferentialCommitMessageParser' => 'applications/differential/parser/DifferentialCommitMessageParser.php',
'DifferentialCommitMessageParserTestCase' => 'applications/differential/parser/__tests__/DifferentialCommitMessageParserTestCase.php',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialCommitsField' => 'applications/differential/customfield/DifferentialCommitsField.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DifferentialConduitAPIMethod' => 'applications/differential/conduit/DifferentialConduitAPIMethod.php',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialConflictsField' => 'applications/differential/customfield/DifferentialConflictsField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialController' => 'applications/differential/controller/DifferentialController.php',
Implement new-style "Summary" field Summary: Ref T3886. - Adds "Summary" field. - Adds "CoreField" for fields stored on the actual object, to reduce code duplication a bit for the main fields. Test Plan: {F115902} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8283
2014-02-21 20:52:52 +01:00
'DifferentialCoreCustomField' => 'applications/differential/customfield/DifferentialCoreCustomField.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DifferentialCreateCommentConduitAPIMethod' => 'applications/differential/conduit/DifferentialCreateCommentConduitAPIMethod.php',
'DifferentialCreateDiffConduitAPIMethod' => 'applications/differential/conduit/DifferentialCreateDiffConduitAPIMethod.php',
'DifferentialCreateInlineConduitAPIMethod' => 'applications/differential/conduit/DifferentialCreateInlineConduitAPIMethod.php',
Differential - add ability to setup "create" addresses for revisions Summary: Fixes T1476. The body of the email should be just the output of some diff command. Test Plan: git diff master > text.txt; ./bin/mail receive-test --to <configured-diff-create-address> < text.txt; a diff was successfully created...! email generated had a working link to the diff. ./bin/mail receive-test --to <configured-diff-create-address> < README.md; a diff was not created as expected...! email generated had a sensical error message, telling me that the mail body should have been generated via a diff command Reviewers: epriestley Reviewed By: epriestley Subscribers: johnny-bit, Korvin, epriestley Maniphest Tasks: T1476 Differential Revision: https://secure.phabricator.com/D11574
2015-01-30 19:31:39 +01:00
'DifferentialCreateMailReceiver' => 'applications/differential/mail/DifferentialCreateMailReceiver.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DifferentialCreateRawDiffConduitAPIMethod' => 'applications/differential/conduit/DifferentialCreateRawDiffConduitAPIMethod.php',
'DifferentialCreateRevisionConduitAPIMethod' => 'applications/differential/conduit/DifferentialCreateRevisionConduitAPIMethod.php',
Implement "Pro" version of revision editor, with one field Summary: Ref T3886. I spent a few hours trying to make `DifferentialFieldSpecification` extend `PhabricatorCustomField` so I could be more blunt in my approach here and just swap the whole thing over in one go (more or less like I did with Maniphest) but we have a ton of custom fields and things felt really shaky and the change was enormous and hard to keep track of. Instead, I'm going to do this more gradually and go field-by-field. This implements a CustomField version of the "Title" field. (There are no links to this in the UI.) Test Plan: {F115353} {F115354} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8276
2014-02-19 01:32:55 +01:00
'DifferentialCustomField' => 'applications/differential/customfield/DifferentialCustomField.php',
Clean up various pieces of dead/obsolete Differential code Summary: Ref T2222. - Removes `DifferentialTasksAttacher`, which has had no callsites for a very long time. - Moves `differential.getrevisioncomments` off `DifferentialCommentQuery`. - Moves Releeph churn field off `DifferentialCommentQuery`. - Removes dead code in `DifferentialRevisionViewController`. - Removes `DifferentialException` (no references). - Removes `DifferentialRevision->loadComments()` (no callsites). - Removes `DifferentialRevision->loadReviewedBy()` (all callsites updated). - Removes `DifferentialCommentQuery` (all callsites updated). Test Plan: Mostly a lot of `grep`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8476
2014-03-09 21:44:54 +01:00
'DifferentialCustomFieldDependsOnParser' => 'applications/differential/parser/DifferentialCustomFieldDependsOnParser.php',
'DifferentialCustomFieldDependsOnParserTestCase' => 'applications/differential/parser/__tests__/DifferentialCustomFieldDependsOnParserTestCase.php',
Adjust keys for new Differential inline comment table Summary: Ref T2222. This sequences //before// D7139 and sorts out keys on the table. In particular: - There was a fairly silly `draft` key modeled after Pholio; drop it. - Add a `revisionPHID` key. This is queried mostly-transitionally on the revision view screen. - Add a `changesetID` key. This is queried by a bunch of interfaces that want more surgical results than `revisionPHID` provides. - Add an `authorPHID, transactionPHID` key. This is queried on the list interface to find pending drafts. - Add a `legacy` key. This is queried by the feed publisher. Test Plan: Used the query analyzer to hit all (I think?) of the pages, saw keyed queries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D7140
2013-09-26 22:48:36 +02:00
'DifferentialCustomFieldNumericIndex' => 'applications/differential/storage/DifferentialCustomFieldNumericIndex.php',
Clean up various pieces of dead/obsolete Differential code Summary: Ref T2222. - Removes `DifferentialTasksAttacher`, which has had no callsites for a very long time. - Moves `differential.getrevisioncomments` off `DifferentialCommentQuery`. - Moves Releeph churn field off `DifferentialCommentQuery`. - Removes dead code in `DifferentialRevisionViewController`. - Removes `DifferentialException` (no references). - Removes `DifferentialRevision->loadComments()` (no callsites). - Removes `DifferentialRevision->loadReviewedBy()` (all callsites updated). - Removes `DifferentialCommentQuery` (all callsites updated). Test Plan: Mostly a lot of `grep`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8476
2014-03-09 21:44:54 +01:00
'DifferentialCustomFieldRevertsParser' => 'applications/differential/parser/DifferentialCustomFieldRevertsParser.php',
'DifferentialCustomFieldRevertsParserTestCase' => 'applications/differential/parser/__tests__/DifferentialCustomFieldRevertsParserTestCase.php',
Adjust keys for new Differential inline comment table Summary: Ref T2222. This sequences //before// D7139 and sorts out keys on the table. In particular: - There was a fairly silly `draft` key modeled after Pholio; drop it. - Add a `revisionPHID` key. This is queried mostly-transitionally on the revision view screen. - Add a `changesetID` key. This is queried by a bunch of interfaces that want more surgical results than `revisionPHID` provides. - Add an `authorPHID, transactionPHID` key. This is queried on the list interface to find pending drafts. - Add a `legacy` key. This is queried by the feed publisher. Test Plan: Used the query analyzer to hit all (I think?) of the pages, saw keyed queries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D7140
2013-09-26 22:48:36 +02:00
'DifferentialCustomFieldStorage' => 'applications/differential/storage/DifferentialCustomFieldStorage.php',
'DifferentialCustomFieldStringIndex' => 'applications/differential/storage/DifferentialCustomFieldStringIndex.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialDAO' => 'applications/differential/storage/DifferentialDAO.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'DifferentialDefaultViewCapability' => 'applications/differential/capability/DifferentialDefaultViewCapability.php',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialDependenciesField' => 'applications/differential/customfield/DifferentialDependenciesField.php',
'DifferentialDependsOnField' => 'applications/differential/customfield/DifferentialDependsOnField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialDiff' => 'applications/differential/storage/DifferentialDiff.php',
Modernize all Herald DifferentialDiff fields Summary: Ref T8726. This deals with all the Differential diff fields, same deal as previous changes. Test Plan: - Wrote a rule with every field. - Migrated it. - Saw the same rule working. - Rigged the hell out of transcripts (diffs normally do not generate transcripts, because the only action is "block" and they don't exist yet when Herald runs). - Verified that all fields looked sensible in the transcript. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13590
2015-07-08 21:25:38 +02:00
'DifferentialDiffAffectedFilesHeraldField' => 'applications/differential/herald/DifferentialDiffAffectedFilesHeraldField.php',
'DifferentialDiffAuthorHeraldField' => 'applications/differential/herald/DifferentialDiffAuthorHeraldField.php',
'DifferentialDiffAuthorProjectsHeraldField' => 'applications/differential/herald/DifferentialDiffAuthorProjectsHeraldField.php',
'DifferentialDiffContentAddedHeraldField' => 'applications/differential/herald/DifferentialDiffContentAddedHeraldField.php',
'DifferentialDiffContentHeraldField' => 'applications/differential/herald/DifferentialDiffContentHeraldField.php',
'DifferentialDiffContentRemovedHeraldField' => 'applications/differential/herald/DifferentialDiffContentRemovedHeraldField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialDiffCreateController' => 'applications/differential/controller/DifferentialDiffCreateController.php',
Allow Herald "diff" rules to reject content before it is written Summary: Fixes T5915. Occasionally, users derp up and diff private key material. Adding a pre-write Herald phase enables configuration of a partial layer of protection that will reject these changes before they hit disk, provided they can be detected by, e.g., filename. Test Plan: - Added a rule with checks on every field, verified they looked fine in the transcript. - Created some revisions to test those changes (I have a bunch of revision rules locally). - Verified rejects don't write transcripts to the database. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5915 Differential Revision: https://secure.phabricator.com/D10305
2014-08-20 23:26:29 +02:00
'DifferentialDiffEditor' => 'applications/differential/editor/DifferentialDiffEditor.php',
Move diff extraction from commits to a separate test with a CLI command Summary: Ref T9319. When we discover a commit, we sometimes update the corresponding revision with a "this is the actual committed change" diff and send out a link to the changes between review and commit. This is currently very difficult to test, because it only happens the first time and you have to either go set up a bunch of objects or add a bunch of special casing to the parser to hit the workflow. I'm making some changes to how it pulls file content. To make those changes easier to test, first start extracting this stuff so the code can be run with `bin/differential extract ...` instead of needing to do a bunch of more complicated setup steps. Test Plan: - Ran `bin/differential extract ...` to extract diffs from commits. - Forced my way through the daemon workflow by faking out a bunch of flags, got a clean extract + attach + update. After this patch, this should rarely be necessary. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9319 Differential Revision: https://secure.phabricator.com/D14967
2016-01-08 13:35:17 +01:00
'DifferentialDiffExtractionEngine' => 'applications/differential/engine/DifferentialDiffExtractionEngine.php',
Modernize all Herald DifferentialDiff fields Summary: Ref T8726. This deals with all the Differential diff fields, same deal as previous changes. Test Plan: - Wrote a rule with every field. - Migrated it. - Saw the same rule working. - Rigged the hell out of transcripts (diffs normally do not generate transcripts, because the only action is "block" and they don't exist yet when Herald runs). - Verified that all fields looked sensible in the transcript. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13590
2015-07-08 21:25:38 +02:00
'DifferentialDiffHeraldField' => 'applications/differential/herald/DifferentialDiffHeraldField.php',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'DifferentialDiffHeraldFieldGroup' => 'applications/differential/herald/DifferentialDiffHeraldFieldGroup.php',
Extend TransactionCommentQuery for Differential Summary: Ref T2009. Ref T1460. Replace hard-coded garbage with a real Query-layer query. Test Plan: Submitted inline comments in Differential. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2009, T1460 Differential Revision: https://secure.phabricator.com/D12027
2015-03-09 20:40:29 +01:00
'DifferentialDiffInlineCommentQuery' => 'applications/differential/query/DifferentialDiffInlineCommentQuery.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'DifferentialDiffPHIDType' => 'applications/differential/phid/DifferentialDiffPHIDType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialDiffProperty' => 'applications/differential/storage/DifferentialDiffProperty.php',
Add DifferentialDiffQuery and change most callsites Summary: Ref T603. This introduces a policy-aware DifferentialDiffQuery and converts most callsites. I've left unusual callsites (mostly: hard to get the viewer, unusual query, queries related to active diffs) alone for now, so this isn't exhaustive but hits 60-80% of sites. Test Plan: Created diff; created revision; viewed diffs and revisions; made additional conduit calls. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D6338
2013-07-01 21:38:42 +02:00
'DifferentialDiffQuery' => 'applications/differential/query/DifferentialDiffQuery.php',
Modernize all Herald DifferentialDiff fields Summary: Ref T8726. This deals with all the Differential diff fields, same deal as previous changes. Test Plan: - Wrote a rule with every field. - Migrated it. - Saw the same rule working. - Rigged the hell out of transcripts (diffs normally do not generate transcripts, because the only action is "block" and they don't exist yet when Herald runs). - Verified that all fields looked sensible in the transcript. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13590
2015-07-08 21:25:38 +02:00
'DifferentialDiffRepositoryHeraldField' => 'applications/differential/herald/DifferentialDiffRepositoryHeraldField.php',
'DifferentialDiffRepositoryProjectsHeraldField' => 'applications/differential/herald/DifferentialDiffRepositoryProjectsHeraldField.php',
Don't skip even lines in copied code detector Summary: PHP 3 basics: `each()` advances internal pointer so calling `next()` is wrong. Test Plan: New test. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4011
2012-11-21 21:30:38 +01:00
'DifferentialDiffTestCase' => 'applications/differential/storage/__tests__/DifferentialDiffTestCase.php',
Differential - make DifferentialDiffEditor into a real transaction editor. Summary: Ref T6237. This sets us up for some future work like T6152, T6200 and generally cleaning up this workflow a bit. Tried to do as little as possible so not exposing transaction view yet. (Though that timeline is going to be a little funky in the common case of just the lone create transaction.) Test Plan: made a diff from web ui and it worked. made a herald rule to block certain diffs then tried to make such a diff and saw UI letting me know i was blocked Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6237 Differential Revision: https://secure.phabricator.com/D10869
2014-11-19 00:32:23 +01:00
'DifferentialDiffTransaction' => 'applications/differential/storage/DifferentialDiffTransaction.php',
Add "Autoplans" to Harbormaster Summary: Ref T8095. Two general problems: - I want Harbormaster to own all lint and unit test results. - I don't want users to have to configure anything for `arc` to keep working automatically. These are in conflict because generic lint/unit test ownership in Harbormaster requires that build targets exist which we can attach build results to. However, we can't currently create build targets on demand: Harbormaster assumes it is responsible for creating targets, then running code or making third-party service calls to actually run the builds. I considered two broad approaches to let `arc` push results into Harbormaster without requiring administrators to configure some kind of "arc results" build plan: # Add magic target PHIDs like `PHID-MAGIC-this-is-really-arc-unit`. # Add new code to build real targets with real PHIDs. (1) is probably a bit less work to get off the ground, but I think it's worse overall and very likely to create more problems in the long run. I particularly worry that it will lead to a small amount of special casing in a very large number of places, which seems more fragile. (2) is more work upfront but I think does a better job of putting all the special casing in one place that we can, e.g., more reasonably unit test, and letting the rest of the code rarely/never care about this case since it's just dealing with normal plans/steps/targets as far as it can tell. This diff introduces "autoplans", which are source templates for plans/steps. This let us "push" these targets into Harbormaster. Hypthetically, any process "like" arc can use autoplans to upload test/lint/etc results. In practice, probably only `arc` will ever use this, but I think it's still quite a bit cleaner than the alternative despite all the generality. Workflow is basically: - `arc` creates a diff. - `arc` calls `harbormaster.queryautotargets`, passing the diff PHID and saying "I have some lint and unit results I want to stick on this thing". - Harbormaster builds the plan, steps, and targets (if any of them don't already exist), and hands back the target PHIDs so `arc` has a completely standard-looking place to put results. - `arc` uploads the test results to the right targets, as though Harbormaster had asked it to run unit/lint in the first place. (This doesn't actually do any of that yet, just sets things up.) I'll maybe doc turn that ^^^^^^ into a doc for posterity since I think it's hard to guess what an "autotarget" is, but I'm going to grab some lunch first. Test Plan: - Added unit tests to make sure we can build these things properly. - Used `harbormaster.queryautotargets` to build autotargets for a bunch of diffs. - Verified targets come up in "waiting for message" state. - Verified plans and steps are not editable. Reviewers: btrahan Reviewed By: btrahan Subscribers: hach-que, epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13345
2015-06-21 18:04:21 +02:00
'DifferentialDiffTransactionQuery' => 'applications/differential/query/DifferentialDiffTransactionQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialDiffViewController' => 'applications/differential/controller/DifferentialDiffViewController.php',
Generalize Asana-publishable feed story objects Summary: Ref T2852. Pulls the Differential-specific aspects of the Asana sync out of the worker. Next diff will add a publisher for Audit/Diffusion. Test Plan: Published events, including state changes. Saw them reflected correctly in Asana. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6569
2013-07-26 17:56:35 +02:00
'DifferentialDoorkeeperRevisionFeedStoryPublisher' => 'applications/differential/doorkeeper/DifferentialDoorkeeperRevisionFeedStoryPublisher.php',
Differential - add DifferentialDraft to track whether revisions have draft feedback or not Summary: ...do it somewhat generically, so we could fairly easily add this to other applications. Fixes T3496. I got a wee bit lazy and decided not to migrate existing drafts. My excuses aside from laziness are doing it this way will let us see if anyone complains, we can always do a migration later if people do complain, and there's likely to be a lot of garbage data for older / bigger installs, and the migration didn't seem worth itgiven it would also likely be expensive in these cases. Test Plan: made a draft inline comment on DX and observed DX had a note icon on Differential home page. made a draft comment on DX and observed DX had a note icon on Differential home page. deleted a draft inline comment and noted icon disappeared from Differential homepage. Submitted a draft comment + inline comment and noted icon disappeared. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T3496 Differential Revision: https://secure.phabricator.com/D8275
2014-02-19 01:25:16 +01:00
'DifferentialDraft' => 'applications/differential/storage/DifferentialDraft.php',
Implement view and edit policies in Differential CustomFields Summary: Ref T3886. Ref T418. - Adds "View Policy" and "Edit Policy" fields. - Allows CustomFields to produce arbitrary types of transactions, so these fields can produce standard view/edit policy transactions and get all the strings and validation associated with them. Test Plan: {F116001} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T3886 Differential Revision: https://secure.phabricator.com/D8287
2014-02-21 20:53:48 +01:00
'DifferentialEditPolicyField' => 'applications/differential/customfield/DifferentialEditPolicyField.php',
Clean up various pieces of dead/obsolete Differential code Summary: Ref T2222. - Removes `DifferentialTasksAttacher`, which has had no callsites for a very long time. - Moves `differential.getrevisioncomments` off `DifferentialCommentQuery`. - Moves Releeph churn field off `DifferentialCommentQuery`. - Removes dead code in `DifferentialRevisionViewController`. - Removes `DifferentialException` (no references). - Removes `DifferentialRevision->loadComments()` (no callsites). - Removes `DifferentialRevision->loadReviewedBy()` (all callsites updated). - Removes `DifferentialCommentQuery` (all callsites updated). Test Plan: Mostly a lot of `grep`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8476
2014-03-09 21:44:54 +01:00
'DifferentialFieldParseException' => 'applications/differential/exception/DifferentialFieldParseException.php',
'DifferentialFieldValidationException' => 'applications/differential/exception/DifferentialFieldValidationException.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DifferentialFindConduitAPIMethod' => 'applications/differential/conduit/DifferentialFindConduitAPIMethod.php',
'DifferentialGetAllDiffsConduitAPIMethod' => 'applications/differential/conduit/DifferentialGetAllDiffsConduitAPIMethod.php',
'DifferentialGetCommitMessageConduitAPIMethod' => 'applications/differential/conduit/DifferentialGetCommitMessageConduitAPIMethod.php',
'DifferentialGetCommitPathsConduitAPIMethod' => 'applications/differential/conduit/DifferentialGetCommitPathsConduitAPIMethod.php',
'DifferentialGetDiffConduitAPIMethod' => 'applications/differential/conduit/DifferentialGetDiffConduitAPIMethod.php',
'DifferentialGetRawDiffConduitAPIMethod' => 'applications/differential/conduit/DifferentialGetRawDiffConduitAPIMethod.php',
'DifferentialGetRevisionCommentsConduitAPIMethod' => 'applications/differential/conduit/DifferentialGetRevisionCommentsConduitAPIMethod.php',
'DifferentialGetRevisionConduitAPIMethod' => 'applications/differential/conduit/DifferentialGetRevisionConduitAPIMethod.php',
Land Revision button for hosted git repos Summary: ref T182. Simple approach of clone, patch, push. While waiting for drydock, implement a hackish mutex setup for the workspace, which should work ok as long as there's only one committer who is carefull about theses things. Less obvious note: This is taking the both author and commiter's 'primary email' for the commit - which might rub some people wrong. Test Plan: With a hosted repo, created some diffs and landed them. Also clicked button for some error cases, got the right error message. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: hach-que, Korvin, epriestley, aran Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D7486
2013-11-05 22:00:12 +01:00
'DifferentialGetWorkingCopy' => 'applications/differential/DifferentialGetWorkingCopy.php',
Rename `DifferentialLandingStrategy` subclasses for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: avivey, Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11186
2015-01-04 20:33:42 +01:00
'DifferentialGitHubLandingStrategy' => 'applications/differential/landing/DifferentialGitHubLandingStrategy.php',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialGitSVNIDField' => 'applications/differential/customfield/DifferentialGitSVNIDField.php',
Reduce Lint/Unit rendering duplication Summary: Ref T8096. No functional changes, just a bit less code. Test Plan: Viewed some revisions, saw the same stuff as before. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8096 Differential Revision: https://secure.phabricator.com/D13404
2015-06-23 22:33:09 +02:00
'DifferentialHarbormasterField' => 'applications/differential/customfield/DifferentialHarbormasterField.php',
Allow inline comments to be individually hidden Summary: Ref T7447. Implements per-viewer comment hiding. Once a comment is obsolete or uninteresting, you can hide it completely. This is sticky per-user. My hope is that this will strike a better balance between concerns than some of the other approaches (conservative porting, summarization, hide-all). Specifically, this adds a new action here: {F435621} Clicking it completely collapses the comment into a small icon on the previous line, and saves the comment state as hidden for you: {F435626} You can click the icon to reveal all hidden comments below the line. Test Plan: - Hid comments. - Showed comments. - Created, edited, deleted and submitted comments. - Used Diffusion comments (hiding is not implemented there yet, but I'd plan to bring it there eventually if it works out in Differential). Reviewers: btrahan, chad Reviewed By: btrahan Subscribers: jparise, yelirekim, epriestley Maniphest Tasks: T7447 Differential Revision: https://secure.phabricator.com/D13009
2015-05-27 19:28:38 +02:00
'DifferentialHiddenComment' => 'applications/differential/storage/DifferentialHiddenComment.php',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialHostField' => 'applications/differential/customfield/DifferentialHostField.php',
Rename `DifferentialLandingStrategy` subclasses for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: avivey, Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11186
2015-01-04 20:33:42 +01:00
'DifferentialHostedGitLandingStrategy' => 'applications/differential/landing/DifferentialHostedGitLandingStrategy.php',
'DifferentialHostedMercurialLandingStrategy' => 'applications/differential/landing/DifferentialHostedMercurialLandingStrategy.php',
Modernize Hovercard implementation Summary: Ref T8980. Move away from events to EngineExtensions. This also simplifies hovercards a bit: - Removes tasks from revision cards. - Removes blockers/blocked from task cards. - Removes "Send Message" from user cards. These mostly felt cluttery to me. Open to arguments to retain them. I think we can make better use of the space, though (e.g., flags, projects + board columns). Test Plan: - Viewed people, task, revision, commit and project hovercards. {F1043256} {F1043257} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8980 Differential Revision: https://secure.phabricator.com/D14878
2015-12-24 20:20:18 +01:00
'DifferentialHovercardEngineExtension' => 'applications/differential/engineextension/DifferentialHovercardEngineExtension.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialHunk' => 'applications/differential/storage/DifferentialHunk.php',
re-factor DifferentialChangesetParser pass 3 / N Summary: introducing a new friend called DifferentialHunkParser. Sort of like the DifferentialChangesetParser but works with hunks only. tried to grab hunk parsing type things from across the code base and move them into this new class. Test Plan: unit tests and played around in Differential a bit. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4351
2013-01-09 22:11:17 +01:00
'DifferentialHunkParser' => 'applications/differential/parser/DifferentialHunkParser.php',
'DifferentialHunkParserTestCase' => 'applications/differential/parser/__tests__/DifferentialHunkParserTestCase.php',
Add DifferentialHunkQuery to start hiding hunk storage details Summary: Ref T4045. We have a lot of direct queries against the hunk table right now. These are messy, not really policy-aware, and limit our options on T4045. This query is unusual (it requires changesets, and does not accept IDs). This keeps us from having to load changeset -> diff -> revision in order to do policy checks. We could also fix this with smarter policy checks and caching, but I'd rather not open that can of worms for now. This object is very low level and relatively unusual, and this small deviation from convention seems like the cleanest cut to make to keep this from snowballing. Test Plan: Used Herald dry runs to verify that the affected rules still output the same data. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4045 Differential Revision: https://secure.phabricator.com/D8765
2014-04-14 21:06:26 +02:00
'DifferentialHunkQuery' => 'applications/differential/query/DifferentialHunkQuery.php',
Simplify DifferentialHunk::getAddedLines() Summary: I will also need `getRemovedLines()` so refactor this first. Test Plan: New test case. Viewed uncached diff. Verified that the only callsite of `getAddedLines()` trims lines. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D2875
2012-06-27 19:44:29 +02:00
'DifferentialHunkTestCase' => 'applications/differential/storage/__tests__/DifferentialHunkTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialInlineComment' => 'applications/differential/storage/DifferentialInlineComment.php',
'DifferentialInlineCommentEditController' => 'applications/differential/controller/DifferentialInlineCommentEditController.php',
Rough cut of inline comment context Summary: Ref T10694. This is still missing some pieces, but seems to get most of the data into the mail in a plausible format: - When an inline remarks on code, show the patch inline in the mail body. - When an inline replies to another inline, show that other inline in the mail body. - Apply remarkup rendering to inline content. - Apply basic styling to mail body blocks. Not covered yet: - Syntax highlighting. - Diff highlighting. - Maybe clearer style/layout hints to connect comments to what they reply to? Current approach might get messy with inlines that have blockquotes and code blocks inside them, for example. - I probably want to cap the amount of diff context we ever show to ~7 lines, even if you drag over 200 lines of code. - CSS is a generally a bit rough still. - The `unified-comment-context` option is effectively always on now, and should be removed. - Text section is getting indented right now but probably shouldn't be. - Spacing, etc., might be a bit off. Test Plan: Rigged Home to render these things, got a plausible-looking render (top is text, bottom is HTML): {F1259052} Sent myself some inline comment mail, got a plausible result. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10694 Differential Revision: https://secure.phabricator.com/D15850
2016-05-05 13:42:29 +02:00
'DifferentialInlineCommentMailView' => 'applications/differential/mail/DifferentialInlineCommentMailView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialInlineCommentPreviewController' => 'applications/differential/controller/DifferentialInlineCommentPreviewController.php',
Abstract access to DifferentialInlineComment behind a Query Summary: Ref T2222. See D6260. Push all this junk behind a Query so I can move the storage out from underneath it. Test Plan: Viewed home page, list view, revision. Made draft, looked at preview, submitted draft, viewed inline, replied to inline. Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D6262
2013-06-21 21:54:56 +02:00
'DifferentialInlineCommentQuery' => 'applications/differential/query/DifferentialInlineCommentQuery.php',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialJIRAIssuesField' => 'applications/differential/customfield/DifferentialJIRAIssuesField.php',
Land Revision button for hosted git repos Summary: ref T182. Simple approach of clone, patch, push. While waiting for drydock, implement a hackish mutex setup for the workspace, which should work ok as long as there's only one committer who is carefull about theses things. Less obvious note: This is taking the both author and commiter's 'primary email' for the commit - which might rub some people wrong. Test Plan: With a hosted repo, created some diffs and landed them. Also clicked button for some error cases, got the right error message. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: hach-que, Korvin, epriestley, aran Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D7486
2013-11-05 22:00:12 +01:00
'DifferentialLandingActionMenuEventListener' => 'applications/differential/landing/DifferentialLandingActionMenuEventListener.php',
'DifferentialLandingStrategy' => 'applications/differential/landing/DifferentialLandingStrategy.php',
Rename `DifferentialHunk` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11470
2015-01-22 21:17:04 +01:00
'DifferentialLegacyHunk' => 'applications/differential/storage/DifferentialLegacyHunk.php',
Implement rough content-aware inline adjustment rules for ghosts Summary: Ref T7447. Fixes T7600. This likely needs significant adjustment, but implements content-aware comment porting for line changes. Specifically, this moves lines around to adjust their position considering added and removed lines between the diffs and across rebases. It does not try to do any actual content (line against line) matching. Test Plan: - Unit tests. - Poking around in the web UI seems to generate mostly reasonable-ish results? - This may be a huge step backward in some cases that I just haven't hit. Reviewers: btrahan Reviewed By: btrahan Subscribers: yelirekim, epriestley Maniphest Tasks: T7600, T7447 Differential Revision: https://secure.phabricator.com/D12741
2015-05-07 23:09:41 +02:00
'DifferentialLineAdjustmentMap' => 'applications/differential/parser/DifferentialLineAdjustmentMap.php',
Add modern Unit/Lint field support Summary: Ref T2222. This is mostly copy/paste. No effect yet. Test Plan: Looked at fields. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8360
2014-02-27 20:06:37 +01:00
'DifferentialLintField' => 'applications/differential/customfield/DifferentialLintField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialLintStatus' => 'applications/differential/constants/DifferentialLintStatus.php',
'DifferentialLocalCommitsView' => 'applications/differential/view/DifferentialLocalCommitsView.php',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialManiphestTasksField' => 'applications/differential/customfield/DifferentialManiphestTasksField.php',
Rename `DifferentialHunk` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11470
2015-01-22 21:17:04 +01:00
'DifferentialModernHunk' => 'applications/differential/storage/DifferentialModernHunk.php',
Move "Next Step" to a custom field in Differential Summary: Fixes T9672. This was never turned into a custom field, for no particular reason. Convert it into one. This is substantially similar to the existing "Apply Patch" field, which does the same thing (only shows a command). We might rethink or remove this eventually (e.g., in a post-"Land Revision" world) but this makes it easier, at the very least. Test Plan: - Viewed a non-accepted revision (no hint). - Viewed an accepted revision from a raw diff source (no hint). - Viewed an accepted revision from Git (`arc land` hint). Reviewers: chad Reviewed By: chad Maniphest Tasks: T9672 Differential Revision: https://secure.phabricator.com/D14367
2015-10-30 17:00:53 +01:00
'DifferentialNextStepField' => 'applications/differential/customfield/DifferentialNextStepField.php',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'DifferentialParseCacheGarbageCollector' => 'applications/differential/garbagecollector/DifferentialParseCacheGarbageCollector.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DifferentialParseCommitMessageConduitAPIMethod' => 'applications/differential/conduit/DifferentialParseCommitMessageConduitAPIMethod.php',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialParseRenderTestCase' => 'applications/differential/__tests__/DifferentialParseRenderTestCase.php',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialPathField' => 'applications/differential/customfield/DifferentialPathField.php',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialProjectReviewersField' => 'applications/differential/customfield/DifferentialProjectReviewersField.php',
Projects for DifferentialRevision Summary: T2628, Adding project tags to revisions Test Plan: Edit revision, verify projects can be tagged. Add project hashtag to comments or commit templates, verify revision is tagged with project Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D9686
2014-06-23 18:49:52 +02:00
'DifferentialProjectsField' => 'applications/differential/customfield/DifferentialProjectsField.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DifferentialQueryConduitAPIMethod' => 'applications/differential/conduit/DifferentialQueryConduitAPIMethod.php',
'DifferentialQueryDiffsConduitAPIMethod' => 'applications/differential/conduit/DifferentialQueryDiffsConduitAPIMethod.php',
Abstract raw diff rendering into DifferentialRawDiffRenderer Test Plan: Enable inline patches: ``` bin/config set metamta.differential.patch-format 'unified' bin/config set metamta.differential.inline-patches 100000000 ``` Create a new diff and confirm it renders correctly via email. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D7198
2013-10-03 01:28:03 +02:00
'DifferentialRawDiffRenderer' => 'applications/differential/render/DifferentialRawDiffRenderer.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'DifferentialReleephRequestFieldSpecification' => 'applications/releeph/differential/DifferentialReleephRequestFieldSpecification.php',
Pre-prepare for hovercards Summary: D5120 and followups refactor and generalize object references in Remarkup -- notably, they move remarkup rules from a central location to the implementing applications. Preserve blame by doing moves/renames only first. This change moves application remarkup rules into those applications, and renames the ones D5120 modifies. Test Plan: Typed some preview text into a textarea, got a valid Remarkup render. Reviewers: vrana, chad Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5123
2013-02-26 23:57:41 +01:00
'DifferentialRemarkupRule' => 'applications/differential/remarkup/DifferentialRemarkupRule.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'DifferentialReplyHandler' => 'applications/differential/mail/DifferentialReplyHandler.php',
Implement "Repository" as a new-style CustomField in Differential Summary: Ref T3886. Ref T418. - Adds new capabilities for CustomField: - Controls can now bulk-load PHIDs (e.g., for tokenizers). - Transactions can now bulk-load PHIDs (e.g., for relationship changes). - Implements "Repository" control. - Improves tokenizer StandardCustomField controls. Test Plan: {F115942} {F115943} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T3886 Differential Revision: https://secure.phabricator.com/D8286
2014-02-21 20:53:37 +01:00
'DifferentialRepositoryField' => 'applications/differential/customfield/DifferentialRepositoryField.php',
When creating or updating a revision, infer the repository from the diff Summary: Ref T603. When a diff is attached to a revision, try to guess the repository if possible. In cases where we succeed, this automatically gives us intuitive policy behavior (i.e., you can see a revision if you can see the repository the change is against). I pulled this into a funky little "Lookup" class for two reasons: - It's used in two places; - I anticipate that we might need to add some sort of `explainWhy()` method if users find the heuristics confusing. Test Plan: Created and updated revisions, saw them pick up the correct repository association. Ran Herald dry run against associable and nonassociable revisions, saw correct values populate. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7147
2013-09-27 00:28:42 +02:00
'DifferentialRepositoryLookup' => 'applications/differential/query/DifferentialRepositoryLookup.php',
Allow Herald to "Require legal signatures" for reviews Summary: Ref T3116. Add a Herald action "Require legal signatures" which requires revision authors to accept legal agreements before their revisions can be accepted. - Herald will check which documents the author has signed, and trigger a "you have to sign X, Y, Z" for other documents. - If the author has already signed everything, we don't spam the revision -- basically, this only triggers when signatures are missing. - The UI will show which documents must be signed and warn that the revision can't be accepted until they're completed. - Users aren't allowed to "Accept" the revision until documents are cleared. Fixes T1157. The original install making the request (Hive) no longer uses Phabricator, and this satisfies our requirements. Test Plan: - Added a Herald rule. - Created a revision, saw the rule trigger. - Viewed as author and non-author, saw field UI (generic for non-author, specific for author), transaction UI, and accept-warning UI. - Tried to accept revision. - Signed document, saw UI update. Note that signatures don't currently //push// an update to the revision, but could eventually (like blocking tasks work). - Accepted revision. - Created another revision, saw rules not add the document (since it's already signed, this is the "no spam" case). Reviewers: btrahan, chad Reviewed By: chad Subscribers: asherkin, epriestley Maniphest Tasks: T1157, T3116 Differential Revision: https://secure.phabricator.com/D9771
2014-06-29 16:53:53 +02:00
'DifferentialRequiredSignaturesField' => 'applications/differential/customfield/DifferentialRequiredSignaturesField.php',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialRevertPlanField' => 'applications/differential/customfield/DifferentialRevertPlanField.php',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialReviewedByField' => 'applications/differential/customfield/DifferentialReviewedByField.php',
Methods for reading reviewers from edges in differential Summary: Add `getReviewerStatus` to get an array of `DifferentialReviewer` objects. The method `needReviewerStatus` in `DifferentialRevisionQuery` loads the edges into the revisions loaded. Test Plan: Added `->needReviewerStatus(true)` to `DifferentialRevisionSearchEngine` and checked through logging that the data was being loaded correctly. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6450
2013-07-15 04:18:55 +02:00
'DifferentialReviewer' => 'applications/differential/storage/DifferentialReviewer.php',
Migrate Differential revision edges to use modern `EdgeType` subclasses Summary: Modernize Differential edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: From previous experience, these changes are fairly trivial and safe. I poked around a little to make sure things looked reasonably okay. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, Krenair, epriestley Differential Revision: https://secure.phabricator.com/D11074
2015-01-01 04:43:26 +01:00
'DifferentialReviewerForRevisionEdgeType' => 'applications/differential/edge/DifferentialReviewerForRevisionEdgeType.php',
Store revision reviewer state as edges Summary: Keep track of the state of a reviewer in an edge between reviewer and revision. The edge stores the state of the review, added or rejected. And if the revision was accepted by that reviewer the id of the diff accepted. Test Plan: Create diffs and clowncopterize reviewer list changes. This includes: * Adding new reviewers * Resigning * Commandering a revision Reviewers: epriestley CC: aran, Korvin Maniphest Tasks: T1279 Differential Revision: https://secure.phabricator.com/D6372 Conflicts: src/applications/differential/editor/DifferentialCommentEditor.php
2013-07-10 22:45:14 +02:00
'DifferentialReviewerStatus' => 'applications/differential/constants/DifferentialReviewerStatus.php',
Modularize Differential Reviewer actions in Herald Ref T8726. Modularizes the "Add Reviewers" and "Add Blocking Reviewers" Herald actions.
2015-07-30 20:39:35 +02:00
'DifferentialReviewersAddBlockingReviewersHeraldAction' => 'applications/differential/herald/DifferentialReviewersAddBlockingReviewersHeraldAction.php',
'DifferentialReviewersAddBlockingSelfHeraldAction' => 'applications/differential/herald/DifferentialReviewersAddBlockingSelfHeraldAction.php',
'DifferentialReviewersAddReviewersHeraldAction' => 'applications/differential/herald/DifferentialReviewersAddReviewersHeraldAction.php',
'DifferentialReviewersAddSelfHeraldAction' => 'applications/differential/herald/DifferentialReviewersAddSelfHeraldAction.php',
Implement a "Reviewers" CustomField Summary: Ref T3886: - Adds a "Reviewers" field as a modern CustomField. Ref T418: - Allows CustomFields to emit transaction metadata. Test Plan: {F116254} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T3886 Differential Revision: https://secure.phabricator.com/D8291
2014-02-21 20:54:32 +01:00
'DifferentialReviewersField' => 'applications/differential/customfield/DifferentialReviewersField.php',
Modularize Differential Reviewer actions in Herald Ref T8726. Modularizes the "Add Reviewers" and "Add Blocking Reviewers" Herald actions.
2015-07-30 20:39:35 +02:00
'DifferentialReviewersHeraldAction' => 'applications/differential/herald/DifferentialReviewersHeraldAction.php',
Split users apart from projects/packages in reviewer and audit UIs Summary: Ref T1279. Show separate sections for "Reviewers" and "Project Reviewers" (Differential) and for "Auditors" and "Package/Project Auditors" (Diffusion/Audit). Test Plan: - Looked at a commit. Saw separation. - Looked at a revision. Saw separation. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1279 Differential Revision: https://secure.phabricator.com/D7233
2013-10-05 16:54:42 +02:00
'DifferentialReviewersView' => 'applications/differential/view/DifferentialReviewersView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialRevision' => 'applications/differential/storage/DifferentialRevision.php',
Modularize all DifferentialRevision fields Summary: Ref T8726. Make all the DifferentialRevision stuff modular. Test Plan: - Created a rule with all fields. - Ran upgrade. - Saw all fields preserved with new modular versions. - Used test console to run rule with all fields, verified field values as broadly sensible. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13598
2015-07-08 21:25:48 +02:00
'DifferentialRevisionAffectedFilesHeraldField' => 'applications/differential/herald/DifferentialRevisionAffectedFilesHeraldField.php',
'DifferentialRevisionAuthorHeraldField' => 'applications/differential/herald/DifferentialRevisionAuthorHeraldField.php',
'DifferentialRevisionAuthorProjectsHeraldField' => 'applications/differential/herald/DifferentialRevisionAuthorProjectsHeraldField.php',
Increase clarity when closing a revision in response to a commit Summary: I am not sure how valuable this is *as is* - I think it needs different explanations for what happened in mercurial or subversion? I do not know what those explanations are. Made an error in D10485 - the $hashes that were saved is an array of objects, so it ends up turning into garbage via the wonders of serialization and de-serialization. Fix that by explicitly saving the tree hash. I would like to make this work for the other VCS types we support, add the "undo / nope" button and call it fixed. Ref T3686. Test Plan: clicked "explan why" and saw why Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5693, T3686 Differential Revision: https://secure.phabricator.com/D10489
2014-10-14 01:55:26 +02:00
'DifferentialRevisionCloseDetailsController' => 'applications/differential/controller/DifferentialRevisionCloseDetailsController.php',
Modularize all DifferentialRevision fields Summary: Ref T8726. Make all the DifferentialRevision stuff modular. Test Plan: - Created a rule with all fields. - Ran upgrade. - Saw all fields preserved with new modular versions. - Used test console to run rule with all fields, verified field values as broadly sensible. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13598
2015-07-08 21:25:48 +02:00
'DifferentialRevisionContentAddedHeraldField' => 'applications/differential/herald/DifferentialRevisionContentAddedHeraldField.php',
'DifferentialRevisionContentHeraldField' => 'applications/differential/herald/DifferentialRevisionContentHeraldField.php',
'DifferentialRevisionContentRemovedHeraldField' => 'applications/differential/herald/DifferentialRevisionContentRemovedHeraldField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialRevisionControlSystem' => 'applications/differential/constants/DifferentialRevisionControlSystem.php',
Migrate Differential revision edges to use modern `EdgeType` subclasses Summary: Modernize Differential edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: From previous experience, these changes are fairly trivial and safe. I poked around a little to make sure things looked reasonably okay. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, Krenair, epriestley Differential Revision: https://secure.phabricator.com/D11074
2015-01-01 04:43:26 +01:00
'DifferentialRevisionDependedOnByRevisionEdgeType' => 'applications/differential/edge/DifferentialRevisionDependedOnByRevisionEdgeType.php',
'DifferentialRevisionDependsOnRevisionEdgeType' => 'applications/differential/edge/DifferentialRevisionDependsOnRevisionEdgeType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialRevisionEditController' => 'applications/differential/controller/DifferentialRevisionEditController.php',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'DifferentialRevisionFulltextEngine' => 'applications/differential/search/DifferentialRevisionFulltextEngine.php',
Migrate Differential revision edges to use modern `EdgeType` subclasses Summary: Modernize Differential edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: From previous experience, these changes are fairly trivial and safe. I poked around a little to make sure things looked reasonably okay. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, Krenair, epriestley Differential Revision: https://secure.phabricator.com/D11074
2015-01-01 04:43:26 +01:00
'DifferentialRevisionHasCommitEdgeType' => 'applications/differential/edge/DifferentialRevisionHasCommitEdgeType.php',
'DifferentialRevisionHasReviewerEdgeType' => 'applications/differential/edge/DifferentialRevisionHasReviewerEdgeType.php',
Modernize task/revision edges and write inverse transactions Summary: Ref T5245. See some discussion in D9838. When we attach object A to object B, we'd like to write transactions on both sides but only write the actual edges once. To do this, allow edge types to `shouldWriteInverseTransactions()`. When an edge type opts into this, have editors apply the inverse transactions before writing the edge. These inverse transactions don't actually apply effects, they just show up in the transaction log. Test Plan: Attached and detached revisions from tasks, saw transactions appear on both sides of the operation. Reviewers: chad, btrahan, joshuaspence Reviewed By: btrahan, joshuaspence Subscribers: epriestley Maniphest Tasks: T5245 Differential Revision: https://secure.phabricator.com/D9839
2014-07-18 00:41:08 +02:00
'DifferentialRevisionHasTaskEdgeType' => 'applications/differential/edge/DifferentialRevisionHasTaskEdgeType.php',
Modularize all DifferentialRevision fields Summary: Ref T8726. Make all the DifferentialRevision stuff modular. Test Plan: - Created a rule with all fields. - Ran upgrade. - Saw all fields preserved with new modular versions. - Used test console to run rule with all fields, verified field values as broadly sensible. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13598
2015-07-08 21:25:48 +02:00
'DifferentialRevisionHeraldField' => 'applications/differential/herald/DifferentialRevisionHeraldField.php',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'DifferentialRevisionHeraldFieldGroup' => 'applications/differential/herald/DifferentialRevisionHeraldFieldGroup.php',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialRevisionIDField' => 'applications/differential/customfield/DifferentialRevisionIDField.php',
Land Revision button for hosted git repos Summary: ref T182. Simple approach of clone, patch, push. While waiting for drydock, implement a hackish mutex setup for the workspace, which should work ok as long as there's only one committer who is carefull about theses things. Less obvious note: This is taking the both author and commiter's 'primary email' for the commit - which might rub some people wrong. Test Plan: With a hosted repo, created some diffs and landed them. Also clicked button for some error cases, got the right error message. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: hach-que, Korvin, epriestley, aran Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D7486
2013-11-05 22:00:12 +01:00
'DifferentialRevisionLandController' => 'applications/differential/controller/DifferentialRevisionLandController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialRevisionListController' => 'applications/differential/controller/DifferentialRevisionListController.php',
'DifferentialRevisionListView' => 'applications/differential/view/DifferentialRevisionListView.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'DifferentialRevisionMailReceiver' => 'applications/differential/mail/DifferentialRevisionMailReceiver.php',
Rough cut of DrydockRepositoryOperation Summary: Ref T182. This doesn't do anything interesting yet and is mostly scaffolding, but here's roughly the workflow. From previous revision, you can configure "Repository Automation" for a repository: {F875741} If it's configured, a new "Land Revision" button shows up: {F875743} Once you click it you get a big warning dialog that it won't work, and then this shows up at the top of the revision (completely temporary/placeholder UI, some day a nice progress bar or whatever): {F875747} If you're lucky, the operation eventually sort of works: {F875750} It only runs `git show` right now, doesn't actually do any writes or anything. Test Plan: - Clicked "Land Revision". - Watched `phd debug task`. - Saw it log `git show` to output. - Verified operation success in UI (by fiddling URL, no way to get there normally yet). Reviewers: chad Reviewed By: chad Subscribers: revi Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D14266
2015-10-14 00:46:12 +02:00
'DifferentialRevisionOperationController' => 'applications/differential/controller/DifferentialRevisionOperationController.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'DifferentialRevisionPHIDType' => 'applications/differential/phid/DifferentialRevisionPHIDType.php',
Modularize all DifferentialRevision fields Summary: Ref T8726. Make all the DifferentialRevision stuff modular. Test Plan: - Created a rule with all fields. - Ran upgrade. - Saw all fields preserved with new modular versions. - Used test console to run rule with all fields, verified field values as broadly sensible. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13598
2015-07-08 21:25:48 +02:00
'DifferentialRevisionPackageHeraldField' => 'applications/differential/herald/DifferentialRevisionPackageHeraldField.php',
'DifferentialRevisionPackageOwnerHeraldField' => 'applications/differential/herald/DifferentialRevisionPackageOwnerHeraldField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialRevisionQuery' => 'applications/differential/query/DifferentialRevisionQuery.php',
Modularize all DifferentialRevision fields Summary: Ref T8726. Make all the DifferentialRevision stuff modular. Test Plan: - Created a rule with all fields. - Ran upgrade. - Saw all fields preserved with new modular versions. - Used test console to run rule with all fields, verified field values as broadly sensible. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13598
2015-07-08 21:25:48 +02:00
'DifferentialRevisionRepositoryHeraldField' => 'applications/differential/herald/DifferentialRevisionRepositoryHeraldField.php',
'DifferentialRevisionRepositoryProjectsHeraldField' => 'applications/differential/herald/DifferentialRevisionRepositoryProjectsHeraldField.php',
'DifferentialRevisionReviewersHeraldField' => 'applications/differential/herald/DifferentialRevisionReviewersHeraldField.php',
Use ApplicationSearch in Differential Summary: Ref T603. Ref T2625. Fixes T3241. Depends on D5451. Depends on D6346. @wez, this changes the Differential revision list UI substantially and may generate a lot of bikeshedding / who-moved-my-cheese churn. See T3417 for context, for example. The motivations for this change are: - The list now works on devices, like phones and tablets. This is a requirement to make the rest of Differential work on devices. - Although ApplicationSearch intentionally presents a simpler interface initially and some options which were one click away before aren't now, it is much more powerful than the search it replaces and allows users to build, save, share, fork, edit, and customize a much wider range of queries. Users who used the old filters frequently can use Advanced Search -> Save Custom Query to create new versions of them, and of any other query. "Edit Queries.." allows users to remove and reorder queries, including builtin queries. Basically, there are like three things which have gone from "1-click" to "a few clicks", and ten trillion things which have gone from "hard/impossible" to "relatively easy". The local screenshots look a bit iffy, but I think a lot of this is the fakenesss of my test data. If they still feel iffy in production we can tweak them until they feel good, like we did for Maniphest. Test Plan: {F48477} {F48478} Reviewers: btrahan, chad, wez Reviewed By: btrahan CC: aran, s Maniphest Tasks: T603, T2625, T3241 Differential Revision: https://secure.phabricator.com/D6347
2013-07-03 15:11:07 +02:00
'DifferentialRevisionSearchEngine' => 'applications/differential/query/DifferentialRevisionSearchEngine.php',
change DifferentialRevisionDetailView to use newer fangled UI abstractions Summary: actions are still a bit messy - unsatisfactory icons (T2013 will help!) Test Plan: viewed diffs - they look good Reviewers: epriestley, vrana Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2007 Differential Revision: https://secure.phabricator.com/D3904
2012-12-11 23:59:27 +01:00
'DifferentialRevisionStatus' => 'applications/differential/constants/DifferentialRevisionStatus.php',
Modularize all DifferentialRevision fields Summary: Ref T8726. Make all the DifferentialRevision stuff modular. Test Plan: - Created a rule with all fields. - Ran upgrade. - Saw all fields preserved with new modular versions. - Used test console to run rule with all fields, verified field values as broadly sensible. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13598
2015-07-08 21:25:48 +02:00
'DifferentialRevisionSummaryHeraldField' => 'applications/differential/herald/DifferentialRevisionSummaryHeraldField.php',
'DifferentialRevisionTitleHeraldField' => 'applications/differential/herald/DifferentialRevisionTitleHeraldField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialRevisionUpdateHistoryView' => 'applications/differential/view/DifferentialRevisionUpdateHistoryView.php',
'DifferentialRevisionViewController' => 'applications/differential/controller/DifferentialRevisionViewController.php',
Begin generating meaningful expected schemata Summary: Ref T1191. This lays some groundwork for generating the expected schemata, so we can compare them to the actual schemata and produce a meaningful diff. - In general, each application will subclass `PhabricatorConfigSchemaSpec` and provide a definition of the tables it expects. - This class has helper methods to mostly-automatically build table definitions for Lisk and (in the future) edges. - When building expected schema, we specify a "data type", like "epoch". This is the type of data the application stores in the column, from the application's point of view. The SchemaSpec converts this into the best avilable storage type: for example, "text" will translate to `utf8mb4` if it's availalbe, or `binary` if not. This gives us a layer of indirection to insulate us from craziness. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10497
2014-09-18 17:25:34 +02:00
'DifferentialSchemaSpec' => 'applications/differential/storage/DifferentialSchemaSpec.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DifferentialSetDiffPropertyConduitAPIMethod' => 'applications/differential/conduit/DifferentialSetDiffPropertyConduitAPIMethod.php',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialStoredCustomField' => 'applications/differential/customfield/DifferentialStoredCustomField.php',
Implement Differential subscribers as a CustomField Summary: Ref T3886. Now that a custom field can emit a core transaction, just emit a subscribers transaction. Test Plan: {F116014} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8289
2014-02-21 20:54:08 +01:00
'DifferentialSubscribersField' => 'applications/differential/customfield/DifferentialSubscribersField.php',
Implement new-style "Summary" field Summary: Ref T3886. - Adds "Summary" field. - Adds "CoreField" for fields stored on the actual object, to reduce code duplication a bit for the main fields. Test Plan: {F115902} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8283
2014-02-21 20:52:52 +01:00
'DifferentialSummaryField' => 'applications/differential/customfield/DifferentialSummaryField.php',
Implement "Test Plan" as a CustomField Summary: Ref T3886. Moves some of the "required" logic to the base class ("DifferentialCoreField") so Title and Test Plan can share it. Test Plan: Edited revisions using "pro" editor, saw test plan transactions. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8285
2014-02-21 20:53:27 +01:00
'DifferentialTestPlanField' => 'applications/differential/customfield/DifferentialTestPlanField.php',
Implement "Pro" version of revision editor, with one field Summary: Ref T3886. I spent a few hours trying to make `DifferentialFieldSpecification` extend `PhabricatorCustomField` so I could be more blunt in my approach here and just swap the whole thing over in one go (more or less like I did with Maniphest) but we have a ton of custom fields and things felt really shaky and the change was enormous and hard to keep track of. Instead, I'm going to do this more gradually and go field-by-field. This implements a CustomField version of the "Title" field. (There are no links to this in the UI.) Test Plan: {F115353} {F115354} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8276
2014-02-19 01:32:55 +01:00
'DifferentialTitleField' => 'applications/differential/customfield/DifferentialTitleField.php',
Add storage for new Differential transactions and transaction comments Summary: Ref T2222. Ref T1460. Depends on D6260. This creates the new tables, but doesn't start using them. I added three new fields for {T1460}, to represent fixed/done/replied states. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T1460, T2222 Differential Revision: https://secure.phabricator.com/D6261
2013-06-21 21:54:29 +02:00
'DifferentialTransaction' => 'applications/differential/storage/DifferentialTransaction.php',
'DifferentialTransactionComment' => 'applications/differential/storage/DifferentialTransactionComment.php',
Implement "Pro" version of revision editor, with one field Summary: Ref T3886. I spent a few hours trying to make `DifferentialFieldSpecification` extend `PhabricatorCustomField` so I could be more blunt in my approach here and just swap the whole thing over in one go (more or less like I did with Maniphest) but we have a ton of custom fields and things felt really shaky and the change was enormous and hard to keep track of. Instead, I'm going to do this more gradually and go field-by-field. This implements a CustomField version of the "Title" field. (There are no links to this in the UI.) Test Plan: {F115353} {F115354} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8276
2014-02-19 01:32:55 +01:00
'DifferentialTransactionEditor' => 'applications/differential/editor/DifferentialTransactionEditor.php',
Migrate Differential comments to ApplicationTransactions Summary: Ref T2222. This is the big one. This migrates each `DifferentialComment` to one or more ApplicationTransactions (action, cc, reviewers, update, comment, inlines), and makes `DifferentialComment` a double-reader for ApplicationTransactions. The migration is pretty straightforward: - If a comment took an action not otherwise covered, it gets an "action" transaction. This is something like "epriestley abandoned this revision.". - If a comment updated the diff, it gets an "updated diff" transaction. Very old transactions of this type may not have a diff ID (probably only at Facebook). - If a comment added or removed reviewers, it gets a "changed reviewers" transaction. - If a comment added CCs, it gets a "subscribers" transaction. - If a comment added comment text, it gets a "comment" transaction. - For each inline attached to a comment, we generate an "inline" transaction. Most comments generate a small number of transactions, but a few generate a significant number. At HEAD, the code is basically already doing this, so comments in the last day or two already obey these rules, roughly, and will all generate only one transaction (except inlines). Because we've already preallocated PHIDs in the comment text table, we only need to write to the transaction table. NOTE: This significantly degrades Differential, making inline comments pretty much useless (they each get their own transaction, and don't show line numbers or files). The data is all fine, but the UI is garbage now. This needs to be fixed before we can deploy this to users, but it's easily separable since it's all just display code. Specifically, they look like this: {F112270} Test Plan: I've migrated locally and put things through their paces, but it's hard to catch sketchy stuff locally because most of my test data is nonsense and bad migrations wouldn't necessarily look out of place. IMPORTANT: I'm planning to push this to a branch and then shift production over to the branch, and run it for a day or two before bringing it to master. I generally feel good about this change: it's not that big since we were able to separate a lot of pieces out of it, and it's pretty straightforward. That said, it's still one of the most scary/dangerous changes we've ever made. Reviewers: btrahan CC: chad, aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8210
2014-02-12 00:36:58 +01:00
'DifferentialTransactionQuery' => 'applications/differential/query/DifferentialTransactionQuery.php',
Use timeline view in Differential and make inlines somewhat usable again Summary: Ref T2222. This gets rid of Differential's custom view and uses a standard view instead. This also mostly fixes the rendering logic for inlines. This is headed to the `tmp.differential` branch. Test Plan: {F112696} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T1790, T2222 Differential Revision: https://secure.phabricator.com/D8215
2014-02-12 23:05:40 +01:00
'DifferentialTransactionView' => 'applications/differential/view/DifferentialTransactionView.php',
Add modern Unit/Lint field support Summary: Ref T2222. This is mostly copy/paste. No effect yet. Test Plan: Looked at fields. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8360
2014-02-27 20:06:37 +01:00
'DifferentialUnitField' => 'applications/differential/customfield/DifferentialUnitField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialUnitStatus' => 'applications/differential/constants/DifferentialUnitStatus.php',
'DifferentialUnitTestResult' => 'applications/differential/constants/DifferentialUnitTestResult.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DifferentialUpdateRevisionConduitAPIMethod' => 'applications/differential/conduit/DifferentialUpdateRevisionConduitAPIMethod.php',
Implement view and edit policies in Differential CustomFields Summary: Ref T3886. Ref T418. - Adds "View Policy" and "Edit Policy" fields. - Allows CustomFields to produce arbitrary types of transactions, so these fields can produce standard view/edit policy transactions and get all the strings and validation associated with them. Test Plan: {F116001} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T3886 Differential Revision: https://secure.phabricator.com/D8287
2014-02-21 20:53:48 +01:00
'DifferentialViewPolicyField' => 'applications/differential/customfield/DifferentialViewPolicyField.php',
Modernize "user, project or package" typeahead datasource Summary: Ref T4420. Call this "auditor" since that's what it is. Test Plan: - Edited auditors in auditor search. - Edited auditors in "add auditors" in Diffusion. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9888
2014-07-18 00:45:21 +02:00
'DiffusionAuditorDatasource' => 'applications/diffusion/typeahead/DiffusionAuditorDatasource.php',
Modernize Audit search engine Summary: Fixes T9279. Modernizes the SearchEngine and Query classes. User-facing changes: - Added order by commit date, default to order by commit date with newest commits first. - Added explicit "Needs Audit by". - Added new `packages(...)` typeahead function. - Picked up automatic subscribers, projects, and order fields. This changes behavior a little bit: we previously attempted to exclude, e.g., commits which a package you own needs to audit, but which you have resigned from. This is difficult in general and I think it needs a more comprehensive solution. This shouldn't impact users much, anyway. Test Plan: {F767628} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9279 Differential Revision: https://secure.phabricator.com/D14013
2015-08-31 19:17:54 +02:00
'DiffusionAuditorFunctionDatasource' => 'applications/diffusion/typeahead/DiffusionAuditorFunctionDatasource.php',
Modularize the Diffusion "Add Auditors" Herald action Ref T8726.
2015-08-03 15:01:24 +02:00
'DiffusionAuditorsAddAuditorsHeraldAction' => 'applications/diffusion/herald/DiffusionAuditorsAddAuditorsHeraldAction.php',
'DiffusionAuditorsAddSelfHeraldAction' => 'applications/diffusion/herald/DiffusionAuditorsAddSelfHeraldAction.php',
'DiffusionAuditorsHeraldAction' => 'applications/diffusion/herald/DiffusionAuditorsHeraldAction.php',
Implement a dedicated "diffusion.blame" API method Summary: Fixes T2451. Several motivations here, from strongest to weakest: - Currently, getting blame and file content are closely entwined. This makes fixing T9319 more difficult, and I want to fix it. I want to separate blame from content so there's more flexibility in how we approach this issue. - This makes pursuing T2450 easier, if it turns out to be a meaningful win. - If we can get a win on blame performance, we can do `arc blame` eventually if we want. Test Plan: - Blamed in SVN, Git and Mercurial. Reviewers: chad Reviewed By: chad Maniphest Tasks: T2451 Differential Revision: https://secure.phabricator.com/D14957
2016-01-06 13:56:27 +01:00
'DiffusionBlameConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionBlameConduitAPIMethod.php',
'DiffusionBlameQuery' => 'applications/diffusion/query/blame/DiffusionBlameQuery.php',
Modularize the Diffusion/Differential "Block" Herald actions Also removes HeraldCustomAction. This completes action modularization. Ref T8726.
2015-08-03 21:54:40 +02:00
'DiffusionBlockHeraldAction' => 'applications/diffusion/herald/DiffusionBlockHeraldAction.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionBranchQueryConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionBranchQueryConduitAPIMethod.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionBranchTableController' => 'applications/diffusion/controller/DiffusionBranchTableController.php',
'DiffusionBranchTableView' => 'applications/diffusion/view/DiffusionBranchTableView.php',
'DiffusionBrowseController' => 'applications/diffusion/controller/DiffusionBrowseController.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionBrowseQueryConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionBrowseQueryConduitAPIMethod.php',
Diffusion - move DiffusionBrowseQuery => Conduit Summary: see title. Ref T2784. Test Plan: In diffusion, for each of SVN, Mercurial, and Git, I loaded up /diffusion/CALLSIGN/. I verified the README was displayed and things looked good. Next I clicked on "browse" on the top-most commit and verified things looked correct. Also clicked through to a file for a good measure and things looked good. In owners, for each of SVN, Mercurial, and Git, I played around with the path typeahead / validator. It worked correctly! Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5883
2013-05-10 20:02:58 +02:00
'DiffusionBrowseResultSet' => 'applications/diffusion/data/DiffusionBrowseResultSet.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionBrowseTableView' => 'applications/diffusion/view/DiffusionBrowseTableView.php',
Provide a fast path for resolving repository refs Summary: Ref T2783. With service-oriented calls, we take a larger performacne hit than necessary resolving refs. Instead of resolving refs over the wire, try to resolve them from the database first. This can resolve almost all refs (commit hashes, branch and tag names). This can't resolve weird refs like `master~50`, and obviously can't resolve invalid refs. In those cases we'll go back to the old logic, call `diffusion.resolverefs`, and end up with the right result. Test Plan: - Browsed repositories in Diffusion. - Verified that service repositories no longer make unnecessary `diffusion.resolverefs` calls for common refs (branch names, commit hashes). - Resolved refs like `master~50`, saw call to underlying VCS and correct result. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2783 Differential Revision: https://secure.phabricator.com/D11476
2015-01-23 22:31:17 +01:00
'DiffusionCachedResolveRefsQuery' => 'applications/diffusion/query/DiffusionCachedResolveRefsQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionChangeController' => 'applications/diffusion/controller/DiffusionChangeController.php',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'DiffusionChangeHeraldFieldGroup' => 'applications/diffusion/herald/DiffusionChangeHeraldFieldGroup.php',
Extract repository command construction from Repositories Summary: Ref T4292. Ref T10366. Depends on D15751. Today, generating repository commands is purely a function of the repository, so they use protocols and credentials based on the repository configuration. For example, a repository with an SSH "remote URI" always generate SSH "remote commands". This needs to change in the future: - After T10366, repositories won't necessarily just have one type of remote URI. They can only have one at a time still, but the repository itself won't change based on which one is currently active. - For T4292, I need to generate intracluster commands, regardless of repository configuration. These will have different protocols and credentials. Prepare for these cases by separating out command construction, so they'll be able to generate commands in a more flexible way. Test Plan: - Added unit tests. - Browsed diffusion. - Ran `bin/phd debug pull` to pull a bunch of repos. - Ran daemons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4292, T10366 Differential Revision: https://secure.phabricator.com/D15752
2016-04-19 00:22:52 +02:00
'DiffusionCommandEngine' => 'applications/diffusion/protocol/DiffusionCommandEngine.php',
'DiffusionCommandEngineTestCase' => 'applications/diffusion/protocol/__tests__/DiffusionCommandEngineTestCase.php',
Modularize all Diffusion commit Herald fields Summary: Ref T8726. Test Plan: Created a giant rule with every commit field: {F594686} Ran the upgrade, got the same rule with new fields: {F594688} Used "Test Console" to run transcripts, saw all the fields populate correctly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13567
2015-07-07 20:53:17 +02:00
'DiffusionCommitAffectedFilesHeraldField' => 'applications/diffusion/herald/DiffusionCommitAffectedFilesHeraldField.php',
'DiffusionCommitAuthorHeraldField' => 'applications/diffusion/herald/DiffusionCommitAuthorHeraldField.php',
'DiffusionCommitAutocloseHeraldField' => 'applications/diffusion/herald/DiffusionCommitAutocloseHeraldField.php',
Load commit branches and tags by AJAX Summary: Each query takes over 2 seconds in FBCODE. I didn't find a way how to speed them up. There's also no easy way how to parallelize them at least. So AJAX is the last instance. Test Plan: Loaded commit with one branch and no tag. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3112
2012-08-01 01:27:48 +02:00
'DiffusionCommitBranchesController' => 'applications/diffusion/controller/DiffusionCommitBranchesController.php',
Modularize all Diffusion commit Herald fields Summary: Ref T8726. Test Plan: Created a giant rule with every commit field: {F594686} Ran the upgrade, got the same rule with new fields: {F594688} Used "Test Console" to run transcripts, saw all the fields populate correctly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13567
2015-07-07 20:53:17 +02:00
'DiffusionCommitBranchesHeraldField' => 'applications/diffusion/herald/DiffusionCommitBranchesHeraldField.php',
'DiffusionCommitCommitterHeraldField' => 'applications/diffusion/herald/DiffusionCommitCommitterHeraldField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionCommitController' => 'applications/diffusion/controller/DiffusionCommitController.php',
Modularize all Diffusion commit Herald fields Summary: Ref T8726. Test Plan: Created a giant rule with every commit field: {F594686} Ran the upgrade, got the same rule with new fields: {F594688} Used "Test Console" to run transcripts, saw all the fields populate correctly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13567
2015-07-07 20:53:17 +02:00
'DiffusionCommitDiffContentAddedHeraldField' => 'applications/diffusion/herald/DiffusionCommitDiffContentAddedHeraldField.php',
'DiffusionCommitDiffContentHeraldField' => 'applications/diffusion/herald/DiffusionCommitDiffContentHeraldField.php',
'DiffusionCommitDiffContentRemovedHeraldField' => 'applications/diffusion/herald/DiffusionCommitDiffContentRemovedHeraldField.php',
'DiffusionCommitDiffEnormousHeraldField' => 'applications/diffusion/herald/DiffusionCommitDiffEnormousHeraldField.php',
Allow commits to be associated with projects and associated goodies Summary: - Commit detail view - List of projects - "edit" action which takes the user to a simple form where they can only add / remove projects. - Integrated the project relationship into the commit search indexer - fixed a bug from D790; it seems you must select the column if you're going to join against it later. Without this change searching for author or projectfails 100% for me. Test Plan: added and removed projects. verified appropriate projects showed up in detail and edit view. searched for commits by project and found the ones I was supposed to...! Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1614 Differential Revision: https://secure.phabricator.com/D3189
2012-08-08 19:03:41 +02:00
'DiffusionCommitEditController' => 'applications/diffusion/controller/DiffusionCommitEditController.php',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'DiffusionCommitFulltextEngine' => 'applications/repository/search/DiffusionCommitFulltextEngine.php',
Migrate Differential revision edges to use modern `EdgeType` subclasses Summary: Modernize Differential edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: From previous experience, these changes are fairly trivial and safe. I poked around a little to make sure things looked reasonably okay. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, Krenair, epriestley Differential Revision: https://secure.phabricator.com/D11074
2015-01-01 04:43:26 +01:00
'DiffusionCommitHasRevisionEdgeType' => 'applications/diffusion/edge/DiffusionCommitHasRevisionEdgeType.php',
Modernize commit/edge transaction when parsing commit messages Summary: Ref T5245. With work elsewhere (notably, D9839) we can remove this TODO and use real transactions. Test Plan: Pushed a `closes Txxx` commit and got a close + transaction. Reviewers: chad, btrahan, joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5245 Differential Revision: https://secure.phabricator.com/D9848
2014-07-18 00:42:06 +02:00
'DiffusionCommitHasTaskEdgeType' => 'applications/diffusion/edge/DiffusionCommitHasTaskEdgeType.php',
Move commit hash querying to DiffusionLowLevelCommitQuery Summary: Ref T4195. I need this for the Herald pre-commit rules, and it generally simplifies things. Test Plan: Used `reparse.php` plus `var_dump()` to inspect refs in Git, Mercurial and SVN repos. They all looked correct and reparsed correctly. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7804
2013-12-20 21:38:15 +01:00
'DiffusionCommitHash' => 'applications/diffusion/data/DiffusionCommitHash.php',
Modularize all Diffusion commit Herald fields Summary: Ref T8726. Test Plan: Created a giant rule with every commit field: {F594686} Ran the upgrade, got the same rule with new fields: {F594688} Used "Test Console" to run transcripts, saw all the fields populate correctly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13567
2015-07-07 20:53:17 +02:00
'DiffusionCommitHeraldField' => 'applications/diffusion/herald/DiffusionCommitHeraldField.php',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'DiffusionCommitHeraldFieldGroup' => 'applications/diffusion/herald/DiffusionCommitHeraldFieldGroup.php',
Install pre-commit hooks in Git repositories Summary: Ref T4189. T4189 describes most of the intent here: - When updating hosted repositories, sync a pre-commit hook into them instead of doing a `git fetch`. - The hook calls into Phabricator. The acting Phabricator user is sent via PHABRICATOR_USER in the environment. The active repository is sent via CLI. - The hook doesn't do anything useful yet; it just veifies basic parameters, does a little parsing, and exits 0 to allow the commit. Test Plan: - Performed Git pushes and pulls over SSH and HTTP. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4189 Differential Revision: https://secure.phabricator.com/D7682
2013-12-03 00:45:36 +01:00
'DiffusionCommitHookEngine' => 'applications/diffusion/engine/DiffusionCommitHookEngine.php',
Reject dangerous changes in Git repositories by default Summary: Ref T4189. This adds a per-repository "dangerous changes" flag, which defaults to off. This flag must be enabled to do non-appending branch mutation (delete branches / rewrite history). Test Plan: With flag on and off, performed various safe and dangerous pushes. >>> orbital ~/repos/POEMS $ git push origin :blarp remote: +---------------------------------------------------------------+ remote: | * * * PUSH REJECTED BY EVIL DRAGON BUREAUCRATS * * * | remote: +---------------------------------------------------------------+ remote: \ remote: \ ^ /^ remote: \ / \ // \ remote: \ |\___/| / \// .\ remote: \ /V V \__ / // | \ \ *----* remote: / / \/_/ // | \ \ \ | remote: @___@` \/_ // | \ \ \/\ \ remote: 0/0/| \/_ // | \ \ \ \ remote: 0/0/0/0/| \/// | \ \ | | remote: 0/0/0/0/0/_|_ / ( // | \ _\ | / remote: 0/0/0/0/0/0/`/,_ _ _/ ) ; -. | _ _\.-~ / / remote: ,-} _ *-.|.-~-. .~ ~ remote: \ \__/ `/\ / ~-. _ .-~ / remote: \____(Oo) *. } { / remote: ( (--) .----~-.\ \-` .~ remote: //__\\ \ DENIED! ///.----..< \ _ -~ remote: // \\ ///-._ _ _ _ _ _ _{^ - - - - ~ remote: remote: remote: DANGEROUS CHANGE: The change you're attempting to push deletes the branch 'blarp'. remote: Dangerous change protection is enabled for this repository. remote: Edit the repository configuration before making dangerous changes. remote: To ssh://dweller@localhost/diffusion/POEMS/ ! [remote rejected] blarp (pre-receive hook declined) error: failed to push some refs to 'ssh://dweller@localhost/diffusion/POEMS/' Reviewers: btrahan Reviewed By: btrahan CC: aran, chad, richardvanvelzen Maniphest Tasks: T4189 Differential Revision: https://secure.phabricator.com/D7689
2013-12-03 19:28:39 +01:00
'DiffusionCommitHookRejectException' => 'applications/diffusion/exception/DiffusionCommitHookRejectException.php',
Add "Is merge commit?" to commit fields in Herald Summary: Fixes T5788. We already have this as a pre-commit field, add it as a post-commit field too. Test Plan: Ran this rule on a merge commit. Also ran it on a non-merge commit. Both got the correct value. Reviewers: avivey, chad Reviewed By: avivey, chad Subscribers: avivey Maniphest Tasks: T5788 Differential Revision: https://secure.phabricator.com/D14685
2015-12-05 21:54:51 +01:00
'DiffusionCommitMergeHeraldField' => 'applications/diffusion/herald/DiffusionCommitMergeHeraldField.php',
Modularize all Diffusion commit Herald fields Summary: Ref T8726. Test Plan: Created a giant rule with every commit field: {F594686} Ran the upgrade, got the same rule with new fields: {F594688} Used "Test Console" to run transcripts, saw all the fields populate correctly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13567
2015-07-07 20:53:17 +02:00
'DiffusionCommitMessageHeraldField' => 'applications/diffusion/herald/DiffusionCommitMessageHeraldField.php',
'DiffusionCommitPackageAuditHeraldField' => 'applications/diffusion/herald/DiffusionCommitPackageAuditHeraldField.php',
'DiffusionCommitPackageHeraldField' => 'applications/diffusion/herald/DiffusionCommitPackageHeraldField.php',
'DiffusionCommitPackageOwnerHeraldField' => 'applications/diffusion/herald/DiffusionCommitPackageOwnerHeraldField.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionCommitParentsQueryConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionCommitParentsQueryConduitAPIMethod.php',
Prepare Diffusion for hovercards Summary: Move Diffusion to be hovercard-ready, and expand our ability to resolve commit references. - Link unqualified hashes of 7 characters or more which match a commit. - Link qualified hashes of 5 characters or more which match a commit. - Support `{...}` syntax. Test Plan: {F33896} Reviewers: chad, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5121
2013-02-27 17:04:54 +01:00
'DiffusionCommitQuery' => 'applications/diffusion/query/DiffusionCommitQuery.php',
Move git commit metadata parsing into a LowLevelQuery Summary: Ref T4195. I need to issue this command from the pre-commit hook to get commit bodies for hooks. Test Plan: Ran `reparse.php --message --trace` and dumped the $ref, which looked correct. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7793
2013-12-19 02:48:06 +01:00
'DiffusionCommitRef' => 'applications/diffusion/data/DiffusionCommitRef.php',
Add a Diffusion repository remarkup rule Summary: Currently we markup `rXabcd`, but not `rX` on its own. Mark these up as repository object names. Test Plan: Typed `rPOEMS`, `rPOEMS1`, `rPOEMS139893189`, etc. Reviewers: btrahan, dctrwatson Reviewed By: btrahan CC: aran, poop Differential Revision: https://secure.phabricator.com/D7859
2013-12-31 20:08:08 +01:00
'DiffusionCommitRemarkupRule' => 'applications/diffusion/remarkup/DiffusionCommitRemarkupRule.php',
Fix an issue with tail parsing in object embeds in remarkup Summary: Fixes T6619. In `{Xnnn key=value, key=value}` we did not require a separator between the object and the key-value part. This could lead to `{rX11aaa}` being parsed as `{rX11 aaa}`, i.e. a reference to `rX11` with parameter `aaa` set. Instead, require a space or comma before we'll parse key-value parts of embedded objects. Test Plan: Added and executed unit tests. {F242002} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6619 Differential Revision: https://secure.phabricator.com/D10915
2014-12-02 03:48:20 +01:00
'DiffusionCommitRemarkupRuleTestCase' => 'applications/diffusion/remarkup/__tests__/DiffusionCommitRemarkupRuleTestCase.php',
Modularize all Diffusion commit Herald fields Summary: Ref T8726. Test Plan: Created a giant rule with every commit field: {F594686} Ran the upgrade, got the same rule with new fields: {F594688} Used "Test Console" to run transcripts, saw all the fields populate correctly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13567
2015-07-07 20:53:17 +02:00
'DiffusionCommitRepositoryHeraldField' => 'applications/diffusion/herald/DiffusionCommitRepositoryHeraldField.php',
'DiffusionCommitRepositoryProjectsHeraldField' => 'applications/diffusion/herald/DiffusionCommitRepositoryProjectsHeraldField.php',
Write edges for commit reverts Summary: Ref T1751. When a commit reverts another commit: - Add an edge linking them; - Show the edge in Diffusion. Next steps are: - If the reverted commit is associated with a Differential revision, leave a comment; - Also leave a comment on the commit (no API yet); - Also trigger an audit by the original commit's author. Test Plan: Used `scripts/repository/reparse.php --message ...` to parse commits with revert language. Verified they appear correctly in Diffusion, and update Differential. Reviewers: btrahan, epriestley Reviewed By: btrahan, epriestley Subscribers: Korvin, epriestley, cburroughs, joshuaspence, sascha-egerer, aran Maniphest Tasks: T4896, T1751 Differential Revision: https://secure.phabricator.com/D5846
2015-01-04 20:52:38 +01:00
'DiffusionCommitRevertedByCommitEdgeType' => 'applications/diffusion/edge/DiffusionCommitRevertedByCommitEdgeType.php',
'DiffusionCommitRevertsCommitEdgeType' => 'applications/diffusion/edge/DiffusionCommitRevertsCommitEdgeType.php',
Modularize all Diffusion commit Herald fields Summary: Ref T8726. Test Plan: Created a giant rule with every commit field: {F594686} Ran the upgrade, got the same rule with new fields: {F594688} Used "Test Console" to run transcripts, saw all the fields populate correctly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13567
2015-07-07 20:53:17 +02:00
'DiffusionCommitReviewerHeraldField' => 'applications/diffusion/herald/DiffusionCommitReviewerHeraldField.php',
'DiffusionCommitRevisionAcceptedHeraldField' => 'applications/diffusion/herald/DiffusionCommitRevisionAcceptedHeraldField.php',
'DiffusionCommitRevisionHeraldField' => 'applications/diffusion/herald/DiffusionCommitRevisionHeraldField.php',
'DiffusionCommitRevisionReviewersHeraldField' => 'applications/diffusion/herald/DiffusionCommitRevisionReviewersHeraldField.php',
'DiffusionCommitRevisionSubscribersHeraldField' => 'applications/diffusion/herald/DiffusionCommitRevisionSubscribersHeraldField.php',
Load commit branches and tags by AJAX Summary: Each query takes over 2 seconds in FBCODE. I didn't find a way how to speed them up. There's also no easy way how to parallelize them at least. So AJAX is the last instance. Test Plan: Loaded commit with one branch and no tag. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3112
2012-08-01 01:27:48 +02:00
'DiffusionCommitTagsController' => 'applications/diffusion/controller/DiffusionCommitTagsController.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionConduitAPIMethod.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionController' => 'applications/diffusion/controller/DiffusionController.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionCreateCommentConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionCreateCommentConduitAPIMethod.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'DiffusionCreateRepositoriesCapability' => 'applications/diffusion/capability/DiffusionCreateRepositoriesCapability.php',
'DiffusionDefaultEditCapability' => 'applications/diffusion/capability/DiffusionDefaultEditCapability.php',
'DiffusionDefaultPushCapability' => 'applications/diffusion/capability/DiffusionDefaultPushCapability.php',
'DiffusionDefaultViewCapability' => 'applications/diffusion/capability/DiffusionDefaultViewCapability.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionDiffController' => 'applications/diffusion/controller/DiffusionDiffController.php',
Extend TransactionCommentQuery for Diffusion Summary: Ref T2009. Ref T1460. Reduces the amount of garbage involved in loading inline comments and routes more pathways through the proper Query layer. Test Plan: Viewed, edited, previewed, submitted inline comments in Diffusion. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2009, T1460 Differential Revision: https://secure.phabricator.com/D12028
2015-03-09 20:50:33 +01:00
'DiffusionDiffInlineCommentQuery' => 'applications/diffusion/query/DiffusionDiffInlineCommentQuery.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionDiffQueryConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionDiffQueryConduitAPIMethod.php',
Add commits/audits to Asana bridge Summary: Ref T2852. Adds sync for commits/audits. Test Plan: {F51660} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6573
2013-07-26 19:31:35 +02:00
'DiffusionDoorkeeperCommitFeedStoryPublisher' => 'applications/diffusion/doorkeeper/DiffusionDoorkeeperCommitFeedStoryPublisher.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionEmptyResultView' => 'applications/diffusion/view/DiffusionEmptyResultView.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionExistsQueryConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionExistsQueryConduitAPIMethod.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionExternalController' => 'applications/diffusion/controller/DiffusionExternalController.php',
Framework for external symbol search Summary: Ref T7984. With this, an install can add an ExternalSymbolsSource to src/extensions, which will include whatever source they have. Test Plan: search for php and python builtins. Reviewers: joshuaspence, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7984 Differential Revision: https://secure.phabricator.com/D13036
2015-05-31 16:36:54 +02:00
'DiffusionExternalSymbolQuery' => 'applications/diffusion/symbol/DiffusionExternalSymbolQuery.php',
'DiffusionExternalSymbolsSource' => 'applications/diffusion/symbol/DiffusionExternalSymbolsSource.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionFileContentQuery' => 'applications/diffusion/query/filecontent/DiffusionFileContentQuery.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionFileContentQueryConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionFileContentQueryConduitAPIMethod.php',
'DiffusionFindSymbolsConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionFindSymbolsConduitAPIMethod.php',
'DiffusionGetLintMessagesConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionGetLintMessagesConduitAPIMethod.php',
'DiffusionGetRecentCommitsByPathConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionGetRecentCommitsByPathConduitAPIMethod.php',
Implement a dedicated "diffusion.blame" API method Summary: Fixes T2451. Several motivations here, from strongest to weakest: - Currently, getting blame and file content are closely entwined. This makes fixing T9319 more difficult, and I want to fix it. I want to separate blame from content so there's more flexibility in how we approach this issue. - This makes pursuing T2450 easier, if it turns out to be a meaningful win. - If we can get a win on blame performance, we can do `arc blame` eventually if we want. Test Plan: - Blamed in SVN, Git and Mercurial. Reviewers: chad Reviewed By: chad Maniphest Tasks: T2451 Differential Revision: https://secure.phabricator.com/D14957
2016-01-06 13:56:27 +01:00
'DiffusionGitBlameQuery' => 'applications/diffusion/query/blame/DiffusionGitBlameQuery.php',
DiffusionBranchQuery => Conduit Summary: ref T2784. This one had a few fun spots where I had to move data around. Also, is there some common object (or should I add it?) that can do this toDictionary newFromConduit stuff? Also, this assumes D5803 is largely correct at the time of this diff. Test Plan: browsed mercurial and git repository page. saw the branches i expected. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5810
2013-05-01 23:56:36 +02:00
'DiffusionGitBranch' => 'applications/diffusion/data/DiffusionGitBranch.php',
'DiffusionGitBranchTestCase' => 'applications/diffusion/data/__tests__/DiffusionGitBranchTestCase.php',
Extract repository command construction from Repositories Summary: Ref T4292. Ref T10366. Depends on D15751. Today, generating repository commands is purely a function of the repository, so they use protocols and credentials based on the repository configuration. For example, a repository with an SSH "remote URI" always generate SSH "remote commands". This needs to change in the future: - After T10366, repositories won't necessarily just have one type of remote URI. They can only have one at a time still, but the repository itself won't change based on which one is currently active. - For T4292, I need to generate intracluster commands, regardless of repository configuration. These will have different protocols and credentials. Prepare for these cases by separating out command construction, so they'll be able to generate commands in a more flexible way. Test Plan: - Added unit tests. - Browsed diffusion. - Ran `bin/phd debug pull` to pull a bunch of repos. - Ran daemons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4292, T10366 Differential Revision: https://secure.phabricator.com/D15752
2016-04-19 00:22:52 +02:00
'DiffusionGitCommandEngine' => 'applications/diffusion/protocol/DiffusionGitCommandEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionGitFileContentQuery' => 'applications/diffusion/query/filecontent/DiffusionGitFileContentQuery.php',
Implement "git-lfs-authenticate" over SSH Summary: Ref T7789. This implements a (probably) usable "git-lfs-authenticate" on top of the new temporary token infrastructure. This won't actually do anything yet, since nothing reads the tokens. Test Plan: ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate' phabricator-ssh-exec: Expected `git-lfs-authenticate <path> <operation>`, but received too few arguments. ``` ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate x' phabricator-ssh-exec: Unrecognized repository path "x". Expected a path like "/diffusion/X/" or "/diffusion/123/". ``` ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate diffusion/22' Exception: Expected `git-lfs-authenticate <path> <operation>`, but received too few arguments. ``` ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate diffusion/22 y' Exception: Git LFS operation "y" is not supported by this server. ``` ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate diffusion/22 upload' {"header":{"Authorization":"Basic QGdpdC1sZnM6NmR2bDVreWVsaXNuMmtnNXBtbnZwM3VlaWhubmI1bmI="},"href":"http:\/\/local.phacility.com\/diffusion\/22\/new-callsign-free-repository.git\/info\/lfs"} ``` Reviewers: chad Reviewed By: chad Maniphest Tasks: T7789 Differential Revision: https://secure.phabricator.com/D15482
2016-03-16 15:44:25 +01:00
'DiffusionGitLFSAuthenticateWorkflow' => 'applications/diffusion/gitlfs/DiffusionGitLFSAuthenticateWorkflow.php',
Implement a Git LFS server which supports no operations Summary: Ref T7789. This builds on top of `git-lfs-authenticate` to detect LFS requests, read LFS tokens, and route them to a handler which can do useful things. This handler promptly drops them on the floor with an error message. Test Plan: Here's a transcript showing the parts working together so far: - `git-lfs` connects to the server with SSH, and gets told how to connect with HTTP to do uploads. - `git-lfs` uses HTTP, and authenticates with the tokens properly. - But the server tells it to go away, and that it doesn't support anything, so the operation ultimately fails. ``` $ GIT_TRACE=1 git lfs push origin master 12:45:56.153913 git.c:558 trace: exec: 'git-lfs' 'push' 'origin' 'master' 12:45:56.154376 run-command.c:335 trace: run_command: 'git-lfs' 'push' 'origin' 'master' trace git-lfs: Upload refs origin to remote [master] trace git-lfs: run_command: git rev-list --objects master --not --remotes=origin trace git-lfs: run_command: git cat-file --batch-check trace git-lfs: run_command: git cat-file --batch trace git-lfs: run_command: 'git' config -l trace git-lfs: tq: starting 3 transfer workers trace git-lfs: tq: running as batched queue, batch size of 100 trace git-lfs: prepare upload: b7e0aeb82a03d627c6aa5fc1bbfd454b6789d9d9affc8607d40168fa18cf6c69 lfs/dog1.jpg 1/1 trace git-lfs: tq: sending batch of size 1 trace git-lfs: ssh: local@localvault.phacility.com git-lfs-authenticate diffusion/18/poems.git upload trace git-lfs: api: batch 1 files trace git-lfs: HTTP: POST http://local.phacility.com/diffusion/POEMS/poems.git/info/lfs/objects/batch trace git-lfs: HTTP: 404 trace git-lfs: HTTP: {"message":"Git LFS operation \"objects\/batch\" is not supported by this server."} trace git-lfs: HTTP: trace git-lfs: api: batch not implemented: 404 trace git-lfs: run_command: 'git' config lfs.batch false trace git-lfs: tq: batch api not implemented, falling back to individual trace git-lfs: ssh: local@localvault.phacility.com git-lfs-authenticate diffusion/18/poems.git upload b7e0aeb82a03d627c6aa5fc1bbfd454b6789d9d9affc8607d40168fa18cf6c69 trace git-lfs: api: uploading (b7e0aeb82a03d627c6aa5fc1bbfd454b6789d9d9affc8607d40168fa18cf6c69) trace git-lfs: HTTP: POST http://local.phacility.com/diffusion/POEMS/poems.git/info/lfs/objects trace git-lfs: HTTP: 404 trace git-lfs: HTTP: {"message":"Git LFS operation \"objects\" is not supported by this server."} trace git-lfs: HTTP: trace git-lfs: tq: retrying 1 failed transfers trace git-lfs: ssh: local@localvault.phacility.com git-lfs-authenticate diffusion/18/poems.git upload b7e0aeb82a03d627c6aa5fc1bbfd454b6789d9d9affc8607d40168fa18cf6c69 trace git-lfs: api: uploading (b7e0aeb82a03d627c6aa5fc1bbfd454b6789d9d9affc8607d40168fa18cf6c69) trace git-lfs: HTTP: POST http://local.phacility.com/diffusion/POEMS/poems.git/info/lfs/objects trace git-lfs: HTTP: 404 trace git-lfs: HTTP: {"message":"Git LFS operation \"objects\" is not supported by this server."} trace git-lfs: HTTP: Git LFS: (0 of 1 files) 0 B / 87.12 KB Git LFS operation "objects" is not supported by this server. Git LFS operation "objects" is not supported by this server. ``` Reviewers: chad Reviewed By: chad Subscribers: eadler Maniphest Tasks: T7789 Differential Revision: https://secure.phabricator.com/D15485
2016-03-16 20:42:21 +01:00
'DiffusionGitLFSResponse' => 'applications/diffusion/response/DiffusionGitLFSResponse.php',
Implement "git-lfs-authenticate" over SSH Summary: Ref T7789. This implements a (probably) usable "git-lfs-authenticate" on top of the new temporary token infrastructure. This won't actually do anything yet, since nothing reads the tokens. Test Plan: ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate' phabricator-ssh-exec: Expected `git-lfs-authenticate <path> <operation>`, but received too few arguments. ``` ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate x' phabricator-ssh-exec: Unrecognized repository path "x". Expected a path like "/diffusion/X/" or "/diffusion/123/". ``` ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate diffusion/22' Exception: Expected `git-lfs-authenticate <path> <operation>`, but received too few arguments. ``` ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate diffusion/22 y' Exception: Git LFS operation "y" is not supported by this server. ``` ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate diffusion/22 upload' {"header":{"Authorization":"Basic QGdpdC1sZnM6NmR2bDVreWVsaXNuMmtnNXBtbnZwM3VlaWhubmI1bmI="},"href":"http:\/\/local.phacility.com\/diffusion\/22\/new-callsign-free-repository.git\/info\/lfs"} ``` Reviewers: chad Reviewed By: chad Maniphest Tasks: T7789 Differential Revision: https://secure.phabricator.com/D15482
2016-03-16 15:44:25 +01:00
'DiffusionGitLFSTemporaryTokenType' => 'applications/diffusion/gitlfs/DiffusionGitLFSTemporaryTokenType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionGitRawDiffQuery' => 'applications/diffusion/query/rawdiff/DiffusionGitRawDiffQuery.php',
Rename `DiffusionSSHWorkflow` subclasses for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11185
2015-01-04 20:33:18 +01:00
'DiffusionGitReceivePackSSHWorkflow' => 'applications/diffusion/ssh/DiffusionGitReceivePackSSHWorkflow.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionGitRequest' => 'applications/diffusion/request/DiffusionGitRequest.php',
Serve Git reads over HTTP Summary: Mostly ripped from D7391. No writes yet. Test Plan: Ran `git clone` against a local over HTTP, got a clone. Reviewers: btrahan, hach-que Reviewed By: hach-que CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7423
2013-10-26 21:10:52 +02:00
'DiffusionGitResponse' => 'applications/diffusion/response/DiffusionGitResponse.php',
Rename `DiffusionSSHWorkflow` subclasses for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11185
2015-01-04 20:33:18 +01:00
'DiffusionGitSSHWorkflow' => 'applications/diffusion/ssh/DiffusionGitSSHWorkflow.php',
'DiffusionGitUploadPackSSHWorkflow' => 'applications/diffusion/ssh/DiffusionGitUploadPackSSHWorkflow.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionHistoryController' => 'applications/diffusion/controller/DiffusionHistoryController.php',
Fix misspelled file name Summary: This class was renamed in D9991, but the filename is incorrect. Test Plan: Eyeball it Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D10117
2014-08-02 09:05:49 +02:00
'DiffusionHistoryQueryConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionHistoryQueryConduitAPIMethod.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionHistoryTableView' => 'applications/diffusion/view/DiffusionHistoryTableView.php',
Modernize Hovercard implementation Summary: Ref T8980. Move away from events to EngineExtensions. This also simplifies hovercards a bit: - Removes tasks from revision cards. - Removes blockers/blocked from task cards. - Removes "Send Message" from user cards. These mostly felt cluttery to me. Open to arguments to retain them. I think we can make better use of the space, though (e.g., flags, projects + board columns). Test Plan: - Viewed people, task, revision, commit and project hovercards. {F1043256} {F1043257} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8980 Differential Revision: https://secure.phabricator.com/D14878
2015-12-24 20:20:18 +01:00
'DiffusionHovercardEngineExtension' => 'applications/diffusion/engineextension/DiffusionHovercardEngineExtension.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionInlineCommentController' => 'applications/diffusion/controller/DiffusionInlineCommentController.php',
Make inline comment preview work in Diffusion Summary: created a PhabricatorInlineCommentPreviewController so controllers in Diffusion and Differential respectively just have to handle the URI mapping and data loading like good little controllers. Test Plan: left inline comments on commits, deleted inline commits, submitted inline comments -- all worked well did the same on some diffs Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1176 Differential Revision: https://secure.phabricator.com/D3034
2012-07-23 20:01:28 +02:00
'DiffusionInlineCommentPreviewController' => 'applications/diffusion/controller/DiffusionInlineCommentPreviewController.php',
Use Conduit in PhabricatorRepositoryGitCommitChangeParserWorker Summary: Ref T2783. This allows this worker to run on a machine different to the one that stores the repository, by routing the execution of Git over Conduit calls. This API method is super gross, but fixing it isn't straightforward and it runs into other complicated considerations. We can fix it later; for now, just define it as "internal" to limit how much mess this creates. "Internal" methods do not appear on the console. Test Plan: Ran `bin/repository reparse --change <commit> --trace` on several commits, saw daemons make a Conduit call instead of running a `git` command. Reviewers: hach-que, chad Reviewed By: chad Subscribers: joshuaspence, Korvin, epriestley Maniphest Tasks: T2783 Differential Revision: https://secure.phabricator.com/D11874
2016-04-08 22:08:56 +02:00
'DiffusionInternalGitRawDiffQueryConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionInternalGitRawDiffQueryConduitAPIMethod.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionLastModifiedController' => 'applications/diffusion/controller/DiffusionLastModifiedController.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionLastModifiedQueryConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionLastModifiedQueryConduitAPIMethod.php',
Display lint overview in Diffusion Summary: I will add links from /diffusion/ARC/lint/ in future diff. Test Plan: /diffusion/ - clicked on lint messages link. /diffusion/ARC/ - clicked on lint messages link. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3926
2012-11-08 20:11:44 +01:00
'DiffusionLintController' => 'applications/diffusion/controller/DiffusionLintController.php',
Implement a lint count query Summary: Ref T2683. This query is currently unbatched and happens inside a view. Leave it inside the view for now, but separate it and make it batchable. Test Plan: {F34848} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley, vrana, aran Maniphest Tasks: T2683 Differential Revision: https://secure.phabricator.com/D5252
2014-05-11 00:21:05 +02:00
'DiffusionLintCountQuery' => 'applications/diffusion/query/DiffusionLintCountQuery.php',
Simplify and optimize save_lint.php Test Plan: Ran it. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2038 Differential Revision: https://secure.phabricator.com/D3933
2012-11-09 03:37:15 +01:00
'DiffusionLintSaveRunner' => 'applications/diffusion/DiffusionLintSaveRunner.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionLookSoonConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionLookSoonConduitAPIMethod.php',
Move commit message/metadata field query to a separate class Summary: Ref T4195. I need to query commit metadata to figure out which revision a commit is associated with. Move this out of the MessageParser so the code can be called from the HookEngine. Test Plan: Used `reparse.php` to reparse a variety of SVN, Mercurial and Git commits. Used `var_dump()` to verify sensible fields were returned. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7805
2013-12-20 21:38:44 +01:00
'DiffusionLowLevelCommitFieldsQuery' => 'applications/diffusion/query/lowlevel/DiffusionLowLevelCommitFieldsQuery.php',
Provide a low-level SVN commit query, and merge the VCS query types Summary: Ref T4195. Even though we use `svnlook` in the hook itself, I need this query elsewhere, so provide it and merge the classes into one which does the right thing. Test Plan: - Used `reparse.php` to reparse messages for Git, SVN and Mercurial commits, using `var_dump()` to examine the commit refs for sanity. - Used `reparse.php` to reparse changes for an SVN commit. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7800
2013-12-19 20:05:06 +01:00
'DiffusionLowLevelCommitQuery' => 'applications/diffusion/query/lowlevel/DiffusionLowLevelCommitQuery.php',
Consolidate querying of things which we can use `git for-each-ref` for Summary: Ref T2230. This cleans up D7442, by using `git for-each-ref` everywhere we can, in a basically reasonable way. Test Plan: In bare and non-bare repositories: - Ran discovery with `bin/repository discover`; - listed branches on `/diffusion/X/`; - listed tags on `/diffusion/X/`; - listed tags, branches and refs on `/diffusion/rXnnnn`. Reviewers: btrahan, avivey Reviewed By: avivey CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7447
2013-10-30 21:06:09 +01:00
'DiffusionLowLevelGitRefQuery' => 'applications/diffusion/query/lowlevel/DiffusionLowLevelGitRefQuery.php',
Clean up `hg --debug branches` calls Summary: Ref T1493. Consolidate these a bit; they might need some more magic once we do `--noupdate` checkouts. Mostly just trying to clean up and centralize this code a bit. Test Plan: Viewed and `bin/repository discover`'d Mercurial repos with and without any branches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1493 Differential Revision: https://secure.phabricator.com/D7480
2013-11-04 21:15:32 +01:00
'DiffusionLowLevelMercurialBranchesQuery' => 'applications/diffusion/query/lowlevel/DiffusionLowLevelMercurialBranchesQuery.php',
Diffusion - replace last `hg manifest` call with `hg locate` Summary: Fixes T4387. Test Plan: Setup a mercurial repository for rabbitmq-server. Browsed around it and things looked good. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4387 Differential Revision: https://secure.phabricator.com/D10380
2014-08-28 22:08:42 +02:00
'DiffusionLowLevelMercurialPathsQuery' => 'applications/diffusion/query/lowlevel/DiffusionLowLevelMercurialPathsQuery.php',
Conditionally use `hg files` vs. `hg locate` depending on version of Mercurial Summary: In Mercurial 3.2 the `locate` command was deprecated in favor of `files` command. This change updates the DiffusionLowLevelMercurialPathsQuery command to conditionally use `locate` or `files` based on the version of Mercurial used. Closes T7375 Test Plan: My test/develop Phabricator instance is setup to run Mercurial 3.5.1. The test procedure to verify valid file listings are being returned: 1. I navigated to `http://192.168.0.133/conduit/method/diffusion.querypaths/` 2. I populated the following fields: - path: `"/"` - commit: `"d721d5b57fc9ef72e47ff9d4e0c583d74a46590c"` - callsign: `"HGTEST"` 3. I submitted request and verified that result contained all files in the repository: ``` { "0": "README", "1": "alpha/beta/trifle", "2": "test/Chupacabra.cow", "3": "test/socket.ks" } ``` I repeated the above steps after setting up Mercurial 2.6.2, which I installed in the following manner: 1. I downloaded Mercurial 2.6.2 source and run `make local` which will only compile it to work from its own directory (`/opt/mercurial-2.6.2`) 2. I linked `/usr/local/bin/hg -> /opt/mercurial-2.6.2/hg` (there's also a `/usr/bin/hg` which is a link to `/usr/local/bin/hg`) 3. I navigated to my home directory and verify that `hg --version` returns 2.6.2. 4. I restarted phabricator services (probably unnecessary). With the Multimeter application active 1. I verified that `/usr/local/bin/hg` referred to version 2.6 2. I ran the same conduit call from the conduit application 3. I verified that `http://192.168.0.133/multimeter/?type=2&group=label` incremented values for `bin.hg locate`. 4. I swapped out mercurial versions for 3.5.1 5. I ran the same conduit call from the conduit application 6. I verified that `http://192.168.0.133/multimeter/?type=2&group=label` incremented values for `bin.hg files` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T7375 Differential Revision: https://secure.phabricator.com/D14253
2015-10-13 02:50:26 +02:00
'DiffusionLowLevelMercurialPathsQueryTests' => 'applications/diffusion/query/lowlevel/__tests__/DiffusionLowLevelMercurialPathsQueryTests.php',
Modernize Diffusion `commitparentsquery` Summary: Ref T4195. Ref T2783. We have an old-school implementation of this; move it into a LowLevel query and make callers all run through Conduit. I need the LowLevel query for hooks, to implement an "is merge commit" Herald rule. Test Plan: - Ran query via Conduit for SVN, Mercurial, Git. - Parsed a commit which closed a revision, attach/closed worked correctly. - Browsed Diffusion. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195, T2783 Differential Revision: https://secure.phabricator.com/D7808
2013-12-20 21:39:21 +01:00
'DiffusionLowLevelParentsQuery' => 'applications/diffusion/query/lowlevel/DiffusionLowLevelParentsQuery.php',
Consolidate querying of things which we can use `git for-each-ref` for Summary: Ref T2230. This cleans up D7442, by using `git for-each-ref` everywhere we can, in a basically reasonable way. Test Plan: In bare and non-bare repositories: - Ran discovery with `bin/repository discover`; - listed branches on `/diffusion/X/`; - listed tags on `/diffusion/X/`; - listed tags, branches and refs on `/diffusion/rXnnnn`. Reviewers: btrahan, avivey Reviewed By: avivey CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7447
2013-10-30 21:06:09 +01:00
'DiffusionLowLevelQuery' => 'applications/diffusion/query/lowlevel/DiffusionLowLevelQuery.php',
Merge "expandshortcommitquery" and "stablecommitnamequery" into "resolverefs" Summary: Ref T1493. Diffusion has some garbagey behavior for things we can't resolve. Common cases are: - Looking at a branch that doesn't exist. - Looking at a repository with no branches. - Looking at a commit that doesn't exist. - Looking at an empty repository. In these cases, we generally fatal unhelpfully. I want to untangle this mess. This doesn't help much, but does clean things up a bit. We currently have two separate query paths, "stablecommitname" and "expandshortcommit". These are pretty much doing the same thing -- taking some ref like "master" or "default" or a tag name or part of a commit name, and turning it into a full commit name. Merge them into a single "resolverefs" method. This simplifies the code a fair bit, and gives us better error messages. They still aren't great, but they're like this now: Ref "7498aec194ecf2d333e0e2baddd9d5cdf922d7f1" is ambiguous or does not exist. ...instead of just: ERR-INVALID-COMMIT Test Plan: Looked at Git, Mercurial and Subversion repositories that were empty and non-empty. Looked at branches/heads. Tried to look at invalid commits. Looked at tags. All of this still works, and some behaviors are a bit better than they used to be. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1493 Differential Revision: https://secure.phabricator.com/D7484
2013-11-04 23:13:07 +01:00
'DiffusionLowLevelResolveRefsQuery' => 'applications/diffusion/query/lowlevel/DiffusionLowLevelResolveRefsQuery.php',
Implement a dedicated "diffusion.blame" API method Summary: Fixes T2451. Several motivations here, from strongest to weakest: - Currently, getting blame and file content are closely entwined. This makes fixing T9319 more difficult, and I want to fix it. I want to separate blame from content so there's more flexibility in how we approach this issue. - This makes pursuing T2450 easier, if it turns out to be a meaningful win. - If we can get a win on blame performance, we can do `arc blame` eventually if we want. Test Plan: - Blamed in SVN, Git and Mercurial. Reviewers: chad Reviewed By: chad Maniphest Tasks: T2451 Differential Revision: https://secure.phabricator.com/D14957
2016-01-06 13:56:27 +01:00
'DiffusionMercurialBlameQuery' => 'applications/diffusion/query/blame/DiffusionMercurialBlameQuery.php',
Extract repository command construction from Repositories Summary: Ref T4292. Ref T10366. Depends on D15751. Today, generating repository commands is purely a function of the repository, so they use protocols and credentials based on the repository configuration. For example, a repository with an SSH "remote URI" always generate SSH "remote commands". This needs to change in the future: - After T10366, repositories won't necessarily just have one type of remote URI. They can only have one at a time still, but the repository itself won't change based on which one is currently active. - For T4292, I need to generate intracluster commands, regardless of repository configuration. These will have different protocols and credentials. Prepare for these cases by separating out command construction, so they'll be able to generate commands in a more flexible way. Test Plan: - Added unit tests. - Browsed diffusion. - Ran `bin/phd debug pull` to pull a bunch of repos. - Ran daemons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4292, T10366 Differential Revision: https://secure.phabricator.com/D15752
2016-04-19 00:22:52 +02:00
'DiffusionMercurialCommandEngine' => 'applications/diffusion/protocol/DiffusionMercurialCommandEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionMercurialFileContentQuery' => 'applications/diffusion/query/filecontent/DiffusionMercurialFileContentQuery.php',
'DiffusionMercurialRawDiffQuery' => 'applications/diffusion/query/rawdiff/DiffusionMercurialRawDiffQuery.php',
'DiffusionMercurialRequest' => 'applications/diffusion/request/DiffusionMercurialRequest.php',
Allow Phabricator to serve Mercurial repositories over HTTP Summary: Ref T2230. This is easily the worst thing I've had to write in a while. I'll leave some notes inline. Test Plan: Ran `hg clone http://...` on a hosted repo. Ran `hg push` on the same. Changed sync'd both ways. Reviewers: asherkin, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7520
2013-11-07 03:00:42 +01:00
'DiffusionMercurialResponse' => 'applications/diffusion/response/DiffusionMercurialResponse.php',
Rename `DiffusionSSHWorkflow` subclasses for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11185
2015-01-04 20:33:18 +01:00
'DiffusionMercurialSSHWorkflow' => 'applications/diffusion/ssh/DiffusionMercurialSSHWorkflow.php',
'DiffusionMercurialServeSSHWorkflow' => 'applications/diffusion/ssh/DiffusionMercurialServeSSHWorkflow.php',
Fix a filename Summary: Third time lucky... the filename should match the class name now. Test Plan: `arc lint` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11362
2015-01-13 21:03:32 +01:00
'DiffusionMercurialWireClientSSHProtocolChannel' => 'applications/diffusion/ssh/DiffusionMercurialWireClientSSHProtocolChannel.php',
Allow Phabricator to serve Mercurial repositories over HTTP Summary: Ref T2230. This is easily the worst thing I've had to write in a while. I'll leave some notes inline. Test Plan: Ran `hg clone http://...` on a hosted repo. Ran `hg push` on the same. Changed sync'd both ways. Reviewers: asherkin, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7520
2013-11-07 03:00:42 +01:00
'DiffusionMercurialWireProtocol' => 'applications/diffusion/protocol/DiffusionMercurialWireProtocol.php',
Added an intercept to Mercurial's `capabilities` command to remove bundle2. Summary: If Mercurial 3.4+ is used to host repositories in Phabricator, any clients using 3.5+ will receive an exception after the bundle is pushed up. Clients will also fail to update phases for changesets pushed up. Before directly responding to mercurial clients with all capabilities, this change filters out the 'bundle2' capability so the client negotiates using a legacy bundle wire format instead. Test Plan: Server: Mercurial 3.5 Client: Mercurial 3.4 Test with both HTTP and SSH protocols: 1. Create a local commit on client 2. Push commit to server 3. Verify the client emits something like: ``` searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files ``` Closes T9450 Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T9450 Differential Revision: https://secure.phabricator.com/D14241
2015-10-10 16:14:48 +02:00
'DiffusionMercurialWireProtocolTests' => 'applications/diffusion/protocol/__tests__/DiffusionMercurialWireProtocolTests.php',
Rename `DiffusionSSHWorkflow` subclasses for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11185
2015-01-04 20:33:18 +01:00
'DiffusionMercurialWireSSHTestCase' => 'applications/diffusion/ssh/__tests__/DiffusionMercurialWireSSHTestCase.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionMergedCommitsQueryConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionMergedCommitsQueryConduitAPIMethod.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionPathChange' => 'applications/diffusion/data/DiffusionPathChange.php',
'DiffusionPathChangeQuery' => 'applications/diffusion/query/pathchange/DiffusionPathChangeQuery.php',
'DiffusionPathCompleteController' => 'applications/diffusion/controller/DiffusionPathCompleteController.php',
'DiffusionPathIDQuery' => 'applications/diffusion/query/pathid/DiffusionPathIDQuery.php',
'DiffusionPathQuery' => 'applications/diffusion/query/DiffusionPathQuery.php',
'DiffusionPathQueryTestCase' => 'applications/diffusion/query/pathid/__tests__/DiffusionPathQueryTestCase.php',
Add a SublimeText-style repository typeahead Summary: Allows you to quickly search for files within a repository. Roughly: - We build a big tree of everything and ship it to the client. - The client implements a bunch of Sublime-ish magic to find paths. Test Plan: {F154007} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley, zeeg Differential Revision: https://secure.phabricator.com/D9087
2014-05-13 23:08:21 +02:00
'DiffusionPathTreeController' => 'applications/diffusion/controller/DiffusionPathTreeController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionPathValidateController' => 'applications/diffusion/controller/DiffusionPathValidateController.php',
Framework for external symbol search Summary: Ref T7984. With this, an install can add an ExternalSymbolsSource to src/extensions, which will include whatever source they have. Test Plan: search for php and python builtins. Reviewers: joshuaspence, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7984 Differential Revision: https://secure.phabricator.com/D13036
2015-05-31 16:36:54 +02:00
'DiffusionPhpExternalSymbolsSource' => 'applications/diffusion/symbol/DiffusionPhpExternalSymbolsSource.php',
Modularize Herald Diffusion pre-commit content fields Summary: Ref T8726. The gruntwork part of this is finally over. Test Plan: - Made a huge rule with every field. - Applied migration. - Verified the rule was still the same. - Pushed a bunch of commits and verified transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13601
2015-07-08 21:26:57 +02:00
'DiffusionPreCommitContentAffectedFilesHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentAffectedFilesHeraldField.php',
'DiffusionPreCommitContentAuthorHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentAuthorHeraldField.php',
'DiffusionPreCommitContentAuthorRawHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentAuthorRawHeraldField.php',
'DiffusionPreCommitContentBranchesHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentBranchesHeraldField.php',
'DiffusionPreCommitContentCommitterHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentCommitterHeraldField.php',
'DiffusionPreCommitContentCommitterRawHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentCommitterRawHeraldField.php',
'DiffusionPreCommitContentDiffContentAddedHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentDiffContentAddedHeraldField.php',
'DiffusionPreCommitContentDiffContentHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentDiffContentHeraldField.php',
'DiffusionPreCommitContentDiffContentRemovedHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentDiffContentRemovedHeraldField.php',
'DiffusionPreCommitContentDiffEnormousHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentDiffEnormousHeraldField.php',
'DiffusionPreCommitContentHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentHeraldField.php',
'DiffusionPreCommitContentMergeHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentMergeHeraldField.php',
'DiffusionPreCommitContentMessageHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentMessageHeraldField.php',
'DiffusionPreCommitContentPusherHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentPusherHeraldField.php',
'DiffusionPreCommitContentPusherIsCommitterHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentPusherIsCommitterHeraldField.php',
'DiffusionPreCommitContentPusherProjectsHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentPusherProjectsHeraldField.php',
'DiffusionPreCommitContentRepositoryHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentRepositoryHeraldField.php',
'DiffusionPreCommitContentRepositoryProjectsHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentRepositoryProjectsHeraldField.php',
'DiffusionPreCommitContentRevisionAcceptedHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentRevisionAcceptedHeraldField.php',
'DiffusionPreCommitContentRevisionHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentRevisionHeraldField.php',
'DiffusionPreCommitContentRevisionReviewersHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentRevisionReviewersHeraldField.php',
'DiffusionPreCommitContentRevisionSubscribersHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitContentRevisionSubscribersHeraldField.php',
Modularize all Herald pre-commit ref fields Summary: Ref T8726. Just (pre-commit content) one more left. Test Plan: - Created a big rule with every field. - Migrated it. - Verified the rule was still the same. - Pushed a bunch of changes and reviewed the transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13600
2015-07-08 21:26:00 +02:00
'DiffusionPreCommitRefChangeHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitRefChangeHeraldField.php',
'DiffusionPreCommitRefHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitRefHeraldField.php',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'DiffusionPreCommitRefHeraldFieldGroup' => 'applications/diffusion/herald/DiffusionPreCommitRefHeraldFieldGroup.php',
Modularize all Herald pre-commit ref fields Summary: Ref T8726. Just (pre-commit content) one more left. Test Plan: - Created a big rule with every field. - Migrated it. - Verified the rule was still the same. - Pushed a bunch of changes and reviewed the transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13600
2015-07-08 21:26:00 +02:00
'DiffusionPreCommitRefNameHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitRefNameHeraldField.php',
'DiffusionPreCommitRefPusherHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitRefPusherHeraldField.php',
'DiffusionPreCommitRefPusherProjectsHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitRefPusherProjectsHeraldField.php',
'DiffusionPreCommitRefRepositoryHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitRefRepositoryHeraldField.php',
'DiffusionPreCommitRefRepositoryProjectsHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitRefRepositoryProjectsHeraldField.php',
'DiffusionPreCommitRefTypeHeraldField' => 'applications/diffusion/herald/DiffusionPreCommitRefTypeHeraldField.php',
Support ID-based repository URIs, and canonicalize repository URIs Summary: Ref T4245. Make `/diffusion/123/` work, but redirect the user to `/diffusion/XYZ/` if the repository has a callsign. (Right now, every repository has a callsign, so this always redirects.) Also redirect `/R123:abcdef` if the repository has a callsign. Also also, move the Pull garbage collector somewhere more sensible. Test Plan: - Added test coverage. - Visited `/diffusion/1/`, was redirected. - Visited `/diffusion/R1:abcdef`, was redirected. - Browsed Diffusion normally. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4245 Differential Revision: https://secure.phabricator.com/D15301
2016-02-18 13:06:13 +01:00
'DiffusionPullEventGarbageCollector' => 'applications/diffusion/garbagecollector/DiffusionPullEventGarbageCollector.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'DiffusionPushCapability' => 'applications/diffusion/capability/DiffusionPushCapability.php',
Provide an "event" page for push logs, which shows details on all events in a given push Summary: Ref T4677. This shows a more detailed view of an entire "git push", "hg push", or "svn commit". This is mostly to give push summary emails a reasonable, stable URI to link to for T4677. Test Plan: - Pushed into SVN, Git and Mercurial. - Viewed partial and imported event records. {F134864} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4677 Differential Revision: https://secure.phabricator.com/D8616
2014-03-26 15:42:30 +01:00
'DiffusionPushEventViewController' => 'applications/diffusion/controller/DiffusionPushEventViewController.php',
'DiffusionPushLogController' => 'applications/diffusion/controller/DiffusionPushLogController.php',
Add a basic push log for recording repository push events Summary: Ref T4195. This log serves two purposes: - It's a log, so you can see what happened. Particularly, in Git/Hg, there is no other way to tell: - Who //pushed// a change (vs committed / authored)? - When was a change pushed? - What was the old value of some tag/branch before someone destroyed it? - We can hand these objects off to Herald to implement pre-commit rules. This is a very basic implementation, but gets some data written and has a basic UI for it. Test Plan: {F87339} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7705
2013-12-05 20:56:14 +01:00
'DiffusionPushLogListController' => 'applications/diffusion/controller/DiffusionPushLogListController.php',
Move Push log rendering to SearchEngine Summary: Ref T4986. Move push logs to a View, then have all the stuff that needs to use it use that View. Test Plan: Viewed push logs and transaction detail in Diffusion. Created a panel. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9104
2014-05-13 23:00:24 +02:00
'DiffusionPushLogListView' => 'applications/diffusion/view/DiffusionPushLogListView.php',
Framework for external symbol search Summary: Ref T7984. With this, an install can add an ExternalSymbolsSource to src/extensions, which will include whatever source they have. Test Plan: search for php and python builtins. Reviewers: joshuaspence, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7984 Differential Revision: https://secure.phabricator.com/D13036
2015-05-31 16:36:54 +02:00
'DiffusionPythonExternalSymbolsSource' => 'applications/diffusion/symbol/DiffusionPythonExternalSymbolsSource.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionQuery' => 'applications/diffusion/query/DiffusionQuery.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionQueryCommitsConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionQueryCommitsConduitAPIMethod.php',
'DiffusionQueryConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionQueryConduitAPIMethod.php',
'DiffusionQueryPathsConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionQueryPathsConduitAPIMethod.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionRawDiffQuery' => 'applications/diffusion/query/rawdiff/DiffusionRawDiffQuery.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionRawDiffQueryConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionRawDiffQueryConduitAPIMethod.php',
Fix diffusion.readmequery to work in a cluster enviroment Summary: Ref T2783. This method is kind of goofballs: - We send a big list of paths to it. - It sends back a giant blob of HTML. Instead, just figure out the path we want locally, then fetch the content with `diffusion.filecontentquery`. Test Plan: - Viewed main view and directory view, saw a README. - See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2783 Differential Revision: https://secure.phabricator.com/D11099
2014-12-31 20:54:52 +01:00
'DiffusionReadmeView' => 'applications/diffusion/view/DiffusionReadmeView.php',
Add a DiffusionRefDatasource for typeahead'ing branches, tags, bookmarks and refs Summary: Ref T9952. This will let me put a "Branch: [____]" control on the "Land Revision" dialog so users can choose a branch to target. Test Plan: Used `/typeahead/class/` to vet basic behavior. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9952 Differential Revision: https://secure.phabricator.com/D14732
2015-12-10 22:17:11 +01:00
'DiffusionRefDatasource' => 'applications/diffusion/typeahead/DiffusionRefDatasource.php',
Throw a more tailored exception after failing to resolve a ref Summary: Ref T2683. Throw a more tailored exception to allow callers to distinguish between bad refs (which are expected, if users try to visit garbage branches) and other types of errors. Test Plan: Tried to view branch "alksndfklansdf". Viewed branch "master". Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2683 Differential Revision: https://secure.phabricator.com/D9094
2014-05-13 22:52:33 +02:00
'DiffusionRefNotFoundException' => 'applications/diffusion/exception/DiffusionRefNotFoundException.php',
Add a "refs" table to Diffusion Summary: Ref T7100. When a user navigates to a branch like "default" which is ambiguous: - don't fatal; - choose one alternative to resolve it to (currently more or less at random); - sometimes show what we did in the UI. Also, add a new table to show the alternatives. This will get refined in followup changes. Test Plan: {F384335} {F384336} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7100 Differential Revision: https://secure.phabricator.com/D12547
2015-04-27 12:49:57 +02:00
'DiffusionRefTableController' => 'applications/diffusion/controller/DiffusionRefTableController.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionRefsQueryConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionRefsQueryConduitAPIMethod.php',
Read rename information from DB instead of repository Summary: We already have this information for all VCSes, there's no point in parsing it again. We currently support it only for Git and I remember there were some bugs in it. It should also be faster. Test Plan: Blamed previous revision of a file which was moved in SVN. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3564
2012-09-28 23:36:47 +02:00
'DiffusionRenameHistoryQuery' => 'applications/diffusion/query/DiffusionRenameHistoryQuery.php',
Port "Actions" to new Repository UI Summary: Ref T10748. This brings the "Actions" items (publish/notify + autoclose enabled) into the new UI. Test Plan: - Edited this stuff via EditEngine and Conduit. - Viewed via new Manage UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15811
2016-04-28 00:40:35 +02:00
'DiffusionRepositoryActionsManagementPanel' => 'applications/diffusion/management/DiffusionRepositoryActionsManagementPanel.php',
Port "Automation" panel to new Repository Manage UI Summary: Ref T10748. Ports this UI and exposes it on the EditEngine. Test Plan: - Edited via EditEngine. - Viewed new manage UI. Reviewers: chad Reviewed By: chad Subscribers: hach-que Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15804
2016-04-27 00:54:01 +02:00
'DiffusionRepositoryAutomationManagementPanel' => 'applications/diffusion/management/DiffusionRepositoryAutomationManagementPanel.php',
Rough in basics + policies + history repository management panels Summary: Ref T10748. This is roughly where I'm headed, if it makes some kind of sense? The "Edit" links in sub-sections don't work yet since I haven't built the thing. Probably depends on D15736. Test Plan: Manually navigated to `/manage/`, clicked around. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15737
2016-04-17 02:33:27 +02:00
'DiffusionRepositoryBasicsManagementPanel' => 'applications/diffusion/management/DiffusionRepositoryBasicsManagementPanel.php',
Port Repository "Branches" to new UI Summary: Ref T10748. Makes a "Branches" panel, enables these transactions in the EditEngine. Test Plan: - Edited via EditEngine + Conduit. - Viewed via manage UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15809
2016-04-27 19:51:13 +02:00
'DiffusionRepositoryBranchesManagementPanel' => 'applications/diffusion/management/DiffusionRepositoryBranchesManagementPanel.php',
make repo callsigns optional Summary: Ref T4245 Make repo callsigns optional This is far from done and still very ugly. I'm just submitting it to check if i'm solving this in the right places. Right now there's three places with duplicate code and building the identifierMap in the CommitQuery is very ugly. If we only want to support this in the user frontend then i could hack it into the Markup rule itself and not touch the CommitQuery. Even uglier but more limited in scope... Generally this approach will need a lot of "check this first and then try the other" in a few places. I could move the Repository queries into a specialised PhabricatorRepositoryQuery method (withCallsignOrID) but i'm not sure about that. Test Plan: - phid.lookup works with R1 and rTEST (which is the same repo) - R1 and rTEST euqally work in remarkup (tested in comments). - Reviewed the following syntax also all works: rTEST rTESTd773137a7cb9 rTEST:d773137a7cb9 R1 R1:d773137a7cb9 d773137a7cb9 {rTEST} {rTESTd773137a7cb9} {rTEST:d773137a7cb9} {R1} {R1:d773137a7cb9} {d773137a7cb9} Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T4245 Differential Revision: https://secure.phabricator.com/D11050
2015-01-01 17:07:26 +01:00
'DiffusionRepositoryByIDRemarkupRule' => 'applications/diffusion/remarkup/DiffusionRepositoryByIDRemarkupRule.php',
Move all cluster locking logic to a separate class Summary: Ref T10860. This doesn't change anything, it just separates all this stuff out of `PhabricatorRepository` since I'm planning to add a bit more state to it and it's already pretty big and fairly separable. Test Plan: Pulled, pushed, browsed Diffusion. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10860 Differential Revision: https://secure.phabricator.com/D15790
2016-04-24 18:04:27 +02:00
'DiffusionRepositoryClusterEngine' => 'applications/diffusion/protocol/DiffusionRepositoryClusterEngine.php',
Make cluster repositories more chatty Summary: Ref T10860. At least in Git over SSH, we can freely echo a bunch of stuff to stderr and Git will print it to the console, so we can tell users what's going on. This should make debugging, etc., easier. We could tone this down a little bit once things are more stable if it's a little too chatty. Test Plan: ``` $ echo D >> record && git commit -am D && git push [master ca5efff] D 1 file changed, 1 insertion(+) # Push received by "local001.phacility.net", forwarding to cluster host. # Waiting up to 120 second(s) for a cluster write lock... # Acquired write lock immediately. # Waiting up to 120 second(s) for a cluster read lock on "local001.phacility.net"... # Acquired read lock immediately. # Device "local001.phacility.net" is already a cluster leader and does not need to be synchronized. # Ready to receive on cluster host "local001.phacility.net". Counting objects: 3, done. Delta compression using up to 8 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 256 bytes | 0 bytes/s, done. Total 3 (delta 1), reused 0 (delta 0) To ssh://local@localvault.phacility.com/diffusion/26/locktopia.git 8616189..ca5efff master -> master ``` Reviewers: chad Reviewed By: chad Maniphest Tasks: T10860 Differential Revision: https://secure.phabricator.com/D15791
2016-04-24 18:49:18 +02:00
'DiffusionRepositoryClusterEngineLogInterface' => 'applications/diffusion/protocol/DiffusionRepositoryClusterEngineLogInterface.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionRepositoryController' => 'applications/diffusion/controller/DiffusionRepositoryController.php',
Modernize "repositories" typeahead datasource Summary: Ref T4420. - Allow tokenizers to accept either a `Datasource` object (new style) or a URI (old style). - Read URI and placeholder text from object, if available. - Swap the "repositories" datasource (which seemed like the simplest one) over to the new stuff. - Tweak/update the repo tokens a little bit. Test Plan: - Used tokenizer in Herald, Differential (search), Differential (edit), Push Logs. - Grepped for other callsites. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9874
2014-07-11 01:18:04 +02:00
'DiffusionRepositoryDatasource' => 'applications/diffusion/typeahead/DiffusionRepositoryDatasource.php',
Accept and route VCS HTTP requests Summary: Mostly ripped from D7391, with some changes: - Serve repositories at `/diffusion/X/`, with no special `/git/` or `/serve/` URI component. - This requires a little bit of magic, but I got the magic working for Git, Mercurial and SVN, and it seems reasonable. - I think having one URI for everything will make it easier for users to understand. - One downside is that git will clone into `X` by default, but I think that's not a big deal, and we can work around that in the future easily enough. - Accept HTTP requests for Git, SVN and Mercurial repositories. - Auth logic is a little different in order to be more consistent with how other things work. - Instead of AphrontBasicAuthResponse, added "VCSResponse". Mercurial can print strings we send it on the CLI if we're careful, so support that. I did a fair amount of digging and didn't have any luck with git or svn. - Commands we don't know about are assumed to require "Push" capability by default. No actual VCS data going over the wire yet. Test Plan: Ran a bunch of stuff like this: $ hg clone http://local.aphront.com:8080/diffusion/P/ abort: HTTP Error 403: This repository is not available over HTTP. ...and got pretty reasonable-seeming errors in all cases. All this can do is produce errors for now. Reviewers: hach-que, btrahan Reviewed By: hach-que CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7417
2013-10-26 16:56:17 +02:00
'DiffusionRepositoryDefaultController' => 'applications/diffusion/controller/DiffusionRepositoryDefaultController.php',
Document most of the new Diffusion management panel Summary: Ref T10923. This isn't complete yet, but reduces lies and increases truths. Test Plan: Read documentation, clicked new "Documentation" nav item. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10923 Differential Revision: https://secure.phabricator.com/D15868
2016-05-09 17:10:21 +02:00
'DiffusionRepositoryDocumentationManagementPanel' => 'applications/diffusion/management/DiffusionRepositoryDocumentationManagementPanel.php',
Allow repositories to be activate/deactivated in a transaction-aware way Summary: Adds activate/deactivate action plus transactions. Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7057
2013-09-22 01:23:35 +02:00
'DiffusionRepositoryEditActivateController' => 'applications/diffusion/controller/DiffusionRepositoryEditActivateController.php',
Trivially implement RepositoryEditEngine and API methods Summary: Ref T10748. Ref T10337. This technically implements this stuff, but it does not do anything useful yet. This skips all the hard stuff. Test Plan: - Technically used `diffusion.repository.search` to get repository information. - Technically used `diffusion.repository.edit` to change a repository name. - Used `editpro/` to edit a repository name. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10337, T10748 Differential Revision: https://secure.phabricator.com/D15736
2016-04-17 01:45:19 +02:00
'DiffusionRepositoryEditConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionRepositoryEditConduitAPIMethod.php',
Begin transacitonalizing repository edits and provide a more sensible edit interface Summary: Ref T2231, T603. Plan of attack here is pretty much: - Built out a new (currently not linked in the UI) edit interface in Diffusion which is transaction-based and has a sensible layout. - Build out a new create interface based on PagedForm which dumps into the new edit interface. - Throw the old stuff away. - Everyone lives happily ever after. Test Plan: {F44163} {F44164} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D6029
2013-05-24 21:37:42 +02:00
'DiffusionRepositoryEditController' => 'applications/diffusion/controller/DiffusionRepositoryEditController.php',
Reject dangerous changes in Git repositories by default Summary: Ref T4189. This adds a per-repository "dangerous changes" flag, which defaults to off. This flag must be enabled to do non-appending branch mutation (delete branches / rewrite history). Test Plan: With flag on and off, performed various safe and dangerous pushes. >>> orbital ~/repos/POEMS $ git push origin :blarp remote: +---------------------------------------------------------------+ remote: | * * * PUSH REJECTED BY EVIL DRAGON BUREAUCRATS * * * | remote: +---------------------------------------------------------------+ remote: \ remote: \ ^ /^ remote: \ / \ // \ remote: \ |\___/| / \// .\ remote: \ /V V \__ / // | \ \ *----* remote: / / \/_/ // | \ \ \ | remote: @___@` \/_ // | \ \ \/\ \ remote: 0/0/| \/_ // | \ \ \ \ remote: 0/0/0/0/| \/// | \ \ | | remote: 0/0/0/0/0/_|_ / ( // | \ _\ | / remote: 0/0/0/0/0/0/`/,_ _ _/ ) ; -. | _ _\.-~ / / remote: ,-} _ *-.|.-~-. .~ ~ remote: \ \__/ `/\ / ~-. _ .-~ / remote: \____(Oo) *. } { / remote: ( (--) .----~-.\ \-` .~ remote: //__\\ \ DENIED! ///.----..< \ _ -~ remote: // \\ ///-._ _ _ _ _ _ _{^ - - - - ~ remote: remote: remote: DANGEROUS CHANGE: The change you're attempting to push deletes the branch 'blarp'. remote: Dangerous change protection is enabled for this repository. remote: Edit the repository configuration before making dangerous changes. remote: To ssh://dweller@localhost/diffusion/POEMS/ ! [remote rejected] blarp (pre-receive hook declined) error: failed to push some refs to 'ssh://dweller@localhost/diffusion/POEMS/' Reviewers: btrahan Reviewed By: btrahan CC: aran, chad, richardvanvelzen Maniphest Tasks: T4189 Differential Revision: https://secure.phabricator.com/D7689
2013-12-03 19:28:39 +01:00
'DiffusionRepositoryEditDangerousController' => 'applications/diffusion/controller/DiffusionRepositoryEditDangerousController.php',
Proteins
2013-10-29 22:23:30 +01:00
'DiffusionRepositoryEditDeleteController' => 'applications/diffusion/controller/DiffusionRepositoryEditDeleteController.php',
Trivially implement RepositoryEditEngine and API methods Summary: Ref T10748. Ref T10337. This technically implements this stuff, but it does not do anything useful yet. This skips all the hard stuff. Test Plan: - Technically used `diffusion.repository.search` to get repository information. - Technically used `diffusion.repository.edit` to change a repository name. - Used `editpro/` to edit a repository name. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10337, T10748 Differential Revision: https://secure.phabricator.com/D15736
2016-04-17 01:45:19 +02:00
'DiffusionRepositoryEditEngine' => 'applications/diffusion/editor/DiffusionRepositoryEditEngine.php',
Improve UX for repository updates Summary: Fixes T5926. Fixes T5830. Ref T4767. Users currently sometimes have a hard time understanding repository update frequencies. This is compounded by aggressive backoff and incorrect backoff while importing repositories. - Don't back off while importing repositories. This prevents us from hanging at 99.99% for inactive repositories while waiting for the next update. - Back off less aggressively in general, and even more gradually during the first 3 days. This should make behavior around weekends better. - Show update frequency in the UI. - Provide an explicit "update now" button to call `diffusion.looksoon` in a more user-friendly way. - Document how backoff policies work and how to adjust behavior. Test Plan: - Ran `bin/phd debug pulllocal` and verified backoff worked correctly from debugging output. - Clicked "Update Now" to get a hint, reloaded page to see it update. - Read documentation. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4767, T5830, T5926 Differential Revision: https://secure.phabricator.com/D10323
2014-08-21 20:30:12 +02:00
'DiffusionRepositoryEditUpdateController' => 'applications/diffusion/controller/DiffusionRepositoryEditUpdateController.php',
Rough in basics + policies + history repository management panels Summary: Ref T10748. This is roughly where I'm headed, if it makes some kind of sense? The "Edit" links in sub-sections don't work yet since I haven't built the thing. Probably depends on D15736. Test Plan: Manually navigated to `/manage/`, clicked around. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15737
2016-04-17 02:33:27 +02:00
'DiffusionRepositoryHistoryManagementPanel' => 'applications/diffusion/management/DiffusionRepositoryHistoryManagementPanel.php',
Rename `DiffusionHomeController` to `DiffusionRepositoryListController` Summary: Improves consistency across applications. Test Plan: Loaded `/diffusion/`. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6916
2013-09-11 00:24:44 +02:00
'DiffusionRepositoryListController' => 'applications/diffusion/controller/DiffusionRepositoryListController.php',
Rough cut at new "pro" Diffusion edit UI skeleton Summary: Ref T4292. This puts a very rough skeleton in place for the new "Manage Repository" UI, somewhat similar to the "Settings" UI. Right now, it has one panel with no content, and is not reachable from the UI. Test Plan: {F1214525} Reviewers: chad Reviewed By: chad Maniphest Tasks: T4292 Differential Revision: https://secure.phabricator.com/D15683
2016-04-11 19:17:46 +02:00
'DiffusionRepositoryManageController' => 'applications/diffusion/controller/DiffusionRepositoryManageController.php',
Sort out EditController / ManageController / EditproController Diffusion hierarchy Summary: Ref T10923. This cleans up the remaining "pro" mess left by the cutover. Test Plan: Viewed, managed, edited a repository. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10923 Differential Revision: https://secure.phabricator.com/D15871
2016-05-09 23:24:21 +02:00
'DiffusionRepositoryManagePanelsController' => 'applications/diffusion/controller/DiffusionRepositoryManagePanelsController.php',
Rough cut at new "pro" Diffusion edit UI skeleton Summary: Ref T4292. This puts a very rough skeleton in place for the new "Manage Repository" UI, somewhat similar to the "Settings" UI. Right now, it has one panel with no content, and is not reachable from the UI. Test Plan: {F1214525} Reviewers: chad Reviewed By: chad Maniphest Tasks: T4292 Differential Revision: https://secure.phabricator.com/D15683
2016-04-11 19:17:46 +02:00
'DiffusionRepositoryManagementPanel' => 'applications/diffusion/management/DiffusionRepositoryManagementPanel.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionRepositoryPath' => 'applications/diffusion/data/DiffusionRepositoryPath.php',
Rough in basics + policies + history repository management panels Summary: Ref T10748. This is roughly where I'm headed, if it makes some kind of sense? The "Edit" links in sub-sections don't work yet since I haven't built the thing. Probably depends on D15736. Test Plan: Manually navigated to `/manage/`, clicked around. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15737
2016-04-17 02:33:27 +02:00
'DiffusionRepositoryPoliciesManagementPanel' => 'applications/diffusion/management/DiffusionRepositoryPoliciesManagementPanel.php',
Consolidate querying of things which we can use `git for-each-ref` for Summary: Ref T2230. This cleans up D7442, by using `git for-each-ref` everywhere we can, in a basically reasonable way. Test Plan: In bare and non-bare repositories: - Ran discovery with `bin/repository discover`; - listed branches on `/diffusion/X/`; - listed tags on `/diffusion/X/`; - listed tags, branches and refs on `/diffusion/rXnnnn`. Reviewers: btrahan, avivey Reviewed By: avivey CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7447
2013-10-30 21:06:09 +01:00
'DiffusionRepositoryRef' => 'applications/diffusion/data/DiffusionRepositoryRef.php',
Add a Diffusion repository remarkup rule Summary: Currently we markup `rXabcd`, but not `rX` on its own. Mark these up as repository object names. Test Plan: Typed `rPOEMS`, `rPOEMS1`, `rPOEMS139893189`, etc. Reviewers: btrahan, dctrwatson Reviewed By: btrahan CC: aran, poop Differential Revision: https://secure.phabricator.com/D7859
2013-12-31 20:08:08 +01:00
'DiffusionRepositoryRemarkupRule' => 'applications/diffusion/remarkup/DiffusionRepositoryRemarkupRule.php',
Trivially implement RepositoryEditEngine and API methods Summary: Ref T10748. Ref T10337. This technically implements this stuff, but it does not do anything useful yet. This skips all the hard stuff. Test Plan: - Technically used `diffusion.repository.search` to get repository information. - Technically used `diffusion.repository.edit` to change a repository name. - Used `editpro/` to edit a repository name. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10337, T10748 Differential Revision: https://secure.phabricator.com/D15736
2016-04-17 01:45:19 +02:00
'DiffusionRepositorySearchConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionRepositorySearchConduitAPIMethod.php',
Port "Staging Area" repository section to new management UI Summary: Ref T10748. Brings this over and adds EditEngine support for it. Test Plan: Viewed and edited staging area information. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15801
2016-04-26 14:54:51 +02:00
'DiffusionRepositoryStagingManagementPanel' => 'applications/diffusion/management/DiffusionRepositoryStagingManagementPanel.php',
Copy repository status to a management panel Summary: Ref T10748. Pretty straightforward. I'd like to put a little "!" icon in the menu if there's a warning/error eventually, but can deal with that latre. Test Plan: {F1223096} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15741
2016-04-17 14:10:18 +02:00
'DiffusionRepositoryStatusManagementPanel' => 'applications/diffusion/management/DiffusionRepositoryStatusManagementPanel.php',
Port local storage path to new repository Manage UI Summary: Ref T10748. This merges "Storage" and "Cluster" into a single UI which combines the information of both. Test Plan: {F1246882} Reviewers: chad Reviewed By: chad Subscribers: hach-que Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15800
2016-04-26 14:43:35 +02:00
'DiffusionRepositoryStorageManagementPanel' => 'applications/diffusion/management/DiffusionRepositoryStorageManagementPanel.php',
Restore edit UI for "Import Only" in Subversion Summary: Ref T10923. Although I'd ideally like to get rid of this eventually, keep it around for now. Test Plan: - Edited value for an SVN repository. - Observed no panel present for a Git repository. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10923 Differential Revision: https://secure.phabricator.com/D15883
2016-05-11 02:13:11 +02:00
'DiffusionRepositorySubversionManagementPanel' => 'applications/diffusion/management/DiffusionRepositorySubversionManagementPanel.php',
Port Repository "Symbols" to Manage/Panel UI Summary: Ref T10748. Port this, add EditEngine support, add some type validation to the transaction. Test Plan: - Edited via EditEngine. - Edited via Conduit. - Viewed via Management UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15808
2016-04-27 19:32:43 +02:00
'DiffusionRepositorySymbolsManagementPanel' => 'applications/diffusion/management/DiffusionRepositorySymbolsManagementPanel.php',
DiffusionBranchQuery => Conduit Summary: ref T2784. This one had a few fun spots where I had to move data around. Also, is there some common object (or should I add it?) that can do this toDictionary newFromConduit stuff? Also, this assumes D5803 is largely correct at the time of this diff. Test Plan: browsed mercurial and git repository page. saw the branches i expected. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5810
2013-05-01 23:56:36 +02:00
'DiffusionRepositoryTag' => 'applications/diffusion/data/DiffusionRepositoryTag.php',
Add some Drydock documentation plus "Test Configuration" for repository automation Summary: Ref T182. Ref T9252. - Adds a "Test" repository operation that just runs `git status` to see if things work. - Adds a button for it in Edit Repository. - Shows operation status on the operation detail view to make this workflow work a little better. - Adds a lot of words. Words words words words. Test Plan: - Tested repository operation. - Read words. Reviewers: chad Reviewed By: chad Maniphest Tasks: T182, T9252 Differential Revision: https://secure.phabricator.com/D14349
2015-10-27 19:04:02 +01:00
'DiffusionRepositoryTestAutomationController' => 'applications/diffusion/controller/DiffusionRepositoryTestAutomationController.php',
Fill in new URI credential edit web UI interfaces Summary: Ref T10748. Ref T10366. Allows users to set credential for new URIs. - Ref T7221. Our handling of the "git://" protocol is currently incorrect. This protocol is not authenticated, but is considered an SSH protocol. In the new UI, it is considered an anonymous/unauthenticated protocol instead. - Ref T10241. This fixes the `PassphraseCredentialControl` so it doesn't silently edit the value if the current value is not visible to you and/or not valid. Test Plan: Performed a whole lot of credential edits, removals, and adjustments. I'll give this additional vetting before cutting over to it. {F1253207} Reviewers: chad Reviewed By: chad Maniphest Tasks: T7221, T10241, T10366, T10748 Differential Revision: https://secure.phabricator.com/D15829
2016-05-01 15:59:22 +02:00
'DiffusionRepositoryURICredentialController' => 'applications/diffusion/controller/DiffusionRepositoryURICredentialController.php',
Flesh out more web UI actions for new URI interface Summary: Ref T10748. - Allow users to add new URIs by clicking a button instead of knowing a secret URI. - Validate that URIs are actually valid URIs. - Add enable/disable action and strings. Test Plan: - Created a new URI. - Tried to create a nonsense URI, created a good URI. - Enabled/disabled a URI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15825
2016-04-30 01:51:05 +02:00
'DiffusionRepositoryURIDisableController' => 'applications/diffusion/controller/DiffusionRepositoryURIDisableController.php',
Rough sketch of new repository URI editing Summary: Ref T10748. Ref T10366. This adds a new EditEngine, EditController, Editor, Query, and Transaction for RepositoryURIs. None of these really do anything helpful yet, and these URIs are still unused in the actual application. Test Plan: {F1249794} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10366, T10748 Differential Revision: https://secure.phabricator.com/D15815
2016-04-28 17:33:44 +02:00
'DiffusionRepositoryURIEditController' => 'applications/diffusion/controller/DiffusionRepositoryURIEditController.php',
Add repository URI view pages and IO/Display edit logic Summary: Ref T10748. - New View page for repository URIs. - Make display and I/O behavior (observe, mirror, read, read/write) editable. - Add a bunch of checks to prevent you from completely screwing up a repository by making it writable from a bunch of differnet sources. Test Plan: {F1249866} {F1249867} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15816
2016-04-28 19:40:35 +02:00
'DiffusionRepositoryURIViewController' => 'applications/diffusion/controller/DiffusionRepositoryURIViewController.php',
Move repository URIs to a dedicated index Summary: Ref T4705 (there are also some other adjacent related tasks dealing with URIs). Currently, we issue a "get repositories matching URIs: ..." query by loading every possible repository and then checking their URIs in PHP. Instead, put URIs in a separate table. I plan for each repository to potentially have multiple URIs soon, so this prepares for that. Test Plan: - Ran migrations. - Looked at index table, made sure it appeared sensible. - Ran some queries by `uri` to find repositories, found the repositories I expected. - Updated the remote URI of a repository, saw queries / index update appropriately. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4705 Differential Revision: https://secure.phabricator.com/D15005
2016-01-12 15:45:17 +01:00
'DiffusionRepositoryURIsIndexEngineExtension' => 'applications/diffusion/engineextension/DiffusionRepositoryURIsIndexEngineExtension.php',
Rough in the new custom URI panel Summary: Ref T10748. Ref T10366. No support for editing and no impact on the UI, but get some of the basics in place. Test Plan: {F1223279} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10366, T10748 Differential Revision: https://secure.phabricator.com/D15742
2016-04-17 17:17:49 +02:00
'DiffusionRepositoryURIsManagementPanel' => 'applications/diffusion/management/DiffusionRepositoryURIsManagementPanel.php',
Allow callers to query information about repository URIs from diffusion.repository.search Summary: Ref T10748. Adds a "uris" attachment with URI information. Test Plan: Queried URI information via Conduit, saw reasonable looking information. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15822
2016-04-29 23:10:04 +02:00
'DiffusionRepositoryURIsSearchEngineAttachment' => 'applications/diffusion/engineextension/DiffusionRepositoryURIsSearchEngineAttachment.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionRequest' => 'applications/diffusion/request/DiffusionRequest.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionResolveRefsConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionResolveRefsConduitAPIMethod.php',
Provide a standalone query for resolution of commit author/committer into Phabricator users Summary: Ref T4195. To implement the "Author" and "Committer" rules, I need to resolve author/committer strings into Phabricator users. The code to do this is currently buried in the daemons. Extract it into a standalone query. I also added `bin/repository lookup-users <commit>` to test this query, both to improve confidence I'm getting this right and to provide a diagnostic command for users, since there's occasionally some confusion over how author/committer strings resolve into valid users. Test Plan: I tested this using `bin/repository lookup-users` and `reparse.php --message` on Git, Mercurial and SVN commits. Here's the `lookup-users` output: >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rINIS3 Examining commit rINIS3... Raw author string: epriestley Phabricator user: epriestley (Evan Priestley ) Raw committer string: null >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rPOEMS165b6c54f487c8 Examining commit rPOEMS165b6c54f487... Raw author string: epriestley <git@epriestley.com> Phabricator user: epriestley (Evan Priestley ) Raw committer string: epriestley <git@epriestley.com> Phabricator user: epriestley (Evan Priestley ) >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rINIH6d24c1aee7741e Examining commit rINIH6d24c1aee774... Raw author string: epriestley <hg@yghe.net> Phabricator user: epriestley (Evan Priestley ) Raw committer string: null >>> orbital ~/devtools/phabricator $ The `reparse.php` output was similar, and all VCSes resolved authors correctly. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1731, T4195 Differential Revision: https://secure.phabricator.com/D7801
2013-12-19 20:05:17 +01:00
'DiffusionResolveUserQuery' => 'applications/diffusion/query/DiffusionResolveUserQuery.php',
Route some VCS connections over SSH Summary: - Add web UI for configuring SSH hosting. - Route git reads (`git-upload-pack` over SSH). Test Plan: >>> orbital ~ $ git clone ssh://127.0.0.1/ Cloning into '127.0.0.1'... Exception: Unrecognized repository path "/". Expected a path like "/diffusion/X/". fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. >>> orbital ~ $ git clone ssh://127.0.0.1/diffusion/X/ Cloning into 'X'... Exception: No repository "X" exists! fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. >>> orbital ~ $ git clone ssh://127.0.0.1/diffusion/MT/ Cloning into 'MT'... Exception: This repository is not available over SSH. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. >>> orbital ~ $ git clone ssh://127.0.0.1/diffusion/P/ Cloning into 'P'... Exception: TODO: Implement serve over SSH. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Reviewers: btrahan Reviewed By: btrahan CC: hach-que, aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7421
2013-10-26 19:46:09 +02:00
'DiffusionSSHWorkflow' => 'applications/diffusion/ssh/DiffusionSSHWorkflow.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionSearchQueryConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionSearchQueryConduitAPIMethod.php',
Split Diffusion VSC serve code into its own controller Summary: This is starting to get a bit sizable and it turns out Mercurial is sort of a beast, so split the VCS serve stuff into a separate controller. Test Plan: Pushed and pulled an authenticated Git repository. Reviewers: btrahan Reviewed By: btrahan CC: aran, hach-que Differential Revision: https://secure.phabricator.com/D7494
2013-11-07 02:55:46 +01:00
'DiffusionServeController' => 'applications/diffusion/controller/DiffusionServeController.php',
Rename `DiffusionSetPasswordPanel` for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11178
2015-01-03 14:46:28 +01:00
'DiffusionSetPasswordSettingsPanel' => 'applications/diffusion/panel/DiffusionSetPasswordSettingsPanel.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionSetupException' => 'applications/diffusion/exception/DiffusionSetupException.php',
Extract repository command construction from Repositories Summary: Ref T4292. Ref T10366. Depends on D15751. Today, generating repository commands is purely a function of the repository, so they use protocols and credentials based on the repository configuration. For example, a repository with an SSH "remote URI" always generate SSH "remote commands". This needs to change in the future: - After T10366, repositories won't necessarily just have one type of remote URI. They can only have one at a time still, but the repository itself won't change based on which one is currently active. - For T4292, I need to generate intracluster commands, regardless of repository configuration. These will have different protocols and credentials. Prepare for these cases by separating out command construction, so they'll be able to generate commands in a more flexible way. Test Plan: - Added unit tests. - Browsed diffusion. - Ran `bin/phd debug pull` to pull a bunch of repos. - Ran daemons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4292, T10366 Differential Revision: https://secure.phabricator.com/D15752
2016-04-19 00:22:52 +02:00
'DiffusionSubversionCommandEngine' => 'applications/diffusion/protocol/DiffusionSubversionCommandEngine.php',
Rename `DiffusionSSHWorkflow` subclasses for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11185
2015-01-04 20:33:18 +01:00
'DiffusionSubversionSSHWorkflow' => 'applications/diffusion/ssh/DiffusionSubversionSSHWorkflow.php',
'DiffusionSubversionServeSSHWorkflow' => 'applications/diffusion/ssh/DiffusionSubversionServeSSHWorkflow.php',
Support serving SVN repositories over SSH Summary: Ref T2230. The SVN protocol has a sensible protocol format with a good spec here: http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_ra_svn/protocol Particularly, compare this statement to the clown show that is the Mercurial wire protocol: > It is possible to parse an item without knowing its type in advance. WHAT A REASONABLE STATEMENT TO BE ABLE TO MAKE ABOUT A WIRE PROTOCOL Although it makes substantially more sense than Mercurial, it's much heavier-weight than the Git or Mercurial protocols, since it isn't distributed. It's also not possible to figure out if a request is a write request (or even which repository it is against) without proxying some of the protocol frames. Finally, several protocol commands embed repository URLs, and we need to reach into the protocol and translate them. Test Plan: Ran various SVN commands over SSH (`svn log`, `svn up`, `svn commit`, etc). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7556
2013-11-11 21:19:06 +01:00
'DiffusionSubversionWireProtocol' => 'applications/diffusion/protocol/DiffusionSubversionWireProtocol.php',
'DiffusionSubversionWireProtocolTestCase' => 'applications/diffusion/protocol/__tests__/DiffusionSubversionWireProtocolTestCase.php',
Implement a dedicated "diffusion.blame" API method Summary: Fixes T2451. Several motivations here, from strongest to weakest: - Currently, getting blame and file content are closely entwined. This makes fixing T9319 more difficult, and I want to fix it. I want to separate blame from content so there's more flexibility in how we approach this issue. - This makes pursuing T2450 easier, if it turns out to be a meaningful win. - If we can get a win on blame performance, we can do `arc blame` eventually if we want. Test Plan: - Blamed in SVN, Git and Mercurial. Reviewers: chad Reviewed By: chad Maniphest Tasks: T2451 Differential Revision: https://secure.phabricator.com/D14957
2016-01-06 13:56:27 +01:00
'DiffusionSvnBlameQuery' => 'applications/diffusion/query/blame/DiffusionSvnBlameQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionSvnFileContentQuery' => 'applications/diffusion/query/filecontent/DiffusionSvnFileContentQuery.php',
'DiffusionSvnRawDiffQuery' => 'applications/diffusion/query/rawdiff/DiffusionSvnRawDiffQuery.php',
'DiffusionSvnRequest' => 'applications/diffusion/request/DiffusionSvnRequest.php',
'DiffusionSymbolController' => 'applications/diffusion/controller/DiffusionSymbolController.php',
Modernize global search typeahead datasource Summary: Ref T4420. Bring the global search up to date. Test Plan: Typed various things into global search. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9889
2014-07-18 00:48:36 +02:00
'DiffusionSymbolDatasource' => 'applications/diffusion/typeahead/DiffusionSymbolDatasource.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionSymbolQuery' => 'applications/diffusion/query/DiffusionSymbolQuery.php',
'DiffusionTagListController' => 'applications/diffusion/controller/DiffusionTagListController.php',
'DiffusionTagListView' => 'applications/diffusion/view/DiffusionTagListView.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionTagsQueryConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionTagsQueryConduitAPIMethod.php',
Add `diffusion.uri.edit` for creating and editing repository URIs Summary: Ref T10748. Brings the rest of the transactions to EditEngine, supports creating via API. Test Plan: - Created a URI via API. - Created a URI via web. - Tried to apply sneaky transactions, got rejected with good error messages. <_< >_> Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15821
2016-04-29 22:10:37 +02:00
'DiffusionURIEditConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionURIEditConduitAPIMethod.php',
Rough sketch of new repository URI editing Summary: Ref T10748. Ref T10366. This adds a new EditEngine, EditController, Editor, Query, and Transaction for RepositoryURIs. None of these really do anything helpful yet, and these URIs are still unused in the actual application. Test Plan: {F1249794} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10366, T10748 Differential Revision: https://secure.phabricator.com/D15815
2016-04-28 17:33:44 +02:00
'DiffusionURIEditEngine' => 'applications/diffusion/editor/DiffusionURIEditEngine.php',
'DiffusionURIEditor' => 'applications/diffusion/editor/DiffusionURIEditor.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionURITestCase' => 'applications/diffusion/request/__tests__/DiffusionURITestCase.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionUpdateCoverageConduitAPIMethod' => 'applications/diffusion/conduit/DiffusionUpdateCoverageConduitAPIMethod.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionView' => 'applications/diffusion/view/DiffusionView.php',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerArticleAtomizer' => 'applications/diviner/atomizer/DivinerArticleAtomizer.php',
'DivinerAtom' => 'applications/diviner/atom/DivinerAtom.php',
'DivinerAtomCache' => 'applications/diviner/cache/DivinerAtomCache.php',
Add an Atom controller to Diviner Summary: Ref T988. Lots of rough edges still, but this pulls the right data and dumps it into a reasonable-looking shell. Test Plan: {F44883} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6104
2013-06-01 00:14:39 +02:00
'DivinerAtomController' => 'applications/diviner/controller/DivinerAtomController.php',
Use ApplicationSearch in Diviner Summary: Ref T988. Ref T2625. Rough cut of ApplicationSearch in Diviner, for detailed Atom queries. This isn't useful yet, and isn't linked in the UI. Test Plan: {F44836} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T2625 Differential Revision: https://secure.phabricator.com/D6094
2013-05-31 19:52:25 +02:00
'DivinerAtomListController' => 'applications/diviner/controller/DivinerAtomListController.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'DivinerAtomPHIDType' => 'applications/diviner/phid/DivinerAtomPHIDType.php',
Use ApplicationSearch in Diviner Summary: Ref T988. Ref T2625. Rough cut of ApplicationSearch in Diviner, for detailed Atom queries. This isn't useful yet, and isn't linked in the UI. Test Plan: {F44836} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T2625 Differential Revision: https://secure.phabricator.com/D6094
2013-05-31 19:52:25 +02:00
'DivinerAtomQuery' => 'applications/diviner/query/DivinerAtomQuery.php',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerAtomRef' => 'applications/diviner/atom/DivinerAtomRef.php',
Use ApplicationSearch in Diviner Summary: Ref T988. Ref T2625. Rough cut of ApplicationSearch in Diviner, for detailed Atom queries. This isn't useful yet, and isn't linked in the UI. Test Plan: {F44836} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T2625 Differential Revision: https://secure.phabricator.com/D6094
2013-05-31 19:52:25 +02:00
'DivinerAtomSearchEngine' => 'applications/diviner/query/DivinerAtomSearchEngine.php',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerAtomizeWorkflow' => 'applications/diviner/workflow/DivinerAtomizeWorkflow.php',
'DivinerAtomizer' => 'applications/diviner/atomizer/DivinerAtomizer.php',
Add a book controller and various amenities to Diviner's live view Summary: Ref T988. Mostly backend changes, with a very rough frontend on top of them. See Conpherence discussion. Test Plan: {F45010} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6113
2013-06-04 20:15:34 +02:00
'DivinerBookController' => 'applications/diviner/controller/DivinerBookController.php',
Allow atoms to be queried by book Summary: Ref T4558. Allows querying for atoms from specified books. Depends on D13091. Test Plan: Poked around at `/diviner/query/`. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4558 Differential Revision: https://secure.phabricator.com/D13303
2015-06-19 10:06:53 +02:00
'DivinerBookDatasource' => 'applications/diviner/typeahead/DivinerBookDatasource.php',
Modernize Diviner Summary: Ref T4558. This diff modernizes the #diviner application. Basically: - Add an edit controller, accessible at `/book/$BOOK/edit/`. - Add edit/view policies. - Added an action menu to the `DivinerBookController` to expose the edit interface. - Allows projects to be associated with books. - Implement edges and transactions. - Implemented `PhabricatorApplicationTransactionInterface` in `DivinerLiveBook`. Test Plan: - Generated a Diviner book with `./bin/diviner generate`. - Added projects to a book and ensured that they persisted. - Changed the view policy on a book and made sure it was effective. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4558 Differential Revision: https://secure.phabricator.com/D13091
2015-06-16 23:09:53 +02:00
'DivinerBookEditController' => 'applications/diviner/controller/DivinerBookEditController.php',
Diviner Book Index styles Summary: Slightly more readable, less space than current index. LMK if you hate it though. Test Plan: Look at user and dev book indexes. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6932
2013-09-10 18:39:50 +02:00
'DivinerBookItemView' => 'applications/diviner/view/DivinerBookItemView.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'DivinerBookPHIDType' => 'applications/diviner/phid/DivinerBookPHIDType.php',
Use ApplicationSearch in Diviner Summary: Ref T988. Ref T2625. Rough cut of ApplicationSearch in Diviner, for detailed Atom queries. This isn't useful yet, and isn't linked in the UI. Test Plan: {F44836} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T2625 Differential Revision: https://secure.phabricator.com/D6094
2013-05-31 19:52:25 +02:00
'DivinerBookQuery' => 'applications/diviner/query/DivinerBookQuery.php',
'DivinerController' => 'applications/diviner/controller/DivinerController.php',
Add "live" publisher and storage to Diviner Summary: Ref T988. This adds basics for the non-static publishing target: - Storage (called "Live", e.g. `DivinerLiveAtom` to distinguish it from shared classes like `DivinerAtom`). - Mostly populate the storage. - Some minor fixes and improvements. Test Plan: Generated docs, looked at DB, saw mostly-sensible output. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D5973
2013-05-20 19:18:26 +02:00
'DivinerDAO' => 'applications/diviner/storage/DivinerDAO.php',
Modernize Diviner Summary: Ref T4558. This diff modernizes the #diviner application. Basically: - Add an edit controller, accessible at `/book/$BOOK/edit/`. - Add edit/view policies. - Added an action menu to the `DivinerBookController` to expose the edit interface. - Allows projects to be associated with books. - Implement edges and transactions. - Implemented `PhabricatorApplicationTransactionInterface` in `DivinerLiveBook`. Test Plan: - Generated a Diviner book with `./bin/diviner generate`. - Added projects to a book and ensured that they persisted. - Changed the view policy on a book and made sure it was effective. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4558 Differential Revision: https://secure.phabricator.com/D13091
2015-06-16 23:09:53 +02:00
'DivinerDefaultEditCapability' => 'applications/diviner/capability/DivinerDefaultEditCapability.php',
Move Diviner further toward usability Summary: - Complete the "project" -> "book" stuff. This is cleaner conceptually and keeps us from having yet another meaning for the word "project". - Normalize symbols during atomization. This simplifies publishing a great deal, and allows static documentation to link to dynamic documentation and vice versa, because the canonical names of symbols are agreed upon (we can tweak the actual algorithm). - Give articles a specifiable name distinct from the title, and default to something like "support" instead of "Get Help! Get Support!" so URIs end up more readable (not "Get_Help!_Get_Support!"). - Have the atomizers set book information on atoms. - Implement very basic publishers. Publishers are basically glue code between the atomization process and the rendering process -- the two we'll have initially are "static" (publish to files on disk) and "phabricator" (or similar -- publish into the database). - Handle duplicate symbol definitions in the atomize and publish pipelines. This fixes the issue where a project defines two functions named "idx()" and we currently tell them not to do that and break. Realistically, this is common in the real world and we should just roll our eyes and do the legwork to generate documentation as best we can. - Particularly, dirty all atoms with the same name as a dirty atom (e.g., if 'function f()' is updated, regnerate the documentation for all functions named f() in the book). - When publishing, we publish these at "function/f/@1", "function/f/@2". The base page will offer to disambiguate ("There are 8 functions named 'f' in this codebase, which one do you want?"). - Implement a very very basic renderer. This generates the actual HTML (or text, or XML, or whatever else) for the documentation, which the publisher dumps onto disk or into a database or whatever. - The atomize workflow actually needs to depend on books, at least sort of, so make it load config and use it properly. - Propagate multilevel dirties through the graph. If "C extends B" and "B extends A", we should regenerate C when A changes. Prior to this diff, we would regnerate B only. Test Plan: Generated some documentation. Named two articles "feedback", generated docs, saw "article/feedback/@1/" and "article/feedback/@2/" created. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4896
2013-02-18 00:39:36 +01:00
'DivinerDefaultRenderer' => 'applications/diviner/renderer/DivinerDefaultRenderer.php',
Modernize Diviner Summary: Ref T4558. This diff modernizes the #diviner application. Basically: - Add an edit controller, accessible at `/book/$BOOK/edit/`. - Add edit/view policies. - Added an action menu to the `DivinerBookController` to expose the edit interface. - Allows projects to be associated with books. - Implement edges and transactions. - Implemented `PhabricatorApplicationTransactionInterface` in `DivinerLiveBook`. Test Plan: - Generated a Diviner book with `./bin/diviner generate`. - Added projects to a book and ensured that they persisted. - Changed the view policy on a book and made sure it was effective. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4558 Differential Revision: https://secure.phabricator.com/D13091
2015-06-16 23:09:53 +02:00
'DivinerDefaultViewCapability' => 'applications/diviner/capability/DivinerDefaultViewCapability.php',
Add a publish cache for the Diviner static publisher Summary: Keep track of what we've written to disk, and regenerate only new documents. Test Plan: Changed a small number of files, saw that number of files get regenerated. Ran with "--clean" and saw everything regenerate. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4897
2013-02-18 00:40:00 +01:00
'DivinerDiskCache' => 'applications/diviner/cache/DivinerDiskCache.php',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerFileAtomizer' => 'applications/diviner/atomizer/DivinerFileAtomizer.php',
Diviner: improve links, book index, and atom view Summary: Ref T988. Minor improvements to diviner: link stuff to a valid endpoint which actually works; fix group names on the book index; improve the topics index for atom views. Test Plan: Clicked links in an article, viewed book index, viewed an article with long headers. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6598
2013-07-28 22:07:30 +02:00
'DivinerFindController' => 'applications/diviner/controller/DivinerFindController.php',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerGenerateWorkflow' => 'applications/diviner/workflow/DivinerGenerateWorkflow.php',
Add "live" publisher and storage to Diviner Summary: Ref T988. This adds basics for the non-static publishing target: - Storage (called "Live", e.g. `DivinerLiveAtom` to distinguish it from shared classes like `DivinerAtom`). - Mostly populate the storage. - Some minor fixes and improvements. Test Plan: Generated docs, looked at DB, saw mostly-sensible output. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D5973
2013-05-20 19:18:26 +02:00
'DivinerLiveAtom' => 'applications/diviner/storage/DivinerLiveAtom.php',
'DivinerLiveBook' => 'applications/diviner/storage/DivinerLiveBook.php',
Modernize Diviner Summary: Ref T4558. This diff modernizes the #diviner application. Basically: - Add an edit controller, accessible at `/book/$BOOK/edit/`. - Add edit/view policies. - Added an action menu to the `DivinerBookController` to expose the edit interface. - Allows projects to be associated with books. - Implement edges and transactions. - Implemented `PhabricatorApplicationTransactionInterface` in `DivinerLiveBook`. Test Plan: - Generated a Diviner book with `./bin/diviner generate`. - Added projects to a book and ensured that they persisted. - Changed the view policy on a book and made sure it was effective. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4558 Differential Revision: https://secure.phabricator.com/D13091
2015-06-16 23:09:53 +02:00
'DivinerLiveBookEditor' => 'applications/diviner/editor/DivinerLiveBookEditor.php',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'DivinerLiveBookFulltextEngine' => 'applications/diviner/search/DivinerLiveBookFulltextEngine.php',
Modernize Diviner Summary: Ref T4558. This diff modernizes the #diviner application. Basically: - Add an edit controller, accessible at `/book/$BOOK/edit/`. - Add edit/view policies. - Added an action menu to the `DivinerBookController` to expose the edit interface. - Allows projects to be associated with books. - Implement edges and transactions. - Implemented `PhabricatorApplicationTransactionInterface` in `DivinerLiveBook`. Test Plan: - Generated a Diviner book with `./bin/diviner generate`. - Added projects to a book and ensured that they persisted. - Changed the view policy on a book and made sure it was effective. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4558 Differential Revision: https://secure.phabricator.com/D13091
2015-06-16 23:09:53 +02:00
'DivinerLiveBookTransaction' => 'applications/diviner/storage/DivinerLiveBookTransaction.php',
'DivinerLiveBookTransactionQuery' => 'applications/diviner/query/DivinerLiveBookTransactionQuery.php',
Add "live" publisher and storage to Diviner Summary: Ref T988. This adds basics for the non-static publishing target: - Storage (called "Live", e.g. `DivinerLiveAtom` to distinguish it from shared classes like `DivinerAtom`). - Mostly populate the storage. - Some minor fixes and improvements. Test Plan: Generated docs, looked at DB, saw mostly-sensible output. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D5973
2013-05-20 19:18:26 +02:00
'DivinerLivePublisher' => 'applications/diviner/publisher/DivinerLivePublisher.php',
'DivinerLiveSymbol' => 'applications/diviner/storage/DivinerLiveSymbol.php',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'DivinerLiveSymbolFulltextEngine' => 'applications/diviner/search/DivinerLiveSymbolFulltextEngine.php',
Give Diviner a non-legacy root controller Summary: Ref T988. Instead of hard-coding the application landing page, make the Diviner root show books if any have been generated. Otherwise, show a helpful message about how to generate documentation locally. Test Plan: {F122723} {F122724} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D8416
2014-03-05 22:07:50 +01:00
'DivinerMainController' => 'applications/diviner/controller/DivinerMainController.php',
Generate PHP function documentation in Diviner Summary: Ref T988. Various improvements: - Generate function documentation, mostly correctly. - Raise some warnings about bad documentation. - Allow `.book` files to exclude paths from generation. - Add a book for technical docs. - Exclude "ghosts" from common queries (atoms which used to exist, but no longer do, but which we want to keep the PHIDs around for in case they come back later). This is a bit rough still, but puts us much closer to being able to get rid of the old Diviner. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6812
2013-08-27 12:14:00 +02:00
'DivinerPHPAtomizer' => 'applications/diviner/atomizer/DivinerPHPAtomizer.php',
'DivinerParameterTableView' => 'applications/diviner/view/DivinerParameterTableView.php',
Add a publish cache for the Diviner static publisher Summary: Keep track of what we've written to disk, and regenerate only new documents. Test Plan: Changed a small number of files, saw that number of files get regenerated. Ran with "--clean" and saw everything regenerate. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4897
2013-02-18 00:40:00 +01:00
'DivinerPublishCache' => 'applications/diviner/cache/DivinerPublishCache.php',
Move Diviner further toward usability Summary: - Complete the "project" -> "book" stuff. This is cleaner conceptually and keeps us from having yet another meaning for the word "project". - Normalize symbols during atomization. This simplifies publishing a great deal, and allows static documentation to link to dynamic documentation and vice versa, because the canonical names of symbols are agreed upon (we can tweak the actual algorithm). - Give articles a specifiable name distinct from the title, and default to something like "support" instead of "Get Help! Get Support!" so URIs end up more readable (not "Get_Help!_Get_Support!"). - Have the atomizers set book information on atoms. - Implement very basic publishers. Publishers are basically glue code between the atomization process and the rendering process -- the two we'll have initially are "static" (publish to files on disk) and "phabricator" (or similar -- publish into the database). - Handle duplicate symbol definitions in the atomize and publish pipelines. This fixes the issue where a project defines two functions named "idx()" and we currently tell them not to do that and break. Realistically, this is common in the real world and we should just roll our eyes and do the legwork to generate documentation as best we can. - Particularly, dirty all atoms with the same name as a dirty atom (e.g., if 'function f()' is updated, regnerate the documentation for all functions named f() in the book). - When publishing, we publish these at "function/f/@1", "function/f/@2". The base page will offer to disambiguate ("There are 8 functions named 'f' in this codebase, which one do you want?"). - Implement a very very basic renderer. This generates the actual HTML (or text, or XML, or whatever else) for the documentation, which the publisher dumps onto disk or into a database or whatever. - The atomize workflow actually needs to depend on books, at least sort of, so make it load config and use it properly. - Propagate multilevel dirties through the graph. If "C extends B" and "B extends A", we should regenerate C when A changes. Prior to this diff, we would regnerate B only. Test Plan: Generated some documentation. Named two articles "feedback", generated docs, saw "article/feedback/@1/" and "article/feedback/@2/" created. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4896
2013-02-18 00:39:36 +01:00
'DivinerPublisher' => 'applications/diviner/publisher/DivinerPublisher.php',
'DivinerRenderer' => 'applications/diviner/renderer/DivinerRenderer.php',
Generate PHP function documentation in Diviner Summary: Ref T988. Various improvements: - Generate function documentation, mostly correctly. - Raise some warnings about bad documentation. - Allow `.book` files to exclude paths from generation. - Add a book for technical docs. - Exclude "ghosts" from common queries (atoms which used to exist, but no longer do, but which we want to keep the PHIDs around for in case they come back later). This is a bit rough still, but puts us much closer to being able to get rid of the old Diviner. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6812
2013-08-27 12:14:00 +02:00
'DivinerReturnTableView' => 'applications/diviner/view/DivinerReturnTableView.php',
Modernize Diviner Summary: Ref T4558. This diff modernizes the #diviner application. Basically: - Add an edit controller, accessible at `/book/$BOOK/edit/`. - Add edit/view policies. - Added an action menu to the `DivinerBookController` to expose the edit interface. - Allows projects to be associated with books. - Implement edges and transactions. - Implemented `PhabricatorApplicationTransactionInterface` in `DivinerLiveBook`. Test Plan: - Generated a Diviner book with `./bin/diviner generate`. - Added projects to a book and ensured that they persisted. - Changed the view policy on a book and made sure it was effective. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4558 Differential Revision: https://secure.phabricator.com/D13091
2015-06-16 23:09:53 +02:00
'DivinerSchemaSpec' => 'applications/diviner/storage/DivinerSchemaSpec.php',
More Diviner style updates Summary: This adds a number of new styles for Diviner documentation. Not sure I've covered all the bases or wrote this in the most efficient manner, but passing it along now for early review before tightening everything up. Test Plan: Review various class pages. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6888
2013-09-05 21:29:07 +02:00
'DivinerSectionView' => 'applications/diviner/view/DivinerSectionView.php',
Move Diviner further toward usability Summary: - Complete the "project" -> "book" stuff. This is cleaner conceptually and keeps us from having yet another meaning for the word "project". - Normalize symbols during atomization. This simplifies publishing a great deal, and allows static documentation to link to dynamic documentation and vice versa, because the canonical names of symbols are agreed upon (we can tweak the actual algorithm). - Give articles a specifiable name distinct from the title, and default to something like "support" instead of "Get Help! Get Support!" so URIs end up more readable (not "Get_Help!_Get_Support!"). - Have the atomizers set book information on atoms. - Implement very basic publishers. Publishers are basically glue code between the atomization process and the rendering process -- the two we'll have initially are "static" (publish to files on disk) and "phabricator" (or similar -- publish into the database). - Handle duplicate symbol definitions in the atomize and publish pipelines. This fixes the issue where a project defines two functions named "idx()" and we currently tell them not to do that and break. Realistically, this is common in the real world and we should just roll our eyes and do the legwork to generate documentation as best we can. - Particularly, dirty all atoms with the same name as a dirty atom (e.g., if 'function f()' is updated, regnerate the documentation for all functions named f() in the book). - When publishing, we publish these at "function/f/@1", "function/f/@2". The base page will offer to disambiguate ("There are 8 functions named 'f' in this codebase, which one do you want?"). - Implement a very very basic renderer. This generates the actual HTML (or text, or XML, or whatever else) for the documentation, which the publisher dumps onto disk or into a database or whatever. - The atomize workflow actually needs to depend on books, at least sort of, so make it load config and use it properly. - Propagate multilevel dirties through the graph. If "C extends B" and "B extends A", we should regenerate C when A changes. Prior to this diff, we would regnerate B only. Test Plan: Generated some documentation. Named two articles "feedback", generated docs, saw "article/feedback/@1/" and "article/feedback/@2/" created. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4896
2013-02-18 00:39:36 +01:00
'DivinerStaticPublisher' => 'applications/diviner/publisher/DivinerStaticPublisher.php',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'DivinerSymbolRemarkupRule' => 'applications/diviner/markup/DivinerSymbolRemarkupRule.php',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerWorkflow' => 'applications/diviner/workflow/DivinerWorkflow.php',
Rename `DoorkeeperFeedWorker` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11148
2015-01-03 00:25:25 +01:00
'DoorkeeperAsanaFeedWorker' => 'applications/doorkeeper/worker/DoorkeeperAsanaFeedWorker.php',
Rename some remarkup classes Summary: Ref T5655. Rename `DoorkeeperRemarkupRuleAsana` and `DoorkeeperRemarkupRuleJIRA` for consistency. Test Plan: N/A Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D13165
2015-06-08 03:27:19 +02:00
'DoorkeeperAsanaRemarkupRule' => 'applications/doorkeeper/remarkup/DoorkeeperAsanaRemarkupRule.php',
Add DoorkeeperObjectRef, DoorkeeperBridge, DoorkeeperBridgeAsana Summary: - `DoorkeeperObjectRef` is a convenience object to keep track of `<applicationType, applicationDomain, objectType, objectID>` tuples. - `DoorkeeperBridge` provides pull/push between Phabricator and external systems. - `DoorkeeperBridgeAsana` is a bridge to Asana. Test Plan: Ran this snippet and got a task from Asana: {P871} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6273
2013-06-25 00:54:54 +02:00
'DoorkeeperBridge' => 'applications/doorkeeper/bridge/DoorkeeperBridge.php',
'DoorkeeperBridgeAsana' => 'applications/doorkeeper/bridge/DoorkeeperBridgeAsana.php',
Begin bridging GitHub objects through Doorkeeper Summary: Ref T10538. This sets up a Doorkeeper bridge for GitHub issues, and pulls issues from GitHub to create ExternalObject references. Broadly, does nothing useful. Test Plan: Put a `var_dump()` in there somewhere and saw it probably do something when running `bin/nuance update --item 44`. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10538 Differential Revision: https://secure.phabricator.com/D15447
2016-03-09 15:30:22 +01:00
'DoorkeeperBridgeGitHub' => 'applications/doorkeeper/bridge/DoorkeeperBridgeGitHub.php',
'DoorkeeperBridgeGitHubIssue' => 'applications/doorkeeper/bridge/DoorkeeperBridgeGitHubIssue.php',
Bridge GitHub users into Phabricator and attribute actions to them Summary: Ref T10538. Ref T10537. This creates PHIDs which represent GitHub users, and uses them as the actors for synchronized comments. I've just made them Doorkeeper objects. There are three major kinds of objects they //could// possibly be: - Nuance requestor objects. - External account objects. - Doorkeeper objects. I don't think we actually need distinct nuance requestor objects. These don't really do anything right now, and were originally created before Doorkeeper. I think Doorkeeper is a superset of nuance requestor functionality, and better developed and more flexible. Likewise, doorkeeper objects are much more flexible than external account objects, and it's nice to imagine that we can import from Twootfeed or whatever without needing to build full OAuth for it. I also like less stuff touching auth code, when possible. Making these separate from external accounts does make it a bit harder to reconcile external users with internal users, but I think that's OK, and that it's generally desirable to show the real source of a piece of content. That is, if I wrote a comment on GitHub but also have a Phabricator account, I think it's good to show "epriestley (GitHub)" (the GitHub user) as the author, not "epriestley" (the Phabricator user). I think this is generally less confusing overall, and we can add more linkage later to make it clearer. Test Plan: {F1194104} {F1194105} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537, T10538 Differential Revision: https://secure.phabricator.com/D15541
2016-03-28 21:01:18 +02:00
'DoorkeeperBridgeGitHubUser' => 'applications/doorkeeper/bridge/DoorkeeperBridgeGitHubUser.php',
Add JIRA doorkeeper and remarkup support Summary: Ref T3687. Adds a Doorkeeper bridge for JIRA issues, plus remarkup support. In particular: - The Asana and JIRA remarkup rules shared most of their implementation, so I refactored what I could into a base class. - Actual bridge implementation is straightforward and similar to Asana, although probably not similar enough to really justify refactoring. Test Plan: - When logged in as a JIRA-connected user, pasted a JIRA issue link and saw it enriched at rendering time. - Logged in and out with JIRA. - Tested an Asana link, too (seems I haven't broken anything). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6878
2013-09-04 02:27:38 +02:00
'DoorkeeperBridgeJIRA' => 'applications/doorkeeper/bridge/DoorkeeperBridgeJIRA.php',
Fix JIRA issue URI selection for JIRA installs which are not on the domain root Summary: Fixes T4859. See that for details. Test Plan: - Verified things still work on my local (domain root) install. - Added some unit tests. - Did not verify a non-root install since I don't have one handy, hopefully @salehe can help. Reviewers: btrahan Reviewed By: btrahan Subscribers: salehe, epriestley Maniphest Tasks: T4859 Differential Revision: https://secure.phabricator.com/D8836
2014-05-18 14:45:21 +02:00
'DoorkeeperBridgeJIRATestCase' => 'applications/doorkeeper/bridge/__tests__/DoorkeeperBridgeJIRATestCase.php',
When an object has been imported from an external source, show a curtain panel Summary: Ref T10537. Show when an object is bridged to something external. Test Plan: {F1190099} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15520
2016-03-25 13:29:19 +01:00
'DoorkeeperBridgedObjectCurtainExtension' => 'applications/doorkeeper/engineextension/DoorkeeperBridgedObjectCurtainExtension.php',
Introduce "bridged" objects Summary: Ref T10537. These are objects which are bound to some external object, like a Maniphest task which is a representation of a GitHub issue. This doesn't do much yet and may change, but my thinking is: - I'm putting these on-object instead of on edges because I think we want to actively change the UI for them (e.g., clearly call out that the object is bridged) but don't want every page to need to do extra queries in the common case where zero bridged objects exist anywhere in the system. - I'm making these one-to-one, more or less: an issue can't be bridged to a bunch of tasks, nor can a bunch of tasks be bridged to a single issue. Pretty sure this makes sense? I can't come up with any reasonable, realistic cases where you want a single GitHub issue to publish to multiple different tasks in Maniphest. - Technically, one type of each bridgable object could be bridged, but I expect this to never actually occur. Hopefully. Test Plan: Ran storage upgrade, loaded some pages. Reviewers: chad Reviewed By: chad Subscribers: Luke081515.2 Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15502
2016-03-09 17:40:19 +01:00
'DoorkeeperBridgedObjectInterface' => 'applications/doorkeeper/bridge/DoorkeeperBridgedObjectInterface.php',
Add DoorkeeperExternalObject Summary: Ref T2852. This table holds data about external objects and allows us to write edges to them. Objects are identified with an `<applicationType, applicationDomain, objectType, objectID>` tuple. For example, Asana tasks will be, e.g., `<asana, asana.com, asana:task, 93829279873>` or similar. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6271
2013-06-25 00:54:36 +02:00
'DoorkeeperDAO' => 'applications/doorkeeper/storage/DoorkeeperDAO.php',
'DoorkeeperExternalObject' => 'applications/doorkeeper/storage/DoorkeeperExternalObject.php',
Bridge GitHub users into Phabricator and attribute actions to them Summary: Ref T10538. Ref T10537. This creates PHIDs which represent GitHub users, and uses them as the actors for synchronized comments. I've just made them Doorkeeper objects. There are three major kinds of objects they //could// possibly be: - Nuance requestor objects. - External account objects. - Doorkeeper objects. I don't think we actually need distinct nuance requestor objects. These don't really do anything right now, and were originally created before Doorkeeper. I think Doorkeeper is a superset of nuance requestor functionality, and better developed and more flexible. Likewise, doorkeeper objects are much more flexible than external account objects, and it's nice to imagine that we can import from Twootfeed or whatever without needing to build full OAuth for it. I also like less stuff touching auth code, when possible. Making these separate from external accounts does make it a bit harder to reconcile external users with internal users, but I think that's OK, and that it's generally desirable to show the real source of a piece of content. That is, if I wrote a comment on GitHub but also have a Phabricator account, I think it's good to show "epriestley (GitHub)" (the GitHub user) as the author, not "epriestley" (the Phabricator user). I think this is generally less confusing overall, and we can add more linkage later to make it clearer. Test Plan: {F1194104} {F1194105} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537, T10538 Differential Revision: https://secure.phabricator.com/D15541
2016-03-28 21:01:18 +02:00
'DoorkeeperExternalObjectPHIDType' => 'applications/doorkeeper/phid/DoorkeeperExternalObjectPHIDType.php',
Add DoorkeeperExternalObjectQuery, expose more ref/import APIs Summary: Ref T2852. - Broadly, we support "I have a Ref, I need a PHID" well but not "I have a PHID, I need a Ref". - Add DoorkeeperExternalObjectQuery, and use it to query ExternalObjects. - Allow external objects to be imported by their internal PHIDs. Basically, if we have an edge pointing at an ExternalObject, we can say "load all the data about this" from just the PHID and have it hit all the same code. - Allow construction of Refs from ExternalObjects. This makes the "I have a PHID, I need a Ref" easier. Test Plan: - Verified Asana links still enrich properly at display time. - Used in future revision. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6294
2013-06-26 01:30:44 +02:00
'DoorkeeperExternalObjectQuery' => 'applications/doorkeeper/query/DoorkeeperExternalObjectQuery.php',
Generalize Asana-publishable feed story objects Summary: Ref T2852. Pulls the Differential-specific aspects of the Asana sync out of the worker. Next diff will add a publisher for Audit/Diffusion. Test Plan: Published events, including state changes. Saw them reflected correctly in Asana. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6569
2013-07-26 17:56:35 +02:00
'DoorkeeperFeedStoryPublisher' => 'applications/doorkeeper/engine/DoorkeeperFeedStoryPublisher.php',
Refactor shared code between JIRA + Asana publishers into a base class Summary: Ref T3687. See some discussion in D6892. The JIRA doorkeeper publisher shares a reasonable amount of code with the Asana publisher. Remedy this: - Create `DoorkeeperFeedWorker`, where shared functionality lives (mostly related to building story context objects). - Push responsibility for enabling/disabling a worker into this new layer, via `isEnabled()`. This allows `FeedPublisherWorker` to dynamically find and schedule doorkeeper publishers, so third parties can add additional doorkeeper publishers. - Some general cleanup/documentation. Test Plan: Used `bin/feed republish` to republish stories about objects with JIRA and Asana links. Verified that doorkeeper publishers activated properly, made calls, and published events into the remote systems. Reviewers: btrahan, akopanev22 Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6906
2013-09-11 00:22:01 +02:00
'DoorkeeperFeedWorker' => 'applications/doorkeeper/worker/DoorkeeperFeedWorker.php',
Add remarkup support for Asana URIs Summary: Ref T2852. Primarily, this expands API access to Asana. As a user-visible effect, it links Asana tasks in Remarkup. When a user enters an Asana URI, we register an onload behavior to make an Ajax call for the lookup. This respects privacy imposed by the API without creating a significant performance impact. Test Plan: {F47183} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6274
2013-06-25 00:55:08 +02:00
'DoorkeeperImportEngine' => 'applications/doorkeeper/engine/DoorkeeperImportEngine.php',
Rename `DoorkeeperFeedWorker` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11148
2015-01-03 00:25:25 +01:00
'DoorkeeperJIRAFeedWorker' => 'applications/doorkeeper/worker/DoorkeeperJIRAFeedWorker.php',
Rename some remarkup classes Summary: Ref T5655. Rename `DoorkeeperRemarkupRuleAsana` and `DoorkeeperRemarkupRuleJIRA` for consistency. Test Plan: N/A Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D13165
2015-06-08 03:27:19 +02:00
'DoorkeeperJIRARemarkupRule' => 'applications/doorkeeper/remarkup/DoorkeeperJIRARemarkupRule.php',
Make "JIRA Issues" field work better with noncredentialed accounts Summary: Currently, users get an error when making any changes to this field if they don't have a linked JIRA account. Instead: - We should only raise an error if they're trying to //add// issues, and only on the new issues. It's always fine to remove issues, and existing issues the author can't see are also fine. - When we can't add things because there's no account (vs because there's a permissions error or they don't exist), raise a more tailored exception. Test Plan: - As JIRA and non-JIRA users, made various edits to this field. - Got appropriate exceptions, including better tailoring. Reviewers: btrahan Reviewed By: btrahan Subscribers: mbishopim3, epriestley Differential Revision: https://secure.phabricator.com/D8676
2014-04-02 21:03:59 +02:00
'DoorkeeperMissingLinkException' => 'applications/doorkeeper/exception/DoorkeeperMissingLinkException.php',
Add DoorkeeperObjectRef, DoorkeeperBridge, DoorkeeperBridgeAsana Summary: - `DoorkeeperObjectRef` is a convenience object to keep track of `<applicationType, applicationDomain, objectType, objectID>` tuples. - `DoorkeeperBridge` provides pull/push between Phabricator and external systems. - `DoorkeeperBridgeAsana` is a bridge to Asana. Test Plan: Ran this snippet and got a task from Asana: {P871} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6273
2013-06-25 00:54:54 +02:00
'DoorkeeperObjectRef' => 'applications/doorkeeper/engine/DoorkeeperObjectRef.php',
Add JIRA doorkeeper and remarkup support Summary: Ref T3687. Adds a Doorkeeper bridge for JIRA issues, plus remarkup support. In particular: - The Asana and JIRA remarkup rules shared most of their implementation, so I refactored what I could into a base class. - Actual bridge implementation is straightforward and similar to Asana, although probably not similar enough to really justify refactoring. Test Plan: - When logged in as a JIRA-connected user, pasted a JIRA issue link and saw it enriched at rendering time. - Logged in and out with JIRA. - Tested an Asana link, too (seems I haven't broken anything). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6878
2013-09-04 02:27:38 +02:00
'DoorkeeperRemarkupRule' => 'applications/doorkeeper/remarkup/DoorkeeperRemarkupRule.php',
Generate expected schemata for Doorkeeper, Draft, Drydock, Feed Summary: Ref T1191. Notable: - Allowed objects to remove default columns (some feed tables have no `id`). - Added a "note" severity and moved all the charset stuff down to that to make progress more clear. Test Plan: Trying to make the whole thing blue... {F205970} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10519
2014-09-18 20:15:49 +02:00
'DoorkeeperSchemaSpec' => 'applications/doorkeeper/storage/DoorkeeperSchemaSpec.php',
Render linked JIRA issues with a Doorkeeper tag Summary: Fixes T3687. Instead of rendering "JIRA Issues" in Differential using plain links, render them using Doorkeeper tags so they get the nice "enhance with object name" effect. Test Plan: {F84886} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D7648
2013-11-25 23:54:35 +01:00
'DoorkeeperTagView' => 'applications/doorkeeper/view/DoorkeeperTagView.php',
Add remarkup support for Asana URIs Summary: Ref T2852. Primarily, this expands API access to Asana. As a user-visible effect, it links Asana tasks in Remarkup. When a user enters an Asana URI, we register an onload behavior to make an Ajax call for the lookup. This respects privacy imposed by the API without creating a significant performance impact. Test Plan: {F47183} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6274
2013-06-25 00:55:08 +02:00
'DoorkeeperTagsController' => 'applications/doorkeeper/controller/DoorkeeperTagsController.php',
Implement a rough AlmanacService blueprint in Drydock Summary: Ref T9253. Broadly, this realigns Allocator behavior to be more consistent and straightforward and amenable to intended future changes. This attempts to make language more consistent: resources are "allocated" and leases are "acquired". This prepares for (but does not implement) optimistic "slot locking", as discussed in D10304. Although I suspect some blueprints will need to perform other locking eventually, this does feel like a good fit for most of the locking blueprints need to do. In particular, I've made the blueprint operations on `$resource` and `$lease` objects more purposeful: they need to invoke an activator on the appropriate object to be implemented correctly. Before they invoke this activator method, they configure the object. In a future diff, this configuration will include specifying slot locks that the lease or resource must acquire. So the API will be something like: $lease ->setActivateWhenAcquired(true) ->needSlotLock('x') ->needSlotLock('y') ->acquireOnResource($resource); In the common case where slot locks are a good fit, I think this should make correct blueprint implementation very straightforward. This prepares for (but does not implement) resources and leases which need significant setup steps. I've basically carved out two modes: - The "activate immediately" mode, as here, immediately opens the resource or activates the lease. This is appropriate if little or no setup is required. I expect many leases to operate in this mode, although I expect many resources will operate in the other mode. - The "allocate now, activate later" mode, which is not fully implemented yet. This will queue setup workers when the allocator exits. Overall, this will work very similarly to Harbormaster. - This new structure makes it acceptable for blueprints to sleep as long as they want during resource allocation and lease acquisition, so long as they are not waiting on anything which needs to be completed by the queue. Putting a `sleep(15 * 60)` in your EC2Blueprint to wait for EC2 to bring a machine up will perform worse than using delayed activation, but won't deadlock the queue or block any locks. Overall, this flow is more similar to Harbormaster's flow. Having consistency between Harbormaster's model and Drydock's model is good, and I think Harbormaster's model is also simply much better than Drydock's (what exists today in Drydock was implemented a long time ago, and we had more support and infrastructure by the time Harbormaster was implemented, as well as a more clearly defined problem). The particular strength of Harbormaster is that objects always (or almost always, at least) have a single, clearly defined writer. Ensuring objects have only one writer prevents races and makes reasoning about everything easier. Drydock does not currently have a clearly defined single writer, but this moves us in that direction. We'll probably need more primitives eventually to flesh this out, like Harbormaster's command queue for messaging objects which you can't write to. This blueprint was originally implemented in D13843. This makes a few changes to the blueprint itself: - A bunch of code from that (e.g., interfaces) doesn't exist yet. - I let the blueprint have multiple services. This simplifies the code a little and seems like it costs us nothing. This also removes `bin/drydock create-resource`, which no longer makes sense to expose. It won't get locking, leasing, etc., correct, and can not be made correct. NOTE: This technically works but doesn't do anything useful yet. Test Plan: Used `bin/drydock lease --type host` to acquire leases against these blueprints. Reviewers: hach-que, chad Reviewed By: hach-que, chad Subscribers: Mnkras Maniphest Tasks: T9253 Differential Revision: https://secure.phabricator.com/D14117
2015-09-21 13:43:53 +02:00
'DrydockAlmanacServiceHostBlueprintImplementation' => 'applications/drydock/blueprint/DrydockAlmanacServiceHostBlueprintImplementation.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockApacheWebrootInterface' => 'applications/drydock/interface/webroot/DrydockApacheWebrootInterface.php',
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 16:15:25 +02:00
'DrydockAuthorization' => 'applications/drydock/storage/DrydockAuthorization.php',
'DrydockAuthorizationAuthorizeController' => 'applications/drydock/controller/DrydockAuthorizationAuthorizeController.php',
'DrydockAuthorizationListController' => 'applications/drydock/controller/DrydockAuthorizationListController.php',
'DrydockAuthorizationListView' => 'applications/drydock/view/DrydockAuthorizationListView.php',
'DrydockAuthorizationPHIDType' => 'applications/drydock/phid/DrydockAuthorizationPHIDType.php',
'DrydockAuthorizationQuery' => 'applications/drydock/query/DrydockAuthorizationQuery.php',
'DrydockAuthorizationSearchEngine' => 'applications/drydock/query/DrydockAuthorizationSearchEngine.php',
'DrydockAuthorizationViewController' => 'applications/drydock/controller/DrydockAuthorizationViewController.php',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockBlueprint' => 'applications/drydock/storage/DrydockBlueprint.php',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockBlueprintController' => 'applications/drydock/controller/DrydockBlueprintController.php',
Allow Drydock blueprints to define and use custom fields Summary: This allows Drydock blueprints to define custom fields for blueprint settings. Test Plan: Pulled out of EC2 allocator diff. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D10224
2014-08-12 00:39:00 +02:00
'DrydockBlueprintCoreCustomField' => 'applications/drydock/customfield/DrydockBlueprintCoreCustomField.php',
'DrydockBlueprintCustomField' => 'applications/drydock/customfield/DrydockBlueprintCustomField.php',
Improve Drydock log search engine Summary: Ref T2015. This allows searching based on blueprints, resources or leases when viewing the logs, which helps when searching for events that occured to a particular blueprint / resource / lease. Unlike the logs shown on the resource / lease pages, the search engine supports paging properly, which means it can be used to find entries in the past. Test Plan: Used the Drydock log search page. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: joshuaspence, Korvin, epriestley Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D10874
2015-08-24 13:13:20 +02:00
'DrydockBlueprintDatasource' => 'applications/drydock/typeahead/DrydockBlueprintDatasource.php',
Allow Drydock blueprints to be disabled Summary: Ref T9252. If you have a blueprint and you do not like that blueprint very much, you can disable it. Test Plan: Disabled / enabled some blueprints. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14156
2015-09-24 19:18:17 +02:00
'DrydockBlueprintDisableController' => 'applications/drydock/controller/DrydockBlueprintDisableController.php',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockBlueprintEditController' => 'applications/drydock/controller/DrydockBlueprintEditController.php',
Convert DrydockBlueprints to EditEngine Summary: Ref T10457. Fixes T10024. This primarily just modernizes blueprints to use EditEngine. This also fixes T10024, which was an issue with stored properties not being flagged correctly. Also slightly improves typeaheads for blueprints (more information, disabled state). Test Plan: - Created and edited various types of blueprints. - Set and removed limits. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10024, T10457 Differential Revision: https://secure.phabricator.com/D15390
2016-03-03 13:34:47 +01:00
'DrydockBlueprintEditEngine' => 'applications/drydock/editor/DrydockBlueprintEditEngine.php',
Add transactions to Drydock blueprint editing Summary: Ref T2015. Fixes TODO. Test Plan: {F100338} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7922
2014-01-09 21:19:54 +01:00
'DrydockBlueprintEditor' => 'applications/drydock/editor/DrydockBlueprintEditor.php',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockBlueprintImplementation' => 'applications/drydock/blueprint/DrydockBlueprintImplementation.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'DrydockBlueprintImplementationTestCase' => 'applications/drydock/blueprint/__tests__/DrydockBlueprintImplementationTestCase.php',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockBlueprintListController' => 'applications/drydock/controller/DrydockBlueprintListController.php',
Allow Drydock blueprints to be searched by name Summary: Ref T10457. The ngram indexing seems to be working well; extend it into Drydock. Also clean up the list controller a little bit. Test Plan: - Ran migrations. - Searched for blueprints by name. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15389
2016-03-03 13:17:24 +01:00
'DrydockBlueprintNameNgrams' => 'applications/drydock/storage/DrydockBlueprintNameNgrams.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'DrydockBlueprintPHIDType' => 'applications/drydock/phid/DrydockBlueprintPHIDType.php',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockBlueprintQuery' => 'applications/drydock/query/DrydockBlueprintQuery.php',
Use ApplicationSearch for Drydock Blueprints Summary: Ref T2015. This turns the side nav into a bigger mess for now, but uses ApplicationSearch for blueprints. Test Plan: Queried blueprints in the UI. Reviewers: btrahan Reviewed By: btrahan CC: hach-que, aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7829
2013-12-26 21:30:04 +01:00
'DrydockBlueprintSearchEngine' => 'applications/drydock/query/DrydockBlueprintSearchEngine.php',
Add transactions to Drydock blueprint editing Summary: Ref T2015. Fixes TODO. Test Plan: {F100338} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7922
2014-01-09 21:19:54 +01:00
'DrydockBlueprintTransaction' => 'applications/drydock/storage/DrydockBlueprintTransaction.php',
'DrydockBlueprintTransactionQuery' => 'applications/drydock/query/DrydockBlueprintTransactionQuery.php',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockBlueprintViewController' => 'applications/drydock/controller/DrydockBlueprintViewController.php',
Add a command queue to Drydock to manage lease/resource release Summary: Ref T9252. Broadly, Drydock currently races on releasing objects from the "active" state. To reproduce this: - Scatter some sleep()s pretty much anywhere in the release code. - Release several times from web UI or CLI in quick succession. Resources or leases will execute some release code twice or otherwise do inconsistent things. (I didn't chase down a detailed reproduction scenario for this since inspection of the code makes it clear that there are no meaningful locks or mechanisms preventing this.) Instead, add a Harbormaster-style command queue to resources and leases. When something wants to do a release, it adds a command to the queue and schedules a worker. The workers acquire a lock, then try to consume commands from the queue. This guarantees that only one process is responsible for writes to active resource/leases. This is the last major step to giving resources and leases a single writer during all states: - Resource, Unsaved: AllocatorWorker - Resource, Pending: ResourceWorker (Possible rename to "Allocated?") - Resource, Open: This diff, ResourceUpdateWorker. (Likely rename to "Active"). - Resource, Closed/Broken: Future destruction worker. (Likely rename to "Released" / "Broken"; maybe remove "Broken"). - Resource, Destroyed: No writes. - Lease, Unsaved: Whatever wants the lease. - Lease, Pending: AllocatorWorker - Lease, Acquired: LeaseWorker - Lease, Active: This diff, LeaseUpdateWorker. - Lease, Released/Broken: Future destruction worker (Maybe remove "Broken"?) - Lease, Expired: No writes. (Likely rename to "Destroyed"). In most phases, we can already guarantee that there is a single writer without doing any extra work. This is more complicated in the "Active" case because the release buttons on the web UI, the release tools on the CLI, the lease requestor itself, the garbage collector, and any other release process cleaning up related objects may try to effect a release. All of these could race one another (and, in many cases, race other processes from other phases because all of these get to act immediately) as this code is currently written. Using a queue here lets us make sure there's only a single writer in this phase. One thing which is notable is that whatever acquires a lease **can not write to it**! It is never the writer once it queues the lease for activation. It can not write to any resources, either. And, likewise, Blueprints can not write to resources while acquiring or releasing leases. We may need to provide a mechinism so that blueprints and/or resource/lease holders get to attach some storage to resources/leases for bookkeeping. For example, a blueprint might need to keep some kind of cache on a resource to help it manage state. But I think we can cross that bridge when we come to it, and nothing else would need to write to this storage so it's technically straightforward to introduce such a mechanism if we need one. Test Plan: - Viewed buttons in web UI, checked enabled/disabled states. - Clicked the buttons. - Saw commands show up in the command queue. - Saw some daemon stuff get scheduled. - Ran CLI tools, saw commands get consumed and resources/leases release. Reviewers: hach-que, chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14143
2015-09-23 16:42:08 +02:00
'DrydockCommand' => 'applications/drydock/storage/DrydockCommand.php',
Improve Drydock errors for empty commits and missing changes Summary: Ref T10093. Show better errors when a commit fails because it has already been merged and when a fetch fails because the ref isn't present in the remote. Test Plan: {F1160794} {F1160795} Reviewers: chad Reviewed By: chad Subscribers: michaeljs1990, yelirekim Maniphest Tasks: T10093 Differential Revision: https://secure.phabricator.com/D15420
2016-03-07 00:13:40 +01:00
'DrydockCommandError' => 'applications/drydock/exception/DrydockCommandError.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockCommandInterface' => 'applications/drydock/interface/command/DrydockCommandInterface.php',
Add a command queue to Drydock to manage lease/resource release Summary: Ref T9252. Broadly, Drydock currently races on releasing objects from the "active" state. To reproduce this: - Scatter some sleep()s pretty much anywhere in the release code. - Release several times from web UI or CLI in quick succession. Resources or leases will execute some release code twice or otherwise do inconsistent things. (I didn't chase down a detailed reproduction scenario for this since inspection of the code makes it clear that there are no meaningful locks or mechanisms preventing this.) Instead, add a Harbormaster-style command queue to resources and leases. When something wants to do a release, it adds a command to the queue and schedules a worker. The workers acquire a lock, then try to consume commands from the queue. This guarantees that only one process is responsible for writes to active resource/leases. This is the last major step to giving resources and leases a single writer during all states: - Resource, Unsaved: AllocatorWorker - Resource, Pending: ResourceWorker (Possible rename to "Allocated?") - Resource, Open: This diff, ResourceUpdateWorker. (Likely rename to "Active"). - Resource, Closed/Broken: Future destruction worker. (Likely rename to "Released" / "Broken"; maybe remove "Broken"). - Resource, Destroyed: No writes. - Lease, Unsaved: Whatever wants the lease. - Lease, Pending: AllocatorWorker - Lease, Acquired: LeaseWorker - Lease, Active: This diff, LeaseUpdateWorker. - Lease, Released/Broken: Future destruction worker (Maybe remove "Broken"?) - Lease, Expired: No writes. (Likely rename to "Destroyed"). In most phases, we can already guarantee that there is a single writer without doing any extra work. This is more complicated in the "Active" case because the release buttons on the web UI, the release tools on the CLI, the lease requestor itself, the garbage collector, and any other release process cleaning up related objects may try to effect a release. All of these could race one another (and, in many cases, race other processes from other phases because all of these get to act immediately) as this code is currently written. Using a queue here lets us make sure there's only a single writer in this phase. One thing which is notable is that whatever acquires a lease **can not write to it**! It is never the writer once it queues the lease for activation. It can not write to any resources, either. And, likewise, Blueprints can not write to resources while acquiring or releasing leases. We may need to provide a mechinism so that blueprints and/or resource/lease holders get to attach some storage to resources/leases for bookkeeping. For example, a blueprint might need to keep some kind of cache on a resource to help it manage state. But I think we can cross that bridge when we come to it, and nothing else would need to write to this storage so it's technically straightforward to introduce such a mechanism if we need one. Test Plan: - Viewed buttons in web UI, checked enabled/disabled states. - Clicked the buttons. - Saw commands show up in the command queue. - Saw some daemon stuff get scheduled. - Ran CLI tools, saw commands get consumed and resources/leases release. Reviewers: hach-que, chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14143
2015-09-23 16:42:08 +02:00
'DrydockCommandQuery' => 'applications/drydock/query/DrydockCommandQuery.php',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockConsoleController' => 'applications/drydock/controller/DrydockConsoleController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockConstants' => 'applications/drydock/constants/DrydockConstants.php',
'DrydockController' => 'applications/drydock/controller/DrydockController.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'DrydockCreateBlueprintsCapability' => 'applications/drydock/capability/DrydockCreateBlueprintsCapability.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockDAO' => 'applications/drydock/storage/DrydockDAO.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'DrydockDefaultEditCapability' => 'applications/drydock/capability/DrydockDefaultEditCapability.php',
'DrydockDefaultViewCapability' => 'applications/drydock/capability/DrydockDefaultViewCapability.php',
Implement "Upload Artifact" build step Summary: This implements a build step for uploading an artifact from a build machine to Phabricator. It uses SFTP so that it will work on both UNIX and Windows build machines. Test Plan: Ran an "Upload Artifact" build against a Windows machine (with FreeSSHD installed). The artifact uploaded to Phabricator, appeared on the build view and the file contents could be viewed from Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7582
2013-12-06 04:11:05 +01:00
'DrydockFilesystemInterface' => 'applications/drydock/interface/filesystem/DrydockFilesystemInterface.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockInterface' => 'applications/drydock/interface/DrydockInterface.php',
Rough cut of DrydockRepositoryOperation Summary: Ref T182. This doesn't do anything interesting yet and is mostly scaffolding, but here's roughly the workflow. From previous revision, you can configure "Repository Automation" for a repository: {F875741} If it's configured, a new "Land Revision" button shows up: {F875743} Once you click it you get a big warning dialog that it won't work, and then this shows up at the top of the revision (completely temporary/placeholder UI, some day a nice progress bar or whatever): {F875747} If you're lucky, the operation eventually sort of works: {F875750} It only runs `git show` right now, doesn't actually do any writes or anything. Test Plan: - Clicked "Land Revision". - Watched `phd debug task`. - Saw it log `git show` to output. - Verified operation success in UI (by fiddling URL, no way to get there normally yet). Reviewers: chad Reviewed By: chad Subscribers: revi Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D14266
2015-10-14 00:46:12 +02:00
'DrydockLandRepositoryOperation' => 'applications/drydock/operation/DrydockLandRepositoryOperation.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockLease' => 'applications/drydock/storage/DrydockLease.php',
Add Drydock log types and more logging Summary: Ref T9252. Make log types modular so they can be translated and have complicated rendering logic if necessary (currently, none have this). Test Plan: {F855330} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14198
2015-10-01 17:10:07 +02:00
'DrydockLeaseAcquiredLogType' => 'applications/drydock/logtype/DrydockLeaseAcquiredLogType.php',
'DrydockLeaseActivatedLogType' => 'applications/drydock/logtype/DrydockLeaseActivatedLogType.php',
Add more Drydock log types and some additional logging Summary: Ref T9252. Add a bit more logging and improve some behaviors. Test Plan: Restarted a build, got a good result. Reviewers: chad, hach-que Reviewed By: hach-que Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14210
2015-10-01 17:11:42 +02:00
'DrydockLeaseActivationFailureLogType' => 'applications/drydock/logtype/DrydockLeaseActivationFailureLogType.php',
'DrydockLeaseActivationYieldLogType' => 'applications/drydock/logtype/DrydockLeaseActivationYieldLogType.php',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockLeaseController' => 'applications/drydock/controller/DrydockLeaseController.php',
Improve Drydock log search engine Summary: Ref T2015. This allows searching based on blueprints, resources or leases when viewing the logs, which helps when searching for events that occured to a particular blueprint / resource / lease. Unlike the logs shown on the resource / lease pages, the search engine supports paging properly, which means it can be used to find entries in the past. Test Plan: Used the Drydock log search page. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: joshuaspence, Korvin, epriestley Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D10874
2015-08-24 13:13:20 +02:00
'DrydockLeaseDatasource' => 'applications/drydock/typeahead/DrydockLeaseDatasource.php',
Add Drydock log types and more logging Summary: Ref T9252. Make log types modular so they can be translated and have complicated rendering logic if necessary (currently, none have this). Test Plan: {F855330} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14198
2015-10-01 17:10:07 +02:00
'DrydockLeaseDestroyedLogType' => 'applications/drydock/logtype/DrydockLeaseDestroyedLogType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockLeaseListController' => 'applications/drydock/controller/DrydockLeaseListController.php',
Move Drydock object list rendering to SearchEngine Summary: Ref T4986. Allows the Drydock search engines to render as panels. Test Plan: Viewed affected interfaces in Drydock. Created panels from each engine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9103
2014-05-13 21:14:33 +02:00
'DrydockLeaseListView' => 'applications/drydock/view/DrydockLeaseListView.php',
Use Drydock authorizations when acquiring leases Summary: Ref T9519. When acquiring leases on resources: - Only consider resources created by authorized blueprints. - Only consider authorized blueprints when creating new resources. - Fail with a tailored error if no blueprints are allowed. - Fail with a tailored error if missing authorizations are causing acquisition failure. One somewhat-substantial issue with this is that it's pretty hard to figure out from the Harbormaster side. Specifically, the Build step UI does not show field value anywhere, so the presence of unapproved blueprints is not communicated. This is much more clear in Drydock. I'll plan to address this in future changes to Harbormaster, since there are other related/similar issues anyway. Test Plan: {F872527} Reviewers: hach-que, chad Reviewed By: chad Maniphest Tasks: T9519 Differential Revision: https://secure.phabricator.com/D14254
2015-10-13 02:02:35 +02:00
'DrydockLeaseNoAuthorizationsLogType' => 'applications/drydock/logtype/DrydockLeaseNoAuthorizationsLogType.php',
'DrydockLeaseNoBlueprintsLogType' => 'applications/drydock/logtype/DrydockLeaseNoBlueprintsLogType.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'DrydockLeasePHIDType' => 'applications/drydock/phid/DrydockLeasePHIDType.php',
Show Drydock resource leases, add DrydockLeaseQuery, allow reuse of working copies Summary: Minor updates to Drydock things to make them work better. In particular, after this patch working copies are correctly allocated or reused. Test Plan: Ran "reparse.php --harbormaster <derp derp>", saw reuse of working copies when unleased resources were avilable. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D4216
2012-12-17 22:53:32 +01:00
'DrydockLeaseQuery' => 'applications/drydock/query/DrydockLeaseQuery.php',
Add Drydock log types and more logging Summary: Ref T9252. Make log types modular so they can be translated and have complicated rendering logic if necessary (currently, none have this). Test Plan: {F855330} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14198
2015-10-01 17:10:07 +02:00
'DrydockLeaseQueuedLogType' => 'applications/drydock/logtype/DrydockLeaseQueuedLogType.php',
Make Drydock reclaim unused resources when it reaches a resource limit Summary: Fixes T9994. Currently, when Drydock can't allocate a new resource because some limit has been reached, it waits patiently for a resource to become available. It is possible that no resource will ever become available. Particularly with "Working Copy" resources, the new lease may want a copy of `rB`, but the resource may already be maxed out on `rA`. Right now, no process exists to automatically reclaim the unused `rA`. When we encounter this situation, try to reclaim one of the other resources if it is just sitting there unused. Specifically: - Add a "reclaim" command which means "release this resource //if// it is completely unused". - Add a `bin/drydock reclaim` to send this command to every active resource. - When we try to acquire a resource and can't, but only because of some kind of limit / utilization problem, try to release an unused resource to free up some room. Test Plan: - Set "Working Copy" resource limit to 1. - Ran "Test Configuration" in `rA`, which worked. - Ran "Test Configuration" in `rB`, which hung forever. - Applied patch. - Ran "Test Configuration" in `rB`, saw it reclaim the `rA` resource, use the slot, then succeed. - Ran "Test Configuration" in `rA` again, saw it grab the slot back. - Ran `bin/drydock reclaim` and saw it reclaim a bunch of old orphaned resources. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9994 Differential Revision: https://secure.phabricator.com/D14819
2015-12-18 17:44:13 +01:00
'DrydockLeaseReclaimLogType' => 'applications/drydock/logtype/DrydockLeaseReclaimLogType.php',
Allow leases to be explicitly released via web or CLI Summary: Permit the forcible release of Drydock leases. The implementation isn't very exciting for now. Test Plan: Released leases via web and CLI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D4181
2012-12-15 00:42:58 +01:00
'DrydockLeaseReleaseController' => 'applications/drydock/controller/DrydockLeaseReleaseController.php',
Add Drydock log types and more logging Summary: Ref T9252. Make log types modular so they can be translated and have complicated rendering logic if necessary (currently, none have this). Test Plan: {F855330} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14198
2015-10-01 17:10:07 +02:00
'DrydockLeaseReleasedLogType' => 'applications/drydock/logtype/DrydockLeaseReleasedLogType.php',
Use ApplicationSearch to manage DrydockLeases Summary: Ref T2015. Applies ApplicationSearch to DrydockLease. This makes the left nav in Drydock a little funky. It will probably get worse for a bit before it gets better, since I want to bring everything to ApplicationSearch and then sort out the details. Test Plan: Queried leases in Drydock. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7827
2013-12-26 19:42:00 +01:00
'DrydockLeaseSearchEngine' => 'applications/drydock/query/DrydockLeaseSearchEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockLeaseStatus' => 'applications/drydock/constants/DrydockLeaseStatus.php',
Add a command queue to Drydock to manage lease/resource release Summary: Ref T9252. Broadly, Drydock currently races on releasing objects from the "active" state. To reproduce this: - Scatter some sleep()s pretty much anywhere in the release code. - Release several times from web UI or CLI in quick succession. Resources or leases will execute some release code twice or otherwise do inconsistent things. (I didn't chase down a detailed reproduction scenario for this since inspection of the code makes it clear that there are no meaningful locks or mechanisms preventing this.) Instead, add a Harbormaster-style command queue to resources and leases. When something wants to do a release, it adds a command to the queue and schedules a worker. The workers acquire a lock, then try to consume commands from the queue. This guarantees that only one process is responsible for writes to active resource/leases. This is the last major step to giving resources and leases a single writer during all states: - Resource, Unsaved: AllocatorWorker - Resource, Pending: ResourceWorker (Possible rename to "Allocated?") - Resource, Open: This diff, ResourceUpdateWorker. (Likely rename to "Active"). - Resource, Closed/Broken: Future destruction worker. (Likely rename to "Released" / "Broken"; maybe remove "Broken"). - Resource, Destroyed: No writes. - Lease, Unsaved: Whatever wants the lease. - Lease, Pending: AllocatorWorker - Lease, Acquired: LeaseWorker - Lease, Active: This diff, LeaseUpdateWorker. - Lease, Released/Broken: Future destruction worker (Maybe remove "Broken"?) - Lease, Expired: No writes. (Likely rename to "Destroyed"). In most phases, we can already guarantee that there is a single writer without doing any extra work. This is more complicated in the "Active" case because the release buttons on the web UI, the release tools on the CLI, the lease requestor itself, the garbage collector, and any other release process cleaning up related objects may try to effect a release. All of these could race one another (and, in many cases, race other processes from other phases because all of these get to act immediately) as this code is currently written. Using a queue here lets us make sure there's only a single writer in this phase. One thing which is notable is that whatever acquires a lease **can not write to it**! It is never the writer once it queues the lease for activation. It can not write to any resources, either. And, likewise, Blueprints can not write to resources while acquiring or releasing leases. We may need to provide a mechinism so that blueprints and/or resource/lease holders get to attach some storage to resources/leases for bookkeeping. For example, a blueprint might need to keep some kind of cache on a resource to help it manage state. But I think we can cross that bridge when we come to it, and nothing else would need to write to this storage so it's technically straightforward to introduce such a mechanism if we need one. Test Plan: - Viewed buttons in web UI, checked enabled/disabled states. - Clicked the buttons. - Saw commands show up in the command queue. - Saw some daemon stuff get scheduled. - Ran CLI tools, saw commands get consumed and resources/leases release. Reviewers: hach-que, chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14143
2015-09-23 16:42:08 +02:00
'DrydockLeaseUpdateWorker' => 'applications/drydock/worker/DrydockLeaseUpdateWorker.php',
Make minor improvements to Drydock web interface Summary: Consolidate some code and start on lease detail pages. Test Plan: {F22783} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3901
2012-11-07 00:28:33 +01:00
'DrydockLeaseViewController' => 'applications/drydock/controller/DrydockLeaseViewController.php',
Add more Drydock log types and some additional logging Summary: Ref T9252. Add a bit more logging and improve some behaviors. Test Plan: Restarted a build, got a good result. Reviewers: chad, hach-que Reviewed By: hach-que Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14210
2015-10-01 17:11:42 +02:00
'DrydockLeaseWaitingForResourcesLogType' => 'applications/drydock/logtype/DrydockLeaseWaitingForResourcesLogType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockLog' => 'applications/drydock/storage/DrydockLog.php',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockLogController' => 'applications/drydock/controller/DrydockLogController.php',
Garbage collect Drydock logs after 30 days Summary: Ref T9252. Drydock logs are almost exclusively useful as a diagnostic tool for debugging immediate problems, so GC them fairly aggressively. (I expect 99% of the usefulness of these logs to be within the first 24 hours, basically "why isn't my thing working". I can't really think of any cases where having old logs would be useful.) Test Plan: - Ran GC, saw it hit the log table (with no effect). - Changed TTL from 30 days to 30 seconds, ran GC, saw it wipe recent logs. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14197
2015-10-01 17:09:27 +02:00
'DrydockLogGarbageCollector' => 'applications/drydock/garbagecollector/DrydockLogGarbageCollector.php',
Use ApplicationSearch for DrydockLog Summary: Ref T2015. Move logs over to ApplicationSearch. Test Plan: Browsed logs in UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7832
2013-12-26 21:30:29 +01:00
'DrydockLogListController' => 'applications/drydock/controller/DrydockLogListController.php',
Move Drydock object list rendering to SearchEngine Summary: Ref T4986. Allows the Drydock search engines to render as panels. Test Plan: Viewed affected interfaces in Drydock. Created panels from each engine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9103
2014-05-13 21:14:33 +02:00
'DrydockLogListView' => 'applications/drydock/view/DrydockLogListView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockLogQuery' => 'applications/drydock/query/DrydockLogQuery.php',
Use ApplicationSearch for DrydockLog Summary: Ref T2015. Move logs over to ApplicationSearch. Test Plan: Browsed logs in UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7832
2013-12-26 21:30:29 +01:00
'DrydockLogSearchEngine' => 'applications/drydock/query/DrydockLogSearchEngine.php',
Add Drydock log types and more logging Summary: Ref T9252. Make log types modular so they can be translated and have complicated rendering logic if necessary (currently, none have this). Test Plan: {F855330} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14198
2015-10-01 17:10:07 +02:00
'DrydockLogType' => 'applications/drydock/logtype/DrydockLogType.php',
Allow AlmanacHost blueprints to build a meaningful CommandInterface Summary: Ref T9253. Provide a meaningful command interface for Almanac hosts. Test Plan: Configued and leased a real host (`sbuild001.phacility.net`) and ran a command on it. ``` $ ./bin/drydock command --lease 90 -- ls / bin boot core dev etc home initrd.img lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var vmlinuz ``` Reviewers: chad, hach-que Reviewed By: chad, hach-que Maniphest Tasks: T9253 Differential Revision: https://secure.phabricator.com/D14126
2015-09-21 13:46:02 +02:00
'DrydockManagementCommandWorkflow' => 'applications/drydock/management/DrydockManagementCommandWorkflow.php',
Modernize the `drydock` script Summary: Add a bin/drydock symlink and break it into workflows. Nothing too special here. Test Plan: Ran `bin/drydock wait-for-lease`, `bin/drydock lease`, `bin/drydock help`, etc. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3867
2012-11-01 23:30:14 +01:00
'DrydockManagementLeaseWorkflow' => 'applications/drydock/management/DrydockManagementLeaseWorkflow.php',
Make Drydock reclaim unused resources when it reaches a resource limit Summary: Fixes T9994. Currently, when Drydock can't allocate a new resource because some limit has been reached, it waits patiently for a resource to become available. It is possible that no resource will ever become available. Particularly with "Working Copy" resources, the new lease may want a copy of `rB`, but the resource may already be maxed out on `rA`. Right now, no process exists to automatically reclaim the unused `rA`. When we encounter this situation, try to reclaim one of the other resources if it is just sitting there unused. Specifically: - Add a "reclaim" command which means "release this resource //if// it is completely unused". - Add a `bin/drydock reclaim` to send this command to every active resource. - When we try to acquire a resource and can't, but only because of some kind of limit / utilization problem, try to release an unused resource to free up some room. Test Plan: - Set "Working Copy" resource limit to 1. - Ran "Test Configuration" in `rA`, which worked. - Ran "Test Configuration" in `rB`, which hung forever. - Applied patch. - Ran "Test Configuration" in `rB`, saw it reclaim the `rA` resource, use the slot, then succeed. - Ran "Test Configuration" in `rA` again, saw it grab the slot back. - Ran `bin/drydock reclaim` and saw it reclaim a bunch of old orphaned resources. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9994 Differential Revision: https://secure.phabricator.com/D14819
2015-12-18 17:44:13 +01:00
'DrydockManagementReclaimWorkflow' => 'applications/drydock/management/DrydockManagementReclaimWorkflow.php',
Add a command queue to Drydock to manage lease/resource release Summary: Ref T9252. Broadly, Drydock currently races on releasing objects from the "active" state. To reproduce this: - Scatter some sleep()s pretty much anywhere in the release code. - Release several times from web UI or CLI in quick succession. Resources or leases will execute some release code twice or otherwise do inconsistent things. (I didn't chase down a detailed reproduction scenario for this since inspection of the code makes it clear that there are no meaningful locks or mechanisms preventing this.) Instead, add a Harbormaster-style command queue to resources and leases. When something wants to do a release, it adds a command to the queue and schedules a worker. The workers acquire a lock, then try to consume commands from the queue. This guarantees that only one process is responsible for writes to active resource/leases. This is the last major step to giving resources and leases a single writer during all states: - Resource, Unsaved: AllocatorWorker - Resource, Pending: ResourceWorker (Possible rename to "Allocated?") - Resource, Open: This diff, ResourceUpdateWorker. (Likely rename to "Active"). - Resource, Closed/Broken: Future destruction worker. (Likely rename to "Released" / "Broken"; maybe remove "Broken"). - Resource, Destroyed: No writes. - Lease, Unsaved: Whatever wants the lease. - Lease, Pending: AllocatorWorker - Lease, Acquired: LeaseWorker - Lease, Active: This diff, LeaseUpdateWorker. - Lease, Released/Broken: Future destruction worker (Maybe remove "Broken"?) - Lease, Expired: No writes. (Likely rename to "Destroyed"). In most phases, we can already guarantee that there is a single writer without doing any extra work. This is more complicated in the "Active" case because the release buttons on the web UI, the release tools on the CLI, the lease requestor itself, the garbage collector, and any other release process cleaning up related objects may try to effect a release. All of these could race one another (and, in many cases, race other processes from other phases because all of these get to act immediately) as this code is currently written. Using a queue here lets us make sure there's only a single writer in this phase. One thing which is notable is that whatever acquires a lease **can not write to it**! It is never the writer once it queues the lease for activation. It can not write to any resources, either. And, likewise, Blueprints can not write to resources while acquiring or releasing leases. We may need to provide a mechinism so that blueprints and/or resource/lease holders get to attach some storage to resources/leases for bookkeeping. For example, a blueprint might need to keep some kind of cache on a resource to help it manage state. But I think we can cross that bridge when we come to it, and nothing else would need to write to this storage so it's technically straightforward to introduce such a mechanism if we need one. Test Plan: - Viewed buttons in web UI, checked enabled/disabled states. - Clicked the buttons. - Saw commands show up in the command queue. - Saw some daemon stuff get scheduled. - Ran CLI tools, saw commands get consumed and resources/leases release. Reviewers: hach-que, chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14143
2015-09-23 16:42:08 +02:00
'DrydockManagementReleaseLeaseWorkflow' => 'applications/drydock/management/DrydockManagementReleaseLeaseWorkflow.php',
'DrydockManagementReleaseResourceWorkflow' => 'applications/drydock/management/DrydockManagementReleaseResourceWorkflow.php',
'DrydockManagementUpdateLeaseWorkflow' => 'applications/drydock/management/DrydockManagementUpdateLeaseWorkflow.php',
'DrydockManagementUpdateResourceWorkflow' => 'applications/drydock/management/DrydockManagementUpdateResourceWorkflow.php',
Modernize the `drydock` script Summary: Add a bin/drydock symlink and break it into workflows. Nothing too special here. Test Plan: Ran `bin/drydock wait-for-lease`, `bin/drydock lease`, `bin/drydock help`, etc. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3867
2012-11-01 23:30:14 +01:00
'DrydockManagementWorkflow' => 'applications/drydock/management/DrydockManagementWorkflow.php',
Allow "Repository Automation" to be configured for repositories Summary: Ref T182. This allows you to assign blueprints that a repository can use to perform working copy operations. Eventually, this will support "merge this" in Differential, etc. This is just UI for now, with no material effects. Most of this diff is just taking logic that was in the existing "Blueprints" CustomField and putting it in more general places so Diffusion (which does not use CustomFields) can also access it. Test Plan: - Configured repository automation for a repository. - Removed repository automation for a repository. Reviewers: chad Reviewed By: chad Subscribers: avivey Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D14259
2015-10-14 00:45:59 +02:00
'DrydockObjectAuthorizationView' => 'applications/drydock/view/DrydockObjectAuthorizationView.php',
Introduce DrydockQuery to slightly reduce code duplication Summary: Ref T2015. All the Drydock query classes share the application method; move it into a shared base class to slightly shrink the codebase. Test Plan: Browsed query UIs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7837
2013-12-27 22:15:30 +01:00
'DrydockQuery' => 'applications/drydock/query/DrydockQuery.php',
Rough cut of DrydockRepositoryOperation Summary: Ref T182. This doesn't do anything interesting yet and is mostly scaffolding, but here's roughly the workflow. From previous revision, you can configure "Repository Automation" for a repository: {F875741} If it's configured, a new "Land Revision" button shows up: {F875743} Once you click it you get a big warning dialog that it won't work, and then this shows up at the top of the revision (completely temporary/placeholder UI, some day a nice progress bar or whatever): {F875747} If you're lucky, the operation eventually sort of works: {F875750} It only runs `git show` right now, doesn't actually do any writes or anything. Test Plan: - Clicked "Land Revision". - Watched `phd debug task`. - Saw it log `git show` to output. - Verified operation success in UI (by fiddling URL, no way to get there normally yet). Reviewers: chad Reviewed By: chad Subscribers: revi Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D14266
2015-10-14 00:46:12 +02:00
'DrydockRepositoryOperation' => 'applications/drydock/storage/DrydockRepositoryOperation.php',
Make Drydock repository operations a little more modern and consistent Summary: Ref T10457. Use modern controller and UI tech to build the list view and actions. Test Plan: - Viewed operation list. - Viewed operation detail. - Checked menus on mobile. {F1139757} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15393
2016-03-03 15:34:18 +01:00
'DrydockRepositoryOperationController' => 'applications/drydock/controller/DrydockRepositoryOperationController.php',
Improve UX and messaging for certain errors when landing revisions Summary: Ref T9994. - Allow errors to be dismissed. - Tailor messaging for closed/abandoned revisions. - Reduce scare messaging on land dialog, since it's not really that scary anymore. Test Plan: - Dismissed errors. - Hit new warnings. - Wasn't as scared when landing. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9994 Differential Revision: https://secure.phabricator.com/D14886
2015-12-26 21:20:21 +01:00
'DrydockRepositoryOperationDismissController' => 'applications/drydock/controller/DrydockRepositoryOperationDismissController.php',
Add a basic list view for repository operations Summary: Ref T182. Nothing fancy, just make these slightly easier to work with. Test Plan: {F884754} Reviewers: chad Reviewed By: chad Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D14295
2015-10-17 03:47:05 +02:00
'DrydockRepositoryOperationListController' => 'applications/drydock/controller/DrydockRepositoryOperationListController.php',
Rough cut of DrydockRepositoryOperation Summary: Ref T182. This doesn't do anything interesting yet and is mostly scaffolding, but here's roughly the workflow. From previous revision, you can configure "Repository Automation" for a repository: {F875741} If it's configured, a new "Land Revision" button shows up: {F875743} Once you click it you get a big warning dialog that it won't work, and then this shows up at the top of the revision (completely temporary/placeholder UI, some day a nice progress bar or whatever): {F875747} If you're lucky, the operation eventually sort of works: {F875750} It only runs `git show` right now, doesn't actually do any writes or anything. Test Plan: - Clicked "Land Revision". - Watched `phd debug task`. - Saw it log `git show` to output. - Verified operation success in UI (by fiddling URL, no way to get there normally yet). Reviewers: chad Reviewed By: chad Subscribers: revi Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D14266
2015-10-14 00:46:12 +02:00
'DrydockRepositoryOperationPHIDType' => 'applications/drydock/phid/DrydockRepositoryOperationPHIDType.php',
'DrydockRepositoryOperationQuery' => 'applications/drydock/query/DrydockRepositoryOperationQuery.php',
Add a basic list view for repository operations Summary: Ref T182. Nothing fancy, just make these slightly easier to work with. Test Plan: {F884754} Reviewers: chad Reviewed By: chad Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D14295
2015-10-17 03:47:05 +02:00
'DrydockRepositoryOperationSearchEngine' => 'applications/drydock/query/DrydockRepositoryOperationSearchEngine.php',
Show a more reasonable status element for pull requests Summary: Ref T182. Replace the total mess we had before with a sort-of-reasonable element. This automatically updates using "javascript". Test Plan: {F901983} {F901984} Used "Land Revision", saw the land status go from "Waiting" -> "Working" -> "Landed" without having to mash reload over and over again. Reviewers: chad Reviewed By: chad Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D14314
2015-10-21 20:28:26 +02:00
'DrydockRepositoryOperationStatusController' => 'applications/drydock/controller/DrydockRepositoryOperationStatusController.php',
'DrydockRepositoryOperationStatusView' => 'applications/drydock/view/DrydockRepositoryOperationStatusView.php',
Rough cut of DrydockRepositoryOperation Summary: Ref T182. This doesn't do anything interesting yet and is mostly scaffolding, but here's roughly the workflow. From previous revision, you can configure "Repository Automation" for a repository: {F875741} If it's configured, a new "Land Revision" button shows up: {F875743} Once you click it you get a big warning dialog that it won't work, and then this shows up at the top of the revision (completely temporary/placeholder UI, some day a nice progress bar or whatever): {F875747} If you're lucky, the operation eventually sort of works: {F875750} It only runs `git show` right now, doesn't actually do any writes or anything. Test Plan: - Clicked "Land Revision". - Watched `phd debug task`. - Saw it log `git show` to output. - Verified operation success in UI (by fiddling URL, no way to get there normally yet). Reviewers: chad Reviewed By: chad Subscribers: revi Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D14266
2015-10-14 00:46:12 +02:00
'DrydockRepositoryOperationType' => 'applications/drydock/operation/DrydockRepositoryOperationType.php',
'DrydockRepositoryOperationUpdateWorker' => 'applications/drydock/worker/DrydockRepositoryOperationUpdateWorker.php',
'DrydockRepositoryOperationViewController' => 'applications/drydock/controller/DrydockRepositoryOperationViewController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockResource' => 'applications/drydock/storage/DrydockResource.php',
Add more Drydock log types and some additional logging Summary: Ref T9252. Add a bit more logging and improve some behaviors. Test Plan: Restarted a build, got a good result. Reviewers: chad, hach-que Reviewed By: hach-que Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14210
2015-10-01 17:11:42 +02:00
'DrydockResourceActivationFailureLogType' => 'applications/drydock/logtype/DrydockResourceActivationFailureLogType.php',
'DrydockResourceActivationYieldLogType' => 'applications/drydock/logtype/DrydockResourceActivationYieldLogType.php',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockResourceController' => 'applications/drydock/controller/DrydockResourceController.php',
Improve Drydock log search engine Summary: Ref T2015. This allows searching based on blueprints, resources or leases when viewing the logs, which helps when searching for events that occured to a particular blueprint / resource / lease. Unlike the logs shown on the resource / lease pages, the search engine supports paging properly, which means it can be used to find entries in the past. Test Plan: Used the Drydock log search page. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: joshuaspence, Korvin, epriestley Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D10874
2015-08-24 13:13:20 +02:00
'DrydockResourceDatasource' => 'applications/drydock/typeahead/DrydockResourceDatasource.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockResourceListController' => 'applications/drydock/controller/DrydockResourceListController.php',
Move Drydock object list rendering to SearchEngine Summary: Ref T4986. Allows the Drydock search engines to render as panels. Test Plan: Viewed affected interfaces in Drydock. Created panels from each engine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9103
2014-05-13 21:14:33 +02:00
'DrydockResourceListView' => 'applications/drydock/view/DrydockResourceListView.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'DrydockResourcePHIDType' => 'applications/drydock/phid/DrydockResourcePHIDType.php',
Make most Drydock web interfaces work with mobile Summary: The logs bits still need some work but add crumbs/lists to everything else. Also build a propery DrydockResourceQuery. Test Plan: Looked at lease list/detail; resource list/detail. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D4221
2012-12-17 23:47:21 +01:00
'DrydockResourceQuery' => 'applications/drydock/query/DrydockResourceQuery.php',
Make Drydock reclaim unused resources when it reaches a resource limit Summary: Fixes T9994. Currently, when Drydock can't allocate a new resource because some limit has been reached, it waits patiently for a resource to become available. It is possible that no resource will ever become available. Particularly with "Working Copy" resources, the new lease may want a copy of `rB`, but the resource may already be maxed out on `rA`. Right now, no process exists to automatically reclaim the unused `rA`. When we encounter this situation, try to reclaim one of the other resources if it is just sitting there unused. Specifically: - Add a "reclaim" command which means "release this resource //if// it is completely unused". - Add a `bin/drydock reclaim` to send this command to every active resource. - When we try to acquire a resource and can't, but only because of some kind of limit / utilization problem, try to release an unused resource to free up some room. Test Plan: - Set "Working Copy" resource limit to 1. - Ran "Test Configuration" in `rA`, which worked. - Ran "Test Configuration" in `rB`, which hung forever. - Applied patch. - Ran "Test Configuration" in `rB`, saw it reclaim the `rA` resource, use the slot, then succeed. - Ran "Test Configuration" in `rA` again, saw it grab the slot back. - Ran `bin/drydock reclaim` and saw it reclaim a bunch of old orphaned resources. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9994 Differential Revision: https://secure.phabricator.com/D14819
2015-12-18 17:44:13 +01:00
'DrydockResourceReclaimLogType' => 'applications/drydock/logtype/DrydockResourceReclaimLogType.php',
Add a command queue to Drydock to manage lease/resource release Summary: Ref T9252. Broadly, Drydock currently races on releasing objects from the "active" state. To reproduce this: - Scatter some sleep()s pretty much anywhere in the release code. - Release several times from web UI or CLI in quick succession. Resources or leases will execute some release code twice or otherwise do inconsistent things. (I didn't chase down a detailed reproduction scenario for this since inspection of the code makes it clear that there are no meaningful locks or mechanisms preventing this.) Instead, add a Harbormaster-style command queue to resources and leases. When something wants to do a release, it adds a command to the queue and schedules a worker. The workers acquire a lock, then try to consume commands from the queue. This guarantees that only one process is responsible for writes to active resource/leases. This is the last major step to giving resources and leases a single writer during all states: - Resource, Unsaved: AllocatorWorker - Resource, Pending: ResourceWorker (Possible rename to "Allocated?") - Resource, Open: This diff, ResourceUpdateWorker. (Likely rename to "Active"). - Resource, Closed/Broken: Future destruction worker. (Likely rename to "Released" / "Broken"; maybe remove "Broken"). - Resource, Destroyed: No writes. - Lease, Unsaved: Whatever wants the lease. - Lease, Pending: AllocatorWorker - Lease, Acquired: LeaseWorker - Lease, Active: This diff, LeaseUpdateWorker. - Lease, Released/Broken: Future destruction worker (Maybe remove "Broken"?) - Lease, Expired: No writes. (Likely rename to "Destroyed"). In most phases, we can already guarantee that there is a single writer without doing any extra work. This is more complicated in the "Active" case because the release buttons on the web UI, the release tools on the CLI, the lease requestor itself, the garbage collector, and any other release process cleaning up related objects may try to effect a release. All of these could race one another (and, in many cases, race other processes from other phases because all of these get to act immediately) as this code is currently written. Using a queue here lets us make sure there's only a single writer in this phase. One thing which is notable is that whatever acquires a lease **can not write to it**! It is never the writer once it queues the lease for activation. It can not write to any resources, either. And, likewise, Blueprints can not write to resources while acquiring or releasing leases. We may need to provide a mechinism so that blueprints and/or resource/lease holders get to attach some storage to resources/leases for bookkeeping. For example, a blueprint might need to keep some kind of cache on a resource to help it manage state. But I think we can cross that bridge when we come to it, and nothing else would need to write to this storage so it's technically straightforward to introduce such a mechanism if we need one. Test Plan: - Viewed buttons in web UI, checked enabled/disabled states. - Clicked the buttons. - Saw commands show up in the command queue. - Saw some daemon stuff get scheduled. - Ran CLI tools, saw commands get consumed and resources/leases release. Reviewers: hach-que, chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14143
2015-09-23 16:42:08 +02:00
'DrydockResourceReleaseController' => 'applications/drydock/controller/DrydockResourceReleaseController.php',
Use ApplicationSearch for Drydock Resources Summary: Ref T2015. Bring ApplicationSearch to Resources, too. Test Plan: Browsed/queried resources in UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7830
2013-12-26 21:30:10 +01:00
'DrydockResourceSearchEngine' => 'applications/drydock/query/DrydockResourceSearchEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockResourceStatus' => 'applications/drydock/constants/DrydockResourceStatus.php',
Add a command queue to Drydock to manage lease/resource release Summary: Ref T9252. Broadly, Drydock currently races on releasing objects from the "active" state. To reproduce this: - Scatter some sleep()s pretty much anywhere in the release code. - Release several times from web UI or CLI in quick succession. Resources or leases will execute some release code twice or otherwise do inconsistent things. (I didn't chase down a detailed reproduction scenario for this since inspection of the code makes it clear that there are no meaningful locks or mechanisms preventing this.) Instead, add a Harbormaster-style command queue to resources and leases. When something wants to do a release, it adds a command to the queue and schedules a worker. The workers acquire a lock, then try to consume commands from the queue. This guarantees that only one process is responsible for writes to active resource/leases. This is the last major step to giving resources and leases a single writer during all states: - Resource, Unsaved: AllocatorWorker - Resource, Pending: ResourceWorker (Possible rename to "Allocated?") - Resource, Open: This diff, ResourceUpdateWorker. (Likely rename to "Active"). - Resource, Closed/Broken: Future destruction worker. (Likely rename to "Released" / "Broken"; maybe remove "Broken"). - Resource, Destroyed: No writes. - Lease, Unsaved: Whatever wants the lease. - Lease, Pending: AllocatorWorker - Lease, Acquired: LeaseWorker - Lease, Active: This diff, LeaseUpdateWorker. - Lease, Released/Broken: Future destruction worker (Maybe remove "Broken"?) - Lease, Expired: No writes. (Likely rename to "Destroyed"). In most phases, we can already guarantee that there is a single writer without doing any extra work. This is more complicated in the "Active" case because the release buttons on the web UI, the release tools on the CLI, the lease requestor itself, the garbage collector, and any other release process cleaning up related objects may try to effect a release. All of these could race one another (and, in many cases, race other processes from other phases because all of these get to act immediately) as this code is currently written. Using a queue here lets us make sure there's only a single writer in this phase. One thing which is notable is that whatever acquires a lease **can not write to it**! It is never the writer once it queues the lease for activation. It can not write to any resources, either. And, likewise, Blueprints can not write to resources while acquiring or releasing leases. We may need to provide a mechinism so that blueprints and/or resource/lease holders get to attach some storage to resources/leases for bookkeeping. For example, a blueprint might need to keep some kind of cache on a resource to help it manage state. But I think we can cross that bridge when we come to it, and nothing else would need to write to this storage so it's technically straightforward to introduce such a mechanism if we need one. Test Plan: - Viewed buttons in web UI, checked enabled/disabled states. - Clicked the buttons. - Saw commands show up in the command queue. - Saw some daemon stuff get scheduled. - Ran CLI tools, saw commands get consumed and resources/leases release. Reviewers: hach-que, chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14143
2015-09-23 16:42:08 +02:00
'DrydockResourceUpdateWorker' => 'applications/drydock/worker/DrydockResourceUpdateWorker.php',
Add a detail view for resources in Drydock Summary: Nothing fancy here, just add a detail page. Test Plan: Looked at detail page. {F24808} Reviewers: btrahan Reviewed By: btrahan CC: aran, vrana Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3995
2012-11-20 22:25:22 +01:00
'DrydockResourceViewController' => 'applications/drydock/controller/DrydockResourceViewController.php',
Implement "Upload Artifact" build step Summary: This implements a build step for uploading an artifact from a build machine to Phabricator. It uses SFTP so that it will work on both UNIX and Windows build machines. Test Plan: Ran an "Upload Artifact" build against a Windows machine (with FreeSSHD installed). The artifact uploaded to Phabricator, appeared on the build view and the file contents could be viewed from Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7582
2013-12-06 04:11:05 +01:00
'DrydockSFTPFilesystemInterface' => 'applications/drydock/interface/filesystem/DrydockSFTPFilesystemInterface.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockSSHCommandInterface' => 'applications/drydock/interface/command/DrydockSSHCommandInterface.php',
Allow Drydock blueprints to be tagged and searched, and give types some little icons Summary: Ref T10457. - Let blueprints be tagged so you can search and annotate them a little more easily. - Give each blueprint type an optional icon to make things a little easier to parse visually. Test Plan: - Tagged blueprints. - Searched by tags. - Looked at nice little icons. {F1139712} Reviewers: chad Reviewed By: chad Subscribers: yelirekim Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15392
2016-03-03 14:52:21 +01:00
'DrydockSchemaSpec' => 'applications/drydock/storage/DrydockSchemaSpec.php',
Implement optimistic "slot locks" in Drydock Summary: See discussion in D10304. There's a lot of context there, but the general idea is: - Blueprints should manage locks in a granular way during the actual allocation/acquisition phase. - Optimistic "slot locks" might a pretty good primitive to make that easy to implement and reason about in most cases. The way these locks work is that you just pick some name for the lock (like the PHID of a resource) and say that it needs to be acquired for the allocation/acquisition to work: ``` ... ->needSlotLock("mylock(PHID-XYZQ-...)") ... ``` When you fire off the acquisition or allocation, it fails unless it could acquire the slot with that name. This is really simple (no explicit lock management) and a pretty good fit for most of the locking that blueprints and leases need to do. If you need to do limit-based locks (e.g., maximum of 3 locks) you could acquire a lock like this: ``` mylock(whatever).slot(2) ``` Blueprints generally only contend with themselves, so it's normally OK for them to pick whatever strategy works best for them in naming locks. This may not work as well if you have a huge number of slots (e.g., 100TB you want to give out in 1MB chunks), or other complex needs for locks (like you have to synchronize access to some external resource), but slot locks don't need to be the only mechanism that blueprints use. If they run into a problem that slot locks aren't a good fit for, they can use something else instead. For now, slot locks seem like a good fit for the problems we currently face and most of the problems I anticipate facing. (The release workflows have other race issues which I'm not addressing here. They work fine if nothing races, but aren't race-safe.) Test Plan: To create a race where the same binding is allocated as a resource twice: - Add `sleep(10)` near the beginning of `allocateResource()`, after the free bindings are loaded but before resources are allocated. - (Comment out slot lock acquisition if you have this patch.) - Run `bin/drydock lease ...` in two windows, within 10 seconds of one another. This will reliably double-allocate the binding because both blueprints see a view of the world where the binding is free. To verify the lock works, un-comment it (or apply this patch) and run the same test again. Now, the lock fails in one process and only one resource is allocated. Reviewers: hach-que, chad Reviewed By: hach-que, chad Differential Revision: https://secure.phabricator.com/D14118
2015-09-21 13:45:25 +02:00
'DrydockSlotLock' => 'applications/drydock/storage/DrydockSlotLock.php',
Support working copies and separate allocate + activate steps for resources/leases in Drydock Summary: Ref T9253. For resources and leases that need to do something which takes a lot of time or requires waiting, allow them to allocate/acquire first and then activate later. When we allocate a resource or acquire a lease, the blueprint can either activate it immediately (if all the work can happen quickly/inline) or activate it later. If the blueprint activates it later, we queue a worker to handle activating it. Rebuild the "working copy" blueprint to work with this model: it allocates/acquires and activates in a separate step, once it is able to acquire a host. Test Plan: With some power of imagination, brought up a bunch of working copies with `bin/drydock lease --type working-copy ...` Reviewers: hach-que, chad Reviewed By: hach-que, chad Maniphest Tasks: T9253 Differential Revision: https://secure.phabricator.com/D14127
2015-09-21 13:46:24 +02:00
'DrydockSlotLockException' => 'applications/drydock/exception/DrydockSlotLockException.php',
Add more Drydock log types and some additional logging Summary: Ref T9252. Add a bit more logging and improve some behaviors. Test Plan: Restarted a build, got a good result. Reviewers: chad, hach-que Reviewed By: hach-que Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14210
2015-10-01 17:11:42 +02:00
'DrydockSlotLockFailureLogType' => 'applications/drydock/logtype/DrydockSlotLockFailureLogType.php',
Add some Drydock documentation plus "Test Configuration" for repository automation Summary: Ref T182. Ref T9252. - Adds a "Test" repository operation that just runs `git status` to see if things work. - Adds a button for it in Edit Repository. - Shows operation status on the operation detail view to make this workflow work a little better. - Adds a lot of words. Words words words words. Test Plan: - Tested repository operation. - Read words. Reviewers: chad Reviewed By: chad Maniphest Tasks: T182, T9252 Differential Revision: https://secure.phabricator.com/D14349
2015-10-27 19:04:02 +01:00
'DrydockTestRepositoryOperation' => 'applications/drydock/operation/DrydockTestRepositoryOperation.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockWebrootInterface' => 'applications/drydock/interface/webroot/DrydockWebrootInterface.php',
Support working copies and separate allocate + activate steps for resources/leases in Drydock Summary: Ref T9253. For resources and leases that need to do something which takes a lot of time or requires waiting, allow them to allocate/acquire first and then activate later. When we allocate a resource or acquire a lease, the blueprint can either activate it immediately (if all the work can happen quickly/inline) or activate it later. If the blueprint activates it later, we queue a worker to handle activating it. Rebuild the "working copy" blueprint to work with this model: it allocates/acquires and activates in a separate step, once it is able to acquire a host. Test Plan: With some power of imagination, brought up a bunch of working copies with `bin/drydock lease --type working-copy ...` Reviewers: hach-que, chad Reviewed By: hach-que, chad Maniphest Tasks: T9253 Differential Revision: https://secure.phabricator.com/D14127
2015-09-21 13:46:24 +02:00
'DrydockWorker' => 'applications/drydock/worker/DrydockWorker.php',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockWorkingCopyBlueprintImplementation' => 'applications/drydock/blueprint/DrydockWorkingCopyBlueprintImplementation.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'FeedConduitAPIMethod' => 'applications/feed/conduit/FeedConduitAPIMethod.php',
'FeedPublishConduitAPIMethod' => 'applications/feed/conduit/FeedPublishConduitAPIMethod.php',
Push feed publishing deeper into the task queue Summary: Ref T2852. I want to model Asana integration as a response to feed events. Currently, we queue one feed event for each HTTP hook. Instead, always queue one feed event and then have it queue any necessary followup events (now, http hooks; soon, asana). Add a script to make it easy to reproducibly fire feed event publishing. Test Plan: Republished a feed event and verified it hit configured HTTP hooks correctly. $ ./bin/feed republish 5765774156541908292 --trace >>> [2] <connect> phabricator2_feed <<< [2] <connect> 1,660 us >>> [3] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [3] <query> 595 us >>> [4] <connect> phabricator2_differential <<< [4] <connect> 760 us >>> [5] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [5] <query> 478 us >>> [6] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [6] <query> 449 us >>> [7] <connect> phabricator2_user <<< [7] <connect> 1,062 us >>> [8] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [8] <query> 540 us >>> [9] <connect> phabricator2_file <<< [9] <connect> 951 us >>> [10] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [10] <query> 498 us >>> [11] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [11] <query> 507 us Republishing story... >>> [12] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [12] <query> 685 us >>> [13] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [13] <query> 489 us >>> [14] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [14] <query> 512 us >>> [15] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [15] <query> 601 us >>> [16] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [16] <query> 405 us >>> [17] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [17] <query> 551 us >>> [18] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [18] <query> 507 us >>> [19] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [19] <query> 428 us >>> [20] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [20] <query> 419 us >>> [21] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [21] <query> 591 us >>> [22] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [22] <query> 406 us >>> [23] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [23] <query> 593 us >>> [24] <http> http://127.0.0.1/derp/ <<< [24] <http> 746,157 us [2013-06-24 20:23:26] EXCEPTION: (HTTPFutureResponseStatusHTTP) [HTTP/500] Internal Server Error Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6291
2013-06-26 01:29:47 +02:00
'FeedPublisherHTTPWorker' => 'applications/feed/worker/FeedPublisherHTTPWorker.php',
post feed stories to arbitrary uris via a new Worker Summary: so folks can write applications and whatnot. Test Plan: set feed.http-hooks to local dev instance (200) and localhost (500) in my conf. Verified succcess and retrying respectively. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T305 Differential Revision: https://secure.phabricator.com/D3874
2012-11-02 21:34:18 +01:00
'FeedPublisherWorker' => 'applications/feed/worker/FeedPublisherWorker.php',
Push feed publishing deeper into the task queue Summary: Ref T2852. I want to model Asana integration as a response to feed events. Currently, we queue one feed event for each HTTP hook. Instead, always queue one feed event and then have it queue any necessary followup events (now, http hooks; soon, asana). Add a script to make it easy to reproducibly fire feed event publishing. Test Plan: Republished a feed event and verified it hit configured HTTP hooks correctly. $ ./bin/feed republish 5765774156541908292 --trace >>> [2] <connect> phabricator2_feed <<< [2] <connect> 1,660 us >>> [3] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [3] <query> 595 us >>> [4] <connect> phabricator2_differential <<< [4] <connect> 760 us >>> [5] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [5] <query> 478 us >>> [6] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [6] <query> 449 us >>> [7] <connect> phabricator2_user <<< [7] <connect> 1,062 us >>> [8] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [8] <query> 540 us >>> [9] <connect> phabricator2_file <<< [9] <connect> 951 us >>> [10] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [10] <query> 498 us >>> [11] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [11] <query> 507 us Republishing story... >>> [12] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [12] <query> 685 us >>> [13] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [13] <query> 489 us >>> [14] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [14] <query> 512 us >>> [15] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [15] <query> 601 us >>> [16] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [16] <query> 405 us >>> [17] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [17] <query> 551 us >>> [18] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [18] <query> 507 us >>> [19] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [19] <query> 428 us >>> [20] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [20] <query> 419 us >>> [21] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [21] <query> 591 us >>> [22] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [22] <query> 406 us >>> [23] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [23] <query> 593 us >>> [24] <http> http://127.0.0.1/derp/ <<< [24] <http> 746,157 us [2013-06-24 20:23:26] EXCEPTION: (HTTPFutureResponseStatusHTTP) [HTTP/500] Internal Server Error Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6291
2013-06-26 01:29:47 +02:00
'FeedPushWorker' => 'applications/feed/worker/FeedPushWorker.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'FeedQueryConduitAPIMethod' => 'applications/feed/conduit/FeedQueryConduitAPIMethod.php',
Garbage collect old notifications Summary: Fixes T8473. Adds garbage collection to the `phabricator_feed.feed_storynotification` table. Test Plan: Reduced the TTL to a really small value and ran the trigger daemon. Saw feed notifications removed from the database. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T8473 Differential Revision: https://secure.phabricator.com/D13233
2015-06-10 15:08:57 +02:00
'FeedStoryNotificationGarbageCollector' => 'applications/notification/garbagecollector/FeedStoryNotificationGarbageCollector.php',
Add a chunking storage engine for files Summary: Ref T7149. This isn't complete and isn't active yet, but does basically work. I'll shore it up in the next few diffs. The new workflow goes like this: > Client, file.allocate(): I'd like to upload a file with length L, metadata M, and hash H. Then the server returns `upload` (a boolean) and `filePHID` (a PHID). These mean: | upload | filePHID | means | |---|---|---| | false | false | Server can't accept file. | false | true | File data already known, file created from hash. | true | false | Just upload normally. | true | true | Query chunks to start or resume a chunked upload. All but the last case are uninteresting and work like exising uploads with `file.uploadhash` (which we can eventually deprecate). In the last case: > Client, file.querychunks(): Give me a list of chunks that I should upload. This returns all the chunks for the file. Chunks have a start byte, an end byte, and a "complete" flag to indicate that the server already has the data. Then, the client fills in chunks by sending them: > Client, file.uploadchunk(): Here is the data for one chunk. This stuff doesn't work yet or has some caveats: - I haven't tested resume much. - Files need an "isPartial()" flag for partial uploads, and the UI needs to respect it. - The JS client needs to become chunk-aware. - Chunk size is set crazy low to make testing easier. - Some debugging flags that I'll remove soon-ish. - Downloading works, but still streams the whole file into memory. - This storage engine is disabled by default (hardcoded as a unit test engine) because it's still sketchy. - Need some code to remove the "isParital" flag when the last chunk is uploaded. - Maybe do checksumming on chunks. Test Plan: - Hacked up `arc upload` (see next diff) to be chunk-aware and uploaded a readme in 18 32-byte chunks. Then downloaded it. Got the same file back that I uploaded. - File UI now shows some basic chunk info for chunked files: {F336434} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12060
2015-03-13 19:30:02 +01:00
'FileAllocateConduitAPIMethod' => 'applications/files/conduit/FileAllocateConduitAPIMethod.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'FileConduitAPIMethod' => 'applications/files/conduit/FileConduitAPIMethod.php',
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
'FileCreateMailReceiver' => 'applications/files/mail/FileCreateMailReceiver.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'FileDownloadConduitAPIMethod' => 'applications/files/conduit/FileDownloadConduitAPIMethod.php',
'FileInfoConduitAPIMethod' => 'applications/files/conduit/FileInfoConduitAPIMethod.php',
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
'FileMailReceiver' => 'applications/files/mail/FileMailReceiver.php',
Add a chunking storage engine for files Summary: Ref T7149. This isn't complete and isn't active yet, but does basically work. I'll shore it up in the next few diffs. The new workflow goes like this: > Client, file.allocate(): I'd like to upload a file with length L, metadata M, and hash H. Then the server returns `upload` (a boolean) and `filePHID` (a PHID). These mean: | upload | filePHID | means | |---|---|---| | false | false | Server can't accept file. | false | true | File data already known, file created from hash. | true | false | Just upload normally. | true | true | Query chunks to start or resume a chunked upload. All but the last case are uninteresting and work like exising uploads with `file.uploadhash` (which we can eventually deprecate). In the last case: > Client, file.querychunks(): Give me a list of chunks that I should upload. This returns all the chunks for the file. Chunks have a start byte, an end byte, and a "complete" flag to indicate that the server already has the data. Then, the client fills in chunks by sending them: > Client, file.uploadchunk(): Here is the data for one chunk. This stuff doesn't work yet or has some caveats: - I haven't tested resume much. - Files need an "isPartial()" flag for partial uploads, and the UI needs to respect it. - The JS client needs to become chunk-aware. - Chunk size is set crazy low to make testing easier. - Some debugging flags that I'll remove soon-ish. - Downloading works, but still streams the whole file into memory. - This storage engine is disabled by default (hardcoded as a unit test engine) because it's still sketchy. - Need some code to remove the "isParital" flag when the last chunk is uploaded. - Maybe do checksumming on chunks. Test Plan: - Hacked up `arc upload` (see next diff) to be chunk-aware and uploaded a readme in 18 32-byte chunks. Then downloaded it. Got the same file back that I uploaded. - File UI now shows some basic chunk info for chunked files: {F336434} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12060
2015-03-13 19:30:02 +01:00
'FileQueryChunksConduitAPIMethod' => 'applications/files/conduit/FileQueryChunksConduitAPIMethod.php',
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
'FileReplyHandler' => 'applications/files/mail/FileReplyHandler.php',
Add a chunking storage engine for files Summary: Ref T7149. This isn't complete and isn't active yet, but does basically work. I'll shore it up in the next few diffs. The new workflow goes like this: > Client, file.allocate(): I'd like to upload a file with length L, metadata M, and hash H. Then the server returns `upload` (a boolean) and `filePHID` (a PHID). These mean: | upload | filePHID | means | |---|---|---| | false | false | Server can't accept file. | false | true | File data already known, file created from hash. | true | false | Just upload normally. | true | true | Query chunks to start or resume a chunked upload. All but the last case are uninteresting and work like exising uploads with `file.uploadhash` (which we can eventually deprecate). In the last case: > Client, file.querychunks(): Give me a list of chunks that I should upload. This returns all the chunks for the file. Chunks have a start byte, an end byte, and a "complete" flag to indicate that the server already has the data. Then, the client fills in chunks by sending them: > Client, file.uploadchunk(): Here is the data for one chunk. This stuff doesn't work yet or has some caveats: - I haven't tested resume much. - Files need an "isPartial()" flag for partial uploads, and the UI needs to respect it. - The JS client needs to become chunk-aware. - Chunk size is set crazy low to make testing easier. - Some debugging flags that I'll remove soon-ish. - Downloading works, but still streams the whole file into memory. - This storage engine is disabled by default (hardcoded as a unit test engine) because it's still sketchy. - Need some code to remove the "isParital" flag when the last chunk is uploaded. - Maybe do checksumming on chunks. Test Plan: - Hacked up `arc upload` (see next diff) to be chunk-aware and uploaded a readme in 18 32-byte chunks. Then downloaded it. Got the same file back that I uploaded. - File UI now shows some basic chunk info for chunked files: {F336434} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12060
2015-03-13 19:30:02 +01:00
'FileUploadChunkConduitAPIMethod' => 'applications/files/conduit/FileUploadChunkConduitAPIMethod.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'FileUploadConduitAPIMethod' => 'applications/files/conduit/FileUploadConduitAPIMethod.php',
'FileUploadHashConduitAPIMethod' => 'applications/files/conduit/FileUploadHashConduitAPIMethod.php',
Add default policy to Files application Summary: **WIP** This adds default capability to the Files application Test Plan: Set default to public, go to Files page, see public preset. Upload File. Doesn't work. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6564 Differential Revision: https://secure.phabricator.com/D10888
2014-11-21 20:17:20 +01:00
'FilesDefaultViewCapability' => 'applications/files/capability/FilesDefaultViewCapability.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'FlagConduitAPIMethod' => 'applications/flag/conduit/FlagConduitAPIMethod.php',
'FlagDeleteConduitAPIMethod' => 'applications/flag/conduit/FlagDeleteConduitAPIMethod.php',
'FlagEditConduitAPIMethod' => 'applications/flag/conduit/FlagEditConduitAPIMethod.php',
'FlagQueryConduitAPIMethod' => 'applications/flag/conduit/FlagQueryConduitAPIMethod.php',
Allow users to back initiatives in Fund Summary: Ref T5835. This is still completely made up (no payment integration), but you can "back" an initiative, type a number in the box, and generate a database row. You can then seach for backers and things you've backed and such. Notable changes: - Renamed "FundBacking" to "FundBacker". The former name was sort of because you can back things multiple times, but stuff like `$backings` was just too weird. - I think that's it? Test Plan: - Backed an initiative. - Viewed that I became a backer. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10486
2014-09-12 15:31:11 +02:00
'FundBacker' => 'applications/fund/storage/FundBacker.php',
Give applications control over Phortune cart logic Summary: Ref T2787. Similar to D10634, give applications more control over the cart workflow. For now this just means they get to pick exit URIs, but in the future they can manage more details of cart behavior. Test Plan: Funded an initiative and got returned to the initiative instead of dead-ending in Phortune. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10638
2014-10-06 23:19:08 +02:00
'FundBackerCart' => 'applications/fund/phortune/FundBackerCart.php',
Allow users to back initiatives in Fund Summary: Ref T5835. This is still completely made up (no payment integration), but you can "back" an initiative, type a number in the box, and generate a database row. You can then seach for backers and things you've backed and such. Notable changes: - Renamed "FundBacking" to "FundBacker". The former name was sort of because you can back things multiple times, but stuff like `$backings` was just too weird. - I think that's it? Test Plan: - Backed an initiative. - Viewed that I became a backer. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10486
2014-09-12 15:31:11 +02:00
'FundBackerEditor' => 'applications/fund/editor/FundBackerEditor.php',
'FundBackerListController' => 'applications/fund/controller/FundBackerListController.php',
'FundBackerPHIDType' => 'applications/fund/phid/FundBackerPHIDType.php',
Move Phortune product logic into applications Summary: Ref T2787. `Product` is currently a fairly heavy object, but as Phortune develops it makes a lot of sense to make it a lighter object and put more product logic in applications. Convert it into a fairly lightweight reference to applications. The idea is that Phortune is mostly providing a cart flow, and applications manage the details of products. Test Plan: Funded an initiative for $1. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10634
2014-10-06 19:30:06 +02:00
'FundBackerProduct' => 'applications/fund/phortune/FundBackerProduct.php',
Allow users to back initiatives in Fund Summary: Ref T5835. This is still completely made up (no payment integration), but you can "back" an initiative, type a number in the box, and generate a database row. You can then seach for backers and things you've backed and such. Notable changes: - Renamed "FundBacking" to "FundBacker". The former name was sort of because you can back things multiple times, but stuff like `$backings` was just too weird. - I think that's it? Test Plan: - Backed an initiative. - Viewed that I became a backer. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10486
2014-09-12 15:31:11 +02:00
'FundBackerQuery' => 'applications/fund/query/FundBackerQuery.php',
'FundBackerSearchEngine' => 'applications/fund/query/FundBackerSearchEngine.php',
'FundBackerTransaction' => 'applications/fund/storage/FundBackerTransaction.php',
'FundBackerTransactionQuery' => 'applications/fund/query/FundBackerTransactionQuery.php',
Scaffolding for Fund Summary: Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet. You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc). Only notable decisions: - Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative. - I think that's it? Test Plan: - Created an initiative. - Edited an initiative. - Changed application policy defaults. - Searched for initiatives. - Subscribed to an initiative. - Opened/closed an initiative. - Used `I123` and `{I123}` in remarkup. - Destroyed an initiative. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
'FundController' => 'applications/fund/controller/FundController.php',
'FundCreateInitiativesCapability' => 'applications/fund/capability/FundCreateInitiativesCapability.php',
'FundDAO' => 'applications/fund/storage/FundDAO.php',
'FundDefaultViewCapability' => 'applications/fund/capability/FundDefaultViewCapability.php',
'FundInitiative' => 'applications/fund/storage/FundInitiative.php',
Allow users to back initiatives in Fund Summary: Ref T5835. This is still completely made up (no payment integration), but you can "back" an initiative, type a number in the box, and generate a database row. You can then seach for backers and things you've backed and such. Notable changes: - Renamed "FundBacking" to "FundBacker". The former name was sort of because you can back things multiple times, but stuff like `$backings` was just too weird. - I think that's it? Test Plan: - Backed an initiative. - Viewed that I became a backer. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10486
2014-09-12 15:31:11 +02:00
'FundInitiativeBackController' => 'applications/fund/controller/FundInitiativeBackController.php',
Scaffolding for Fund Summary: Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet. You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc). Only notable decisions: - Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative. - I think that's it? Test Plan: - Created an initiative. - Edited an initiative. - Changed application policy defaults. - Searched for initiatives. - Subscribed to an initiative. - Opened/closed an initiative. - Used `I123` and `{I123}` in remarkup. - Destroyed an initiative. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
'FundInitiativeCloseController' => 'applications/fund/controller/FundInitiativeCloseController.php',
Add commenting to Fund Summary: Adds basic commenting to Fund Initiatives. Test Plan: Leave a comment, see comment. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15554
2016-04-01 00:29:42 +02:00
'FundInitiativeCommentController' => 'applications/fund/controller/FundInitiativeCommentController.php',
Scaffolding for Fund Summary: Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet. You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc). Only notable decisions: - Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative. - I think that's it? Test Plan: - Created an initiative. - Edited an initiative. - Changed application policy defaults. - Searched for initiatives. - Subscribed to an initiative. - Opened/closed an initiative. - Used `I123` and `{I123}` in remarkup. - Destroyed an initiative. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
'FundInitiativeEditController' => 'applications/fund/controller/FundInitiativeEditController.php',
'FundInitiativeEditor' => 'applications/fund/editor/FundInitiativeEditor.php',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'FundInitiativeFulltextEngine' => 'applications/fund/search/FundInitiativeFulltextEngine.php',
Scaffolding for Fund Summary: Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet. You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc). Only notable decisions: - Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative. - I think that's it? Test Plan: - Created an initiative. - Edited an initiative. - Changed application policy defaults. - Searched for initiatives. - Subscribed to an initiative. - Opened/closed an initiative. - Used `I123` and `{I123}` in remarkup. - Destroyed an initiative. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
'FundInitiativeListController' => 'applications/fund/controller/FundInitiativeListController.php',
'FundInitiativePHIDType' => 'applications/fund/phid/FundInitiativePHIDType.php',
'FundInitiativeQuery' => 'applications/fund/query/FundInitiativeQuery.php',
'FundInitiativeRemarkupRule' => 'applications/fund/remarkup/FundInitiativeRemarkupRule.php',
Support feed and email in Fund Summary: Ref T5835. Make fund stories publish to feed and send email. Test Plan: Made edits, etc., saw them in feed and outbound email. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10677
2014-10-10 20:29:42 +02:00
'FundInitiativeReplyHandler' => 'applications/fund/mail/FundInitiativeReplyHandler.php',
Scaffolding for Fund Summary: Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet. You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc). Only notable decisions: - Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative. - I think that's it? Test Plan: - Created an initiative. - Edited an initiative. - Changed application policy defaults. - Searched for initiatives. - Subscribed to an initiative. - Opened/closed an initiative. - Used `I123` and `{I123}` in remarkup. - Destroyed an initiative. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
'FundInitiativeSearchEngine' => 'applications/fund/query/FundInitiativeSearchEngine.php',
'FundInitiativeTransaction' => 'applications/fund/storage/FundInitiativeTransaction.php',
Add commenting to Fund Summary: Adds basic commenting to Fund Initiatives. Test Plan: Leave a comment, see comment. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15554
2016-04-01 00:29:42 +02:00
'FundInitiativeTransactionComment' => 'applications/fund/storage/FundInitiativeTransactionComment.php',
Scaffolding for Fund Summary: Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet. You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc). Only notable decisions: - Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative. - I think that's it? Test Plan: - Created an initiative. - Edited an initiative. - Changed application policy defaults. - Searched for initiatives. - Subscribed to an initiative. - Opened/closed an initiative. - Used `I123` and `{I123}` in remarkup. - Destroyed an initiative. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
'FundInitiativeTransactionQuery' => 'applications/fund/query/FundInitiativeTransactionQuery.php',
'FundInitiativeViewController' => 'applications/fund/controller/FundInitiativeViewController.php',
Add expected schemata for Fund, Files, Flags and Legalpad Summary: Ref T1191. Nothing too exciting in these. Test Plan: Saw more blue in UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10521
2014-09-19 14:44:40 +02:00
'FundSchemaSpec' => 'applications/fund/storage/FundSchemaSpec.php',
Add "Autoplans" to Harbormaster Summary: Ref T8095. Two general problems: - I want Harbormaster to own all lint and unit test results. - I don't want users to have to configure anything for `arc` to keep working automatically. These are in conflict because generic lint/unit test ownership in Harbormaster requires that build targets exist which we can attach build results to. However, we can't currently create build targets on demand: Harbormaster assumes it is responsible for creating targets, then running code or making third-party service calls to actually run the builds. I considered two broad approaches to let `arc` push results into Harbormaster without requiring administrators to configure some kind of "arc results" build plan: # Add magic target PHIDs like `PHID-MAGIC-this-is-really-arc-unit`. # Add new code to build real targets with real PHIDs. (1) is probably a bit less work to get off the ground, but I think it's worse overall and very likely to create more problems in the long run. I particularly worry that it will lead to a small amount of special casing in a very large number of places, which seems more fragile. (2) is more work upfront but I think does a better job of putting all the special casing in one place that we can, e.g., more reasonably unit test, and letting the rest of the code rarely/never care about this case since it's just dealing with normal plans/steps/targets as far as it can tell. This diff introduces "autoplans", which are source templates for plans/steps. This let us "push" these targets into Harbormaster. Hypthetically, any process "like" arc can use autoplans to upload test/lint/etc results. In practice, probably only `arc` will ever use this, but I think it's still quite a bit cleaner than the alternative despite all the generality. Workflow is basically: - `arc` creates a diff. - `arc` calls `harbormaster.queryautotargets`, passing the diff PHID and saying "I have some lint and unit results I want to stick on this thing". - Harbormaster builds the plan, steps, and targets (if any of them don't already exist), and hands back the target PHIDs so `arc` has a completely standard-looking place to put results. - `arc` uploads the test results to the right targets, as though Harbormaster had asked it to run unit/lint in the first place. (This doesn't actually do any of that yet, just sets things up.) I'll maybe doc turn that ^^^^^^ into a doc for posterity since I think it's hard to guess what an "autotarget" is, but I'm going to grab some lunch first. Test Plan: - Added unit tests to make sure we can build these things properly. - Used `harbormaster.queryautotargets` to build autotargets for a bunch of diffs. - Verified targets come up in "waiting for message" state. - Verified plans and steps are not editable. Reviewers: btrahan Reviewed By: btrahan Subscribers: hach-que, epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13345
2015-06-21 18:04:21 +02:00
'HarbormasterArcLintBuildStepImplementation' => 'applications/harbormaster/step/HarbormasterArcLintBuildStepImplementation.php',
'HarbormasterArcUnitBuildStepImplementation' => 'applications/harbormaster/step/HarbormasterArcUnitBuildStepImplementation.php',
Add `harbormaster.createartifact` Summary: Ref T8659. In the general case, this eventually allows build processes to do things like: - Upload build results (like a ".app" or ".exe" or other binary). - Pass complex results between build steps (e.g., build step A does something hard and build step B uses it to do something else). Today, we're a long way away from having the infrastructure for that. However, it is useful to let third party build processes (like Jenkins) upload URIs that link back to the external build results. This adds `harbormaster.createartifact` so they can do that. The only useful thing to do with this method today is have your Jenkins build do this: params = array( "uri": "https://jenkins.mycompany.com/build/23923/details/", "name": "View Build Results in Jenkins", "ui.external": true, ); harbormaster.createartifact(target, 'uri', params); Then (after the next diff) we'll show a link in Differential and a prominent link in Harbormaster. I didn't actually do the UI stuff in this diff since it's already pretty big. This change moves a lot of code around, too: - Adds PHIDs to artifacts. - It modularizes build artifact types (currently "file", "host" and "URI"). - It formalizes build artifact parameters and construction: - This lets me generate usable documentation about how to create artifacts. - This prevents users from doing dangerous or policy-violating things. - It does some other general modernization. Test Plan: {F715633} {F715634} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8659 Differential Revision: https://secure.phabricator.com/D13900
2015-08-15 16:28:56 +02:00
'HarbormasterArtifact' => 'applications/harbormaster/artifact/HarbormasterArtifact.php',
Add "Autoplans" to Harbormaster Summary: Ref T8095. Two general problems: - I want Harbormaster to own all lint and unit test results. - I don't want users to have to configure anything for `arc` to keep working automatically. These are in conflict because generic lint/unit test ownership in Harbormaster requires that build targets exist which we can attach build results to. However, we can't currently create build targets on demand: Harbormaster assumes it is responsible for creating targets, then running code or making third-party service calls to actually run the builds. I considered two broad approaches to let `arc` push results into Harbormaster without requiring administrators to configure some kind of "arc results" build plan: # Add magic target PHIDs like `PHID-MAGIC-this-is-really-arc-unit`. # Add new code to build real targets with real PHIDs. (1) is probably a bit less work to get off the ground, but I think it's worse overall and very likely to create more problems in the long run. I particularly worry that it will lead to a small amount of special casing in a very large number of places, which seems more fragile. (2) is more work upfront but I think does a better job of putting all the special casing in one place that we can, e.g., more reasonably unit test, and letting the rest of the code rarely/never care about this case since it's just dealing with normal plans/steps/targets as far as it can tell. This diff introduces "autoplans", which are source templates for plans/steps. This let us "push" these targets into Harbormaster. Hypthetically, any process "like" arc can use autoplans to upload test/lint/etc results. In practice, probably only `arc` will ever use this, but I think it's still quite a bit cleaner than the alternative despite all the generality. Workflow is basically: - `arc` creates a diff. - `arc` calls `harbormaster.queryautotargets`, passing the diff PHID and saying "I have some lint and unit results I want to stick on this thing". - Harbormaster builds the plan, steps, and targets (if any of them don't already exist), and hands back the target PHIDs so `arc` has a completely standard-looking place to put results. - `arc` uploads the test results to the right targets, as though Harbormaster had asked it to run unit/lint in the first place. (This doesn't actually do any of that yet, just sets things up.) I'll maybe doc turn that ^^^^^^ into a doc for posterity since I think it's hard to guess what an "autotarget" is, but I'm going to grab some lunch first. Test Plan: - Added unit tests to make sure we can build these things properly. - Used `harbormaster.queryautotargets` to build autotargets for a bunch of diffs. - Verified targets come up in "waiting for message" state. - Verified plans and steps are not editable. Reviewers: btrahan Reviewed By: btrahan Subscribers: hach-que, epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13345
2015-06-21 18:04:21 +02:00
'HarbormasterAutotargetsTestCase' => 'applications/harbormaster/__tests__/HarbormasterAutotargetsTestCase.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuild' => 'applications/harbormaster/storage/build/HarbormasterBuild.php',
Abort previous build targets when a build is restarted Summary: Ref T5936. This implements build implementations aborting early when the build has since been restarted. Build steps now periodically poll to see if the build's current generation does not match their generation, and they throw a `HarbormasterBuildAbortedException` if that is the case. Test Plan: Tested locally on my machine with the sleep build step. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5936 Differential Revision: https://secure.phabricator.com/D10322
2014-08-26 12:46:23 +02:00
'HarbormasterBuildAbortedException' => 'applications/harbormaster/exception/HarbormasterBuildAbortedException.php',
Replace "Cancel Build" with "Stop", "Resume" and "Restart" Summary: Ref T1049. Currently you can cancel a build, but now that we're tracking a lot more state we can stop, resume, and restart builds. When the user issues a command against a build, I'm writing it into an auxiliary queue (`HarbormasterBuildCommand`) and then reading them out in the worker. This is mostly to avoid race messes where we try to `save()` the object in multiple places: basically, the BuildEngine is the //only// thing that writes to Build objects, and it holds a lock while it does it. Test Plan: - Created a plan which runs "sleep 2" a bunch of times in a row. - Stopped, resumed, and restarted it. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7892
2014-01-06 21:32:20 +01:00
'HarbormasterBuildActionController' => 'applications/harbormaster/controller/HarbormasterBuildActionController.php',
Add "Autoplans" to Harbormaster Summary: Ref T8095. Two general problems: - I want Harbormaster to own all lint and unit test results. - I don't want users to have to configure anything for `arc` to keep working automatically. These are in conflict because generic lint/unit test ownership in Harbormaster requires that build targets exist which we can attach build results to. However, we can't currently create build targets on demand: Harbormaster assumes it is responsible for creating targets, then running code or making third-party service calls to actually run the builds. I considered two broad approaches to let `arc` push results into Harbormaster without requiring administrators to configure some kind of "arc results" build plan: # Add magic target PHIDs like `PHID-MAGIC-this-is-really-arc-unit`. # Add new code to build real targets with real PHIDs. (1) is probably a bit less work to get off the ground, but I think it's worse overall and very likely to create more problems in the long run. I particularly worry that it will lead to a small amount of special casing in a very large number of places, which seems more fragile. (2) is more work upfront but I think does a better job of putting all the special casing in one place that we can, e.g., more reasonably unit test, and letting the rest of the code rarely/never care about this case since it's just dealing with normal plans/steps/targets as far as it can tell. This diff introduces "autoplans", which are source templates for plans/steps. This let us "push" these targets into Harbormaster. Hypthetically, any process "like" arc can use autoplans to upload test/lint/etc results. In practice, probably only `arc` will ever use this, but I think it's still quite a bit cleaner than the alternative despite all the generality. Workflow is basically: - `arc` creates a diff. - `arc` calls `harbormaster.queryautotargets`, passing the diff PHID and saying "I have some lint and unit results I want to stick on this thing". - Harbormaster builds the plan, steps, and targets (if any of them don't already exist), and hands back the target PHIDs so `arc` has a completely standard-looking place to put results. - `arc` uploads the test results to the right targets, as though Harbormaster had asked it to run unit/lint in the first place. (This doesn't actually do any of that yet, just sets things up.) I'll maybe doc turn that ^^^^^^ into a doc for posterity since I think it's hard to guess what an "autotarget" is, but I'm going to grab some lunch first. Test Plan: - Added unit tests to make sure we can build these things properly. - Used `harbormaster.queryautotargets` to build autotargets for a bunch of diffs. - Verified targets come up in "waiting for message" state. - Verified plans and steps are not editable. Reviewers: btrahan Reviewed By: btrahan Subscribers: hach-que, epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13345
2015-06-21 18:04:21 +02:00
'HarbormasterBuildArcanistAutoplan' => 'applications/harbormaster/autoplan/HarbormasterBuildArcanistAutoplan.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildArtifact' => 'applications/harbormaster/storage/build/HarbormasterBuildArtifact.php',
Add `harbormaster.createartifact` Summary: Ref T8659. In the general case, this eventually allows build processes to do things like: - Upload build results (like a ".app" or ".exe" or other binary). - Pass complex results between build steps (e.g., build step A does something hard and build step B uses it to do something else). Today, we're a long way away from having the infrastructure for that. However, it is useful to let third party build processes (like Jenkins) upload URIs that link back to the external build results. This adds `harbormaster.createartifact` so they can do that. The only useful thing to do with this method today is have your Jenkins build do this: params = array( "uri": "https://jenkins.mycompany.com/build/23923/details/", "name": "View Build Results in Jenkins", "ui.external": true, ); harbormaster.createartifact(target, 'uri', params); Then (after the next diff) we'll show a link in Differential and a prominent link in Harbormaster. I didn't actually do the UI stuff in this diff since it's already pretty big. This change moves a lot of code around, too: - Adds PHIDs to artifacts. - It modularizes build artifact types (currently "file", "host" and "URI"). - It formalizes build artifact parameters and construction: - This lets me generate usable documentation about how to create artifacts. - This prevents users from doing dangerous or policy-violating things. - It does some other general modernization. Test Plan: {F715633} {F715634} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8659 Differential Revision: https://secure.phabricator.com/D13900
2015-08-15 16:28:56 +02:00
'HarbormasterBuildArtifactPHIDType' => 'applications/harbormaster/phid/HarbormasterBuildArtifactPHIDType.php',
Introduce HarbormasterBuildTarget to snapshot build steps through a build Summary: This implements build targets as outlined in D7582. Build targets represent an instance of a build step particular to the build. Logs and artifacts have been adjusted to attach to build targets instead of build / build step pairs. Test Plan: Ran builds and clicked around the interface. Everything seemed to work. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T1049 Differential Revision: https://secure.phabricator.com/D7703
2013-12-05 02:01:12 +01:00
'HarbormasterBuildArtifactQuery' => 'applications/harbormaster/query/HarbormasterBuildArtifactQuery.php',
Add "Autoplans" to Harbormaster Summary: Ref T8095. Two general problems: - I want Harbormaster to own all lint and unit test results. - I don't want users to have to configure anything for `arc` to keep working automatically. These are in conflict because generic lint/unit test ownership in Harbormaster requires that build targets exist which we can attach build results to. However, we can't currently create build targets on demand: Harbormaster assumes it is responsible for creating targets, then running code or making third-party service calls to actually run the builds. I considered two broad approaches to let `arc` push results into Harbormaster without requiring administrators to configure some kind of "arc results" build plan: # Add magic target PHIDs like `PHID-MAGIC-this-is-really-arc-unit`. # Add new code to build real targets with real PHIDs. (1) is probably a bit less work to get off the ground, but I think it's worse overall and very likely to create more problems in the long run. I particularly worry that it will lead to a small amount of special casing in a very large number of places, which seems more fragile. (2) is more work upfront but I think does a better job of putting all the special casing in one place that we can, e.g., more reasonably unit test, and letting the rest of the code rarely/never care about this case since it's just dealing with normal plans/steps/targets as far as it can tell. This diff introduces "autoplans", which are source templates for plans/steps. This let us "push" these targets into Harbormaster. Hypthetically, any process "like" arc can use autoplans to upload test/lint/etc results. In practice, probably only `arc` will ever use this, but I think it's still quite a bit cleaner than the alternative despite all the generality. Workflow is basically: - `arc` creates a diff. - `arc` calls `harbormaster.queryautotargets`, passing the diff PHID and saying "I have some lint and unit results I want to stick on this thing". - Harbormaster builds the plan, steps, and targets (if any of them don't already exist), and hands back the target PHIDs so `arc` has a completely standard-looking place to put results. - `arc` uploads the test results to the right targets, as though Harbormaster had asked it to run unit/lint in the first place. (This doesn't actually do any of that yet, just sets things up.) I'll maybe doc turn that ^^^^^^ into a doc for posterity since I think it's hard to guess what an "autotarget" is, but I'm going to grab some lunch first. Test Plan: - Added unit tests to make sure we can build these things properly. - Used `harbormaster.queryautotargets` to build autotargets for a bunch of diffs. - Verified targets come up in "waiting for message" state. - Verified plans and steps are not editable. Reviewers: btrahan Reviewed By: btrahan Subscribers: hach-que, epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13345
2015-06-21 18:04:21 +02:00
'HarbormasterBuildAutoplan' => 'applications/harbormaster/autoplan/HarbormasterBuildAutoplan.php',
Replace "Cancel Build" with "Stop", "Resume" and "Restart" Summary: Ref T1049. Currently you can cancel a build, but now that we're tracking a lot more state we can stop, resume, and restart builds. When the user issues a command against a build, I'm writing it into an auxiliary queue (`HarbormasterBuildCommand`) and then reading them out in the worker. This is mostly to avoid race messes where we try to `save()` the object in multiple places: basically, the BuildEngine is the //only// thing that writes to Build objects, and it holds a lock while it does it. Test Plan: - Created a plan which runs "sleep 2" a bunch of times in a row. - Stopped, resumed, and restarted it. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7892
2014-01-06 21:32:20 +01:00
'HarbormasterBuildCommand' => 'applications/harbormaster/storage/HarbormasterBuildCommand.php',
Implement build simulation; convert Harbormaster to be purely dependency based Summary: Depends on D9806. This implements the build simulator, which is used to calculate the order of build steps in the plan editor. This includes a migration script to convert existing plans from sequential based to dependency based, and then drops the sequence column. Because build plans are now dependency based, the grippable and re-order behaviour has been removed. Test Plan: Tested the migration, saw the dependencies appear correctly. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D9847
2014-07-31 03:39:49 +02:00
'HarbormasterBuildDependencyDatasource' => 'applications/harbormaster/typeahead/HarbormasterBuildDependencyDatasource.php',
Split Harbormaster workers apart so build steps can run in parallel Summary: Ref T1049. Currently, the Harbormaster worker looks like this: foreach (step) { run_step(step); } This means steps can't ever be run in parallel. Instead, split it into two workers. The "Build" worker starts things off, and basically does: update_build(); (We could theoretically do this in the original process because it should never take very long, but since there's a lock and it's a little bit complex it seemed cleaner to separate it.) The "Target" worker runs an individual target (like a command, or an HTTP request, or whatever), then updates the build: run_one_step(step); update_build(); The new `update_build()` mechanism in `HarbormasterBuildEngine` does this, roughly: figure_out_overall_status_of_all_steps(); if (build is done) { done(); } if (build is fail) { fail(); } foreach (step that is ready to run) { queue_target_worker_for_step(step); } So, overall: - The part of the code that updates Builds is completely separated from the part of the code that updates Targets. - Targets can run in parallel. Test Plan: - Ran a bunch of builds via `bin/harbormaster build`. - Ran a bunch of builds via web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7890
2014-01-06 21:32:10 +01:00
'HarbormasterBuildEngine' => 'applications/harbormaster/engine/HarbormasterBuildEngine.php',
Allow build steps to explicitly fail the build Summary: We've received feedback that the "core - exception" is incredibly confusing, to the point where developers see this and write off the build failure as a Phabricator error that is unrelated to their changes. Test Plan: Ran a build with a `exit 1` run step, didn't see the "core - exception" appear. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D10090
2014-08-01 00:08:28 +02:00
'HarbormasterBuildFailureException' => 'applications/harbormaster/exception/HarbormasterBuildFailureException.php',
Implement build simulation; convert Harbormaster to be purely dependency based Summary: Depends on D9806. This implements the build simulator, which is used to calculate the order of build steps in the plan editor. This includes a migration script to convert existing plans from sequential based to dependency based, and then drops the sequence column. Because build plans are now dependency based, the grippable and re-order behaviour has been removed. Test Plan: Tested the migration, saw the dependencies appear correctly. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D9847
2014-07-31 03:39:49 +02:00
'HarbormasterBuildGraph' => 'applications/harbormaster/engine/HarbormasterBuildGraph.php',
Replace Harbormaster "BuildItem" with Lint/Unit messages Summary: Ref T8095. Harbormaster has a `BuildItem` class, but it has no table and is unused. This was an earlier idea about representing lint/unit results and some other possible types of messages, but I think we want to be more specific than this. Remove `BuildItem` and add `Lint` and `Unit` storage. These tables roughly parallel how we store lint/unit messages today, with some guesses about how where they'll go in the future. Test Plan: Ran `bin/storage upgrade` and got a clean adjust out of it. Reviewers: btrahan Reviewed By: btrahan Subscribers: hach-que, epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13329
2015-06-21 18:00:00 +02:00
'HarbormasterBuildLintMessage' => 'applications/harbormaster/storage/build/HarbormasterBuildLintMessage.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildLog' => 'applications/harbormaster/storage/build/HarbormasterBuildLog.php',
Give HarbormasterBuildLogChunk a real table Summary: Ref T10457. Currently, this table is an ad-hoc table, but can easily be turned into a normal table. This will make iterating over log chunks to compress and archive them easier. Test Plan: Viewed logs, ran `bin/storage adjust` with no issues. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15376
2016-03-01 21:10:27 +01:00
'HarbormasterBuildLogChunk' => 'applications/harbormaster/storage/build/HarbormasterBuildLogChunk.php',
Implement an iterator for build log chunks Summary: Ref T5822. This will make it easier to compress and archive chunks without needing to hold them in memory. Test Plan: Ran a build, looked at some logs. Reviewers: chad Reviewed By: chad Maniphest Tasks: T5822 Differential Revision: https://secure.phabricator.com/D15378
2016-03-01 21:22:14 +01:00
'HarbormasterBuildLogChunkIterator' => 'applications/harbormaster/storage/build/HarbormasterBuildLogChunkIterator.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'HarbormasterBuildLogPHIDType' => 'applications/harbormaster/phid/HarbormasterBuildLogPHIDType.php',
Implemented support for build logs Summary: Depends on D7519. This implements support for build logs in Harbormaster. This includes support for appending to a log from the "Run Remote Command" build step. It also adds the ability to cancel builds. Currently the build view page doesn't update the logs live; I'm sure this can be achieved with Javelin, but I don't have enough experience with Javelin to actually make it poll from updates to content in the background. {F79151} {F79153} {F79150} {F79152} Test Plan: Tested this by setting up SSH on a Windows machine and using a Remote Command configured with: ``` C:\Windows\system32\cmd.exe /C cd C:\Build && mkdir Build_${timestamp} && cd Build_${timestamp} && git clone --recursive https://github.com/hach-que/Tychaia.git && cd Tychaia && Protobuild.exe && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Tychaia.Windows.sln ``` and observed the output of the build stream from the Windows machine into Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7521
2013-11-09 03:09:03 +01:00
'HarbormasterBuildLogQuery' => 'applications/harbormaster/query/HarbormasterBuildLogQuery.php',
Allow external systems to send messages to build targets Summary: Ref T1049. Allows external systems to send a message to a build target. The primary intended use case is: - You make an HTTP request to Jenkins. - The build goes into a "waiting" state. - Later, Jenkins calls `harbormaster.sendmessage` to report that the target passed or failed. - The build continues as appropriate. This is deceptively complicated because: - There are a lot of race concerns. We might get a message back from an external system before it even responds to the request we made. We want to make sure we process these messages no matter when we receive them. - These messages need to be sent to a build target (vs a build or buildable) because we'll get into trouble with parallelization later on otherwise (Jenkins is told to do 3 builds; we can't tell which ones failed or what overall state is unless the message are sent to targets). - I initially thought about implementing this as a separate "Wait for a response from an external system" build step. This gets a lot more complicated for users once we do parallelization, though. Particularly, in the case where you've told Jenkins to do 3 builds, the three "wait" steps need to know which target they're waiting for (and jenkins needs to know some unique identifier for each target). So this pretty much boils down to a more complicated, more error-prone version of using target PHIDs. This makes the already-muddy Build UI a bit worse, but it needs a general clarity pass anyway (it's showing way too much uninteresting data, and should show a better summary of results instead). Test Plan: - This doesn't really do anything interesting yet. - Used Conduit to send messages to build plans. - Viewed the messages on the build screen. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8604
2014-03-26 00:11:28 +01:00
'HarbormasterBuildMessage' => 'applications/harbormaster/storage/HarbormasterBuildMessage.php',
'HarbormasterBuildMessageQuery' => 'applications/harbormaster/query/HarbormasterBuildMessageQuery.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'HarbormasterBuildPHIDType' => 'applications/harbormaster/phid/HarbormasterBuildPHIDType.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildPlan' => 'applications/harbormaster/storage/configuration/HarbormasterBuildPlan.php',
Modernize "build plans" typeahead datasource Summary: Ref T4420. Modernize build plans. Test Plan: - Used build plan typeahead in Harbormaster. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9878
2014-07-11 01:20:58 +02:00
'HarbormasterBuildPlanDatasource' => 'applications/harbormaster/typeahead/HarbormasterBuildPlanDatasource.php',
Give Harbormaster Build Plans real policies Summary: Ref T9614. Currently, a lot of Build Plan behavior is covered by a global "can manage" policy. One install in particular is experiencing difficulty with warring factions within engineering aborting one another's builds. As a first step to remedy this, and also generally make Harbormaster more flexible and bring it in line with other applications in terms of policy power: - Give Build Plans normal view/edit policies. - Require "Can Edit" to run a plan manually. Having "Can View" on plans may be a little weird in some cases (the status of a Buildable might be bad because of a build you can't see) but we can cross that bridge when we come to it. Next change here will require "Can Edit" to abort a build. This will reasonably allow installs to reserve pause/abort for administrators/adults. (I might let anyone restart a plan, though?) Test Plan: - Created a new build plan. - Verified defaults were inherited from application defaults (swapped them around, too). - Saved build plan. - Edited policies. - Verified autoplans get the right policies. - Verified old plans got migrated properly. - Tried to run a plan I couldn't edit (denied). - Ran a plan from CLI with `bin/harbormaster`. - Tried to create a plan with an unprivileged user. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9614 Differential Revision: https://secure.phabricator.com/D14321
2015-10-26 20:38:21 +01:00
'HarbormasterBuildPlanDefaultEditCapability' => 'applications/harbormaster/capability/HarbormasterBuildPlanDefaultEditCapability.php',
'HarbormasterBuildPlanDefaultViewCapability' => 'applications/harbormaster/capability/HarbormasterBuildPlanDefaultViewCapability.php',
Use EditEngine for Harbormaster Build Plans, fix some crumbs/mobile stuff Summary: Ref T10457. - Use EditEngine for Build Plans. - Fix some minor issues with crumbs being inconsistent. - Fix some minor issues with mobile menus not being consistent/available. Test Plan: - Created and edited build plans. - Poked around in mobile width, verified mobile menu had the right stuff in it. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15357
2016-02-27 04:12:55 +01:00
'HarbormasterBuildPlanEditEngine' => 'applications/harbormaster/editor/HarbormasterBuildPlanEditEngine.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildPlanEditor' => 'applications/harbormaster/editor/HarbormasterBuildPlanEditor.php',
Support searching for Harbormater build plans by name substring Summary: Ref T10457. Allow build plans to be queried by name. Test Plan: - Searched for plans by name. - Renamed a plan, searched for new name. {F1133085} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15359
2016-02-27 17:59:33 +01:00
'HarbormasterBuildPlanNameNgrams' => 'applications/harbormaster/storage/configuration/HarbormasterBuildPlanNameNgrams.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'HarbormasterBuildPlanPHIDType' => 'applications/harbormaster/phid/HarbormasterBuildPlanPHIDType.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildPlanQuery' => 'applications/harbormaster/query/HarbormasterBuildPlanQuery.php',
'HarbormasterBuildPlanSearchEngine' => 'applications/harbormaster/query/HarbormasterBuildPlanSearchEngine.php',
'HarbormasterBuildPlanTransaction' => 'applications/harbormaster/storage/configuration/HarbormasterBuildPlanTransaction.php',
'HarbormasterBuildPlanTransactionQuery' => 'applications/harbormaster/query/HarbormasterBuildPlanTransactionQuery.php',
'HarbormasterBuildQuery' => 'applications/harbormaster/query/HarbormasterBuildQuery.php',
Allow builds to have parameters Summary: Ref T9352. See D13635. Build targets can have variables already, but let builds have them too. This mostly enables future use cases (sub-builds, more sophisticated build triggers). Test Plan: With a custom Herald rule + action like the one in T9352, updated a revision and saw it generate multiple builds with varying parameters. Reviewers: chad, hach-que Reviewed By: hach-que Maniphest Tasks: T9352 Differential Revision: https://secure.phabricator.com/D14222
2015-10-02 15:32:08 +02:00
'HarbormasterBuildRequest' => 'applications/harbormaster/engine/HarbormasterBuildRequest.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildStep' => 'applications/harbormaster/storage/configuration/HarbormasterBuildStep.php',
Use ApplicationTransactions and CustomField to implement build steps Summary: Ref T1049. Fixes T4602. Moves all the funky field stuff to CustomField. Uses ApplicationTransactions to apply and record edits. This makes "artifact" fields a little less nice (but still perfectly usable). With D8599, I think they're reasonable overall. We can improve this in the future. All other field types are better (e.g., fixes weird bugs with "bool", fixes lots of weird behavior around required fields), and this gives us access to many new field types. Test Plan: Made a bunch of step edits. Here's an example: {F133694} Note that: - "Required" fields work correctly. - the transaction record is shown at the bottom of the page. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4602, T1049 Differential Revision: https://secure.phabricator.com/D8600
2014-03-26 00:08:40 +01:00
'HarbormasterBuildStepCoreCustomField' => 'applications/harbormaster/customfield/HarbormasterBuildStepCoreCustomField.php',
'HarbormasterBuildStepCustomField' => 'applications/harbormaster/customfield/HarbormasterBuildStepCustomField.php',
'HarbormasterBuildStepEditor' => 'applications/harbormaster/editor/HarbormasterBuildStepEditor.php',
Lump Harbormaster build steps into groups Summary: Ref T8089. We have a lot of broken/confusing/prototype build steps that I want to hide from users when we unprototype Harbormaster. The dialog is also just kind of unwieldy. Organize this UI a little better and put all the sketchy junk in a "prototypes" group that you can't see unless prototypes are enabled. This doesn't break anything (the old steps will still work fine), but should reduce user confusion. Test Plan: Old UI: {F691439} New UI (prototypes off): {F691440} New UI (prototypes on): {F691441} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8089 Differential Revision: https://secure.phabricator.com/D13803
2015-08-06 13:19:42 +02:00
'HarbormasterBuildStepGroup' => 'applications/harbormaster/stepgroup/HarbormasterBuildStepGroup.php',
Rename "BuildStepImplementation" to "HarbormasterBuildStepImplementation" Summary: Ref T1049. D8588 already required custom code to change what it extends, so this is as good a time as we're going to get to move to more standard class name. Test Plan: `arc liberate`; `arc lint` Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8601
2014-03-26 00:09:21 +01:00
'HarbormasterBuildStepImplementation' => 'applications/harbormaster/step/HarbormasterBuildStepImplementation.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'HarbormasterBuildStepImplementationTestCase' => 'applications/harbormaster/step/__tests__/HarbormasterBuildStepImplementationTestCase.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'HarbormasterBuildStepPHIDType' => 'applications/harbormaster/phid/HarbormasterBuildStepPHIDType.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildStepQuery' => 'applications/harbormaster/query/HarbormasterBuildStepQuery.php',
Use ApplicationTransactions and CustomField to implement build steps Summary: Ref T1049. Fixes T4602. Moves all the funky field stuff to CustomField. Uses ApplicationTransactions to apply and record edits. This makes "artifact" fields a little less nice (but still perfectly usable). With D8599, I think they're reasonable overall. We can improve this in the future. All other field types are better (e.g., fixes weird bugs with "bool", fixes lots of weird behavior around required fields), and this gives us access to many new field types. Test Plan: Made a bunch of step edits. Here's an example: {F133694} Note that: - "Required" fields work correctly. - the transaction record is shown at the bottom of the page. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4602, T1049 Differential Revision: https://secure.phabricator.com/D8600
2014-03-26 00:08:40 +01:00
'HarbormasterBuildStepTransaction' => 'applications/harbormaster/storage/configuration/HarbormasterBuildStepTransaction.php',
'HarbormasterBuildStepTransactionQuery' => 'applications/harbormaster/query/HarbormasterBuildStepTransactionQuery.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildTarget' => 'applications/harbormaster/storage/build/HarbormasterBuildTarget.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'HarbormasterBuildTargetPHIDType' => 'applications/harbormaster/phid/HarbormasterBuildTargetPHIDType.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildTargetQuery' => 'applications/harbormaster/query/HarbormasterBuildTargetQuery.php',
Show command transactions in Harbormaster builds Summary: Create transaction, editor, etc, and move command generation over to editor. Show in a timeline in the buildable page. Also prevent Engine from creating an empty transaction when build starts (Fixes T4885). Fixes T4886. Test Plan: Restart builds and buildables, look at timeline. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4885, T4886 Differential Revision: https://secure.phabricator.com/D9110
2014-05-15 16:02:30 +02:00
'HarbormasterBuildTransaction' => 'applications/harbormaster/storage/HarbormasterBuildTransaction.php',
'HarbormasterBuildTransactionEditor' => 'applications/harbormaster/editor/HarbormasterBuildTransactionEditor.php',
'HarbormasterBuildTransactionQuery' => 'applications/harbormaster/query/HarbormasterBuildTransactionQuery.php',
Replace Harbormaster "BuildItem" with Lint/Unit messages Summary: Ref T8095. Harbormaster has a `BuildItem` class, but it has no table and is unused. This was an earlier idea about representing lint/unit results and some other possible types of messages, but I think we want to be more specific than this. Remove `BuildItem` and add `Lint` and `Unit` storage. These tables roughly parallel how we store lint/unit messages today, with some guesses about how where they'll go in the future. Test Plan: Ran `bin/storage upgrade` and got a clean adjust out of it. Reviewers: btrahan Reviewed By: btrahan Subscribers: hach-que, epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13329
2015-06-21 18:00:00 +02:00
'HarbormasterBuildUnitMessage' => 'applications/harbormaster/storage/build/HarbormasterBuildUnitMessage.php',
Implemented support for build logs Summary: Depends on D7519. This implements support for build logs in Harbormaster. This includes support for appending to a log from the "Run Remote Command" build step. It also adds the ability to cancel builds. Currently the build view page doesn't update the logs live; I'm sure this can be achieved with Javelin, but I don't have enough experience with Javelin to actually make it poll from updates to content in the background. {F79151} {F79153} {F79150} {F79152} Test Plan: Tested this by setting up SSH on a Windows machine and using a Remote Command configured with: ``` C:\Windows\system32\cmd.exe /C cd C:\Build && mkdir Build_${timestamp} && cd Build_${timestamp} && git clone --recursive https://github.com/hach-que/Tychaia.git && cd Tychaia && Protobuild.exe && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Tychaia.Windows.sln ``` and observed the output of the build stream from the Windows machine into Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7521
2013-11-09 03:09:03 +01:00
'HarbormasterBuildViewController' => 'applications/harbormaster/controller/HarbormasterBuildViewController.php',
Implement basic Harbormaster daemon and start builds. Summary: This implements a basic Harbormaster daemon that takes pending builds and builds them (currently just sleeps 15 seconds before moving to passed state). It also implements an interface to apply a build plan to a buildable, so that users can kick off builds for a buildable. Test Plan: Ran `bin/phd debug PhabricatorHarbormasterBuildDaemon` and used the interface to start some builds by applying a build plan. Observed them move from 'pending' to 'building' to 'passed'. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7498
2013-11-05 21:43:47 +01:00
'HarbormasterBuildWorker' => 'applications/harbormaster/worker/HarbormasterBuildWorker.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildable' => 'applications/harbormaster/storage/HarbormasterBuildable.php',
Allow entire buildables to restart/stop/resume Summary: Ref T1049. Creates convenience actions at the Buildable level to stop, resume, or restart all builds. Test Plan: - Stopped all builds. - Resumed all builds. - Restarted all builds. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7899
2014-01-06 23:12:15 +01:00
'HarbormasterBuildableActionController' => 'applications/harbormaster/controller/HarbormasterBuildableActionController.php',
Modularize the Harbormaster "Run build plan" Herald action Ref T8726. Modularizes "Run build plan" in Differential and Diffusion.
2015-07-30 21:22:35 +02:00
'HarbormasterBuildableAdapterInterface' => 'applications/harbormaster/herald/HarbormasterBuildableAdapterInterface.php',
Add `bin/harbormaster` to make builds easier to debug Summary: Ref T1049. Adds `bin/harbormaster` and `bin/harbormaster build` for applying plans from the console. Since this gets `--trace`, it's much easier to debug what's going on. This doesn't work properly with some of the Drydock steps yet, I need to look at those. I think `setRunAllTasksInProcess` probably obsoletes some of the mechanisms. It might also not work with "Wait for Builds" but I didn't check. Test Plan: Used `bin/harbormaster` to run a bunch of builds. Ran builds from web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7825
2013-12-26 19:40:52 +01:00
'HarbormasterBuildableInterface' => 'applications/harbormaster/interface/HarbormasterBuildableInterface.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildableListController' => 'applications/harbormaster/controller/HarbormasterBuildableListController.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'HarbormasterBuildablePHIDType' => 'applications/harbormaster/phid/HarbormasterBuildablePHIDType.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildableQuery' => 'applications/harbormaster/query/HarbormasterBuildableQuery.php',
'HarbormasterBuildableSearchEngine' => 'applications/harbormaster/query/HarbormasterBuildableSearchEngine.php',
Show command transactions in Harbormaster builds Summary: Create transaction, editor, etc, and move command generation over to editor. Show in a timeline in the buildable page. Also prevent Engine from creating an empty transaction when build starts (Fixes T4885). Fixes T4886. Test Plan: Restart builds and buildables, look at timeline. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4885, T4886 Differential Revision: https://secure.phabricator.com/D9110
2014-05-15 16:02:30 +02:00
'HarbormasterBuildableTransaction' => 'applications/harbormaster/storage/HarbormasterBuildableTransaction.php',
'HarbormasterBuildableTransactionEditor' => 'applications/harbormaster/editor/HarbormasterBuildableTransactionEditor.php',
'HarbormasterBuildableTransactionQuery' => 'applications/harbormaster/query/HarbormasterBuildableTransactionQuery.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildableViewController' => 'applications/harbormaster/controller/HarbormasterBuildableViewController.php',
Lump Harbormaster build steps into groups Summary: Ref T8089. We have a lot of broken/confusing/prototype build steps that I want to hide from users when we unprototype Harbormaster. The dialog is also just kind of unwieldy. Organize this UI a little better and put all the sketchy junk in a "prototypes" group that you can't see unless prototypes are enabled. This doesn't break anything (the old steps will still work fine), but should reduce user confusion. Test Plan: Old UI: {F691439} New UI (prototypes off): {F691440} New UI (prototypes on): {F691441} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8089 Differential Revision: https://secure.phabricator.com/D13803
2015-08-06 13:19:42 +02:00
'HarbormasterBuiltinBuildStepGroup' => 'applications/harbormaster/stepgroup/HarbormasterBuiltinBuildStepGroup.php',
Add a "Build with CircleCI" build step Summary: Ref T9456. Some rough edges and we can't complete the build yet since I haven't written a webhook, but this mostly seems to be working. Test Plan: - Ran this build on some stuff. - Ran a normal HTTP step build to make sure I didn't break that. {F880301} {F880302} {F880303} Reviewers: chad Reviewed By: chad Subscribers: JustinTulloss, joshma Maniphest Tasks: T9456 Differential Revision: https://secure.phabricator.com/D14286
2015-10-15 05:01:22 +02:00
'HarbormasterCircleCIBuildStepImplementation' => 'applications/harbormaster/step/HarbormasterCircleCIBuildStepImplementation.php',
'HarbormasterCircleCIBuildableInterface' => 'applications/harbormaster/interface/HarbormasterCircleCIBuildableInterface.php',
Add a CircleCI webhook Summary: Ref T9456. This makes everything work, except that CircleCI doesn't fetch tags which are not ancestors of branch heads. Test Plan: Ran passing builds through CircleCI. Reviewers: chad Reviewed By: chad Subscribers: dpaola2, JustinTulloss Maniphest Tasks: T9456 Differential Revision: https://secure.phabricator.com/D14288
2015-10-15 18:07:31 +02:00
'HarbormasterCircleCIHookController' => 'applications/harbormaster/controller/HarbormasterCircleCIHookController.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'HarbormasterConduitAPIMethod' => 'applications/harbormaster/conduit/HarbormasterConduitAPIMethod.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterController' => 'applications/harbormaster/controller/HarbormasterController.php',
Add `harbormaster.createartifact` Summary: Ref T8659. In the general case, this eventually allows build processes to do things like: - Upload build results (like a ".app" or ".exe" or other binary). - Pass complex results between build steps (e.g., build step A does something hard and build step B uses it to do something else). Today, we're a long way away from having the infrastructure for that. However, it is useful to let third party build processes (like Jenkins) upload URIs that link back to the external build results. This adds `harbormaster.createartifact` so they can do that. The only useful thing to do with this method today is have your Jenkins build do this: params = array( "uri": "https://jenkins.mycompany.com/build/23923/details/", "name": "View Build Results in Jenkins", "ui.external": true, ); harbormaster.createartifact(target, 'uri', params); Then (after the next diff) we'll show a link in Differential and a prominent link in Harbormaster. I didn't actually do the UI stuff in this diff since it's already pretty big. This change moves a lot of code around, too: - Adds PHIDs to artifacts. - It modularizes build artifact types (currently "file", "host" and "URI"). - It formalizes build artifact parameters and construction: - This lets me generate usable documentation about how to create artifacts. - This prevents users from doing dangerous or policy-violating things. - It does some other general modernization. Test Plan: {F715633} {F715634} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8659 Differential Revision: https://secure.phabricator.com/D13900
2015-08-15 16:28:56 +02:00
'HarbormasterCreateArtifactConduitAPIMethod' => 'applications/harbormaster/conduit/HarbormasterCreateArtifactConduitAPIMethod.php',
Give Harbormaster Build Plans real policies Summary: Ref T9614. Currently, a lot of Build Plan behavior is covered by a global "can manage" policy. One install in particular is experiencing difficulty with warring factions within engineering aborting one another's builds. As a first step to remedy this, and also generally make Harbormaster more flexible and bring it in line with other applications in terms of policy power: - Give Build Plans normal view/edit policies. - Require "Can Edit" to run a plan manually. Having "Can View" on plans may be a little weird in some cases (the status of a Buildable might be bad because of a build you can't see) but we can cross that bridge when we come to it. Next change here will require "Can Edit" to abort a build. This will reasonably allow installs to reserve pause/abort for administrators/adults. (I might let anyone restart a plan, though?) Test Plan: - Created a new build plan. - Verified defaults were inherited from application defaults (swapped them around, too). - Saved build plan. - Edited policies. - Verified autoplans get the right policies. - Verified old plans got migrated properly. - Tried to run a plan I couldn't edit (denied). - Ran a plan from CLI with `bin/harbormaster`. - Tried to create a plan with an unprivileged user. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9614 Differential Revision: https://secure.phabricator.com/D14321
2015-10-26 20:38:21 +01:00
'HarbormasterCreatePlansCapability' => 'applications/harbormaster/capability/HarbormasterCreatePlansCapability.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HarbormasterDAO' => 'applications/harbormaster/storage/HarbormasterDAO.php',
Put Drydock build steps into their own group in Harbormaster Summary: Ref T9252. Move these into a new "Drydock" group. Test Plan: Clicked "Add Build Step", saw Drydock steps in a Drydock group. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14237
2015-10-06 00:59:35 +02:00
'HarbormasterDrydockBuildStepGroup' => 'applications/harbormaster/stepgroup/HarbormasterDrydockBuildStepGroup.php',
Allow Harbormaster to run commands on Drydock working copies Summary: Ref T9252. This mostly cleans up future and log handling, and edges us closer to being able to do useful work with Harbormaster / Drydock. Test Plan: - Added a "Run `ls -alh`" step to my trivial build plan. - Ran it a bunch of times. - Worked great. - Also did an HTTP plan. {F835227} {F835228} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14161
2015-09-25 19:43:32 +02:00
'HarbormasterDrydockCommandBuildStepImplementation' => 'applications/harbormaster/step/HarbormasterDrydockCommandBuildStepImplementation.php',
Allow Harbormaster to lease working copies from Drydock Summary: Ref T9252. This is still crude in a few ways but basically works, at least for commits. Test Plan: - Made a build plan with just this build step. - Ran `bin/harbormaster build --plan 10 ...` on a commit. - It actually built a working copy, leased it, took no action, and released the lease. MAGIC~~~ Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14160
2015-09-25 02:29:47 +02:00
'HarbormasterDrydockLeaseArtifact' => 'applications/harbormaster/artifact/HarbormasterDrydockLeaseArtifact.php',
Allow Harbormaster to run commands on Drydock working copies Summary: Ref T9252. This mostly cleans up future and log handling, and edges us closer to being able to do useful work with Harbormaster / Drydock. Test Plan: - Added a "Run `ls -alh`" step to my trivial build plan. - Ran it a bunch of times. - Worked great. - Also did an HTTP plan. {F835227} {F835228} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14161
2015-09-25 19:43:32 +02:00
'HarbormasterExecFuture' => 'applications/harbormaster/future/HarbormasterExecFuture.php',
Lump Harbormaster build steps into groups Summary: Ref T8089. We have a lot of broken/confusing/prototype build steps that I want to hide from users when we unprototype Harbormaster. The dialog is also just kind of unwieldy. Organize this UI a little better and put all the sketchy junk in a "prototypes" group that you can't see unless prototypes are enabled. This doesn't break anything (the old steps will still work fine), but should reduce user confusion. Test Plan: Old UI: {F691439} New UI (prototypes off): {F691440} New UI (prototypes on): {F691441} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8089 Differential Revision: https://secure.phabricator.com/D13803
2015-08-06 13:19:42 +02:00
'HarbormasterExternalBuildStepGroup' => 'applications/harbormaster/stepgroup/HarbormasterExternalBuildStepGroup.php',
Add `harbormaster.createartifact` Summary: Ref T8659. In the general case, this eventually allows build processes to do things like: - Upload build results (like a ".app" or ".exe" or other binary). - Pass complex results between build steps (e.g., build step A does something hard and build step B uses it to do something else). Today, we're a long way away from having the infrastructure for that. However, it is useful to let third party build processes (like Jenkins) upload URIs that link back to the external build results. This adds `harbormaster.createartifact` so they can do that. The only useful thing to do with this method today is have your Jenkins build do this: params = array( "uri": "https://jenkins.mycompany.com/build/23923/details/", "name": "View Build Results in Jenkins", "ui.external": true, ); harbormaster.createartifact(target, 'uri', params); Then (after the next diff) we'll show a link in Differential and a prominent link in Harbormaster. I didn't actually do the UI stuff in this diff since it's already pretty big. This change moves a lot of code around, too: - Adds PHIDs to artifacts. - It modularizes build artifact types (currently "file", "host" and "URI"). - It formalizes build artifact parameters and construction: - This lets me generate usable documentation about how to create artifacts. - This prevents users from doing dangerous or policy-violating things. - It does some other general modernization. Test Plan: {F715633} {F715634} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8659 Differential Revision: https://secure.phabricator.com/D13900
2015-08-15 16:28:56 +02:00
'HarbormasterFileArtifact' => 'applications/harbormaster/artifact/HarbormasterFileArtifact.php',
Add a "Make an HTTP Request" build step Summary: Ref T1049. This is very minimal, but does what it says. I merged the variable replacement code so Remote + HTTP can share more stuff. Test Plan: Ran "HTTP" and "Remote" build plans. {F79886} {F79887} Reviewers: hach-que, btrahan Reviewed By: hach-que CC: zeeg, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7541
2013-11-09 16:16:12 +01:00
'HarbormasterHTTPRequestBuildStepImplementation' => 'applications/harbormaster/step/HarbormasterHTTPRequestBuildStepImplementation.php',
Add `harbormaster.createartifact` Summary: Ref T8659. In the general case, this eventually allows build processes to do things like: - Upload build results (like a ".app" or ".exe" or other binary). - Pass complex results between build steps (e.g., build step A does something hard and build step B uses it to do something else). Today, we're a long way away from having the infrastructure for that. However, it is useful to let third party build processes (like Jenkins) upload URIs that link back to the external build results. This adds `harbormaster.createartifact` so they can do that. The only useful thing to do with this method today is have your Jenkins build do this: params = array( "uri": "https://jenkins.mycompany.com/build/23923/details/", "name": "View Build Results in Jenkins", "ui.external": true, ); harbormaster.createartifact(target, 'uri', params); Then (after the next diff) we'll show a link in Differential and a prominent link in Harbormaster. I didn't actually do the UI stuff in this diff since it's already pretty big. This change moves a lot of code around, too: - Adds PHIDs to artifacts. - It modularizes build artifact types (currently "file", "host" and "URI"). - It formalizes build artifact parameters and construction: - This lets me generate usable documentation about how to create artifacts. - This prevents users from doing dangerous or policy-violating things. - It does some other general modernization. Test Plan: {F715633} {F715634} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8659 Differential Revision: https://secure.phabricator.com/D13900
2015-08-15 16:28:56 +02:00
'HarbormasterHostArtifact' => 'applications/harbormaster/artifact/HarbormasterHostArtifact.php',
Allow Harbormaster to lease working copies from Drydock Summary: Ref T9252. This is still crude in a few ways but basically works, at least for commits. Test Plan: - Made a build plan with just this build step. - Ran `bin/harbormaster build --plan 10 ...` on a commit. - It actually built a working copy, leased it, took no action, and released the lease. MAGIC~~~ Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14160
2015-09-25 02:29:47 +02:00
'HarbormasterLeaseWorkingCopyBuildStepImplementation' => 'applications/harbormaster/step/HarbormasterLeaseWorkingCopyBuildStepImplementation.php',
Improve lint/unit limit, sort, view all, collapse behaviors Summary: Ref T8096. Various tweaks here: - Sort result lists by importance (even lint -- "errors first" seems better than "alphabetical by file", I think?). - Do sane stuff with display limits. - Add a "view all" view. - Don't show a huge table of passing tests in Differential. - Link to full results. Test Plan: See screenshots. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8096 Differential Revision: https://secure.phabricator.com/D13407
2015-06-23 22:34:25 +02:00
'HarbormasterLintMessagesController' => 'applications/harbormaster/controller/HarbormasterLintMessagesController.php',
Render lint results as Harbormaster lint messages Summary: Ref T8095. Render lint results in a future-ready way. This makes the renderer accept `HarbormasterBuildLintMessage` objects. If we have legacy data instead, it converts it into `HarbormasterBuildLintMessage` objects. Design is a bit rough but will be cleaned up later after T7739. This moves away from "postponed linters", which are obsolete after Harbormaster (and were only ever used by Facebook). Test Plan: {F523429} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13377
2015-06-21 19:11:53 +02:00
'HarbormasterLintPropertyView' => 'applications/harbormaster/view/HarbormasterLintPropertyView.php',
Compress Harbormaster build logs inline Summary: Ref T5822. - After a log is closed, compress it if possible. - Provide `bin/harbormaster archive-logs` to make it easier to change the storage format of logs. Test Plan: - Ran `bin/harbormaster archive-logs` on a bunch of logs, compressing and decompressing them without issues (same hashes, same decompressed size across multiple iterations). - Ran new builds, verified logs were compressed after they closed. Reviewers: chad Reviewed By: chad Maniphest Tasks: T5822 Differential Revision: https://secure.phabricator.com/D15380
2016-03-01 22:53:13 +01:00
'HarbormasterManagementArchiveLogsWorkflow' => 'applications/harbormaster/management/HarbormasterManagementArchiveLogsWorkflow.php',
Add `bin/harbormaster` to make builds easier to debug Summary: Ref T1049. Adds `bin/harbormaster` and `bin/harbormaster build` for applying plans from the console. Since this gets `--trace`, it's much easier to debug what's going on. This doesn't work properly with some of the Drydock steps yet, I need to look at those. I think `setRunAllTasksInProcess` probably obsoletes some of the mechanisms. It might also not work with "Wait for Builds" but I didn't check. Test Plan: Used `bin/harbormaster` to run a bunch of builds. Ran builds from web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7825
2013-12-26 19:40:52 +01:00
'HarbormasterManagementBuildWorkflow' => 'applications/harbormaster/management/HarbormasterManagementBuildWorkflow.php',
Give Buildables a status, populate it, and return it over Conduit Summary: Ref T4809. Currently, buildables have a status field but nothing populates it. Populate it: - When builds change state, update the Buildable state. - Use the new Buildable state on the web UI. - Return the new Buildable state from Conduit. To make it easier to debug/test this: - Provide `bin/harbormaster update Bxxx ...` to force foreground update of a Buildable. Test Plan: - Used `bin/harbormaster update Bxxx --force --trace` to update buildables. - Looked at buidlable list, saw statuses reported properly. - Used Conduit to read statuses. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4809 Differential Revision: https://secure.phabricator.com/D8799
2014-04-18 01:01:16 +02:00
'HarbormasterManagementUpdateWorkflow' => 'applications/harbormaster/management/HarbormasterManagementUpdateWorkflow.php',
Add `bin/harbormaster` to make builds easier to debug Summary: Ref T1049. Adds `bin/harbormaster` and `bin/harbormaster build` for applying plans from the console. Since this gets `--trace`, it's much easier to debug what's going on. This doesn't work properly with some of the Drydock steps yet, I need to look at those. I think `setRunAllTasksInProcess` probably obsoletes some of the mechanisms. It might also not work with "Wait for Builds" but I didn't check. Test Plan: Used `bin/harbormaster` to run a bunch of builds. Ran builds from web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7825
2013-12-26 19:40:52 +01:00
'HarbormasterManagementWorkflow' => 'applications/harbormaster/management/HarbormasterManagementWorkflow.php',
Document how to use `harbormaster.sendmessage` to report lint and unit results Summary: Fixes T7419. This doesn't really do anything, just adds documentation. Test Plan: - Read the documentation: {F688899} - Created a build plan which makes an HTTP request to `example.com` and waits for a result. - Ran that build plan manually. - Called `harbormaster.sendmessage` manually with the example lint/unit values to provide a result. - Saw the results report correctly and the message ("fail") process as expected: {F688902} Reviewers: chad Reviewed By: chad Maniphest Tasks: T7419 Differential Revision: https://secure.phabricator.com/D13789
2015-08-04 22:05:52 +02:00
'HarbormasterMessageType' => 'applications/harbormaster/engine/HarbormasterMessageType.php',
Add a generic object for unit tests Summary: A later diff adds unit tests against edges, but we need real objects to connect with edges. Add some trivial objects to the Harbormaster database to compliment the similar HarbormasterScratchTable. On its own, this does nothing interesting. Test Plan: Built unit tests on this in a followup. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D2937
2012-07-09 19:39:14 +02:00
'HarbormasterObject' => 'applications/harbormaster/storage/HarbormasterObject.php',
Lump Harbormaster build steps into groups Summary: Ref T8089. We have a lot of broken/confusing/prototype build steps that I want to hide from users when we unprototype Harbormaster. The dialog is also just kind of unwieldy. Organize this UI a little better and put all the sketchy junk in a "prototypes" group that you can't see unless prototypes are enabled. This doesn't break anything (the old steps will still work fine), but should reduce user confusion. Test Plan: Old UI: {F691439} New UI (prototypes off): {F691440} New UI (prototypes on): {F691441} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8089 Differential Revision: https://secure.phabricator.com/D13803
2015-08-06 13:19:42 +02:00
'HarbormasterOtherBuildStepGroup' => 'applications/harbormaster/stepgroup/HarbormasterOtherBuildStepGroup.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterPlanController' => 'applications/harbormaster/controller/HarbormasterPlanController.php',
Allow Harbormaster build plans to be disabled Summary: Fixes T4187. Ref T1049. Allows build plans to be enabled or disabled. Test Plan: Enabled and disabled build plans. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4187, T1049 Differential Revision: https://secure.phabricator.com/D7822
2013-12-26 19:40:22 +01:00
'HarbormasterPlanDisableController' => 'applications/harbormaster/controller/HarbormasterPlanDisableController.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterPlanEditController' => 'applications/harbormaster/controller/HarbormasterPlanEditController.php',
'HarbormasterPlanListController' => 'applications/harbormaster/controller/HarbormasterPlanListController.php',
Formalize "manual" buildables in Harbormaster Summary: Ref T1049. Generally, it's useful to separate test/trial/manual runs from production/automatic runs. For example, you don't want to email a bunch of people that the build is broken just because you messed something up when writing a new build plan. You'd rather try it first, then promote it into production once you have some good runs. Similarly, test runs generally should not affect the outside world, etc. Finally, some build steps (like "wait for other buildables") may want to behave differently when run in production/automation than when run in a testing environment (where they should probably continue immediately). So, formalize the distinction between automatic buildables (those created passively by the system in response to events) and manual buildables (those created explicitly by users). Add filtering, and stop the automated parts of the system from interacting with the manual parts (for example, we won't show manual results on revisions). This also moves the "Apply Build Plan" to a third, new home: instead of the sidebar or Buildables, it's now on plans. I think this generally makes more sense given how things have developed. Broadly, this improves isolation of test environments. Test Plan: Created some builds, browsed around, used filters, etc. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7824
2013-12-26 19:40:43 +01:00
'HarbormasterPlanRunController' => 'applications/harbormaster/controller/HarbormasterPlanRunController.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterPlanViewController' => 'applications/harbormaster/controller/HarbormasterPlanViewController.php',
Lump Harbormaster build steps into groups Summary: Ref T8089. We have a lot of broken/confusing/prototype build steps that I want to hide from users when we unprototype Harbormaster. The dialog is also just kind of unwieldy. Organize this UI a little better and put all the sketchy junk in a "prototypes" group that you can't see unless prototypes are enabled. This doesn't break anything (the old steps will still work fine), but should reduce user confusion. Test Plan: Old UI: {F691439} New UI (prototypes off): {F691440} New UI (prototypes on): {F691441} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8089 Differential Revision: https://secure.phabricator.com/D13803
2015-08-06 13:19:42 +02:00
'HarbormasterPrototypeBuildStepGroup' => 'applications/harbormaster/stepgroup/HarbormasterPrototypeBuildStepGroup.php',
Rename concrete Harbormaster step implementations Summary: Ref T1049. For consistency, rename these to "Harbormaster...". Test Plan: Ran migration, ran builds, everything still works fine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8602
2014-03-26 00:09:51 +01:00
'HarbormasterPublishFragmentBuildStepImplementation' => 'applications/harbormaster/step/HarbormasterPublishFragmentBuildStepImplementation.php',
Add "Autoplans" to Harbormaster Summary: Ref T8095. Two general problems: - I want Harbormaster to own all lint and unit test results. - I don't want users to have to configure anything for `arc` to keep working automatically. These are in conflict because generic lint/unit test ownership in Harbormaster requires that build targets exist which we can attach build results to. However, we can't currently create build targets on demand: Harbormaster assumes it is responsible for creating targets, then running code or making third-party service calls to actually run the builds. I considered two broad approaches to let `arc` push results into Harbormaster without requiring administrators to configure some kind of "arc results" build plan: # Add magic target PHIDs like `PHID-MAGIC-this-is-really-arc-unit`. # Add new code to build real targets with real PHIDs. (1) is probably a bit less work to get off the ground, but I think it's worse overall and very likely to create more problems in the long run. I particularly worry that it will lead to a small amount of special casing in a very large number of places, which seems more fragile. (2) is more work upfront but I think does a better job of putting all the special casing in one place that we can, e.g., more reasonably unit test, and letting the rest of the code rarely/never care about this case since it's just dealing with normal plans/steps/targets as far as it can tell. This diff introduces "autoplans", which are source templates for plans/steps. This let us "push" these targets into Harbormaster. Hypthetically, any process "like" arc can use autoplans to upload test/lint/etc results. In practice, probably only `arc` will ever use this, but I think it's still quite a bit cleaner than the alternative despite all the generality. Workflow is basically: - `arc` creates a diff. - `arc` calls `harbormaster.queryautotargets`, passing the diff PHID and saying "I have some lint and unit results I want to stick on this thing". - Harbormaster builds the plan, steps, and targets (if any of them don't already exist), and hands back the target PHIDs so `arc` has a completely standard-looking place to put results. - `arc` uploads the test results to the right targets, as though Harbormaster had asked it to run unit/lint in the first place. (This doesn't actually do any of that yet, just sets things up.) I'll maybe doc turn that ^^^^^^ into a doc for posterity since I think it's hard to guess what an "autotarget" is, but I'm going to grab some lunch first. Test Plan: - Added unit tests to make sure we can build these things properly. - Used `harbormaster.queryautotargets` to build autotargets for a bunch of diffs. - Verified targets come up in "waiting for message" state. - Verified plans and steps are not editable. Reviewers: btrahan Reviewed By: btrahan Subscribers: hach-que, epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13345
2015-06-21 18:04:21 +02:00
'HarbormasterQueryAutotargetsConduitAPIMethod' => 'applications/harbormaster/conduit/HarbormasterQueryAutotargetsConduitAPIMethod.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'HarbormasterQueryBuildablesConduitAPIMethod' => 'applications/harbormaster/conduit/HarbormasterQueryBuildablesConduitAPIMethod.php',
'HarbormasterQueryBuildsConduitAPIMethod' => 'applications/harbormaster/conduit/HarbormasterQueryBuildsConduitAPIMethod.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterRemarkupRule' => 'applications/harbormaster/remarkup/HarbormasterRemarkupRule.php',
Modularize the Harbormaster "Run build plan" Herald action Ref T8726. Modularizes "Run build plan" in Differential and Diffusion.
2015-07-30 21:22:35 +02:00
'HarbormasterRunBuildPlansHeraldAction' => 'applications/harbormaster/herald/HarbormasterRunBuildPlansHeraldAction.php',
Generate expected schemata for Harbormaster Summary: Ref T1191. Nothing too notable here: - Allow a Lisk object to specify that there's no expectation that a table exists. We have one Harbormaster object and one Token object like this. - Removed BuildPlanTransactionComment because it's currently unused. Test Plan: - Saw ~200 fewer warnings; just ~800 left. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10583
2014-10-01 16:40:36 +02:00
'HarbormasterSchemaSpec' => 'applications/harbormaster/storage/HarbormasterSchemaSpec.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HarbormasterScratchTable' => 'applications/harbormaster/storage/HarbormasterScratchTable.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'HarbormasterSendMessageConduitAPIMethod' => 'applications/harbormaster/conduit/HarbormasterSendMessageConduitAPIMethod.php',
Rename concrete Harbormaster step implementations Summary: Ref T1049. For consistency, rename these to "Harbormaster...". Test Plan: Ran migration, ran builds, everything still works fine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8602
2014-03-26 00:09:51 +01:00
'HarbormasterSleepBuildStepImplementation' => 'applications/harbormaster/step/HarbormasterSleepBuildStepImplementation.php',
Implement interface for adding, editing and deleting build steps on plans. Summary: This implements an interface for adding new build steps, editing existing build steps and deleting build steps from build plans. It uses the settings definitions on the build implementation to work out what fields should be displayed on the edit page. Test Plan: See screenshots: {F78529} {F78532} {F78528} {F78531} {F78527} {F78530} Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7500
2013-11-05 22:54:03 +01:00
'HarbormasterStepAddController' => 'applications/harbormaster/controller/HarbormasterStepAddController.php',
'HarbormasterStepDeleteController' => 'applications/harbormaster/controller/HarbormasterStepDeleteController.php',
'HarbormasterStepEditController' => 'applications/harbormaster/controller/HarbormasterStepEditController.php',
Give Harbormaster build steps a "View" page Summary: Fixes T9519. Right now, build steps go straight from the build to the edit screen. This means that there's no way to see their edit history or review details without edit permission. In particular, this makes it a bit harder to catch the Drydock Blueprint authorization warnings from T9519. - Add a standard view screen. - Add a little warning callout to blueprint authorizations. This also does a bit of a touchup on the weird dropshadow element from T9586. Maybe not totally design-approved now but it's less ugly, at least. Test Plan: {F906695} {F906696} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9519 Differential Revision: https://secure.phabricator.com/D14330
2015-10-26 20:38:32 +01:00
'HarbormasterStepViewController' => 'applications/harbormaster/controller/HarbormasterStepViewController.php',
Add "Autoplans" to Harbormaster Summary: Ref T8095. Two general problems: - I want Harbormaster to own all lint and unit test results. - I don't want users to have to configure anything for `arc` to keep working automatically. These are in conflict because generic lint/unit test ownership in Harbormaster requires that build targets exist which we can attach build results to. However, we can't currently create build targets on demand: Harbormaster assumes it is responsible for creating targets, then running code or making third-party service calls to actually run the builds. I considered two broad approaches to let `arc` push results into Harbormaster without requiring administrators to configure some kind of "arc results" build plan: # Add magic target PHIDs like `PHID-MAGIC-this-is-really-arc-unit`. # Add new code to build real targets with real PHIDs. (1) is probably a bit less work to get off the ground, but I think it's worse overall and very likely to create more problems in the long run. I particularly worry that it will lead to a small amount of special casing in a very large number of places, which seems more fragile. (2) is more work upfront but I think does a better job of putting all the special casing in one place that we can, e.g., more reasonably unit test, and letting the rest of the code rarely/never care about this case since it's just dealing with normal plans/steps/targets as far as it can tell. This diff introduces "autoplans", which are source templates for plans/steps. This let us "push" these targets into Harbormaster. Hypthetically, any process "like" arc can use autoplans to upload test/lint/etc results. In practice, probably only `arc` will ever use this, but I think it's still quite a bit cleaner than the alternative despite all the generality. Workflow is basically: - `arc` creates a diff. - `arc` calls `harbormaster.queryautotargets`, passing the diff PHID and saying "I have some lint and unit results I want to stick on this thing". - Harbormaster builds the plan, steps, and targets (if any of them don't already exist), and hands back the target PHIDs so `arc` has a completely standard-looking place to put results. - `arc` uploads the test results to the right targets, as though Harbormaster had asked it to run unit/lint in the first place. (This doesn't actually do any of that yet, just sets things up.) I'll maybe doc turn that ^^^^^^ into a doc for posterity since I think it's hard to guess what an "autotarget" is, but I'm going to grab some lunch first. Test Plan: - Added unit tests to make sure we can build these things properly. - Used `harbormaster.queryautotargets` to build autotargets for a bunch of diffs. - Verified targets come up in "waiting for message" state. - Verified plans and steps are not editable. Reviewers: btrahan Reviewed By: btrahan Subscribers: hach-que, epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13345
2015-06-21 18:04:21 +02:00
'HarbormasterTargetEngine' => 'applications/harbormaster/engine/HarbormasterTargetEngine.php',
Split Harbormaster workers apart so build steps can run in parallel Summary: Ref T1049. Currently, the Harbormaster worker looks like this: foreach (step) { run_step(step); } This means steps can't ever be run in parallel. Instead, split it into two workers. The "Build" worker starts things off, and basically does: update_build(); (We could theoretically do this in the original process because it should never take very long, but since there's a lock and it's a little bit complex it seemed cleaner to separate it.) The "Target" worker runs an individual target (like a command, or an HTTP request, or whatever), then updates the build: run_one_step(step); update_build(); The new `update_build()` mechanism in `HarbormasterBuildEngine` does this, roughly: figure_out_overall_status_of_all_steps(); if (build is done) { done(); } if (build is fail) { fail(); } foreach (step that is ready to run) { queue_target_worker_for_step(step); } So, overall: - The part of the code that updates Builds is completely separated from the part of the code that updates Targets. - Targets can run in parallel. Test Plan: - Ran a bunch of builds via `bin/harbormaster build`. - Ran a bunch of builds via web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7890
2014-01-06 21:32:10 +01:00
'HarbormasterTargetWorker' => 'applications/harbormaster/worker/HarbormasterTargetWorker.php',
Lump Harbormaster build steps into groups Summary: Ref T8089. We have a lot of broken/confusing/prototype build steps that I want to hide from users when we unprototype Harbormaster. The dialog is also just kind of unwieldy. Organize this UI a little better and put all the sketchy junk in a "prototypes" group that you can't see unless prototypes are enabled. This doesn't break anything (the old steps will still work fine), but should reduce user confusion. Test Plan: Old UI: {F691439} New UI (prototypes off): {F691440} New UI (prototypes on): {F691441} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8089 Differential Revision: https://secure.phabricator.com/D13803
2015-08-06 13:19:42 +02:00
'HarbormasterTestBuildStepGroup' => 'applications/harbormaster/stepgroup/HarbormasterTestBuildStepGroup.php',
Improve several exception behaviors for Harbormaster workers Summary: Ref T2015. Several fixes: - `checkForCancellation()` no longer exists, and isn't relevant for resumable stops. Throw it away for now. - Fix an issue where a build could pass even if the final step failed. - `phlog()` exceptions so they show up in `bin/harbormaster` and the daemon logs. - Write an exception log if a step fails. - Add a "throw an exception" step to debug this stuff more easily. Test Plan: - Grepped for `checkForCancellation()`. - Ran a failing build where the final step caused the failure. - Observed `phlog()` in `bin/harbormaster` output. - Observed log in web UI: {F101168} Reviewers: btrahan, hach-que Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7935
2014-01-13 21:21:49 +01:00
'HarbormasterThrowExceptionBuildStep' => 'applications/harbormaster/step/HarbormasterThrowExceptionBuildStep.php',
Render build status on revisions and commits Summary: This uses an event listener to render the status of builds on their buildables. The revision and commit view now renders out the status of each of the builds. Currently the revision controller has the results for the latest diff rendered out. We might want to show the status of previous diffs in the future, but for now I think the latest diff should do fine. There's also a number of bug fixes in this diff, including a particularly nasty one where builds would have a build plan PHID generated for them, which resulted in handle lookups always returning invalid objects. Test Plan: Ran builds against diffs and commits, saw them appear on the revision and commit view controllers. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7544
2013-11-10 00:02:07 +01:00
'HarbormasterUIEventListener' => 'applications/harbormaster/event/HarbormasterUIEventListener.php',
Add `harbormaster.createartifact` Summary: Ref T8659. In the general case, this eventually allows build processes to do things like: - Upload build results (like a ".app" or ".exe" or other binary). - Pass complex results between build steps (e.g., build step A does something hard and build step B uses it to do something else). Today, we're a long way away from having the infrastructure for that. However, it is useful to let third party build processes (like Jenkins) upload URIs that link back to the external build results. This adds `harbormaster.createartifact` so they can do that. The only useful thing to do with this method today is have your Jenkins build do this: params = array( "uri": "https://jenkins.mycompany.com/build/23923/details/", "name": "View Build Results in Jenkins", "ui.external": true, ); harbormaster.createartifact(target, 'uri', params); Then (after the next diff) we'll show a link in Differential and a prominent link in Harbormaster. I didn't actually do the UI stuff in this diff since it's already pretty big. This change moves a lot of code around, too: - Adds PHIDs to artifacts. - It modularizes build artifact types (currently "file", "host" and "URI"). - It formalizes build artifact parameters and construction: - This lets me generate usable documentation about how to create artifacts. - This prevents users from doing dangerous or policy-violating things. - It does some other general modernization. Test Plan: {F715633} {F715634} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8659 Differential Revision: https://secure.phabricator.com/D13900
2015-08-15 16:28:56 +02:00
'HarbormasterURIArtifact' => 'applications/harbormaster/artifact/HarbormasterURIArtifact.php',
Show additional details for failed builds in Harbormaster Summary: Ref T10457. When tests fail, it currently takes several clicks to figure out //why// they failed. In this project, map rebuilds and `liberate` are fairly common failure conditions, but verifying that they were the root issue requires jumping into a build, then scrolling through a log. Instead, display details if they're available. Test Plan: Before: {F1135453} After: {F1135454} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9951, T10457 Differential Revision: https://secure.phabricator.com/D15363
2016-02-29 15:26:01 +01:00
'HarbormasterUnitMessageListController' => 'applications/harbormaster/controller/HarbormasterUnitMessageListController.php',
'HarbormasterUnitMessageViewController' => 'applications/harbormaster/controller/HarbormasterUnitMessageViewController.php',
Render unit results as Harbormaster unit messages Summary: Ref T8095. Same as D13377, but for unit results. This is a bit rough and there's some duplication between this and unit results. I'll likely merge them later, but I think some of it is superficial since these iterations are still a little crude. Test Plan: {F523499} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13378
2015-06-21 19:37:55 +02:00
'HarbormasterUnitPropertyView' => 'applications/harbormaster/view/HarbormasterUnitPropertyView.php',
Begin making Harbormaster unit test results a little easier to read Summary: Ref T10457. These lack color and iconography and are difficult to parse. Make them easier to read. Test Plan: Before: {F1135396} After: {F1135399} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15362
2016-02-29 15:15:13 +01:00
'HarbormasterUnitStatus' => 'applications/harbormaster/constants/HarbormasterUnitStatus.php',
Give unit test results their own table in Differential Summary: Ref T10457. This gives unit test results a more first-class treatment in the Differential UI, and consolidates some rendering code. Test Plan: Before: {F1135536} After: {F1135537} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15365
2016-02-29 18:53:46 +01:00
'HarbormasterUnitSummaryView' => 'applications/harbormaster/view/HarbormasterUnitSummaryView.php',
Rename concrete Harbormaster step implementations Summary: Ref T1049. For consistency, rename these to "Harbormaster...". Test Plan: Ran migration, ran builds, everything still works fine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8602
2014-03-26 00:09:51 +01:00
'HarbormasterUploadArtifactBuildStepImplementation' => 'applications/harbormaster/step/HarbormasterUploadArtifactBuildStepImplementation.php',
'HarbormasterWaitForPreviousBuildStepImplementation' => 'applications/harbormaster/step/HarbormasterWaitForPreviousBuildStepImplementation.php',
Split Harbormaster workers apart so build steps can run in parallel Summary: Ref T1049. Currently, the Harbormaster worker looks like this: foreach (step) { run_step(step); } This means steps can't ever be run in parallel. Instead, split it into two workers. The "Build" worker starts things off, and basically does: update_build(); (We could theoretically do this in the original process because it should never take very long, but since there's a lock and it's a little bit complex it seemed cleaner to separate it.) The "Target" worker runs an individual target (like a command, or an HTTP request, or whatever), then updates the build: run_one_step(step); update_build(); The new `update_build()` mechanism in `HarbormasterBuildEngine` does this, roughly: figure_out_overall_status_of_all_steps(); if (build is done) { done(); } if (build is fail) { fail(); } foreach (step that is ready to run) { queue_target_worker_for_step(step); } So, overall: - The part of the code that updates Builds is completely separated from the part of the code that updates Targets. - Targets can run in parallel. Test Plan: - Ran a bunch of builds via `bin/harbormaster build`. - Ran a bunch of builds via web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7890
2014-01-06 21:32:10 +01:00
'HarbormasterWorker' => 'applications/harbormaster/worker/HarbormasterWorker.php',
Allow Harbormaster to lease working copies from Drydock Summary: Ref T9252. This is still crude in a few ways but basically works, at least for commits. Test Plan: - Made a build plan with just this build step. - Ran `bin/harbormaster build --plan 10 ...` on a commit. - It actually built a working copy, leased it, took no action, and released the lease. MAGIC~~~ Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14160
2015-09-25 02:29:47 +02:00
'HarbormasterWorkingCopyArtifact' => 'applications/harbormaster/artifact/HarbormasterWorkingCopyArtifact.php',
Make Herald action modularization more aggressive Summary: Ref T8726. Herald actions are technically sort-of modular already, but make them more aggressively modular similar to `HeraldField`. I plan to obsolete and replace `HeraldCustomAction`. Test Plan: Saw actions in nice groups; created and ran a "Do Nothing" action. Transcripts are a bit rough for now. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13646
2015-07-17 19:27:38 +02:00
'HeraldAction' => 'applications/herald/action/HeraldAction.php',
'HeraldActionGroup' => 'applications/herald/action/HeraldActionGroup.php',
Rename "HeraldAction" to "HeraldActionRecord" Summary: Ref T8726. I want to modularize actions like fields, but the base class should be "HeraldAction". Eventually, "HeraldCondition" should probably be "HeraldFieldRecord", and then both Action and Condition should just be rolled into Rule, probably, but that can wait and doesn't block anything. Test Plan: Ran migration, poked around UI, used `git grep`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13644
2015-07-23 22:26:40 +02:00
'HeraldActionRecord' => 'applications/herald/storage/HeraldActionRecord.php',
Make Herald adapters provide content types Summary: Ref T2769. Get content types out of hard-coded config and into dynamic adapters. This removes the "MERGE" and "OWNERS" content types, which were vestigal. These needs are likely better addressed through subscriptions/transactions, and are obsolete, and haven't existed for 2+ years and no one has asked for them to be restored. Test Plan: Mostly a bunch of grep. Viewed rule list, rule edit. Edited a revision. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6656
2013-08-02 17:55:13 +02:00
'HeraldAdapter' => 'applications/herald/adapter/HeraldAdapter.php',
Modularize more Herald fields Summary: Ref T8726. Continue making Herald fields more modular than they currently are. Test Plan: - Created a rule using all the affected fields. - Ran the rule. - Saw reasonable object field values. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13495
2015-07-06 22:15:47 +02:00
'HeraldAlwaysField' => 'applications/herald/field/HeraldAlwaysField.php',
'HeraldAnotherRuleField' => 'applications/herald/field/HeraldAnotherRuleField.php',
Modularize Maniphest Herald "Assign Task" action Summary: Ref T8726. No surprises here. Test Plan: - Created rules using this action. - Applied migration. - Verified rules still work. {F659324} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13706
2015-07-24 21:51:30 +02:00
'HeraldApplicationActionGroup' => 'applications/herald/action/HeraldApplicationActionGroup.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldApplyTranscript' => 'applications/herald/storage/transcript/HeraldApplyTranscript.php',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'HeraldBasicFieldGroup' => 'applications/herald/field/HeraldBasicFieldGroup.php',
Modularize all Diffusion commit Herald fields Summary: Ref T8726. Test Plan: Created a giant rule with every commit field: {F594686} Ran the upgrade, got the same rule with new fields: {F594688} Used "Test Console" to run transcripts, saw all the fields populate correctly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13567
2015-07-07 20:53:17 +02:00
'HeraldCommitAdapter' => 'applications/diffusion/herald/HeraldCommitAdapter.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldCondition' => 'applications/herald/storage/HeraldCondition.php',
'HeraldConditionTranscript' => 'applications/herald/storage/transcript/HeraldConditionTranscript.php',
Begin modularizing Herald fields Summary: Ref T8726. This lays groundwork for modularizing Herald fields and modularizes the "Content source" field. This doesn't touch conditions or values yet. Test Plan: Created a rule with a "content source" field, created a new task, saw rule apply. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13488
2015-07-06 22:15:33 +02:00
'HeraldContentSourceField' => 'applications/herald/field/HeraldContentSourceField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldController' => 'applications/herald/controller/HeraldController.php',
'HeraldDAO' => 'applications/herald/storage/HeraldDAO.php',
Modernize all Herald DifferentialDiff fields Summary: Ref T8726. This deals with all the Differential diff fields, same deal as previous changes. Test Plan: - Wrote a rule with every field. - Migrated it. - Saw the same rule working. - Rigged the hell out of transcripts (diffs normally do not generate transcripts, because the only action is "block" and they don't exist yet when Herald runs). - Verified that all fields looked sensible in the transcript. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13590
2015-07-08 21:25:38 +02:00
'HeraldDifferentialAdapter' => 'applications/differential/herald/HeraldDifferentialAdapter.php',
'HeraldDifferentialDiffAdapter' => 'applications/differential/herald/HeraldDifferentialDiffAdapter.php',
Modularize all DifferentialRevision fields Summary: Ref T8726. Make all the DifferentialRevision stuff modular. Test Plan: - Created a rule with all fields. - Ran upgrade. - Saw all fields preserved with new modular versions. - Used test console to run rule with all fields, verified field values as broadly sensible. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13598
2015-07-08 21:25:48 +02:00
'HeraldDifferentialRevisionAdapter' => 'applications/differential/herald/HeraldDifferentialRevisionAdapter.php',
Allow Herald rules to be disabled, instead of deleted Summary: Ref T603. Ref T1279. Further improves transaction and policy support for Herald. - Instead of deleting rules (which wipes out history and can't be undone) allow them to be disabled. - Track disables with transactions. - Gate disables with policy controls. - Show policy and status information in the headers. - Show transaction history on rule detail screens. - Remove the delete controller. - Support disabled queries in the ApplicationSearch. Test Plan: - Enabled and disabled rules. - Searched for enabled/disabled rules. - Verified disabled rules don't activate. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1279, T603 Differential Revision: https://secure.phabricator.com/D7247
2013-10-07 02:10:29 +02:00
'HeraldDisableController' => 'applications/herald/controller/HeraldDisableController.php',
Make Herald action modularization more aggressive Summary: Ref T8726. Herald actions are technically sort-of modular already, but make them more aggressively modular similar to `HeraldField`. I plan to obsolete and replace `HeraldCustomAction`. Test Plan: Saw actions in nice groups; created and ran a "Do Nothing" action. Transcripts are a bit rough for now. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13646
2015-07-17 19:27:38 +02:00
'HeraldDoNothingAction' => 'applications/herald/action/HeraldDoNothingAction.php',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'HeraldEditFieldGroup' => 'applications/herald/field/HeraldEditFieldGroup.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldEffect' => 'applications/herald/engine/HeraldEffect.php',
Begin modularizing Herald field values Summary: Ref T8726. I'm primarily trying to modularize tokenizer values so we don't have to update JS to add a new one. This is ultimately the blocker for "select" custom fields working in Herald. This inches us toward that. I'm //not// modularizing conditions or control types in this round, but hope to end up with hard-coded conditions (which are highly general and very rarely change), hard-coded control types (which are also highly general and very rarely change) and completely modular fields and values (which have mid-to-low generality and change frequently). Test Plan: Used UI to interact with "none", "text", and new-style "select" controls. No actual support for tokenizers yet. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13613
2015-07-16 23:12:00 +02:00
'HeraldEmptyFieldValue' => 'applications/herald/value/HeraldEmptyFieldValue.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldEngine' => 'applications/herald/engine/HeraldEngine.php',
Add Herald support for projects Summary: Ref T10054. Ref T6113. I'm going to remove subscribers from projects to fix the confusion between "watch" and "subscribe". Users who have unusual use cases where they legitimately want to know when a project's description is updated or members change can use Herald to follow it. This is also useful in general and improves consistency, although I don't have too many use cases for it. Test Plan: Wrote a Herald rule, edited a project, saw the rule fire and send me email about the change. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6113, T10054 Differential Revision: https://secure.phabricator.com/D15061
2016-01-20 02:18:17 +01:00
'HeraldExactProjectsField' => 'applications/project/herald/HeraldExactProjectsField.php',
Begin modularizing Herald fields Summary: Ref T8726. This lays groundwork for modularizing Herald fields and modularizes the "Content source" field. This doesn't touch conditions or values yet. Test Plan: Created a rule with a "content source" field, created a new task, saw rule apply. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13488
2015-07-06 22:15:33 +02:00
'HeraldField' => 'applications/herald/field/HeraldField.php',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'HeraldFieldGroup' => 'applications/herald/field/HeraldFieldGroup.php',
Add a trivial test case for HeraldField Summary: Adds a trivial test case to ensure that `HeraldField` subclasses are properly implemented. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13577
2015-07-07 15:05:02 +02:00
'HeraldFieldTestCase' => 'applications/herald/field/__tests__/HeraldFieldTestCase.php',
Begin modularizing Herald field values Summary: Ref T8726. I'm primarily trying to modularize tokenizer values so we don't have to update JS to add a new one. This is ultimately the blocker for "select" custom fields working in Herald. This inches us toward that. I'm //not// modularizing conditions or control types in this round, but hope to end up with hard-coded conditions (which are highly general and very rarely change), hard-coded control types (which are also highly general and very rarely change) and completely modular fields and values (which have mid-to-low generality and change frequently). Test Plan: Used UI to interact with "none", "text", and new-style "select" controls. No actual support for tokenizers yet. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13613
2015-07-16 23:12:00 +02:00
'HeraldFieldValue' => 'applications/herald/value/HeraldFieldValue.php',
Make Herald action modularization more aggressive Summary: Ref T8726. Herald actions are technically sort-of modular already, but make them more aggressively modular similar to `HeraldField`. I plan to obsolete and replace `HeraldCustomAction`. Test Plan: Saw actions in nice groups; created and ran a "Do Nothing" action. Transcripts are a bit rough for now. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13646
2015-07-17 19:27:38 +02:00
'HeraldGroup' => 'applications/herald/group/HeraldGroup.php',
Remove HeraldActionConfig, HeraldFieldConfig Summary: Ref T2769. Move all of this stuff into Adapters and get rid of the hard-coded classes. I cheated in two places. Test Plan: Edited and activated Herald rules. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6688
2013-08-06 20:23:01 +02:00
'HeraldInvalidActionException' => 'applications/herald/engine/exception/HeraldInvalidActionException.php',
'HeraldInvalidConditionException' => 'applications/herald/engine/exception/HeraldInvalidConditionException.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'HeraldManageGlobalRulesCapability' => 'applications/herald/capability/HeraldManageGlobalRulesCapability.php',
Modularize Herald task status/priority fields Summary: Ref T8726. These are a bit involved because they have custom rendering and editor values. Test Plan: Created new rule using these fields, edited tasks to trigger them, viewed transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13500
2015-07-06 22:17:01 +02:00
'HeraldManiphestTaskAdapter' => 'applications/maniphest/herald/HeraldManiphestTaskAdapter.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldNewController' => 'applications/herald/controller/HeraldNewController.php',
Modularize more Herald fields Summary: Ref T8726. Continue making Herald fields more modular than they currently are. Test Plan: - Created a rule using all the affected fields. - Ran the rule. - Saw reasonable object field values. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13495
2015-07-06 22:15:47 +02:00
'HeraldNewObjectField' => 'applications/herald/field/HeraldNewObjectField.php',
Make Herald action modularization more aggressive Summary: Ref T8726. Herald actions are technically sort-of modular already, but make them more aggressively modular similar to `HeraldField`. I plan to obsolete and replace `HeraldCustomAction`. Test Plan: Saw actions in nice groups; created and ran a "Do Nothing" action. Transcripts are a bit rough for now. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13646
2015-07-17 19:27:38 +02:00
'HeraldNotifyActionGroup' => 'applications/herald/action/HeraldNotifyActionGroup.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldObjectTranscript' => 'applications/herald/storage/transcript/HeraldObjectTranscript.php',
Add Herald Adapters to Phame Summary: Adds a basic HeraldAdapter to Phame Blogs and Posts. Test Plan: Make a Herald rule to CC me on new posts or blogs automatically. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14897
2015-12-28 05:19:39 +01:00
'HeraldPhameBlogAdapter' => 'applications/phame/herald/HeraldPhameBlogAdapter.php',
'HeraldPhamePostAdapter' => 'applications/phame/herald/HeraldPhamePostAdapter.php',
Modularize all remaining Pholio Herald fields Summary: Ref T8726. Use modular fields for the Pholio adapter. Test Plan: - Created rule using all the old fields. - Migrated, saw upgrade apply correctly. - Created mock, reviewed transcript. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13513
2015-07-06 22:17:33 +02:00
'HeraldPholioMockAdapter' => 'applications/pholio/herald/HeraldPholioMockAdapter.php',
Add basic Herald support to Ponder Summary: Ref T6919, Just a basic herald adapter (new questions) for Ponder Test Plan: Created a Personal Rule, got subscribed to new question, saw transcript. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T6919 Differential Revision: https://secure.phabricator.com/D13828
2015-08-08 19:22:18 +02:00
'HeraldPonderQuestionAdapter' => 'applications/ponder/herald/HeraldPonderQuestionAdapter.php',
Allow Herald pre-commit rules to act on repository projects Summary: Fixes T4264. Adds: - New "Repository's projects" field to Herald pre-commit rules, so you can write global rules which act based on projects. - Allows pre-ref/pre-content rules to bind to projects, and fire for all repositories in that project, so users with limited power can write rules which apply to many repositories. - The pre-ref and pre-content classes were starting to share a fair amount of code, so I made them both extend an abstract base class. Test Plan: Wrote new pre-ref and pre-content rules bound to projects, then pushed commits into repositories in those projects and not in those projects. The "repository projects" field populated, and the rules fired for repositories in the relevant projects. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4264 Differential Revision: https://secure.phabricator.com/D7883
2014-01-03 21:24:28 +01:00
'HeraldPreCommitAdapter' => 'applications/diffusion/herald/HeraldPreCommitAdapter.php',
Provide basic commit content hooks for Herald Summary: Ref T4195. This doesn't provide any interesting fields yet (content, affected paths, commit message) but fires the hook correctly. Test Plan: Added a blocking hook and saw it fire. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7789
2013-12-18 23:18:45 +01:00
'HeraldPreCommitContentAdapter' => 'applications/diffusion/herald/HeraldPreCommitContentAdapter.php',
Add Herald support for blocking ref changes Summary: Ref T4195. Allows users to write Herald rules which block ref changes. For example, you can write a rule like `alincoln can not create branches`, or `no one can push to the branch "frozen"`. Test Plan: This covers a lot of ground. I created and pushed a bunch of rules, then looked at transcripts, in general. Here are some bits in detail: Here's a hook-based reject message: >>> orbital ~/repos/POEMS $ git push Counting objects: 5, done. Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 274 bytes, done. Total 3 (delta 2), reused 0 (delta 0) remote: +---------------------------------------------------------------+ remote: | * * * PUSH REJECTED BY EVIL DRAGON BUREAUCRATS * * * | remote: +---------------------------------------------------------------+ remote: \ remote: \ ^ /^ remote: \ / \ // \ remote: \ |\___/| / \// .\ remote: \ /V V \__ / // | \ \ *----* remote: / / \/_/ // | \ \ \ | remote: @___@` \/_ // | \ \ \/\ \ remote: 0/0/| \/_ // | \ \ \ \ remote: 0/0/0/0/| \/// | \ \ | | remote: 0/0/0/0/0/_|_ / ( // | \ _\ | / remote: 0/0/0/0/0/0/`/,_ _ _/ ) ; -. | _ _\.-~ / / remote: ,-} _ *-.|.-~-. .~ ~ remote: \ \__/ `/\ / ~-. _ .-~ / remote: \____(Oo) *. } { / remote: ( (--) .----~-.\ \-` .~ remote: //__\\ \ DENIED! ///.----..< \ _ -~ remote: // \\ ///-._ _ _ _ _ _ _{^ - - - - ~ remote: remote: remote: This commit was rejected by Herald pre-commit rule H24. remote: Rule: No Branches Called Blarp remote: Reason: "blarp" is a bad branch name remote: To ssh://dweller@localhost/diffusion/POEMS/ ! [remote rejected] blarp -> blarp (pre-receive hook declined) error: failed to push some refs to 'ssh://dweller@localhost/diffusion/POEMS/' Here's a transcript, showing that all the field values populate sensibly: {F90453} Here's a rule: {F90454} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7782
2013-12-18 00:23:55 +01:00
'HeraldPreCommitRefAdapter' => 'applications/diffusion/herald/HeraldPreCommitRefAdapter.php',
Make Herald action modularization more aggressive Summary: Ref T8726. Herald actions are technically sort-of modular already, but make them more aggressively modular similar to `HeraldField`. I plan to obsolete and replace `HeraldCustomAction`. Test Plan: Saw actions in nice groups; created and ran a "Do Nothing" action. Transcripts are a bit rough for now. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13646
2015-07-17 19:27:38 +02:00
'HeraldPreventActionGroup' => 'applications/herald/action/HeraldPreventActionGroup.php',
Modularize more Herald fields Summary: Ref T8726. Continue making Herald fields more modular than they currently are. Test Plan: - Created a rule using all the affected fields. - Ran the rule. - Saw reasonable object field values. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13495
2015-07-06 22:15:47 +02:00
'HeraldProjectsField' => 'applications/project/herald/HeraldProjectsField.php',
Remove HeraldActionConfig, HeraldFieldConfig Summary: Ref T2769. Move all of this stuff into Adapters and get rid of the hard-coded classes. I cheated in two places. Test Plan: Edited and activated Herald rules. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6688
2013-08-06 20:23:01 +02:00
'HeraldRecursiveConditionsException' => 'applications/herald/engine/exception/HeraldRecursiveConditionsException.php',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'HeraldRelatedFieldGroup' => 'applications/herald/field/HeraldRelatedFieldGroup.php',
Give Herald rules a standard "Hnnn" object name Summary: Allow Herald rules to be referred to with `H123`, etc., like other object types are. Herald rules now have proper PHIDs and an increasingly prominent role in triggering application actions. Although I suspect users will rarely use `H123` in Remarkup to mention rules, this can simplify some of the interfaces which relate objects across systems. Test Plan: Looked at various interfaces and saw `H123` names. Mentioned `H123` in remarkup. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7786
2013-12-18 21:00:18 +01:00
'HeraldRemarkupRule' => 'applications/herald/remarkup/HeraldRemarkupRule.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldRepetitionPolicyConfig' => 'applications/herald/config/HeraldRepetitionPolicyConfig.php',
'HeraldRule' => 'applications/herald/storage/HeraldRule.php',
'HeraldRuleController' => 'applications/herald/controller/HeraldRuleController.php',
Allow Herald rules to be disabled, instead of deleted Summary: Ref T603. Ref T1279. Further improves transaction and policy support for Herald. - Instead of deleting rules (which wipes out history and can't be undone) allow them to be disabled. - Track disables with transactions. - Gate disables with policy controls. - Show policy and status information in the headers. - Show transaction history on rule detail screens. - Remove the delete controller. - Support disabled queries in the ApplicationSearch. Test Plan: - Enabled and disabled rules. - Searched for enabled/disabled rules. - Verified disabled rules don't activate. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1279, T603 Differential Revision: https://secure.phabricator.com/D7247
2013-10-07 02:10:29 +02:00
'HeraldRuleEditor' => 'applications/herald/editor/HeraldRuleEditor.php',
Use ApplicationSearch in Herald Summary: Ref T2769. Ref T2625. Herald is currently a giant mishmash of hard-codes and weird special cases. Move toward modernization and normality. Test Plan: {F52716} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625, T2769 Differential Revision: https://secure.phabricator.com/D6652
2013-08-02 15:53:01 +02:00
'HeraldRuleListController' => 'applications/herald/controller/HeraldRuleListController.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'HeraldRulePHIDType' => 'applications/herald/phid/HeraldRulePHIDType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldRuleQuery' => 'applications/herald/query/HeraldRuleQuery.php',
Use ApplicationSearch in Herald Summary: Ref T2769. Ref T2625. Herald is currently a giant mishmash of hard-codes and weird special cases. Move toward modernization and normality. Test Plan: {F52716} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625, T2769 Differential Revision: https://secure.phabricator.com/D6652
2013-08-02 15:53:01 +02:00
'HeraldRuleSearchEngine' => 'applications/herald/query/HeraldRuleSearchEngine.php',
Drive Herald edits via transactions Summary: This is kinda bad in terms of UI (It just makes a json of the thing and diffs that), but it's a start. Test Plan: edit rule, create rule, add/remove/edit conditions, actions Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15542
2016-03-29 01:02:41 +02:00
'HeraldRuleSerializer' => 'applications/herald/editor/HeraldRuleSerializer.php',
Make execution order of Herald rules explicit Summary: Fixes T6211. This gives Herald rules an explicit execution order, which seems generally good. See some discussion on T6211 and inline. Test Plan: - Added unit test. - Dry ran rules and saw rules appear in the expected order in the transcript. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6211 Differential Revision: https://secure.phabricator.com/D10624
2014-10-02 18:49:32 +02:00
'HeraldRuleTestCase' => 'applications/herald/storage/__tests__/HeraldRuleTestCase.php',
Add ApplicationTransactions to Herald Summary: Ref T2769. I'm planning to keep this pretty simple, but we have this ad-hoc edit log for rules already and some other mess that we can clean up. Test Plan: No effect yet; see future changes. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6654
2013-08-02 17:28:55 +02:00
'HeraldRuleTransaction' => 'applications/herald/storage/HeraldRuleTransaction.php',
'HeraldRuleTransactionComment' => 'applications/herald/storage/HeraldRuleTransactionComment.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldRuleTranscript' => 'applications/herald/storage/transcript/HeraldRuleTranscript.php',
'HeraldRuleTypeConfig' => 'applications/herald/config/HeraldRuleTypeConfig.php',
Add a normal "view" page for Herald rules Summary: Ref T2769. This will house the transaction list and replace the "edit log" stuff. The UI is a little bit rough and can probably share more code with the transaction history, but seems mostly-reasonable. Test Plan: {F53253} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6690
2013-08-06 22:43:45 +02:00
'HeraldRuleViewController' => 'applications/herald/controller/HeraldRuleViewController.php',
Generate expected schemata for Fact, Owners, Herald and Diviner Summary: Ref T1191. Notable: - `HeraldApplyTranscript` is not actually a DAO and has no table (it is serialized into HeraldTranscript). Test Plan: Down to fewer than 300 issues. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10588
2014-10-01 16:53:12 +02:00
'HeraldSchemaSpec' => 'applications/herald/storage/HeraldSchemaSpec.php',
Begin modularizing Herald field values Summary: Ref T8726. I'm primarily trying to modularize tokenizer values so we don't have to update JS to add a new one. This is ultimately the blocker for "select" custom fields working in Herald. This inches us toward that. I'm //not// modularizing conditions or control types in this round, but hope to end up with hard-coded conditions (which are highly general and very rarely change), hard-coded control types (which are also highly general and very rarely change) and completely modular fields and values (which have mid-to-low generality and change frequently). Test Plan: Used UI to interact with "none", "text", and new-style "select" controls. No actual support for tokenizers yet. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13613
2015-07-16 23:12:00 +02:00
'HeraldSelectFieldValue' => 'applications/herald/value/HeraldSelectFieldValue.php',
Modularize more Herald fields Summary: Ref T8726. Continue making Herald fields more modular than they currently are. Test Plan: - Created a rule using all the affected fields. - Ran the rule. - Saw reasonable object field values. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13495
2015-07-06 22:15:47 +02:00
'HeraldSpaceField' => 'applications/spaces/herald/HeraldSpaceField.php',
'HeraldSubscribersField' => 'applications/subscriptions/herald/HeraldSubscribersField.php',
Make Herald action modularization more aggressive Summary: Ref T8726. Herald actions are technically sort-of modular already, but make them more aggressively modular similar to `HeraldField`. I plan to obsolete and replace `HeraldCustomAction`. Test Plan: Saw actions in nice groups; created and ran a "Do Nothing" action. Transcripts are a bit rough for now. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13646
2015-07-17 19:27:38 +02:00
'HeraldSupportActionGroup' => 'applications/herald/action/HeraldSupportActionGroup.php',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'HeraldSupportFieldGroup' => 'applications/herald/field/HeraldSupportFieldGroup.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldTestConsoleController' => 'applications/herald/controller/HeraldTestConsoleController.php',
Begin modularizing Herald field values Summary: Ref T8726. I'm primarily trying to modularize tokenizer values so we don't have to update JS to add a new one. This is ultimately the blocker for "select" custom fields working in Herald. This inches us toward that. I'm //not// modularizing conditions or control types in this round, but hope to end up with hard-coded conditions (which are highly general and very rarely change), hard-coded control types (which are also highly general and very rarely change) and completely modular fields and values (which have mid-to-low generality and change frequently). Test Plan: Used UI to interact with "none", "text", and new-style "select" controls. No actual support for tokenizers yet. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13613
2015-07-16 23:12:00 +02:00
'HeraldTextFieldValue' => 'applications/herald/value/HeraldTextFieldValue.php',
Fully modularize Herald field values Summary: Ref T8726. This gets rid of all the `VALUE_*` constants and lets Fields provide arbitrary typeaheads without upstream/JS changes. Test Plan: Used all tokenizers. Used "Another Herald Rule". Grepped for all removed constants. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13616
2015-07-16 23:12:44 +02:00
'HeraldTokenizerFieldValue' => 'applications/herald/value/HeraldTokenizerFieldValue.php',
Allow Herald rules to be disabled, instead of deleted Summary: Ref T603. Ref T1279. Further improves transaction and policy support for Herald. - Instead of deleting rules (which wipes out history and can't be undone) allow them to be disabled. - Track disables with transactions. - Gate disables with policy controls. - Show policy and status information in the headers. - Show transaction history on rule detail screens. - Remove the delete controller. - Support disabled queries in the ApplicationSearch. Test Plan: - Enabled and disabled rules. - Searched for enabled/disabled rules. - Verified disabled rules don't activate. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1279, T603 Differential Revision: https://secure.phabricator.com/D7247
2013-10-07 02:10:29 +02:00
'HeraldTransactionQuery' => 'applications/herald/query/HeraldTransactionQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldTranscript' => 'applications/herald/storage/transcript/HeraldTranscript.php',
'HeraldTranscriptController' => 'applications/herald/controller/HeraldTranscriptController.php',
Fully modularize DestructionEngine Summary: Ref T9979. Convert all DestructionEngine behaviors to extensions. Test Plan: {F1033244} Destroyed an object, verifying: - Herald transcripts were destroyed; - edges were destroyed; - flags were destroyed; - tokens were destroyed; - transactions were destroyed; - worker tasks were cancelled. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14832
2015-12-20 17:11:59 +01:00
'HeraldTranscriptDestructionEngineExtension' => 'applications/herald/engineextension/HeraldTranscriptDestructionEngineExtension.php',
Modularize the Garbage Collector Summary: The GC is a big block of hard-coded application GCs right now. Among other things, this means third parties can't tap into the infrastructure. Modularize it into `GarbageCollector` classes. This implements only one to prove the new stuff works; I'll followup with the rest in the next diff or few depending on how much mess I run into. Test Plan: Used `bin/phd debug garbage` to run the collector in debug mode, observed reasonable output and behavior. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7970
2014-01-15 19:02:24 +01:00
'HeraldTranscriptGarbageCollector' => 'applications/herald/garbagecollector/HeraldTranscriptGarbageCollector.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldTranscriptListController' => 'applications/herald/controller/HeraldTranscriptListController.php',
Add PHIDType for HeraldTransaction Test Plan: Paste a HLXS phid to the quick-search box, get transaction page. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D15028
2016-01-15 17:40:48 +01:00
'HeraldTranscriptPHIDType' => 'applications/herald/phid/HeraldTranscriptPHIDType.php',
Make Herald transcripts policy-aware Summary: Ref T603. Herald transcripts potentially leak a bunch of content (task text, revision/commit content). Don't let users see them if they can't see the actual objects. This is a little messy but ends up mostly reasonable-ish. Test Plan: - Verified that transcripts for objects I couldn't see no longer appear in the list, and reject access. - Verified that transcripts for objects in applications I can't see reject access, albeit less gracefully. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7221
2013-10-05 00:17:18 +02:00
'HeraldTranscriptQuery' => 'applications/herald/query/HeraldTranscriptQuery.php',
Herald - add application search for transcripts Summary: this diff also makes the "test console" appear with the main search nav *and* updates application search to use the page title as the crumb rather than just search. Fixes T4399. Test Plan: queried for transcript ids - success! queried for TX and MX - success! saved the TX and MX query and it worked again! Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4399 Differential Revision: https://secure.phabricator.com/D8297
2014-02-21 21:51:25 +01:00
'HeraldTranscriptSearchEngine' => 'applications/herald/query/HeraldTranscriptSearchEngine.php',
Truncate object fields in Herald transcripts Summary: A few users have hit cases where Herald transcripts of large commits exceed the MySQL packet limit, because one of the fields in the transcript is an enomrous textual diff. There's no value in saving these huge amounts of data. Transcripts are useful for understanding the action of Herald rules, but can be reconstructed later. Instead of saving all of the data, limit each field to 4KB of data. For strings, we just truncate at 4KB. For arrays, we truncate after 4KB of values. Test Plan: Ran unit tests. Artificially decreased limit and ran transcripts, saw them truncate properly. Reviewers: btrahan Reviewed By: btrahan CC: frgtn, aran Differential Revision: https://secure.phabricator.com/D7783
2013-12-18 20:59:53 +01:00
'HeraldTranscriptTestCase' => 'applications/herald/storage/__tests__/HeraldTranscriptTestCase.php',
Make Herald action modularization more aggressive Summary: Ref T8726. Herald actions are technically sort-of modular already, but make them more aggressively modular similar to `HeraldField`. I plan to obsolete and replace `HeraldCustomAction`. Test Plan: Saw actions in nice groups; created and ran a "Do Nothing" action. Transcripts are a bit rough for now. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13646
2015-07-17 19:27:38 +02:00
'HeraldUtilityActionGroup' => 'applications/herald/action/HeraldUtilityActionGroup.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'Javelin' => 'infrastructure/javelin/Javelin.php',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'JavelinReactorUIExample' => 'applications/uiexample/examples/JavelinReactorUIExample.php',
Add support for placeholders Summary: Support placeholder text for inputs. We currently don't use this because it requires JS and doesn't degrade (no JS means you have zero idea what the input is for if it isn't separately labeled) but there are some cases where intent is obvious from context (for example, the search input in the menu bar, which is fairly obvious on its own and will soon have a magnifying glass icon) and in such cases it's much prettier and saves a bunch of space over an explicit label. Add a behavior so we can add placeholders where they make sense. This implementation is somewhat sanity-checked agianst the two jQuery placeholder implementations I was able to google: https://github.com/danielstocks/jQuery-Placeholder/ https://github.com/mathiasbynens/jquery-placeholder Since we don't currently have any uses cases, I haven't included support for making JS access to the `value` work, for password inputs, or for dynamically altering the placeholder. Test Plan: Played around with the placeholder in the UI example in various browsers and couldn't break it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3103
2012-07-31 01:08:10 +02:00
'JavelinUIExample' => 'applications/uiexample/examples/JavelinUIExample.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'JavelinViewExampleServerView' => 'applications/uiexample/examples/JavelinViewExampleServerView.php',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'JavelinViewUIExample' => 'applications/uiexample/examples/JavelinViewUIExample.php',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadController' => 'applications/legalpad/controller/LegalpadController.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'LegalpadCreateDocumentsCapability' => 'applications/legalpad/capability/LegalpadCreateDocumentsCapability.php',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadDAO' => 'applications/legalpad/storage/LegalpadDAO.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'LegalpadDefaultEditCapability' => 'applications/legalpad/capability/LegalpadDefaultEditCapability.php',
'LegalpadDefaultViewCapability' => 'applications/legalpad/capability/LegalpadDefaultViewCapability.php',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadDocument' => 'applications/legalpad/storage/LegalpadDocument.php',
'LegalpadDocumentBody' => 'applications/legalpad/storage/LegalpadDocumentBody.php',
'LegalpadDocumentCommentController' => 'applications/legalpad/controller/LegalpadDocumentCommentController.php',
Modernize "legalpad" typeahead datasource Summary: Ref T4420. Modernize legalpad. Test Plan: - Used typeahead in Herald rules. - Used typeahead in Policy dialog. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9876
2014-07-11 01:18:48 +02:00
'LegalpadDocumentDatasource' => 'applications/legalpad/typeahead/LegalpadDocumentDatasource.php',
Streamline Legalpad signature workflow Summary: Generally reduces friction, standardizes, and simplifies this workflow. Particularly, this removes "address" and "phone", which I think we can wait for user demand for. For logged-in users, we just always use their primary email. Test Plan: See screenshots. Reviewers: chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9735
2014-06-26 16:16:42 +02:00
'LegalpadDocumentDoneController' => 'applications/legalpad/controller/LegalpadDocumentDoneController.php',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadDocumentEditController' => 'applications/legalpad/controller/LegalpadDocumentEditController.php',
'LegalpadDocumentEditor' => 'applications/legalpad/editor/LegalpadDocumentEditor.php',
'LegalpadDocumentListController' => 'applications/legalpad/controller/LegalpadDocumentListController.php',
Make view/sign page the primary Legalpad page Summary: - Makes the "legal document" page the main page. - Links to the "manage" page. - The "manage" operation now requires CAN_EDIT. - Modernize some crumbs and such. Test Plan: {F170213} Reviewers: chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9733
2014-06-26 03:38:07 +02:00
'LegalpadDocumentManageController' => 'applications/legalpad/controller/LegalpadDocumentManageController.php',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadDocumentQuery' => 'applications/legalpad/query/LegalpadDocumentQuery.php',
Legalpad - remarkup LX to link to LX Summary: standard ish. Fixes T4388. Test Plan: made a comment with L1 and noted L1 linked to L1. Also observed working-ish hovercard. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4388 Differential Revision: https://secure.phabricator.com/D8178
2014-02-10 20:27:08 +01:00
'LegalpadDocumentRemarkupRule' => 'applications/legalpad/remarkup/LegalpadDocumentRemarkupRule.php',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadDocumentSearchEngine' => 'applications/legalpad/query/LegalpadDocumentSearchEngine.php',
Legalpad - add signature page Summary: Fixes T3481. Sort of - this thing be very ugly. Also it assumes that you'll "always" want to sign terms. I was thinking in a future diff that should be optional as well as configurable, though it was unclear to me if either was worth pursuing... Generally very hideous as the three main elements (PHUIDocument, AphrontErrorView, and AphrontForm with an AphrontFormInset) have never really played together before. Test Plan: agreed to some test terms. noted UI displayed nicely. reloaded and noted UI told me I had signed it already. Went to different terms and filled them out wrong and got sensical errors. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3481 Differential Revision: https://secure.phabricator.com/D6399
2013-07-10 20:46:39 +02:00
'LegalpadDocumentSignController' => 'applications/legalpad/controller/LegalpadDocumentSignController.php',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadDocumentSignature' => 'applications/legalpad/storage/LegalpadDocumentSignature.php',
Allow Legalpad document managers to add signature exemptions Summary: Ref T5532. Allow document managers to add exemptions, which act like signatures but are tracked a little differently. The primary use case for us is users who sign a corporate CLA and need a user-level exemption if they don't want to sign an individual CLA. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T5532 Differential Revision: https://secure.phabricator.com/D9795
2014-07-02 13:59:35 +02:00
'LegalpadDocumentSignatureAddController' => 'applications/legalpad/controller/LegalpadDocumentSignatureAddController.php',
Legalpad - add a view signatures page Summary: ...needs to add a LegalpadDocumentSignatureQuery class to get this done, which is also re-deployed everywhere we were issuing raw queries. Ref T3116. Test Plan: viewed some signatures. Verified color and footer icons showed up how I wanted them to. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D7986
2014-01-17 20:40:26 +01:00
'LegalpadDocumentSignatureListController' => 'applications/legalpad/controller/LegalpadDocumentSignatureListController.php',
'LegalpadDocumentSignatureQuery' => 'applications/legalpad/query/LegalpadDocumentSignatureQuery.php',
Use ApplicationSearch to search for Legalpad signatures Summary: Ref T3116. Currently, document signatures are just in a big list that you can't search through. - Make it easier to check if a specific user has signed. - Restrict this UI to users who have edit permission on the document (roughly, you need to be a document manager to see the full signature list). (It's currently possible to generate a Dashboard panel using this query, but it will just throw an exception. I'm going to leave it like that for now, we might reasonably expose some "view signatures across doucments" UI later so someone can quickly check if a user has signed 5 documents or something.) Test Plan: {F171576} Reviewers: chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D9765
2014-06-29 01:36:37 +02:00
'LegalpadDocumentSignatureSearchEngine' => 'applications/legalpad/query/LegalpadDocumentSignatureSearchEngine.php',
Legalpad - make it work for not logged in users Summary: Adds "verified" and "secretKey" to Legalpad document signatures. For logged in users using an email address they own, things are verified right away. Otherwise, the email is sent a verification letter. When the user clicks the link the signature is marked verified. Test Plan: signed the document with a bogus email address not logged in. verified the email that would be sent looked good from command line. followed link and successfully verified bogus email address Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, asherkin Maniphest Tasks: T4283 Differential Revision: https://secure.phabricator.com/D7930
2014-01-15 02:17:18 +01:00
'LegalpadDocumentSignatureVerificationController' => 'applications/legalpad/controller/LegalpadDocumentSignatureVerificationController.php',
Allow Legalpad document managers to add signature exemptions Summary: Ref T5532. Allow document managers to add exemptions, which act like signatures but are tracked a little differently. The primary use case for us is users who sign a corporate CLA and need a user-level exemption if they don't want to sign an individual CLA. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T5532 Differential Revision: https://secure.phabricator.com/D9795
2014-07-02 13:59:35 +02:00
'LegalpadDocumentSignatureViewController' => 'applications/legalpad/controller/LegalpadDocumentSignatureViewController.php',
Expose all application mail receivers Summary: Fixes T7199. This still isn't a shining example of perfect code, but the raw amount of copy/paste is much lower than it used to be. - Reduce code duplication between existing receivers. - Expose receiving objects in help menus where appropriate. - Connect some "TODO" receivers. Test Plan: - Sent mail to every supported object type. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12249
2015-04-01 20:01:21 +02:00
'LegalpadMailReceiver' => 'applications/legalpad/mail/LegalpadMailReceiver.php',
Modernize Legalpad edge types Summary: Modernize Legalpad edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: # Created a Herald rule to require legal signatures on all diffs. # Created a new diff. # Saw the transaction string appear correctly. I wasn't able to check the inverse transaction because there is none. Also, I couldn't see any text on the feed (presumably, transactions authored by Herald do not generate feed items) Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Krenair, chad, epriestley Differential Revision: https://secure.phabricator.com/D11082
2015-01-01 01:15:34 +01:00
'LegalpadObjectNeedsSignatureEdgeType' => 'applications/legalpad/edge/LegalpadObjectNeedsSignatureEdgeType.php',
Legalpad V0.2 - add mail integration Summary: Supports !unsubscribe and commenting on replies. Subscribers get mailed something reasonable. Fixes T3480. Sneaks in /LX/ support. In the near future I want to have that /LX/ be a clean "signature" page sans all the edit actions and other fluff... Will resolve this as part of T3481. Test Plan: used the metamta console to add comments and unsubscribe. added a phlog() inside mail code to verify mail bodies looked okay. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3480 Differential Revision: https://secure.phabricator.com/D6369
2013-07-04 01:37:05 +02:00
'LegalpadReplyHandler' => 'applications/legalpad/mail/LegalpadReplyHandler.php',
Modularize the Legalpad "Require Signature" Herald Action Ref T8726. Modularizes "Require Signatures" for Legalpad.
2015-07-30 21:09:17 +02:00
'LegalpadRequireSignatureHeraldAction' => 'applications/legalpad/herald/LegalpadRequireSignatureHeraldAction.php',
Add expected schemata for Fund, Files, Flags and Legalpad Summary: Ref T1191. Nothing too exciting in these. Test Plan: Saw more blue in UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10521
2014-09-19 14:44:40 +02:00
'LegalpadSchemaSpec' => 'applications/legalpad/storage/LegalpadSchemaSpec.php',
Modernize Legalpad edge types Summary: Modernize Legalpad edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: # Created a Herald rule to require legal signatures on all diffs. # Created a new diff. # Saw the transaction string appear correctly. I wasn't able to check the inverse transaction because there is none. Also, I couldn't see any text on the feed (presumably, transactions authored by Herald do not generate feed items) Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Krenair, chad, epriestley Differential Revision: https://secure.phabricator.com/D11082
2015-01-01 01:15:34 +01:00
'LegalpadSignatureNeededByObjectEdgeType' => 'applications/legalpad/edge/LegalpadSignatureNeededByObjectEdgeType.php',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadTransaction' => 'applications/legalpad/storage/LegalpadTransaction.php',
'LegalpadTransactionComment' => 'applications/legalpad/storage/LegalpadTransactionComment.php',
'LegalpadTransactionQuery' => 'applications/legalpad/query/LegalpadTransactionQuery.php',
'LegalpadTransactionView' => 'applications/legalpad/view/LegalpadTransactionView.php',
Implement a more compact, general database-backed key-value cache Summary: See discussion in D4204. Facebook currently has a 314MB remarkup cache with a 55MB index, which is slow to access. Under the theory that this is an index size/quality problem (the current index is on a potentially-384-byte field, with many keys sharing prefixes), provide a more general index with fancy new features: - It implements PhutilKeyValueCache, so it can be a component in cache stacks and supports TTL. - It has a 12-byte hash-based key. - It automatically compresses large blocks of data (most of what we store is highly-compressible HTML). Test Plan: - Basics: - Loaded /paste/, saw caches generate and save. - Reloaded /paste/, saw the page hit cache. - GC: - Ran GC daemon, saw nothing. - Set maximum lifetime to 1 second, ran GC daemon, saw it collect the entire cache. - Deflate: - Selected row formats from the database, saw a mixture of 'raw' and 'deflate' storage. - Used profiler to verify that 'deflate' is fast (12 calls @ 220us on my paste list). - Ran unit tests Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D4259
2012-12-21 23:17:56 +01:00
'LiskChunkTestCase' => 'infrastructure/storage/lisk/__tests__/LiskChunkTestCase.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'LiskDAO' => 'infrastructure/storage/lisk/LiskDAO.php',
'LiskDAOSet' => 'infrastructure/storage/lisk/LiskDAOSet.php',
Add regression test for LiskDAO::__call() Summary: D3606 Test Plan: Deleted `call()`, ran the test. Reviewers: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3814
2012-10-24 21:47:53 +02:00
'LiskDAOTestCase' => 'infrastructure/storage/lisk/__tests__/LiskDAOTestCase.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'LiskEphemeralObjectException' => 'infrastructure/storage/lisk/LiskEphemeralObjectException.php',
'LiskFixtureTestCase' => 'infrastructure/storage/lisk/__tests__/LiskFixtureTestCase.php',
'LiskIsolationTestCase' => 'infrastructure/storage/lisk/__tests__/LiskIsolationTestCase.php',
'LiskIsolationTestDAO' => 'infrastructure/storage/lisk/__tests__/LiskIsolationTestDAO.php',
'LiskIsolationTestDAOException' => 'infrastructure/storage/lisk/__tests__/LiskIsolationTestDAOException.php',
Add an iterator to make it easier to perform database migrations Summary: See D3006, D3007. Make it easier to do migrations like that without holding all results in memory. Test Plan: Ran this code with an artificially small page size (2): foreach (new LiskMigrationIterator(new DifferentialRevision()) as $rev) { echo "Revision ".$rev->getID()."\n"; } Verified each revision as loaded and processed. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D3008
2012-07-19 05:01:23 +02:00
'LiskMigrationIterator' => 'infrastructure/storage/lisk/LiskMigrationIterator.php',
Add LiskRawMigrationIterator Summary: Ref T2222. I need this to migrate the Differential comment tables, because they are large. We have the similar `LiskMigrationIterator` already, but it won't work here because I intend to destroy the original objects after migrating them. Test Plan: Wrote a script to iterate over the `differential_comment` table, got reasonable output: {P869} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D6264
2013-06-21 21:55:07 +02:00
'LiskRawMigrationIterator' => 'infrastructure/storage/lisk/LiskRawMigrationIterator.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'MacroConduitAPIMethod' => 'applications/macro/conduit/MacroConduitAPIMethod.php',
'MacroCreateMemeConduitAPIMethod' => 'applications/macro/conduit/MacroCreateMemeConduitAPIMethod.php',
'MacroQueryConduitAPIMethod' => 'applications/macro/conduit/MacroQueryConduitAPIMethod.php',
Move Maniphest to modular mail commands Summary: Ref T7199. This fully modularizes mail command handling in Maniphest. I had to add a couple of minor not-totally-solid-feeling tricks to deal with the "create" case, but they feel not-too-bad, and a million times better than what came before. Test Plan: Used all commands with `receive-test`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12240
2015-04-01 17:40:42 +02:00
'ManiphestAssignEmailCommand' => 'applications/maniphest/command/ManiphestAssignEmailCommand.php',
Collapse "Show unassigned tasks" in Maniphest into a parameterized owners typeahead Summary: Ref T4100. Support viewer(), members(), and add a new none(). Test Plan: - Used all new functions. - Batch edited tasks with unassign action. - Saved a query from master, upgrade it to this patch, checkbox migrated cleanly into a "no one" token. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12470
2015-04-19 17:23:56 +02:00
'ManiphestAssigneeDatasource' => 'applications/maniphest/typeahead/ManiphestAssigneeDatasource.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestBatchEditController' => 'applications/maniphest/controller/ManiphestBatchEditController.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'ManiphestBulkEditCapability' => 'applications/maniphest/capability/ManiphestBulkEditCapability.php',
Move Maniphest to modular mail commands Summary: Ref T7199. This fully modularizes mail command handling in Maniphest. I had to add a couple of minor not-totally-solid-feeling tricks to deal with the "create" case, but they feel not-too-bad, and a million times better than what came before. Test Plan: Used all commands with `receive-test`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12240
2015-04-01 17:40:42 +02:00
'ManiphestClaimEmailCommand' => 'applications/maniphest/command/ManiphestClaimEmailCommand.php',
'ManiphestCloseEmailCommand' => 'applications/maniphest/command/ManiphestCloseEmailCommand.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ManiphestConduitAPIMethod' => 'applications/maniphest/conduit/ManiphestConduitAPIMethod.php',
Convert maniphest to use standard fields Summary: Ref T3794. Drop auxiliary field, use standard field. Test Plan: Performed migration, field seemed to survive it intact. Edited and viewed tasks. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3794 Differential Revision: https://secure.phabricator.com/D7036
2013-09-19 20:56:15 +02:00
'ManiphestConfiguredCustomField' => 'applications/maniphest/field/ManiphestConfiguredCustomField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestConstants' => 'applications/maniphest/constants/ManiphestConstants.php',
'ManiphestController' => 'applications/maniphest/controller/ManiphestController.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ManiphestCreateMailReceiver' => 'applications/maniphest/mail/ManiphestCreateMailReceiver.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ManiphestCreateTaskConduitAPIMethod' => 'applications/maniphest/conduit/ManiphestCreateTaskConduitAPIMethod.php',
Make Maniphest custom fields extend PhabricatorCustomField Summary: Ref T418. These implementations share no method names, so we can safely just move Maniphest fields into the `PhabricatorCustomField` hierarchy. Replaces two Maniphest-specific custom field exceptions which nothing catches. Test Plan: Viewed Maniphest, edited/altered custom fields. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D6927
2013-09-11 00:31:48 +02:00
'ManiphestCustomField' => 'applications/maniphest/field/ManiphestCustomField.php',
Provide generalized custom field storage and custom field indexes in Maniphest Summary: Ref T418. Depends on D6992. This adds index and value storage for Maniphest custom fields. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D6995
2013-09-16 23:06:41 +02:00
'ManiphestCustomFieldNumericIndex' => 'applications/maniphest/storage/ManiphestCustomFieldNumericIndex.php',
Bring "fixes x as y" parser forward and use new parsers instead of old ones Summary: Fixes T3872. Ref T1812. Ref T3886. Modernize the "closes x as y" string parser, and use all the new parsers instead of the old ones. Test Plan: Made a commit full of a pile of these trigger strings, then used `scripts/repository/reparse.php --message` to reparse it. Verified that parses came back as expected using a bunch of `var_dump()`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1812, T3872, T3886 Differential Revision: https://secure.phabricator.com/D8263
2014-02-18 00:59:13 +01:00
'ManiphestCustomFieldStatusParser' => 'applications/maniphest/field/parser/ManiphestCustomFieldStatusParser.php',
'ManiphestCustomFieldStatusParserTestCase' => 'applications/maniphest/field/parser/__tests__/ManiphestCustomFieldStatusParserTestCase.php',
Provide generalized custom field storage and custom field indexes in Maniphest Summary: Ref T418. Depends on D6992. This adds index and value storage for Maniphest custom fields. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D6995
2013-09-16 23:06:41 +02:00
'ManiphestCustomFieldStorage' => 'applications/maniphest/storage/ManiphestCustomFieldStorage.php',
'ManiphestCustomFieldStringIndex' => 'applications/maniphest/storage/ManiphestCustomFieldStringIndex.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestDAO' => 'applications/maniphest/storage/ManiphestDAO.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'ManiphestDefaultEditCapability' => 'applications/maniphest/capability/ManiphestDefaultEditCapability.php',
'ManiphestDefaultViewCapability' => 'applications/maniphest/capability/ManiphestDefaultViewCapability.php',
'ManiphestEditAssignCapability' => 'applications/maniphest/capability/ManiphestEditAssignCapability.php',
Rough in EditEngine for Maniphest Summary: Ref T9132. I'm going hold this until after the release cut since it isn't going to land completely smoothly, but I think I can prep it today/tomorrow and hopefully get it close enough to working to put in HEAD on Saturday after the push. This adds the basics: new EditEngine, new EditController, and new `maniphest.edit` API endpoint. I put the new stuff at `editpro/` for now until it works a little better. Some notes on stuff this is dropping/changing/not-working-yet: - Preview for the description. I'd rather solve this by putting a "Preview" button on every Remarkup area if we want to retain it. Particularly, it does not generalize to adding custom remarkup fields in its current form. See also T3967. - Per-field policies are no longer enforced. They were never truly enforced anyway (for example, any user who can edit a task has always been able to edit every field via Conduit or email actions or Herald, where Herald supports things), and only really served as a hint to users. I think we can obsolete this by having installs hide/lock these fields instead. This is a desirable outcome for me, since I don't like retaining these policies and the idea of truly enforcing them properly is worrisome. These were originally added for Uber as an onboarding sort of thing. I'll prepare users for this in greater detail in the documentation. - Couple of minor bugs with ordering / defaults / only-one-owner-allowed in this diff that I'll clean up in future diffs before this stuff lands. - I don't have a concrete plan on "Create Similar Task" / "Clone" yet (do you have thoughts? Is this worth trying to do in every application?). I'll probably just mostly mimic the current behavior. Test Plan: I'll vet this more thoroughly in followups, just banged around some tasks for now and created/edited via the API. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14659
2015-12-03 23:32:40 +01:00
'ManiphestEditConduitAPIMethod' => 'applications/maniphest/conduit/ManiphestEditConduitAPIMethod.php',
'ManiphestEditEngine' => 'applications/maniphest/editor/ManiphestEditEngine.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'ManiphestEditPoliciesCapability' => 'applications/maniphest/capability/ManiphestEditPoliciesCapability.php',
'ManiphestEditPriorityCapability' => 'applications/maniphest/capability/ManiphestEditPriorityCapability.php',
'ManiphestEditProjectsCapability' => 'applications/maniphest/capability/ManiphestEditProjectsCapability.php',
'ManiphestEditStatusCapability' => 'applications/maniphest/capability/ManiphestEditStatusCapability.php',
Move Maniphest to modular mail commands Summary: Ref T7199. This fully modularizes mail command handling in Maniphest. I had to add a couple of minor not-totally-solid-feeling tricks to deal with the "create" case, but they feel not-too-bad, and a million times better than what came before. Test Plan: Used all commands with `receive-test`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12240
2015-04-01 17:40:42 +02:00
'ManiphestEmailCommand' => 'applications/maniphest/command/ManiphestEmailCommand.php',
Implemented support for different export formats. Summary: This adds support for different export formats to Excel via a drop-down on the Export page as per the discussion in D5443. Test Plan: Export some things from Maniphest. Do a simple implementation of ManiphestExcelFormat just for testing and make sure that it appears in the list after you run `arc liberate`. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2575 Differential Revision: https://secure.phabricator.com/D5642 Conflicts: src/applications/maniphest/controller/ManiphestExportController.php
2013-04-11 20:22:06 +02:00
'ManiphestExcelDefaultFormat' => 'applications/maniphest/export/ManiphestExcelDefaultFormat.php',
'ManiphestExcelFormat' => 'applications/maniphest/export/ManiphestExcelFormat.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'ManiphestExcelFormatTestCase' => 'applications/maniphest/export/__tests__/ManiphestExcelFormatTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestExportController' => 'applications/maniphest/controller/ManiphestExportController.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ManiphestGetTaskTransactionsConduitAPIMethod' => 'applications/maniphest/conduit/ManiphestGetTaskTransactionsConduitAPIMethod.php',
Modernize Hovercard implementation Summary: Ref T8980. Move away from events to EngineExtensions. This also simplifies hovercards a bit: - Removes tasks from revision cards. - Removes blockers/blocked from task cards. - Removes "Send Message" from user cards. These mostly felt cluttery to me. Open to arguments to retain them. I think we can make better use of the space, though (e.g., flags, projects + board columns). Test Plan: - Viewed people, task, revision, commit and project hovercards. {F1043256} {F1043257} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8980 Differential Revision: https://secure.phabricator.com/D14878
2015-12-24 20:20:18 +01:00
'ManiphestHovercardEngineExtension' => 'applications/maniphest/engineextension/ManiphestHovercardEngineExtension.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ManiphestInfoConduitAPIMethod' => 'applications/maniphest/conduit/ManiphestInfoConduitAPIMethod.php',
Provide and populate an object name index for Maniphest Summary: See discussion in D6955. This provides a table we can JOIN against to (effectively) "ORDER BY project name", populates it intially, and keeps it up to date as projects are edited. Test Plan: - Ran storage upgrade, verified projects populated into the table. - Edited a project, verified its entry updated. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6957
2013-09-12 22:06:44 +02:00
'ManiphestNameIndex' => 'applications/maniphest/storage/ManiphestNameIndex.php',
Permit users to touch `maniphest.points` Summary: Ref T4427. Seems fine / not egregiously broken. Test Plan: Edited points configuration. Tried to set a bad value. Set a good value. Persued examples and help text. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4427 Differential Revision: https://secure.phabricator.com/D15256
2016-02-12 02:32:44 +01:00
'ManiphestPointsConfigOptionType' => 'applications/maniphest/config/ManiphestPointsConfigOptionType.php',
Validate configuration of `maniphest.priorities` Summary: Fixes T6132. We currently allow invalid configuration here; validate it. Test Plan: Tried to save invalid config (negative priorities, string priorities, etc). Reviewers: chad Reviewed By: chad Maniphest Tasks: T6132 Differential Revision: https://secure.phabricator.com/D14689
2015-12-06 01:35:36 +01:00
'ManiphestPriorityConfigOptionType' => 'applications/maniphest/config/ManiphestPriorityConfigOptionType.php',
Implement the "!priority" and "!status" mail commands Summary: Ref T7199. Adds "!priority" and "!status". Test Plan: - Used `!priority` and `!status` to adjust tasks. - Changed config and provided keywords. {F355976} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12248
2015-04-01 19:09:47 +02:00
'ManiphestPriorityEmailCommand' => 'applications/maniphest/command/ManiphestPriorityEmailCommand.php',
Remove TYPE_SEARCH_DIDUPDATEINDEX event Summary: Ref T9979. This event had one weird callsite and no known third-party callers. It can be done more cleanly as an extension, now. This index is used to allow us to "Group By: Project" in Maniphest without joining into the Projects database. Test Plan: - Ran a query with "Group By: Project" in Maniphest. - Renamed project "Apples" to "Zebras". - Reloaded page. - UI properly moved "Zebras" tasks to the bottom of the list. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14836
2015-12-21 15:55:23 +01:00
'ManiphestProjectNameFulltextEngineExtension' => 'applications/maniphest/engineextension/ManiphestProjectNameFulltextEngineExtension.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ManiphestQueryConduitAPIMethod' => 'applications/maniphest/conduit/ManiphestQueryConduitAPIMethod.php',
'ManiphestQueryStatusesConduitAPIMethod' => 'applications/maniphest/conduit/ManiphestQueryStatusesConduitAPIMethod.php',
Pre-prepare for hovercards Summary: D5120 and followups refactor and generalize object references in Remarkup -- notably, they move remarkup rules from a central location to the implementing applications. Preserve blame by doing moves/renames only first. This change moves application remarkup rules into those applications, and renames the ones D5120 modifies. Test Plan: Typed some preview text into a textarea, got a valid Remarkup render. Reviewers: vrana, chad Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5123
2013-02-26 23:57:41 +01:00
'ManiphestRemarkupRule' => 'applications/maniphest/remarkup/ManiphestRemarkupRule.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ManiphestReplyHandler' => 'applications/maniphest/mail/ManiphestReplyHandler.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestReportController' => 'applications/maniphest/controller/ManiphestReportController.php',
Generate expected schemata for Maniphest Summary: Ref T1191. - Adds support for custom fields. - Adds support for partial indexes (indexes on a prefix of a column). - Drops old auxiliary storage table: this was moved to custom field storage about a year ago. - Drops old project table: this was moved to edges about two months ago. Test Plan: - Viewed web UI, saw fewer issues. - Used `grep` to verify no readers/writers for storage or project table. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10526
2014-09-19 20:46:44 +02:00
'ManiphestSchemaSpec' => 'applications/maniphest/storage/ManiphestSchemaSpec.php',
Add "maniphest.search" Conduit API endpoint Summary: Ref T9964. This is a basic implementation of the new "maniphest.search" endpoint. Test Plan: Clicked the button in the web UI, got meaningful results back. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14760
2015-12-13 11:31:09 +01:00
'ManiphestSearchConduitAPIMethod' => 'applications/maniphest/conduit/ManiphestSearchConduitAPIMethod.php',
Make Maniphest task statuses user configurable Summary: Fixes T1812. Moves the internal configuration into public space and documents it. Test Plan: - Tried to set it to some invalid stuff. - Set it to various valid things. - Browsed around, changed statuses, filtered statuses, viewed statuses, merged duplictes, examined transaction record, created tasks. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1812 Differential Revision: https://secure.phabricator.com/D8585
2014-03-25 22:05:36 +01:00
'ManiphestStatusConfigOptionType' => 'applications/maniphest/config/ManiphestStatusConfigOptionType.php',
Implement the "!priority" and "!status" mail commands Summary: Ref T7199. Adds "!priority" and "!status". Test Plan: - Used `!priority` and `!status` to adjust tasks. - Changed config and provided keywords. {F355976} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12248
2015-04-01 19:09:47 +02:00
'ManiphestStatusEmailCommand' => 'applications/maniphest/command/ManiphestStatusEmailCommand.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestSubpriorityController' => 'applications/maniphest/controller/ManiphestSubpriorityController.php',
'ManiphestTask' => 'applications/maniphest/storage/ManiphestTask.php',
Modularize Maniphest Herald "Assign Task" action Summary: Ref T8726. No surprises here. Test Plan: - Created rules using this action. - Applied migration. - Verified rules still work. {F659324} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13706
2015-07-24 21:51:30 +02:00
'ManiphestTaskAssignHeraldAction' => 'applications/maniphest/herald/ManiphestTaskAssignHeraldAction.php',
'ManiphestTaskAssignOtherHeraldAction' => 'applications/maniphest/herald/ManiphestTaskAssignOtherHeraldAction.php',
'ManiphestTaskAssignSelfHeraldAction' => 'applications/maniphest/herald/ManiphestTaskAssignSelfHeraldAction.php',
Modularize all remaining Maniphest Herald fields Summary: Ref T8726. The only notable bit here is that the "body" / "title" fields (which are currently shared across a bunch of types) are getting split into application variants. Among other things, this will let us label the field "Commit message" for commits, for example. Test Plan: - Created a rule using all four fields. - Applied patch, saw rule break ("unknown field"). - Ran storage upgrade, saw rule fix itself in the migration. - Edited tasks, triggered rule, viewed transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13501
2015-07-06 22:17:14 +02:00
'ManiphestTaskAssigneeHeraldField' => 'applications/maniphest/herald/ManiphestTaskAssigneeHeraldField.php',
'ManiphestTaskAuthorHeraldField' => 'applications/maniphest/herald/ManiphestTaskAuthorHeraldField.php',
Allow different policy rules for different types of objects Summary: Ref T5681. Policy rules can now select objects they can apply to, so a rule like "task author" only shows up where it makes sense (when defining task policies). This will let us define rules like "members of thread" in Conpherence, "subscribers", etc., to make custom policies more flexible. Notes: - Per D13251, we need to do a little work to get the right options for policies like "Maniphest > Default View Policy". This should allow "task" policies. - This implements a "task author" policy as a simple example. - The `willApplyRule()` signature now accepts `$objects` to support bulk-loading things like subscribers. Test Plan: - Defined a task to be "visible to: task author", verified author could see it and other users could not. - `var_dump()`'d willApplyRule() inputs, verified they were correct (exactly the objects which use the rule). - Set `default view policy` to a task-specific policy. - Verified that other policies like "Can Use Bulk Editor" don't have these options. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5681 Differential Revision: https://secure.phabricator.com/D13252
2015-06-14 00:44:03 +02:00
'ManiphestTaskAuthorPolicyRule' => 'applications/maniphest/policyrule/ManiphestTaskAuthorPolicyRule.php',
Implement open() and closed() Maniphest tokenizer status functions, plus cleanup Summary: Ref T4100. - Make it easy to choose all open or closed tasks. - Make "special" tokenizers composable. - Get `viewer()` generating documentation properly. Test Plan: - Ran queries with new tokens. - Browsed new tokens. - Viewed docs on new tokens. - Used plain status tokens. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12530
2015-04-23 15:47:30 +02:00
'ManiphestTaskClosedStatusDatasource' => 'applications/maniphest/typeahead/ManiphestTaskClosedStatusDatasource.php',
Migrate Maniphest task blockers to modern EdgeType classes Summary: Prevents "edited tasks, added: 1; removed: 1" Fixes T6757, using D9839 as an example Test Plan: Added and removed blockers to/from tasks, saw the expected history entries. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T6757 Differential Revision: https://secure.phabricator.com/D11045
2014-12-28 15:10:49 +01:00
'ManiphestTaskDependedOnByTaskEdgeType' => 'applications/maniphest/edge/ManiphestTaskDependedOnByTaskEdgeType.php',
'ManiphestTaskDependsOnTaskEdgeType' => 'applications/maniphest/edge/ManiphestTaskDependsOnTaskEdgeType.php',
Modularize all remaining Maniphest Herald fields Summary: Ref T8726. The only notable bit here is that the "body" / "title" fields (which are currently shared across a bunch of types) are getting split into application variants. Among other things, this will let us label the field "Commit message" for commits, for example. Test Plan: - Created a rule using all four fields. - Applied patch, saw rule break ("unknown field"). - Ran storage upgrade, saw rule fix itself in the migration. - Edited tasks, triggered rule, viewed transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13501
2015-07-06 22:17:14 +02:00
'ManiphestTaskDescriptionHeraldField' => 'applications/maniphest/herald/ManiphestTaskDescriptionHeraldField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestTaskDetailController' => 'applications/maniphest/controller/ManiphestTaskDetailController.php',
Execute Maniphest batch edits in the background with a web UI progress bar Summary: Ref T8637. This does nothing interesting, just has empty scaffolding for a bulk job queue. Basic idea is that when you do something like a batch edit in Maniphest, we: - Create a BulkJob with all the details. - Queue a worker to start the job. - Send you to a progress bar page for the job. In the background: - The "start job" worker creates a ton of Task objects, then queues worker tasks to do the work. In the foreground: - Fancy ajax animates the progress bar and it goes wooosh. In general: - Big jobs actually work. - Jobs get logged. - You can monitor jobs. - Terrible junk like T8637 should be much harder to write and much easier to catch and diagnose. Test Plan: No interesting code/beahavior yet. Clean `storage adjust`. {F526411} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8637 Differential Revision: https://secure.phabricator.com/D13392
2015-06-23 22:36:16 +02:00
'ManiphestTaskEditBulkJobType' => 'applications/maniphest/bulk/ManiphestTaskEditBulkJobType.php',
Drop "-pro" suffix and "editpro" URIs for EditEngine in Maniphest Summary: Ref T9908. Move all the "pro" stuff into the old locations. Test Plan: Created/edited tasks, looked at URIs, saw non-pro ones. Grepped for `editpro`. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9908 Differential Revision: https://secure.phabricator.com/D14717
2015-12-09 01:54:46 +01:00
'ManiphestTaskEditController' => 'applications/maniphest/controller/ManiphestTaskEditController.php',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'ManiphestTaskFulltextEngine' => 'applications/maniphest/search/ManiphestTaskFulltextEngine.php',
Modernize commit/edge transaction when parsing commit messages Summary: Ref T5245. With work elsewhere (notably, D9839) we can remove this TODO and use real transactions. Test Plan: Pushed a `closes Txxx` commit and got a close + transaction. Reviewers: chad, btrahan, joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5245 Differential Revision: https://secure.phabricator.com/D9848
2014-07-18 00:42:06 +02:00
'ManiphestTaskHasCommitEdgeType' => 'applications/maniphest/edge/ManiphestTaskHasCommitEdgeType.php',
Modernize Pholio edges Summary: Modernize Pholio edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Attached a mock to a task, observed the expected comment in the transaction view (both ways). Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11113
2015-01-02 00:11:41 +01:00
'ManiphestTaskHasMockEdgeType' => 'applications/maniphest/edge/ManiphestTaskHasMockEdgeType.php',
Modernize task/revision edges and write inverse transactions Summary: Ref T5245. See some discussion in D9838. When we attach object A to object B, we'd like to write transactions on both sides but only write the actual edges once. To do this, allow edge types to `shouldWriteInverseTransactions()`. When an edge type opts into this, have editors apply the inverse transactions before writing the edge. These inverse transactions don't actually apply effects, they just show up in the transaction log. Test Plan: Attached and detached revisions from tasks, saw transactions appear on both sides of the operation. Reviewers: chad, btrahan, joshuaspence Reviewed By: btrahan, joshuaspence Subscribers: epriestley Maniphest Tasks: T5245 Differential Revision: https://secure.phabricator.com/D9839
2014-07-18 00:41:08 +02:00
'ManiphestTaskHasRevisionEdgeType' => 'applications/maniphest/edge/ManiphestTaskHasRevisionEdgeType.php',
Modularize all remaining Maniphest Herald fields Summary: Ref T8726. The only notable bit here is that the "body" / "title" fields (which are currently shared across a bunch of types) are getting split into application variants. Among other things, this will let us label the field "Commit message" for commits, for example. Test Plan: - Created a rule using all four fields. - Applied patch, saw rule break ("unknown field"). - Ran storage upgrade, saw rule fix itself in the migration. - Edited tasks, triggered rule, viewed transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13501
2015-07-06 22:17:14 +02:00
'ManiphestTaskHeraldField' => 'applications/maniphest/herald/ManiphestTaskHeraldField.php',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'ManiphestTaskHeraldFieldGroup' => 'applications/maniphest/herald/ManiphestTaskHeraldFieldGroup.php',
Rename `ManiphestTaskListControllerPro` to `ManiphestTaskListController` Summary: This marks the first time in history that "Pro" has been removed. Test Plan: `grep` Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6980
2013-09-13 18:50:46 +02:00
'ManiphestTaskListController' => 'applications/maniphest/controller/ManiphestTaskListController.php',
Make "Create Subtask" work properly in EditEngine Summary: Ref T9908. This fixes "Create Subtask" so it works with the new stuff. Mostly straightforward. Test Plan: Created some subtasks. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9908 Differential Revision: https://secure.phabricator.com/D14706
2015-12-08 16:54:01 +01:00
'ManiphestTaskListHTTPParameterType' => 'applications/maniphest/httpparametertype/ManiphestTaskListHTTPParameterType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestTaskListView' => 'applications/maniphest/view/ManiphestTaskListView.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ManiphestTaskMailReceiver' => 'applications/maniphest/mail/ManiphestTaskMailReceiver.php',
Implement open() and closed() Maniphest tokenizer status functions, plus cleanup Summary: Ref T4100. - Make it easy to choose all open or closed tasks. - Make "special" tokenizers composable. - Get `viewer()` generating documentation properly. Test Plan: - Ran queries with new tokens. - Browsed new tokens. - Viewed docs on new tokens. - Used plain status tokens. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12530
2015-04-23 15:47:30 +02:00
'ManiphestTaskOpenStatusDatasource' => 'applications/maniphest/typeahead/ManiphestTaskOpenStatusDatasource.php',
Make "Create Subtask" work properly in EditEngine Summary: Ref T9908. This fixes "Create Subtask" so it works with the new stuff. Mostly straightforward. Test Plan: Created some subtasks. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9908 Differential Revision: https://secure.phabricator.com/D14706
2015-12-08 16:54:01 +01:00
'ManiphestTaskPHIDResolver' => 'applications/maniphest/httpparametertype/ManiphestTaskPHIDResolver.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'ManiphestTaskPHIDType' => 'applications/maniphest/phid/ManiphestTaskPHIDType.php',
Support enabling a formal points field in Maniphest Summary: Ref T4427. - New config option for labels, enabling, etc., but no UI/niceness yet. - When enabled, add a field. - Allow nonnegative values, including fractional values. - EditEngine is nice and Conduit / actions basically just work with a tiny bit of extra support code. Test Plan: - Edited points via "Edit". - Edited points via Conduit. - Edited points via stacked actions. - Tried to set "zebra" points. - Tried to set -1 points. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4427 Differential Revision: https://secure.phabricator.com/D15220
2016-02-09 00:24:52 +01:00
'ManiphestTaskPoints' => 'applications/maniphest/constants/ManiphestTaskPoints.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestTaskPriority' => 'applications/maniphest/constants/ManiphestTaskPriority.php',
Modernize "task priority" datasource Summary: Ref T4420. Test Plan: - Used typeahead in Herald rules. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9877
2014-07-11 01:20:40 +02:00
'ManiphestTaskPriorityDatasource' => 'applications/maniphest/typeahead/ManiphestTaskPriorityDatasource.php',
Add a "Change priority to: ..." Herald action Summary: Ref T7848. This is a companion to "Change status to: ...". (I'm pretty sure the only reason I didn't originally write these was the tokenizer bug in D14682, I just forgot about it). This is basically a copy/paste of the "status" action. Test Plan: - Wrote a rule to change task priorities. - Edited a task. - Saw rule fire properly. - Tokens also stick around correctly. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7848 Differential Revision: https://secure.phabricator.com/D14683
2015-12-05 20:15:29 +01:00
'ManiphestTaskPriorityHeraldAction' => 'applications/maniphest/herald/ManiphestTaskPriorityHeraldAction.php',
Modularize Herald task status/priority fields Summary: Ref T8726. These are a bit involved because they have custom rendering and editor values. Test Plan: Created new rule using these fields, edited tasks to trigger them, viewed transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13500
2015-07-06 22:17:01 +02:00
'ManiphestTaskPriorityHeraldField' => 'applications/maniphest/herald/ManiphestTaskPriorityHeraldField.php',
Move ManiphestTaskQuery into query/ Summary: Move this into a more consistent location. Test Plan: Loaded Maniphest. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6949
2013-09-12 22:02:55 +02:00
'ManiphestTaskQuery' => 'applications/maniphest/query/ManiphestTaskQuery.php',
Move Maniphest list rendering to SearchEngine Summary: Ref T4986. Moves Maniphest over. Nothing tricky here, just a complex block of rendering. Test Plan: Viewed Maniphest list. Created Maniphest panel. Used batch editor, drag-and-drop. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9139
2014-05-16 04:17:38 +02:00
'ManiphestTaskResultListView' => 'applications/maniphest/view/ManiphestTaskResultListView.php',
Introduce ManiphestTaskSearchEngine plus ManiphestTaskListControllerPro Summary: Ref T603. Ref T2625. Cutting this over is tricky because of Maniphest's existing saved queries. Plan here is: - Build out the "pro" controller at `/maniphest/query/`. - Once it's at parity, migrate custom queries. - Nuke the old UI. This provides a minimal implementation with no filter support. Test Plan: Looked at `/maniphest/query/`, saw results technically available. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6933
2013-09-10 19:04:26 +02:00
'ManiphestTaskSearchEngine' => 'applications/maniphest/query/ManiphestTaskSearchEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestTaskStatus' => 'applications/maniphest/constants/ManiphestTaskStatus.php',
T5015, Allow Herald rules for Maniphest to act on task status changes Summary: Fixes T5015, Allow Herald rules for Maniphest to act on task status changes. Test Plan: Create Herald rule for Maniphest tasks to flag a task with status "wontfix". Change status of Maniphest task to "wontfix". Task should be flagged. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5015 Differential Revision: https://secure.phabricator.com/D10842
2014-11-12 21:54:29 +01:00
'ManiphestTaskStatusDatasource' => 'applications/maniphest/typeahead/ManiphestTaskStatusDatasource.php',
Implement open() and closed() Maniphest tokenizer status functions, plus cleanup Summary: Ref T4100. - Make it easy to choose all open or closed tasks. - Make "special" tokenizers composable. - Get `viewer()` generating documentation properly. Test Plan: - Ran queries with new tokens. - Browsed new tokens. - Viewed docs on new tokens. - Used plain status tokens. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12530
2015-04-23 15:47:30 +02:00
'ManiphestTaskStatusFunctionDatasource' => 'applications/maniphest/typeahead/ManiphestTaskStatusFunctionDatasource.php',
Herald support for changing task status Summary: Ref T7848. This patch is incomplete and has the following issues: - Multiple statuses can be entered on the edit rule page (only the first one is used). - Statuses are not rendered correctly when re-editing a rule. Test Plan: Applied to our local phab instance and verified it works with our task workflow. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: joshuaspence, revi, epriestley, jsmith Maniphest Tasks: T7848 Differential Revision: https://secure.phabricator.com/D14359
2015-12-05 19:51:34 +01:00
'ManiphestTaskStatusHeraldAction' => 'applications/maniphest/herald/ManiphestTaskStatusHeraldAction.php',
Modularize Herald task status/priority fields Summary: Ref T8726. These are a bit involved because they have custom rendering and editor values. Test Plan: Created new rule using these fields, edited tasks to trigger them, viewed transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13500
2015-07-06 22:17:01 +02:00
'ManiphestTaskStatusHeraldField' => 'applications/maniphest/herald/ManiphestTaskStatusHeraldField.php',
Add config validation for task status config Summary: Ref T1812. This still doesn't expose configuration to the user, but adds validation for it. Test Plan: Added a pile of unit tests. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1812 Differential Revision: https://secure.phabricator.com/D8584
2014-03-25 22:04:51 +01:00
'ManiphestTaskStatusTestCase' => 'applications/maniphest/constants/__tests__/ManiphestTaskStatusTestCase.php',
Fix literally thousands of drag-to-reorder priority bugs Summary: Fixes T7563. Fixes T5201. Reframe this as two separate operations: - Move before or after a task. - Move to the beginning or end of a priority. Then: - Make all the order queries unambiguous and properly reversible, with an explicit `id` order. - Just reuse `ManiphestTask` to get results in the correct order. - Simplify the actual transaction apply logic. - Detect and recover from cases where tasks have identical or similar subpriorities. Test Plan: - Wrote and executed unit tests. - Dragged and dropped tasks within priorities and between priorities in the main Maniphest view. - Dragged and dropped tasks within priorities in the workboard view, when ordered by priority. - Also poked at the "natural" order, but that shouldn't be affected. Reviewers: btrahan, chad Reviewed By: chad Subscribers: chad, epriestley Maniphest Tasks: T5201, T7563 Differential Revision: https://secure.phabricator.com/D12121
2015-03-21 01:38:25 +01:00
'ManiphestTaskTestCase' => 'applications/maniphest/__tests__/ManiphestTaskTestCase.php',
Modularize all remaining Maniphest Herald fields Summary: Ref T8726. The only notable bit here is that the "body" / "title" fields (which are currently shared across a bunch of types) are getting split into application variants. Among other things, this will let us label the field "Commit message" for commits, for example. Test Plan: - Created a rule using all four fields. - Applied patch, saw rule break ("unknown field"). - Ran storage upgrade, saw rule fix itself in the migration. - Edited tasks, triggered rule, viewed transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13501
2015-07-06 22:17:14 +02:00
'ManiphestTaskTitleHeraldField' => 'applications/maniphest/herald/ManiphestTaskTitleHeraldField.php',
Rename ManiphestTransactionPro -> ManiphestTransaction Summary: Ref T2217. Pro is the new standard. Test Plan: Lots of `grep`, made a pile of Maniphest views/edits. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2217 Differential Revision: https://secure.phabricator.com/D7093
2013-09-24 19:49:06 +02:00
'ManiphestTransaction' => 'applications/maniphest/storage/ManiphestTransaction.php',
Route all ManiphestTransaction reads through a single class Summary: Ref T2217. I'm going to do the fake-double-writes ("double reads"?) thing where we proxy the storage that worked pretty well for auth. That is: - (Some more cleanup diffs next, maybe?) - Move all the data to the new storage, and make `ManiphestTransaction` read and write by wrapping `ManiphestTransactionPro`. - If nothing breaks, it's a straight shot to nuking ManiphestTransaction callsite by callsite. I think Maniphest is way easier than Differential, because there are very few query sites and no inline comments. Test Plan: `grep` to find callsites. Loaded task view, called Conduit. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T2217 Differential Revision: https://secure.phabricator.com/D7067
2013-09-23 23:25:14 +02:00
'ManiphestTransactionComment' => 'applications/maniphest/storage/ManiphestTransactionComment.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestTransactionEditor' => 'applications/maniphest/editor/ManiphestTransactionEditor.php',
Migrate all Maniphest transaction data to new storage Summary: Ref T2217. This is the risky, hard part; everything after this should be smooth sailing. This is //mostly// clean, except: - The old format would opportunistically combine a comment with some other transaction type if it could. We no longer do that, so: - When migrating, "edit" + "comment" transactions need to be split in two. - When editing now, we should no longer combine these transaction types. - These changes are pretty straightforward and low-impact. - This migration promotes "auxiliary field" data to the new CustomField/StandardField format, so that's not a straight migration either. The formats are very similar, though. Broadly, this takes the same attack that the auth migration did: proxy all the code through to the new storage. `ManiphestTransaction` is now just an API on top of `ManiphestTransactionPro`, which is the new storage format. The two formats are very similar, so this was mostly a straight copy from one table to the other. Test Plan: - Without performing the migration, made a bunch of edits and comments on tasks and verified the new code works correctly. - Droped the test data and performed the migration. - Looked at the resulting data for obvious discrepancies. - Looked at a bunch of tasks and their transaction history. - Used Conduit to pull transaction data. - Edited task description and clicked "View Details" on transaction. - Used batch editor. - Made a bunch more edits. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2217 Differential Revision: https://secure.phabricator.com/D7068
2013-09-23 23:25:28 +02:00
'ManiphestTransactionQuery' => 'applications/maniphest/query/ManiphestTransactionQuery.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ManiphestUpdateConduitAPIMethod' => 'applications/maniphest/conduit/ManiphestUpdateConduitAPIMethod.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestView' => 'applications/maniphest/view/ManiphestView.php',
Fully modularize mail commands Summary: Ref T7199. Everyone can have a mail command! You can have a mail command! You can have a mail command! Mail commands for everyone! Test Plan: Used `bin/mail receive-test` to issue commands against files and pastes. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12238
2015-04-01 17:40:00 +02:00
'MetaMTAEmailTransactionCommand' => 'applications/metamta/command/MetaMTAEmailTransactionCommand.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'MetaMTAEmailTransactionCommandTestCase' => 'applications/metamta/command/__tests__/MetaMTAEmailTransactionCommandTestCase.php',
Add a GC for sent and received mail Summary: Ref T4368. We don't currently GC these tables, and the sent mail table is one of the largest on `secure.phabricator.com`. There's no value in retaining this information indefinitely. Instead, retain it for 90 days, which should be plenty of time to debug/diagnose any issues. Test Plan: Ran `phd debug garbage`, saw it clean up a reasonable amount of data from these tables. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4368 Differential Revision: https://secure.phabricator.com/D8127
2014-02-03 19:51:31 +01:00
'MetaMTAMailReceivedGarbageCollector' => 'applications/metamta/garbagecollector/MetaMTAMailReceivedGarbageCollector.php',
'MetaMTAMailSentGarbageCollector' => 'applications/metamta/garbagecollector/MetaMTAMailSentGarbageCollector.php',
Begin improving the soundness of received mail Summary: We/I broke a couple of things here recently (see D5911) and are doing some work here in general (see D5912, etc.). Generally, this code is pretty oldschool and not especially well architected for modern application-oriented Phabricator. It hardcodes a lot of stuff which should be applications' responsibilites. Take the first steps toward making it more solid to reduce the risk here. In particular: - Factor out the "self mail" and "duplicate mail" checks and add unit tests. - Make Message-ID hash handling automatic. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5915
2013-05-14 01:32:19 +02:00
'MetaMTAReceivedMailStatus' => 'applications/metamta/constants/MetaMTAReceivedMailStatus.php',
Skeleton for "Multimeter", a performance sampling application Summary: Ref T6930. This application collects and displays performance samples -- roughly, things Phabricator spent some kind of resource on. It will collect samples on different types of resources and events: - Wall time (queries, service calls, pages) - Bytes In / Bytes Out (requests) - Implicit requests to CSS/JS (static resources) I've started with the simplest case (static resources), since this can be used in an immediate, straghtforward way to improve packaging (look at which individual files have the most requests recently). There's no aggregation yet and a lot of the data isn't collected properly. Future diffs will add more dimension data (controllers, users), more event and resource types (queries, service calls, wall time), and more display options (aggregation, sorting). Test Plan: {F389344} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6930 Differential Revision: https://secure.phabricator.com/D12623
2015-05-01 22:19:43 +02:00
'MultimeterContext' => 'applications/multimeter/storage/MultimeterContext.php',
'MultimeterControl' => 'applications/multimeter/data/MultimeterControl.php',
'MultimeterController' => 'applications/multimeter/controller/MultimeterController.php',
'MultimeterDAO' => 'applications/multimeter/storage/MultimeterDAO.php',
'MultimeterDimension' => 'applications/multimeter/storage/MultimeterDimension.php',
'MultimeterEvent' => 'applications/multimeter/storage/MultimeterEvent.php',
'MultimeterEventGarbageCollector' => 'applications/multimeter/garbagecollector/MultimeterEventGarbageCollector.php',
'MultimeterHost' => 'applications/multimeter/storage/MultimeterHost.php',
'MultimeterLabel' => 'applications/multimeter/storage/MultimeterLabel.php',
'MultimeterSampleController' => 'applications/multimeter/controller/MultimeterSampleController.php',
'MultimeterViewer' => 'applications/multimeter/storage/MultimeterViewer.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'NuanceConduitAPIMethod' => 'applications/nuance/conduit/NuanceConduitAPIMethod.php',
Add a main page to Nuance Summary: Ref T8783. There's nothing at `/nuance/` right now, put something basic there. Test Plan: {F747078} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8783 Differential Revision: https://secure.phabricator.com/D13965
2015-08-23 16:19:35 +02:00
'NuanceConsoleController' => 'applications/nuance/controller/NuanceConsoleController.php',
Add a Nuance content source, and make use of it Summary: Ref T10537. Add a new content source for Nuance. Prepare for better author attribution. Test Plan: {F1194038} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15539
2016-03-28 20:18:39 +02:00
'NuanceContentSource' => 'applications/nuance/contentsource/NuanceContentSource.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceController' => 'applications/nuance/controller/NuanceController.php',
'NuanceDAO' => 'applications/nuance/storage/NuanceDAO.php',
Add Nuance daemons and item types Summary: Ref T10537. This adds an update daemon for pulling item data (e.g., figuring out who the author of a GitHub comment is) and routing items (e.g., sending them to a queue or applying them directly to a task). Also adds `bin/nuance update --item X` for doing this manually for debugging. And adds item types, for specializing item behavior. Previously, sources completely dictated item behavior, but I think we want something a little more flexible. Test Plan: - This still does nothing. - Ran `bin/nuance update --item 15`. - Saw an item route to a default queue. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15441
2016-03-08 22:07:22 +01:00
'NuanceGitHubEventItemType' => 'applications/nuance/item/NuanceGitHubEventItemType.php',
Split the GitHub import cursor into separate repository and issues event importers Summary: Ref T10538. The primary GitHub event activity stream does not report minor events (labels, milestones, etc). GitHub has a second, similar activity stream which does report these events (the "Issues Events API"). Use two separate cursors: one consumes the primary stream; the second consumes the events stream. One possible issue with this is that we may write events in a different order than they occurred, so GitHub shows "comment, label, close" but we show "comment, close, label" or similar. This is probably OK because the secondary API doesn't seem to have any very important events (e.g., it's probably fine if label changes are out-of-order), but we can conceivably put some buffer stage in between the two if it's an issue. Test Plan: {F1164894} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10538 Differential Revision: https://secure.phabricator.com/D15446
2016-03-09 14:35:08 +01:00
'NuanceGitHubImportCursor' => 'applications/nuance/cursor/NuanceGitHubImportCursor.php',
'NuanceGitHubIssuesImportCursor' => 'applications/nuance/cursor/NuanceGitHubIssuesImportCursor.php',
Begin bridging GitHub objects through Doorkeeper Summary: Ref T10538. This sets up a Doorkeeper bridge for GitHub issues, and pulls issues from GitHub to create ExternalObject references. Broadly, does nothing useful. Test Plan: Put a `var_dump()` in there somewhere and saw it probably do something when running `bin/nuance update --item 44`. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10538 Differential Revision: https://secure.phabricator.com/D15447
2016-03-09 15:30:22 +01:00
'NuanceGitHubRawEvent' => 'applications/nuance/github/NuanceGitHubRawEvent.php',
Begin adding test coverage to GitHub Events API parsers Summary: Ref T10538. This is a tiny fraction of the API. GitHub has 25 primary event types; we currently partially parse 3 of them. GitHub has 17 issue event types; we currently partially parse 12. Test Plan: Ran `arc unit`. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10538 Differential Revision: https://secure.phabricator.com/D15448
2016-03-09 16:01:23 +01:00
'NuanceGitHubRawEventTestCase' => 'applications/nuance/github/__tests__/NuanceGitHubRawEventTestCase.php',
Add a Nuance GitHub repository source and basic polling Summary: Ref T10537. Ref T10538. This calls GitHub, sorta? Test Plan: ``` $ ./bin/nuance import --source poem <cursor:events.repository> Polling GitHub Repository API endpoint "/repos/epriestley/poems/events". <cursor:events.repository> This key has 4,988 remaining API request(s), limit resets in 1,871 second(s). <cursor:events.repository> ETag for this request was ""4abdd3d66ad5ca38f5117b094e76f4ba"". array(4) { [0]=> array(7) { ["id"]=> string(10) "3733510485" ... ``` Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537, T10538 Differential Revision: https://secure.phabricator.com/D15439
2016-03-08 16:50:43 +01:00
'NuanceGitHubRepositoryImportCursor' => 'applications/nuance/cursor/NuanceGitHubRepositoryImportCursor.php',
'NuanceGitHubRepositorySourceDefinition' => 'applications/nuance/source/NuanceGitHubRepositorySourceDefinition.php',
Allow Nuances sources to provide import cursors Summary: Ref T10537. Some sources (like the future "GitHub Repository" source) need to poll remotes. - Provide a mechanism for sources to emit import cursors. - Hook them into the trigger daemon so they'll fire periodically. - Provide some storage. This diff does nothing useful or interesting, and is pure infrastructure. Test Plan: - Ran `bin/storage upgrade -f`, no adjustment issues. - Poked around Nuance. - Ran the trigger daemon, verified it didn't crash and checked for Nuance stuff to do. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15435
2016-03-08 14:59:24 +01:00
'NuanceImportCursor' => 'applications/nuance/cursor/NuanceImportCursor.php',
'NuanceImportCursorData' => 'applications/nuance/storage/NuanceImportCursorData.php',
'NuanceImportCursorDataQuery' => 'applications/nuance/query/NuanceImportCursorDataQuery.php',
'NuanceImportCursorPHIDType' => 'applications/nuance/phid/NuanceImportCursorPHIDType.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceItem' => 'applications/nuance/storage/NuanceItem.php',
Allow Nuance item types to provide actions for items Summary: Ref T10537. This allows item types to expose item actions. Eventually these actions might be things like "promote to task", "tweet reply", "ban user forever", etc. For now, provide a simple action which shows a raw item in a dialog. Test Plan: {F1185573} Reviewers: chad Reviewed By: chad Subscribers: Luke081515.2 Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15504
2016-03-22 01:38:22 +01:00
'NuanceItemActionController' => 'applications/nuance/controller/NuanceItemActionController.php',
Add an ItemCommand queue to Nuance Summary: Ref T10537. Generally, when users interact with Nuance items we'll dump a command into a queue and apply it in the background. This avoids race conditions with multiple users interacting with an item, which Nuance is more subject to than other applications because it has an import/external component. The "sync" command doesn't actually do anything yet. Test Plan: {F1186365} Reviewers: chad Reviewed By: chad Subscribers: Luke081515.2 Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15506
2016-03-22 14:51:22 +01:00
'NuanceItemCommand' => 'applications/nuance/storage/NuanceItemCommand.php',
'NuanceItemCommandQuery' => 'applications/nuance/query/NuanceItemCommandQuery.php',
Import raw GitHub event data into Nuance Summary: Ref T10537. Ref T10538. This polls the GitHub events API and creates Nuance items from the raw data. It does nothing useful with them. Test Plan: - Polled GitHub. - Saw some items get created. - X-Poll-Interval seemed to work. - ETag seemed to work. - Recognizing when we hit items we've already seen seemed to work. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537, T10538 Differential Revision: https://secure.phabricator.com/D15440
2016-03-08 17:51:45 +01:00
'NuanceItemController' => 'applications/nuance/controller/NuanceItemController.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceItemEditor' => 'applications/nuance/editor/NuanceItemEditor.php',
Import raw GitHub event data into Nuance Summary: Ref T10537. Ref T10538. This polls the GitHub events API and creates Nuance items from the raw data. It does nothing useful with them. Test Plan: - Polled GitHub. - Saw some items get created. - X-Poll-Interval seemed to work. - ETag seemed to work. - Recognizing when we hit items we've already seen seemed to work. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537, T10538 Differential Revision: https://secure.phabricator.com/D15440
2016-03-08 17:51:45 +01:00
'NuanceItemListController' => 'applications/nuance/controller/NuanceItemListController.php',
Move Nuance Items to two-column views Summary: Ref T10537. Test Plan: {F1164796} {F1164797} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15444
2016-03-09 13:01:17 +01:00
'NuanceItemManageController' => 'applications/nuance/controller/NuanceItemManageController.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'NuanceItemPHIDType' => 'applications/nuance/phid/NuanceItemPHIDType.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceItemQuery' => 'applications/nuance/query/NuanceItemQuery.php',
Import raw GitHub event data into Nuance Summary: Ref T10537. Ref T10538. This polls the GitHub events API and creates Nuance items from the raw data. It does nothing useful with them. Test Plan: - Polled GitHub. - Saw some items get created. - X-Poll-Interval seemed to work. - ETag seemed to work. - Recognizing when we hit items we've already seen seemed to work. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537, T10538 Differential Revision: https://secure.phabricator.com/D15440
2016-03-08 17:51:45 +01:00
'NuanceItemSearchEngine' => 'applications/nuance/query/NuanceItemSearchEngine.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceItemTransaction' => 'applications/nuance/storage/NuanceItemTransaction.php',
'NuanceItemTransactionComment' => 'applications/nuance/storage/NuanceItemTransactionComment.php',
'NuanceItemTransactionQuery' => 'applications/nuance/query/NuanceItemTransactionQuery.php',
Add Nuance daemons and item types Summary: Ref T10537. This adds an update daemon for pulling item data (e.g., figuring out who the author of a GitHub comment is) and routing items (e.g., sending them to a queue or applying them directly to a task). Also adds `bin/nuance update --item X` for doing this manually for debugging. And adds item types, for specializing item behavior. Previously, sources completely dictated item behavior, but I think we want something a little more flexible. Test Plan: - This still does nothing. - Ran `bin/nuance update --item 15`. - Saw an item route to a default queue. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15441
2016-03-08 22:07:22 +01:00
'NuanceItemType' => 'applications/nuance/item/NuanceItemType.php',
'NuanceItemUpdateWorker' => 'applications/nuance/worker/NuanceItemUpdateWorker.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceItemViewController' => 'applications/nuance/controller/NuanceItemViewController.php',
Provide `bin/nuance import` and ngram indexes for sources Summary: Ref T10537. More infrastructure: - Put a `bin/nuance` in place with `bin/nuance import`. This has no useful behavior yet. - Allow sources to be searched by substring. This supports `bin/nuance import --source whatever` so you don't have to dig up PHIDs. Test Plan: - Applied migrations. - Ran `bin/nuance import --source ...` (no meaningful effect, but works fine). - Searched for sources by substring in the UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15436
2016-03-08 15:27:26 +01:00
'NuanceManagementImportWorkflow' => 'applications/nuance/management/NuanceManagementImportWorkflow.php',
Add Nuance daemons and item types Summary: Ref T10537. This adds an update daemon for pulling item data (e.g., figuring out who the author of a GitHub comment is) and routing items (e.g., sending them to a queue or applying them directly to a task). Also adds `bin/nuance update --item X` for doing this manually for debugging. And adds item types, for specializing item behavior. Previously, sources completely dictated item behavior, but I think we want something a little more flexible. Test Plan: - This still does nothing. - Ran `bin/nuance update --item 15`. - Saw an item route to a default queue. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15441
2016-03-08 22:07:22 +01:00
'NuanceManagementUpdateWorkflow' => 'applications/nuance/management/NuanceManagementUpdateWorkflow.php',
Provide `bin/nuance import` and ngram indexes for sources Summary: Ref T10537. More infrastructure: - Put a `bin/nuance` in place with `bin/nuance import`. This has no useful behavior yet. - Allow sources to be searched by substring. This supports `bin/nuance import --source whatever` so you don't have to dig up PHIDs. Test Plan: - Applied migrations. - Ran `bin/nuance import --source ...` (no meaningful effect, but works fine). - Searched for sources by substring in the UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15436
2016-03-08 15:27:26 +01:00
'NuanceManagementWorkflow' => 'applications/nuance/management/NuanceManagementWorkflow.php',
Nuance - federate out the design of NuanceSource via NuanceSourceDefinition Summary: ...and get the basic edit flow "working" for a new NuanceSourceDefinition - the Phabricator Form. ...and fix a dumb bug in the query class so when you redirect to the view page / try to edit an existing NuanceSource you don't fatal. Test Plan: played around with the edit form and it worked! Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7585
2013-11-20 22:41:19 +01:00
'NuancePhabricatorFormSourceDefinition' => 'applications/nuance/source/NuancePhabricatorFormSourceDefinition.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceQuery' => 'applications/nuance/query/NuanceQuery.php',
'NuanceQueue' => 'applications/nuance/storage/NuanceQueue.php',
Use modern SearchEngine construction in Nuance Summary: Ref T10537. Minor cleanup of controllers to be more modern / work better on mobile. Test Plan: Browsed all queue / source pages. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15428
2016-03-08 00:18:55 +01:00
'NuanceQueueController' => 'applications/nuance/controller/NuanceQueueController.php',
Add very basic routing to Nuance Summary: Ref T8783. Sort out some relationships and fields: - Make Items 1:1 with Queues: each item is always in exactly one queue. Minor discussion on T8783. I think this is easier to understand and reason about (and implement!) and can't come up with any real cases where it isn't powerful enough. - Remove "QueueItem", which allowed items to be in multiple queues at once. - Remove "dateNuanced", which is equivalent to "dateCreated" in all cases. Then add really basic routing: - Add "Default Queue" for Sources. New items from the source route into that queue. - (Some day there will be routing rules, but for now the rule is "always route into the default queue".) - Show queue on items. - Show more / more useful edit history and transactions in several UIs. Test Plan: {F749445} {F749446} {F749447} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8783 Differential Revision: https://secure.phabricator.com/D13988
2015-08-24 18:21:56 +02:00
'NuanceQueueDatasource' => 'applications/nuance/typeahead/NuanceQueueDatasource.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceQueueEditController' => 'applications/nuance/controller/NuanceQueueEditController.php',
Move Nuance Queues to EditEngine Summary: Ref T10537. Update queue editing to use EditEngine. Test Plan: - Created a new queue. - Edited an existing queue. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15431
2016-03-08 01:22:39 +01:00
'NuanceQueueEditEngine' => 'applications/nuance/editor/NuanceQueueEditEngine.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceQueueEditor' => 'applications/nuance/editor/NuanceQueueEditor.php',
Add Nuance Queue list/edit/detail views Summary: Ref T8434. Throw these together. Test Plan: Created a new Queue. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8434 Differential Revision: https://secure.phabricator.com/D13163
2015-06-05 19:49:35 +02:00
'NuanceQueueListController' => 'applications/nuance/controller/NuanceQueueListController.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'NuanceQueuePHIDType' => 'applications/nuance/phid/NuanceQueuePHIDType.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceQueueQuery' => 'applications/nuance/query/NuanceQueueQuery.php',
Add Nuance Queue list/edit/detail views Summary: Ref T8434. Throw these together. Test Plan: Created a new Queue. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8434 Differential Revision: https://secure.phabricator.com/D13163
2015-06-05 19:49:35 +02:00
'NuanceQueueSearchEngine' => 'applications/nuance/query/NuanceQueueSearchEngine.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceQueueTransaction' => 'applications/nuance/storage/NuanceQueueTransaction.php',
'NuanceQueueTransactionComment' => 'applications/nuance/storage/NuanceQueueTransactionComment.php',
'NuanceQueueTransactionQuery' => 'applications/nuance/query/NuanceQueueTransactionQuery.php',
'NuanceQueueViewController' => 'applications/nuance/controller/NuanceQueueViewController.php',
Generate expected schemata for MetaMTA, Nuance, MetaData, OAuthServer Summary: Ref T1191. Handful of minor things here (T6150, T6149, T6148, T6147, T6146) but nothing very noteworthy. Test Plan: Viewed web UI, saw fewer errors. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10527
2014-09-24 22:50:00 +02:00
'NuanceSchemaSpec' => 'applications/nuance/storage/NuanceSchemaSpec.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceSource' => 'applications/nuance/storage/NuanceSource.php',
Give Nuance form sources a web UI Summary: Ref T8434. Hard-codes form sources as a complaint form. This form is close to perfect and I'm not actually sure we need to let users customize it at all. Test Plan: {F473587} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8434 Differential Revision: https://secure.phabricator.com/D13166
2015-06-05 20:01:06 +02:00
'NuanceSourceActionController' => 'applications/nuance/controller/NuanceSourceActionController.php',
Use modern SearchEngine construction in Nuance Summary: Ref T10537. Minor cleanup of controllers to be more modern / work better on mobile. Test Plan: Browsed all queue / source pages. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15428
2016-03-08 00:18:55 +01:00
'NuanceSourceController' => 'applications/nuance/controller/NuanceSourceController.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'NuanceSourceDefaultEditCapability' => 'applications/nuance/capability/NuanceSourceDefaultEditCapability.php',
'NuanceSourceDefaultViewCapability' => 'applications/nuance/capability/NuanceSourceDefaultViewCapability.php',
Nuance - federate out the design of NuanceSource via NuanceSourceDefinition Summary: ...and get the basic edit flow "working" for a new NuanceSourceDefinition - the Phabricator Form. ...and fix a dumb bug in the query class so when you redirect to the view page / try to edit an existing NuanceSource you don't fatal. Test Plan: played around with the edit form and it worked! Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7585
2013-11-20 22:41:19 +01:00
'NuanceSourceDefinition' => 'applications/nuance/source/NuanceSourceDefinition.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'NuanceSourceDefinitionTestCase' => 'applications/nuance/source/__tests__/NuanceSourceDefinitionTestCase.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceSourceEditController' => 'applications/nuance/controller/NuanceSourceEditController.php',
Convert Nuance Sources to EditEngine Summary: Ref T10537. Converts sources to EditEngine. Test Plan: - Created a new source. - Edited an existing source. - Submitted a complaint with the complaint form. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15434
2016-03-08 14:09:25 +01:00
'NuanceSourceEditEngine' => 'applications/nuance/editor/NuanceSourceEditEngine.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceSourceEditor' => 'applications/nuance/editor/NuanceSourceEditor.php',
Add a list view for Nuance sources Summary: Ref T8434. Now you can list them. Test Plan: Listed sources. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8434 Differential Revision: https://secure.phabricator.com/D13162
2015-06-05 19:44:18 +02:00
'NuanceSourceListController' => 'applications/nuance/controller/NuanceSourceListController.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'NuanceSourceManageCapability' => 'applications/nuance/capability/NuanceSourceManageCapability.php',
Provide `bin/nuance import` and ngram indexes for sources Summary: Ref T10537. More infrastructure: - Put a `bin/nuance` in place with `bin/nuance import`. This has no useful behavior yet. - Allow sources to be searched by substring. This supports `bin/nuance import --source whatever` so you don't have to dig up PHIDs. Test Plan: - Applied migrations. - Ran `bin/nuance import --source ...` (no meaningful effect, but works fine). - Searched for sources by substring in the UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15436
2016-03-08 15:27:26 +01:00
'NuanceSourceNameNgrams' => 'applications/nuance/storage/NuanceSourceNameNgrams.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'NuanceSourcePHIDType' => 'applications/nuance/phid/NuanceSourcePHIDType.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceSourceQuery' => 'applications/nuance/query/NuanceSourceQuery.php',
Add a list view for Nuance sources Summary: Ref T8434. Now you can list them. Test Plan: Listed sources. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8434 Differential Revision: https://secure.phabricator.com/D13162
2015-06-05 19:44:18 +02:00
'NuanceSourceSearchEngine' => 'applications/nuance/query/NuanceSourceSearchEngine.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceSourceTransaction' => 'applications/nuance/storage/NuanceSourceTransaction.php',
'NuanceSourceTransactionComment' => 'applications/nuance/storage/NuanceSourceTransactionComment.php',
'NuanceSourceTransactionQuery' => 'applications/nuance/query/NuanceSourceTransactionQuery.php',
'NuanceSourceViewController' => 'applications/nuance/controller/NuanceSourceViewController.php',
'NuanceTransaction' => 'applications/nuance/storage/NuanceTransaction.php',
Add Nuance daemons and item types Summary: Ref T10537. This adds an update daemon for pulling item data (e.g., figuring out who the author of a GitHub comment is) and routing items (e.g., sending them to a queue or applying them directly to a task). Also adds `bin/nuance update --item X` for doing this manually for debugging. And adds item types, for specializing item behavior. Previously, sources completely dictated item behavior, but I think we want something a little more flexible. Test Plan: - This still does nothing. - Ran `bin/nuance update --item 15`. - Saw an item route to a default queue. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15441
2016-03-08 22:07:22 +01:00
'NuanceWorker' => 'applications/nuance/worker/NuanceWorker.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'OwnersConduitAPIMethod' => 'applications/owners/conduit/OwnersConduitAPIMethod.php',
Move Owners to EditEngine Summary: Ref T9132. Paste is in fairly good shape so Owners is up next. Reasoning: - One install wants API access for it. - It's a simple application for getting CustomFields working with EditEngine. This only does the EditEngine part, so CustomFields are no longer editable until I make that work. That will be up next, and I'll hold this until that's ready. Test Plan: - Created and edited packages via web UI. - Created and edited package editing forms via web UI. - Created and edited packages via Conduit. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14598
2015-11-29 18:33:36 +01:00
'OwnersEditConduitAPIMethod' => 'applications/owners/conduit/OwnersEditConduitAPIMethod.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'OwnersPackageReplyHandler' => 'applications/owners/mail/OwnersPackageReplyHandler.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'OwnersQueryConduitAPIMethod' => 'applications/owners/conduit/OwnersQueryConduitAPIMethod.php',
Add "owners.search" Conduit API endpoint, with CustomField support Summary: Ref T9964. Adds a new-style "owners.search" endpoint, and an extension for customfields. Puts enough indirection in place to give us nice, consistent "custom.key" user-facing keys instead of "std:custom:owners:na0shf9a8dfdsafl" junk. Test Plan: - Searched Owners via API. - Searched by ID. - Ordered by custom fields. - Reviewed API docs. - Used normal search with ordering. - Viewed custom field values in search results. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14758
2015-12-13 01:25:51 +01:00
'OwnersSearchConduitAPIMethod' => 'applications/owners/conduit/OwnersSearchConduitAPIMethod.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PHIDConduitAPIMethod' => 'applications/phid/conduit/PHIDConduitAPIMethod.php',
'PHIDInfoConduitAPIMethod' => 'applications/phid/conduit/PHIDInfoConduitAPIMethod.php',
'PHIDLookupConduitAPIMethod' => 'applications/phid/conduit/PHIDLookupConduitAPIMethod.php',
'PHIDQueryConduitAPIMethod' => 'applications/phid/conduit/PHIDQueryConduitAPIMethod.php',
PHUIBoxView Summary: Adds a basic div box that takes some styles. Not sure this is the best approach for the spacing, but overall hoping people can spend less time in CSS and just use this class. Test Plan: UIExamples Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin, AnhNhan Differential Revision: https://secure.phabricator.com/D5723
2013-04-18 20:34:02 +02:00
'PHUI' => 'view/phui/PHUI.php',
PHUIActionPanelView Summary: Super duper sized panels for singluar actions. Test Plan: UIExamples, will need more testing in Phacility. {F286098} Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11709
2015-02-08 02:06:28 +01:00
'PHUIActionPanelExample' => 'applications/uiexample/examples/PHUIActionPanelExample.php',
'PHUIActionPanelView' => 'view/phui/PHUIActionPanelView.php',
Make mobile navigation work properly by default in more cases Summary: Fixes T5752. This obsoletes a bunch of old patterns and I'll follow up on those with a big "go do a bunch of mechanical code changes" task. Major goals are: - Don't load named queries multiple times on search pages. - Don't require extra code to get standard navigation right on mobile. - Reduce the amount of boilerplate in ListControllers. - Reduce the amount of boilerplate around navigation/menus in all controllers. Specifically, here's what this does: - The StandardPage is now a smarter/more structured object with `setNavigation()` and `setCrumbs()` methods. More rendering decisions are delayed until the last possible moment. - It uses this to automatically add crumb actions to the application menu. - It uses this to automatically reuse one SearchEngine instead of running queries multiple times. - The new preferred way to build responses is `$this->newPage()` (like `$this->newDialog()`), which has structured methods for adding stuff (`setTitle()`, etc). - SearchEngine exposes a new convenience method so you don't have to do all the controller delegation stuff. - Building menus is generally simpler. Test Plan: - Tested paste list, view, edit, comment, raw controllers for functionality, mobile menu, crumbs, navigation menu. - Edited saved queries. - Tested Differential, Maniphest (no changes). - Verified the paste pages don't run any duplicate NamedQuery queries. Reviewers: chad Reviewed By: chad Maniphest Tasks: T5752 Differential Revision: https://secure.phabricator.com/D14382
2015-11-02 21:06:28 +01:00
'PHUIApplicationMenuView' => 'view/layout/PHUIApplicationMenuView.php',
PHUIBadgeView Summary: Resonable sketchout of a "Badge" UI for Profiles/Projects/Achievements. Test Plan: weee {F602729} Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T7992 Differential Revision: https://secure.phabricator.com/D13615
2015-07-10 00:12:11 +02:00
'PHUIBadgeBoxView' => 'view/phui/PHUIBadgeBoxView.php',
'PHUIBadgeExample' => 'applications/uiexample/examples/PHUIBadgeExample.php',
PHUIBadgeMiniView Summary: Mini teeny little badges. With Timeline integration. Test Plan: Made some, UIExamples. {F603564} {F603565} Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13620
2015-07-10 19:49:28 +02:00
'PHUIBadgeMiniView' => 'view/phui/PHUIBadgeMiniView.php',
PHUIBadgeView Summary: Resonable sketchout of a "Badge" UI for Profiles/Projects/Achievements. Test Plan: weee {F602729} Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T7992 Differential Revision: https://secure.phabricator.com/D13615
2015-07-10 00:12:11 +02:00
'PHUIBadgeView' => 'view/phui/PHUIBadgeView.php',
Basic NUX blank states Summary: Implement in Badges Test Plan: Test with nux=true. {F1033431} Reviewers: epriestley Reviewed By: epriestley Subscribers: johnny-bit, Korvin Differential Revision: https://secure.phabricator.com/D14833
2015-12-21 16:35:45 +01:00
'PHUIBigInfoView' => 'view/phui/PHUIBigInfoView.php',
PHUIBoxView Summary: Adds a basic div box that takes some styles. Not sure this is the best approach for the spacing, but overall hoping people can spend less time in CSS and just use this class. Test Plan: UIExamples Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin, AnhNhan Differential Revision: https://secure.phabricator.com/D5723
2013-04-18 20:34:02 +02:00
'PHUIBoxExample' => 'applications/uiexample/examples/PHUIBoxExample.php',
'PHUIBoxView' => 'view/phui/PHUIBoxView.php',
PHUIButtonBarView Summary: Adds a handy bar full of tiny buttons. Use only when directed. Ref: T4394 Test Plan: View UI Examples. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D8169
2014-02-10 20:11:36 +01:00
'PHUIButtonBarExample' => 'applications/uiexample/examples/PHUIButtonBarExample.php',
'PHUIButtonBarView' => 'view/phui/PHUIButtonBarView.php',
PHUIButtonView class Summary: Rough pass at a PHUIButtonView Class. Keeps phutil_tag intact and adds some image features if you use the class. Test Plan: UIExamples Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6192
2013-06-13 03:23:35 +02:00
'PHUIButtonExample' => 'applications/uiexample/examples/PHUIButtonExample.php',
'PHUIButtonView' => 'view/phui/PHUIButtonView.php',
First stab at day view Summary: Ref T4393, First stab at day view. Test Plan: Open Calendar Advanced Search, select "Day View (beta)", see rough day view of selected day. Reviewers: chad, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T4393 Differential Revision: https://secure.phabricator.com/D12685
2015-05-04 01:57:18 +02:00
'PHUICalendarDayView' => 'view/phui/calendar/PHUICalendarDayView.php',
Calendar upgrades Summary: Does a handful of things to make Calendar significantly more useful - Enabled overlapping events - Profile has a 'week view' of the user - Profile has a 'month view' of the users - Multiple users on a calendar are color coded - Browse view slightly more useful This stops short of implementing the new 'home' view on Calendar, mostly this is a big step though to make that happen next. Test Plan: Make lots of events on diffent users. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T2897, T4375 Differential Revision: https://secure.phabricator.com/D8317
2014-02-24 19:04:23 +01:00
'PHUICalendarListView' => 'view/phui/calendar/PHUICalendarListView.php',
'PHUICalendarMonthView' => 'view/phui/calendar/PHUICalendarMonthView.php',
Revert "Remove PHUICalendarWidgetView" Summary: This reverts commit 8ce8a761efe9995c371727fdfe9b9e5d7d1b4592. Test Plan: N/A Reviewers: chad, #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D12573
2015-04-27 15:42:32 +02:00
'PHUICalendarWidgetView' => 'view/phui/calendar/PHUICalendarWidgetView.php',
Color Palette Summary: Picked a set of standard colors. Based on our current Maniphest color set, but tweaked to the same hue with http://color.hailpixel.com/ Test Plan: Not intended to be end all be all, but a decent first cut. Applied to Maniphest and Tags. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6229
2013-06-19 00:35:14 +02:00
'PHUIColorPalletteExample' => 'applications/uiexample/examples/PHUIColorPalletteExample.php',
Move PhabricatorCrumbs to PHUICrumbs Summary: Ref T7014, laying the groundwork for redesigning crumbs. Test Plan: Tested numberous pages, grep'd locations. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7014 Differential Revision: https://secure.phabricator.com/D11478
2015-01-23 20:35:09 +01:00
'PHUICrumbView' => 'view/phui/PHUICrumbView.php',
'PHUICrumbsView' => 'view/phui/PHUICrumbsView.php',
Introduce "Curtain" views, panels, and extensions Summary: This opens up the new action column to have specialized rendering and behavior. Briefly: - Converted applications (right now, only Paste) render a `CurtainView` to build the column content. - This view uses new extensions to build panels (projects, subscribers, tokens). - The panel extension code and rendering can be changed without breaking old stuff. Minor changes: - Token awards now load their tokens, for consistency/simplicity. - Removed the rest of the "fork of" / "forked from" UI in Paste -- I essentially removed these features a while ago, and no one has complained. Test Plan: UI is a bit rough, but works, and it's going to get changed now anyway: {F1160550} {F1160551} Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15414
2016-03-05 23:45:56 +01:00
'PHUICurtainExtension' => 'view/extension/PHUICurtainExtension.php',
'PHUICurtainPanelView' => 'view/layout/PHUICurtainPanelView.php',
'PHUICurtainView' => 'view/layout/PHUICurtainView.php',
Rename inline comment views to "PHUIDiff" and give them a base class Summary: Ref T2009. These classes are "Differential" now, but are used elsewhere in diff infrastructure (e.g., Diffusion). - Rename them to "PHUIDiff". - Move them to "src/infrastructure/". - Give them a base class. Test Plan: Interacted with inlines in unified and side-by-side views. Reviewers: btrahan Subscribers: epriestley Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D11996
2015-03-06 14:11:29 +01:00
'PHUIDiffInlineCommentDetailView' => 'infrastructure/diff/view/PHUIDiffInlineCommentDetailView.php',
'PHUIDiffInlineCommentEditView' => 'infrastructure/diff/view/PHUIDiffInlineCommentEditView.php',
Begin separating inline comment scaffolding from other renderers Summary: Ref T2009. Inline comments have "scaffolding", which is basically some empty table cells/rows around them to get the layout correct. The scaffolding depends on the renderer, since the cells are different for side-by-side vs unified diffs. This is currently duplicated all over the place: - Edit view has 1up/2up. - Detail view has 1up/2up. - 1up renderer has 1up. - 2up renderer has four separate copies of the 2up logic. These all have subtle differences, which are mostly bugs. Start making the scaffolding more composable so we can get rid of that mess. Test Plan: Added, edited, and removed inline comments on unified and side-by-side diffs. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D11997
2015-03-06 14:44:36 +01:00
'PHUIDiffInlineCommentRowScaffold' => 'infrastructure/diff/view/PHUIDiffInlineCommentRowScaffold.php',
'PHUIDiffInlineCommentTableScaffold' => 'infrastructure/diff/view/PHUIDiffInlineCommentTableScaffold.php',
Reduce code duplication for inline "Undo" Summary: Ref T2009. This is another almost-identical copy of the row scaffolding, which has the same 1up/2up bugs as the 8 other copies of this code. Turn the "undo" element into an InlineCommentView so we can scaffold it. Then, scaffold it with the same code as everything else. Test Plan: Hit "Undo", swapped from 1up to 2up, hit "undo" again, swapped back, tried left/right, everything rendered with proper scaffolding. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D12019
2015-03-08 23:27:16 +01:00
'PHUIDiffInlineCommentUndoView' => 'infrastructure/diff/view/PHUIDiffInlineCommentUndoView.php',
Rename inline comment views to "PHUIDiff" and give them a base class Summary: Ref T2009. These classes are "Differential" now, but are used elsewhere in diff infrastructure (e.g., Diffusion). - Rename them to "PHUIDiff". - Move them to "src/infrastructure/". - Give them a base class. Test Plan: Interacted with inlines in unified and side-by-side views. Reviewers: btrahan Subscribers: epriestley Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D11996
2015-03-06 14:11:29 +01:00
'PHUIDiffInlineCommentView' => 'infrastructure/diff/view/PHUIDiffInlineCommentView.php',
Begin separating inline comment scaffolding from other renderers Summary: Ref T2009. Inline comments have "scaffolding", which is basically some empty table cells/rows around them to get the layout correct. The scaffolding depends on the renderer, since the cells are different for side-by-side vs unified diffs. This is currently duplicated all over the place: - Edit view has 1up/2up. - Detail view has 1up/2up. - 1up renderer has 1up. - 2up renderer has four separate copies of the 2up logic. These all have subtle differences, which are mostly bugs. Start making the scaffolding more composable so we can get rid of that mess. Test Plan: Added, edited, and removed inline comments on unified and side-by-side diffs. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D11997
2015-03-06 14:44:36 +01:00
'PHUIDiffOneUpInlineCommentRowScaffold' => 'infrastructure/diff/view/PHUIDiffOneUpInlineCommentRowScaffold.php',
Allow inline comments to be individually hidden Summary: Ref T7447. Implements per-viewer comment hiding. Once a comment is obsolete or uninteresting, you can hide it completely. This is sticky per-user. My hope is that this will strike a better balance between concerns than some of the other approaches (conservative porting, summarization, hide-all). Specifically, this adds a new action here: {F435621} Clicking it completely collapses the comment into a small icon on the previous line, and saves the comment state as hidden for you: {F435626} You can click the icon to reveal all hidden comments below the line. Test Plan: - Hid comments. - Showed comments. - Created, edited, deleted and submitted comments. - Used Diffusion comments (hiding is not implemented there yet, but I'd plan to bring it there eventually if it works out in Differential). Reviewers: btrahan, chad Reviewed By: btrahan Subscribers: jparise, yelirekim, epriestley Maniphest Tasks: T7447 Differential Revision: https://secure.phabricator.com/D13009
2015-05-27 19:28:38 +02:00
'PHUIDiffRevealIconView' => 'infrastructure/diff/view/PHUIDiffRevealIconView.php',
Convert DifferentialRevision view to new PHUIDiffTableOfContentsListView Summary: Ref T2183. Introduces a new View which can (in theory) unify the Revision, Diff and Commit table of contents views. This has the same behavior as before, but accepts slightly more general primitives and parameters and has somewhat cleaner code. I've made one intentinoal behavior change: removing the "Open All in Editor" button. I suspect this is essentially unused, and is a pain to keep around. We can look at restoring it if anyone notices. Test Plan: Looked at a bunch of revisions, no changes from before. Reviewers: chad Reviewed By: chad Maniphest Tasks: T2183 Differential Revision: https://secure.phabricator.com/D13908
2015-08-15 20:43:12 +02:00
'PHUIDiffTableOfContentsItemView' => 'infrastructure/diff/view/PHUIDiffTableOfContentsItemView.php',
'PHUIDiffTableOfContentsListView' => 'infrastructure/diff/view/PHUIDiffTableOfContentsListView.php',
Begin separating inline comment scaffolding from other renderers Summary: Ref T2009. Inline comments have "scaffolding", which is basically some empty table cells/rows around them to get the layout correct. The scaffolding depends on the renderer, since the cells are different for side-by-side vs unified diffs. This is currently duplicated all over the place: - Edit view has 1up/2up. - Detail view has 1up/2up. - 1up renderer has 1up. - 2up renderer has four separate copies of the 2up logic. These all have subtle differences, which are mostly bugs. Start making the scaffolding more composable so we can get rid of that mess. Test Plan: Added, edited, and removed inline comments on unified and side-by-side diffs. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D11997
2015-03-06 14:44:36 +01:00
'PHUIDiffTwoUpInlineCommentRowScaffold' => 'infrastructure/diff/view/PHUIDiffTwoUpInlineCommentRowScaffold.php',
PHUIList, PHUIDocument updates Summary: This diff covers a bit of ground. - PHUIDocumentExample has been added - PHUIDocument has been extended with new features - PhabricatorMenuView is now PHUIListView - PhabricatorMenuItemView is now PHUIItemListView Overall - I think I've gotten all the edges covered here. There is some derpi-ness that we can talk about, comments in the code. Responsive design is missing from the new features on PHUIDocument, will follow up later. Test Plan: Tested mobile and desktop menus, old phriction layout, new document views, new lists, and object lists. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6130
2013-06-05 17:41:43 +02:00
'PHUIDocumentExample' => 'applications/uiexample/examples/PHUIDocumentExample.php',
Update PhameBlogView UI Summary: Creates a new PhameBlogView which is more of a blog landing page with the latest posts. Management has moved to PhameManageController with a new timeline. Test Plan: Edit Blog, Publish, Subscribe, view posts. {F1008400} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9360 Differential Revision: https://secure.phabricator.com/D14608
2015-11-30 17:47:46 +01:00
'PHUIDocumentSummaryView' => 'view/phui/PHUIDocumentSummaryView.php',
Separate Phriction style into PHUIDocumentView Summary: Ref T988. Fixes T3150. I want to use this element in Diviner, so separate it from Phriction. This makes no changes to the actual display except for fixing {T3150} by adding `overflow: hidden;`. Test Plan: Viewed Phriction documents in mobile and desktop views. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T3150 Differential Revision: https://secure.phabricator.com/D6101
2013-06-01 00:03:59 +02:00
'PHUIDocumentView' => 'view/phui/PHUIDocumentView.php',
Redesign Diviner Summary: This implements `PHUIDocumentViewPro` which should move to be the base for all documents (Phame, Phriction, Legalpad, Diviner). Overall this feels really good to me, but I'd like to roll it out into Diviner specifically first to work through the issues and then move into other apps and drop `PHUIDocumentView` once everything is converted. Some features are: - White Background, no border on page - Table of Contents is move to hidden menu (more space for documentation) - Property List sits under the document Some design decisions above are in anticipation of Phriction v3 and Unbeta Phame, specifically commenting and maybe some cool new Remarkup text layout options for Phame. Test Plan: Went through tons of pages on Diviner on Desktop, Tablet, Mobile. Bounce back to Phriction to make sure DocumentView CSS changes actually look better there. {F930518} {F930519} {F930520} {F930521} Reviewers: epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, joshuaspence, Korvin Differential Revision: https://secure.phabricator.com/D14374
2015-11-01 17:56:46 +01:00
'PHUIDocumentViewPro' => 'view/phui/PHUIDocumentViewPro.php',
Feed Story UI Examples. Summary: This provides some new display methods and examples to PHUIFeedStory. Test Plan: Tested UIExamples Page, mobile layouts, and existing Feed Pages (feed, profile, etc). I want to add a bit more but am stopping here since it's not a priority. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5749
2013-04-25 00:18:58 +02:00
'PHUIFeedStoryExample' => 'applications/uiexample/examples/PHUIFeedStoryExample.php',
PHUIFeedStoryView, Update Profile Summary: This moves Feed's rendering over to a PHUI class. I want to build it out and have it power Ponder, Phame, Feed, as well as Profiles and Projects in some fashion. It also provides some more data depth over ObjectItemView. Also updated Profile for mobile and fixed some other display issues there. Test Plan: Tested Feed, Profile. Used iOS and Chrome. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin, AnhNhan Differential Revision: https://secure.phabricator.com/D5687
2013-04-15 04:32:26 +02:00
'PHUIFeedStoryView' => 'view/phui/PHUIFeedStoryView.php',
Add instructions about READMEs to new Diffusion basic editor Summary: Provide contextual, in-app documentation about README files. Test Plan: {F44181} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6033
2013-05-24 21:38:27 +02:00
'PHUIFormDividerControl' => 'view/form/control/PHUIFormDividerControl.php',
Add a date range query to Macros Summary: Ref T1163. Ref T2625. This could probably use some tweaks, but I kept things mostly-generic. I added a new control for freeform dates so we can have it render help or whatever later on. Test Plan: See screenshots. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625, T1163 Differential Revision: https://secure.phabricator.com/D6084
2013-05-31 02:32:12 +02:00
'PHUIFormFreeformDateControl' => 'view/form/control/PHUIFormFreeformDateControl.php',
Provide a "PHUIFormIconSetControl" Summary: Ref T9992. This is a step on the path to getting EditEngine working in Badges, Projects and Calendar. This doesn't add a new `EditField` for icons yet, just standardizes the old stuff. New stuff is more general and I saved 150 lines of code. I put the endpoint in Files because the similar "choose a profile picture" endpoint will definitely go there, and this endpoint might eventually feature, like, "draw your own icon~~" or something. Test Plan: - Created events, projects and badges with custom icons. - Edited events, projects and badges, changing their icons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9992 Differential Revision: https://secure.phabricator.com/D14799
2015-12-16 16:53:13 +01:00
'PHUIFormIconSetControl' => 'view/form/control/PHUIFormIconSetControl.php',
Linkify Registration Email Summary: Missed this in previous pass. Send these as links in HTML emails. Test Plan: Register a new user that nees approval. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D10815
2014-11-07 23:16:30 +01:00
'PHUIFormInsetView' => 'view/form/PHUIFormInsetView.php',
Update Form Layouts Summary: This attempts some consistency in form layouts. Notably, they all now contain headers and are 16px off the sides and tops of pages. Also updated dialogs to the same look and feel. I think I got 98% of forms with this pass, but it's likely I missed some buried somewhere. TODO: will take another pass as consolidating these colors and new gradients in another diff. Test Plan: Played in my sandbox all week. Please play with it too and let me know how they feel. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6806
2013-08-26 20:53:11 +02:00
'PHUIFormLayoutView' => 'view/form/PHUIFormLayoutView.php',
Add a basic multipage form Summary: Ref T2232. Very busy day on IRC so I feel like I've made 20 minutes of progress in 1-minute spurts here, but this adds the basics for a form that can have multiple pages and automatically handle pagination and reading to/from the request, objects and responses. The UIExample is reasonably instructive. Basically, you make a form, add pages to the form, and add controls to the pages. The core flow control looks like this: if ($request->isFormPost()) { $form->readFromRequest($request); // (1) if ($form->isComplete()) { // (2) $response = $form->writeToResponse($response); // (3) // Process result here. // (4) } } else { $form->readFromObject($object); // (5) } The key parts are: # This reads the form state from the request, including reading all the inactive pages. # This tests if all pages are valid and the user just clicked "Done" on the last page. # This produces a "response", which might be writing to an object (for simpler forms) or creating a transaction record (for more complex forms). # Here, we would save the object or apply the transactions. # When the user views the form for the first time, we preload all the values from some object (which might just be empty). Ultimate goal here is to fix repository creation to not be a terrible pit of awfulness. There are probably a lot of rough edges and missing features still, but this seems to not be totally crazy. I'm using two submit buttons with different names which doesn't work on IE7 or something, but we can JS our way out of that if we need to. Test Plan: Paged forward and backward through the form. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2232 Differential Revision: https://secure.phabricator.com/D6003
2013-05-23 23:39:01 +02:00
'PHUIFormMultiSubmitControl' => 'view/form/control/PHUIFormMultiSubmitControl.php',
'PHUIFormPageView' => 'view/form/PHUIFormPageView.php',
Prepare a replacement for Controller->renderHandlesForPHIDs() Summary: Ref T7689. This gives HandleLists `renderList()` and `renderHandle()` methods, which return views that can perform just-in-time data fetching and generally look and feel like other rendering code, instead of being odd pseudo-functional methods on `Controller`. Also converts callsites on the Maniphest detail page to use these methods. Next changes will wipe out more of the callsites. Test Plan: - Viewed Maniphest detail page with many relevant handles. - Created a new subtask. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7689 Differential Revision: https://secure.phabricator.com/D12205
2015-03-30 15:18:54 +02:00
'PHUIHandleListView' => 'applications/phid/view/PHUIHandleListView.php',
Use standard tag elements instead of "maniphest project tag" to show tags in list views Summary: Standardizes tag rendering in Maniphest and Maniphest/Diffusion list views. (This might need some size/spacing tweaks, I tried to make it look reasonable.) Test Plan: See screenshots. Reviewers: chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9741
2014-06-26 17:49:44 +02:00
'PHUIHandleTagListView' => 'applications/phid/view/PHUIHandleTagListView.php',
Prepare a replacement for Controller->renderHandlesForPHIDs() Summary: Ref T7689. This gives HandleLists `renderList()` and `renderHandle()` methods, which return views that can perform just-in-time data fetching and generally look and feel like other rendering code, instead of being odd pseudo-functional methods on `Controller`. Also converts callsites on the Maniphest detail page to use these methods. Next changes will wipe out more of the callsites. Test Plan: - Viewed Maniphest detail page with many relevant handles. - Created a new subtask. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7689 Differential Revision: https://secure.phabricator.com/D12205
2015-03-30 15:18:54 +02:00
'PHUIHandleView' => 'applications/phid/view/PHUIHandleView.php',
Solidify PHUITwoColumnView as a page layout Summary: Rolls out a new "Object Page" design with PHUITwoColumnView. This is reasonably polished, but wanted to post it up for you now for feedback before chasing down minor bugs. This implements TwoColumn in the following applications: - Ponder - Paste - Slowvote - Countdown - Projects - Profile - Passphrase This helped track down display issues and inconsistencies and make sure the layout was flexible for different pages. Test Plan: Test each of the applications on mobile, tablet, and desktop breakpoints. {F1135705} {F1135706} {F1135707} {F1135708} {F1135709} {F1135710} {F1135711} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15366
2016-02-26 23:34:51 +01:00
'PHUIHeadThingView' => 'view/phui/PHUIHeadThingView.php',
Policy, Status in PHUIHeaderView Summary: The adds the ability to set 'properties' such as state, privacy, due date to the header of objects. Test Plan: Implemented in Paste, Pholio. Tested various states. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D7016
2013-09-17 18:12:37 +02:00
'PHUIHeaderView' => 'view/phui/PHUIHeaderView.php',
Move PhabricatorHovercard to PHUIHovercard Summary: No UI changes, just some search and replace for UI consistency. Test Plan: Test person and object hovercards still work. UIExamples too. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15172
2016-02-03 17:26:30 +01:00
'PHUIHovercardUIExample' => 'applications/uiexample/examples/PHUIHovercardUIExample.php',
'PHUIHovercardView' => 'view/phui/PHUIHovercardView.php',
PHUIIconCircleView Summary: Icon in a circle. Base class, not much in the way of color choices. Test Plan: UIExamples, Chrome. {F1062027} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15034
2016-01-16 06:37:36 +01:00
'PHUIIconCircleView' => 'view/phui/PHUIIconCircleView.php',
PHUIIconView Summary: Adds a base class for displaying images and icons. Test Plan: Tested giving and taking tokens, viewed action headers, uiexamples for icons, workboards. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5736
2013-04-20 02:44:20 +02:00
'PHUIIconExample' => 'applications/uiexample/examples/PHUIIconExample.php',
'PHUIIconView' => 'view/phui/PHUIIconView.php',
PHUIImageMask Summary: Adds a PHUI class for display images on a center point, with or without a mask. Test Plan: I am bad a math, so like, check that for me please. I tested using Photoshop. Class may need tweaked depending how we store the inline-comment coords. {F167829} Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D9614
2014-06-18 23:09:37 +02:00
'PHUIImageMaskExample' => 'applications/uiexample/examples/PHUIImageMaskExample.php',
'PHUIImageMaskView' => 'view/phui/PHUIImageMaskView.php',
Move PHUIErrorView to PHUIInfoView Summary: Since this element isn't strictly about errors, re-label as info view instead. Test Plan: Grepped for all callsites, tested UIExamples and a few other random pages. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: hach-que, Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11867
2015-03-01 23:45:56 +01:00
'PHUIInfoExample' => 'applications/uiexample/examples/PHUIInfoExample.php',
PHUIInfoPanel Summary: First cut of an 'info panel' for phabricator. Basic concept is for display a list of items with a bit more info and depth and an object item list. Projects could be a good first example. Test Plan: UIExamples Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7398
2013-10-25 20:09:06 +02:00
'PHUIInfoPanelExample' => 'applications/uiexample/examples/PHUIInfoPanelExample.php',
'PHUIInfoPanelView' => 'view/phui/PHUIInfoPanelView.php',
Move PHUIErrorView to PHUIInfoView Summary: Since this element isn't strictly about errors, re-label as info view instead. Test Plan: Grepped for all callsites, tested UIExamples and a few other random pages. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: hach-que, Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11867
2015-03-01 23:45:56 +01:00
'PHUIInfoView' => 'view/form/PHUIInfoView.php',
PHUIListView Examples, CSS Summary: This adds examples and abstracts out CSS for common nav re-use. Test Plan: Tested DocumentExample and ListExample Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6138
2013-06-06 00:03:56 +02:00
'PHUIListExample' => 'applications/uiexample/examples/PHUIListExample.php',
PHUIList, PHUIDocument updates Summary: This diff covers a bit of ground. - PHUIDocumentExample has been added - PHUIDocument has been extended with new features - PhabricatorMenuView is now PHUIListView - PhabricatorMenuItemView is now PHUIItemListView Overall - I think I've gotten all the edges covered here. There is some derpi-ness that we can talk about, comments in the code. Responsive design is missing from the new features on PHUIDocument, will follow up later. Test Plan: Tested mobile and desktop menus, old phriction layout, new document views, new lists, and object lists. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6130
2013-06-05 17:41:43 +02:00
'PHUIListItemView' => 'view/phui/PHUIListItemView.php',
'PHUIListView' => 'view/phui/PHUIListView.php',
'PHUIListViewTestCase' => 'view/layout/__tests__/PHUIListViewTestCase.php',
Begin modularizing main menu items Summary: Ref T10077. Ref T8918. The way the main menu is built is not very modular and fairly hacky. It assumes menus are provided by applications, but this isn't exactly true. Notably, the "Quick Create" menu is not per-application. The current method of building this menu is very inefficient (see T10077). Particularly, we have to build it //twice// because we need to build it once to render the item and then again to render the dropdown options. Start cleaning this up. This diff doesn't actually have any behavioral changes, since I can't swap the menu over until we get rid of all the other items and I haven't extended this to Notifications/Conpherence yet so it doesn't actually fix T8918. Test Plan: Viewed menus while logged in, logged out, in different applications, in desktop/mobile. Nothing appeared different. Reviewers: chad Reviewed By: chad Maniphest Tasks: T8918, T10077 Differential Revision: https://secure.phabricator.com/D14922
2016-01-01 13:26:36 +01:00
'PHUIMainMenuView' => 'view/phui/PHUIMainMenuView.php',
Move PHUIFormBoxView to PHUIObjectBoxView Summary: I'd like to reuse this for other content areas, renaming for now. This might be weird to keep setForm, but I can fix that later if we need. Test Plan: reload a few forms in maniphest, projects, differential Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D7120
2013-09-25 20:23:29 +02:00
'PHUIObjectBoxView' => 'view/phui/PHUIObjectBoxView.php',
Move PhabricatorObjectItem to PHUIObjectItem, add 'plain' setting for lists. Summary: Adds plain support for object lists that just look like lists Test Plan: review UIexamples and a number of other applications Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6922
2013-09-09 23:14:34 +02:00
'PHUIObjectItemListExample' => 'applications/uiexample/examples/PHUIObjectItemListExample.php',
'PHUIObjectItemListView' => 'view/phui/PHUIObjectItemListView.php',
'PHUIObjectItemView' => 'view/phui/PHUIObjectItemView.php',
Add a basic multipage form Summary: Ref T2232. Very busy day on IRC so I feel like I've made 20 minutes of progress in 1-minute spurts here, but this adds the basics for a form that can have multiple pages and automatically handle pagination and reading to/from the request, objects and responses. The UIExample is reasonably instructive. Basically, you make a form, add pages to the form, and add controls to the pages. The core flow control looks like this: if ($request->isFormPost()) { $form->readFromRequest($request); // (1) if ($form->isComplete()) { // (2) $response = $form->writeToResponse($response); // (3) // Process result here. // (4) } } else { $form->readFromObject($object); // (5) } The key parts are: # This reads the form state from the request, including reading all the inactive pages. # This tests if all pages are valid and the user just clicked "Done" on the last page. # This produces a "response", which might be writing to an object (for simpler forms) or creating a transaction record (for more complex forms). # Here, we would save the object or apply the transactions. # When the user views the form for the first time, we preload all the values from some object (which might just be empty). Ultimate goal here is to fix repository creation to not be a terrible pit of awfulness. There are probably a lot of rough edges and missing features still, but this seems to not be totally crazy. I'm using two submit buttons with different names which doesn't work on IE7 or something, but we can JS our way out of that if we need to. Test Plan: Paged forward and backward through the form. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2232 Differential Revision: https://secure.phabricator.com/D6003
2013-05-23 23:39:01 +02:00
'PHUIPagedFormView' => 'view/form/PHUIPagedFormView.php',
[Redesign] PHUIPagerView Summary: Ref T8099, Moves AphrontPagerView to PHUIPagerView, converts to standard PHUIButtons and adds some additional features for icon placement on buttons. Test Plan: Tested Advanced Search and Searching files in Diffusion. Works as expected. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T8342, T8099 Differential Revision: https://secure.phabricator.com/D13092
2015-06-02 23:34:04 +02:00
'PHUIPagerView' => 'view/phui/PHUIPagerView.php',
Update pinboard view styles, move to PHUI Summary: Tightens up the CSS to display more items (4 wide on 15") and fixes some mobile CSS issues with appseach. Fixes T3614 Test Plan: Tested Pholio, Macros, mobile layouts Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3614 Differential Revision: https://secure.phabricator.com/D6694
2013-08-07 19:58:09 +02:00
'PHUIPinboardItemView' => 'view/phui/PHUIPinboardItemView.php',
'PHUIPinboardView' => 'view/phui/PHUIPinboardView.php',
PHUIPropertyListView Summary: This builds out and implements PHUIPropertyListView (container) and PHUIPropertyListItemView (section) as well as adding tabs. Test Plan: Tested each page I edited with the exception of Releeph and Phortune, though those changes look ok to me diff wise. Updated examples page with tabs. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7283
2013-10-11 16:53:56 +02:00
'PHUIPropertyGroupView' => 'view/phui/PHUIPropertyGroupView.php',
'PHUIPropertyListExample' => 'applications/uiexample/examples/PHUIPropertyListExample.php',
'PHUIPropertyListView' => 'view/phui/PHUIPropertyListView.php',
Partially generalize Remarkup previews and add support to Differential Summary: Ref T3671. A lot of applications have pretty ad-hoc preview code. Clean it up a bit and add Summary preview to Differential. After ApplicationTransactions we might want to try to serialize the whole form and show a preview of all the transactions, but this seems not very useful in most cases (I'd guess that Remarkup previews are 99% of the value) and tricky to get right (e.g., adding images which don't exist yet to Pholio mocks). I think I can add this in a few other places, too. Test Plan: Edited Maniphest Tasks and Differential Revisions, mashed some buttons. Verified previews rendered correctly. Grepped for removed CSS classes (no hits). {F52907} Reviewers: btrahan, Firehed Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T3671 Differential Revision: https://secure.phabricator.com/D6673
2013-08-05 19:46:39 +02:00
'PHUIRemarkupPreviewPanel' => 'view/phui/PHUIRemarkupPreviewPanel.php',
Introduce PHUIRemarkupView, a sane way to work with Remarkup Summary: Fixes T9273. Remarkup has reasonably good fundamentals but the API is a giant pain to work with. Provide a `PHUIRemarkupView` to make it easier. This object is way simpler to use by default. It's not currently as powerful, but we can expand the power level later by adding more setters. Eventually I'd expect to replace `PhabricatorRemarkupInterface` and `PhabricatorMarkupOneOff` with this, but no rush on those. I converted a few callsites as a sanity check that it works OK. Test Plan: - Viewed remarkup in Passphrase. - Viewed remarkup in Badges. - Viewed a Conduit method. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9273 Differential Revision: https://secure.phabricator.com/D14289
2015-10-15 19:20:19 +02:00
'PHUIRemarkupView' => 'infrastructure/markup/view/PHUIRemarkupView.php',
First cut of progress bars (PHUISegmentBarView) Summary: Ref T10288. I couldn't figure out how to reasonably get the interior right borders to round like the mock, but I think this is otherwise mostly faithful. Feel free to fix stuff. Test Plan: {F1100415} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10288 Differential Revision: https://secure.phabricator.com/D15219
2016-02-08 23:37:31 +01:00
'PHUISegmentBarSegmentView' => 'view/phui/PHUISegmentBarSegmentView.php',
'PHUISegmentBarView' => 'view/phui/PHUISegmentBarView.php',
Put Spaces on Hovercards and ObjectItemLists Summary: Ref T8449. Test Plan: {F474186} {F474187} Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T8449 Differential Revision: https://secure.phabricator.com/D13173
2015-06-05 23:20:25 +02:00
'PHUISpacesNamespaceContextView' => 'applications/spaces/view/PHUISpacesNamespaceContextView.php',
Add PHUIStatusListView Summary: For Diffusion's auditors list, and Differential's reviewers list (eventually). An inline option might make more sense in Differential, but I want to use this in Diffusion first, and we need more information there. Test Plan: {F51424} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6559
2013-07-24 23:13:22 +02:00
'PHUIStatusItemView' => 'view/phui/PHUIStatusItemView.php',
'PHUIStatusListView' => 'view/phui/PHUIStatusListView.php',
Move PhabricatorTagView to PHUITagView Summary: For consistency and great justice. Test Plan: tested audit, uiexamples, action headers Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7967
2014-01-14 23:09:52 +01:00
'PHUITagExample' => 'applications/uiexample/examples/PHUITagExample.php',
'PHUITagView' => 'view/phui/PHUITagView.php',
PHUITimelineView Summary: Updates PhabricatorTimeline to PHUITimeline. Uses standard colors and spacing, softens up the actors, and reduces visual spacing of action-only events. - Also updated some 2x sprite images. Test Plan: Tested Tasks Paste and Pholio in my sandbox. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D8205
2014-02-12 18:02:05 +01:00
'PHUITimelineEventView' => 'view/phui/PHUITimelineEventView.php',
'PHUITimelineExample' => 'applications/uiexample/examples/PHUITimelineExample.php',
'PHUITimelineView' => 'view/phui/PHUITimelineView.php',
Add similiar questions sidebar to Ponder Summary: Ref T9099. Testing out a two column layout in Ponder, with the main idea being creating a more browsable, discoverable product. I'd like the side column though to be a little smarter and provide project based searching. Ideally, if I'm reading Resolved Maniphest questions, other Resolved Maniphest questions are likely interesting. Another scenario is if I'm answering questions, in which case browsing more Open questions would also be interesting. Ponder "Main Column" still needs to be redesigned. Test Plan: Browse open questions, resolved questions. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9099 Differential Revision: https://secure.phabricator.com/D13849
2015-08-10 23:55:43 +02:00
'PHUITwoColumnView' => 'view/phui/PHUITwoColumnView.php',
Make token UI stronger and more consistent Summary: Ref T4100. Overall: - Use token background color to communicate token type (blue = object, yellow = function, grey = disabled/closed, red = invalid). - Use token icon color to make color choices consistent (specifically, use project icon colors in project tokens). - For functions, use token icon to communicate function result type (e.g., viewer() has a user icon; members(...) has a group icon), since we don't need the icon to indicate "this is a function" anymore. Test Plan: {F374615} {F374616} {F374617} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12446
2015-04-17 16:00:43 +02:00
'PHUITypeaheadExample' => 'applications/uiexample/examples/PHUITypeaheadExample.php',
Move Workboards to PHUI Summary: This is just renaming to PHUI (I like shorter text :) Test Plan: reload workboard examples page, seems to not fatal and looks very appealing Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6904
2013-09-06 23:06:12 +02:00
'PHUIWorkboardView' => 'view/phui/PHUIWorkboardView.php',
'PHUIWorkpanelView' => 'view/phui/PHUIWorkpanelView.php',
Add "PassphraseKey" classes for code which needs to actually use credentials Summary: Ref T4122. These classes provide typed, checked access to credentials, so you can say "give me this password, and throw if anything is funky". Test Plan: Used in next revision. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7625
2013-11-23 00:23:10 +01:00
'PassphraseAbstractKey' => 'applications/passphrase/keys/PassphraseAbstractKey.php',
Implement `passphrase.query` for querying credentials Summary: Resolves T5868. This implements `passphrase.query` and a mechanism for allowing Conduit access to credentials. Test Plan: Tested locally. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: talshiri, epriestley, Korvin Maniphest Tasks: T5868 Differential Revision: https://secure.phabricator.com/D10262
2014-08-16 14:41:03 +02:00
'PassphraseConduitAPIMethod' => 'applications/passphrase/conduit/PassphraseConduitAPIMethod.php',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseController' => 'applications/passphrase/controller/PassphraseController.php',
'PassphraseCredential' => 'applications/passphrase/storage/PassphraseCredential.php',
Save authorPHID on Passphrase Credentials to support "Credential Author" object policy Summary: Fixes T5135. Currently, when you create a credential, we default the policies to your PHID. This means we can't have an application-level configurable default because there's no way to select "the actor's PHID" as a policy. Start tracking the credential author's PHID and add an object policy for it, so there is such a setting. Then, add policy defaults. This mostly unblocks T6787. This obsoletes T6860. Test Plan: - Created a credential with "Credential Author" policy. - Verified I can see/edit it, but other users can not. - Changed default policies to something else. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5135 Differential Revision: https://secure.phabricator.com/D13385
2015-06-22 20:28:33 +02:00
'PassphraseCredentialAuthorPolicyRule' => 'applications/passphrase/policyrule/PassphraseCredentialAuthorPolicyRule.php',
Implement `passphrase.query` for querying credentials Summary: Resolves T5868. This implements `passphrase.query` and a mechanism for allowing Conduit access to credentials. Test Plan: Tested locally. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: talshiri, epriestley, Korvin Maniphest Tasks: T5868 Differential Revision: https://secure.phabricator.com/D10262
2014-08-16 14:41:03 +02:00
'PassphraseCredentialConduitController' => 'applications/passphrase/controller/PassphraseCredentialConduitController.php',
Add a credential selection control to Passphrase Summary: Ref T4122. Adds a control for choosing credentials. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran, lsave Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7617
2013-11-21 21:35:36 +01:00
'PassphraseCredentialControl' => 'applications/passphrase/view/PassphraseCredentialControl.php',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseCredentialCreateController' => 'applications/passphrase/controller/PassphraseCredentialCreateController.php',
'PassphraseCredentialDestroyController' => 'applications/passphrase/controller/PassphraseCredentialDestroyController.php',
'PassphraseCredentialEditController' => 'applications/passphrase/controller/PassphraseCredentialEditController.php',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PassphraseCredentialFulltextEngine' => 'applications/passphrase/search/PassphraseCredentialFulltextEngine.php',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseCredentialListController' => 'applications/passphrase/controller/PassphraseCredentialListController.php',
Add a "Lock Permanently" action to Passphrase Summary: Fixes T4931. Each new credential should come with the ability to lock the credential permanently, so that no one can ever edit again. Each existing credential must allow user to lock existing credential. Test Plan: Create new credential, verify that you can lock it before saving it. Open existing unlocked credential, verify that option to lock it exists. Once credential is locked, the option to reveal it should be disabled, and editing the credential won't allow username/password updates. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4931 Differential Revision: https://secure.phabricator.com/D8947
2014-05-03 03:05:19 +02:00
'PassphraseCredentialLockController' => 'applications/passphrase/controller/PassphraseCredentialLockController.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PassphraseCredentialPHIDType' => 'applications/passphrase/phid/PassphraseCredentialPHIDType.php',
Allow Passphrase to generate SSH keypairs and extact public keys from private keys Summary: Ref T4587. - Add an option to generate a keypair. - Add an option to view the public keys for existing keypairs. Test Plan: - Generated keypairs. - Viewed public keys. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4587 Differential Revision: https://secure.phabricator.com/D8515
2014-03-13 02:58:25 +01:00
'PassphraseCredentialPublicController' => 'applications/passphrase/controller/PassphraseCredentialPublicController.php',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseCredentialQuery' => 'applications/passphrase/query/PassphraseCredentialQuery.php',
'PassphraseCredentialRevealController' => 'applications/passphrase/controller/PassphraseCredentialRevealController.php',
'PassphraseCredentialSearchEngine' => 'applications/passphrase/query/PassphraseCredentialSearchEngine.php',
'PassphraseCredentialTransaction' => 'applications/passphrase/storage/PassphraseCredentialTransaction.php',
'PassphraseCredentialTransactionEditor' => 'applications/passphrase/editor/PassphraseCredentialTransactionEditor.php',
'PassphraseCredentialTransactionQuery' => 'applications/passphrase/query/PassphraseCredentialTransactionQuery.php',
'PassphraseCredentialType' => 'applications/passphrase/credentialtype/PassphraseCredentialType.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PassphraseCredentialTypeTestCase' => 'applications/passphrase/credentialtype/__tests__/PassphraseCredentialTypeTestCase.php',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseCredentialViewController' => 'applications/passphrase/controller/PassphraseCredentialViewController.php',
'PassphraseDAO' => 'applications/passphrase/storage/PassphraseDAO.php',
Save authorPHID on Passphrase Credentials to support "Credential Author" object policy Summary: Fixes T5135. Currently, when you create a credential, we default the policies to your PHID. This means we can't have an application-level configurable default because there's no way to select "the actor's PHID" as a policy. Start tracking the credential author's PHID and add an object policy for it, so there is such a setting. Then, add policy defaults. This mostly unblocks T6787. This obsoletes T6860. Test Plan: - Created a credential with "Credential Author" policy. - Verified I can see/edit it, but other users can not. - Changed default policies to something else. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5135 Differential Revision: https://secure.phabricator.com/D13385
2015-06-22 20:28:33 +02:00
'PassphraseDefaultEditCapability' => 'applications/passphrase/capability/PassphraseDefaultEditCapability.php',
'PassphraseDefaultViewCapability' => 'applications/passphrase/capability/PassphraseDefaultViewCapability.php',
Added a Note Credential Type for Passphrase Summary: Closes T8481. Test Plan: Verify that in Passphrase > Create an option to create a Note credential exists and credentials of type Note are createable. Reviewers: epriestley, #blessed_reviewers, eadler, lpriestley Reviewed By: eadler Subscribers: joshuaspence, epriestley, Korvin Maniphest Tasks: T8481 Differential Revision: https://secure.phabricator.com/D13261
2015-06-16 22:44:51 +02:00
'PassphraseNoteCredentialType' => 'applications/passphrase/credentialtype/PassphraseNoteCredentialType.php',
Rename PassphraseCredentialType subclasses for consistency Summary: Ref T5655. Test Plan: `arc unit` + `grep` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D13266
2015-06-14 06:11:55 +02:00
'PassphrasePasswordCredentialType' => 'applications/passphrase/credentialtype/PassphrasePasswordCredentialType.php',
Add "PassphraseKey" classes for code which needs to actually use credentials Summary: Ref T4122. These classes provide typed, checked access to credentials, so you can say "give me this password, and throw if anything is funky". Test Plan: Used in next revision. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7625
2013-11-23 00:23:10 +01:00
'PassphrasePasswordKey' => 'applications/passphrase/keys/PassphrasePasswordKey.php',
Implement `passphrase.query` for querying credentials Summary: Resolves T5868. This implements `passphrase.query` and a mechanism for allowing Conduit access to credentials. Test Plan: Tested locally. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: talshiri, epriestley, Korvin Maniphest Tasks: T5868 Differential Revision: https://secure.phabricator.com/D10262
2014-08-16 14:41:03 +02:00
'PassphraseQueryConduitAPIMethod' => 'applications/passphrase/conduit/PassphraseQueryConduitAPIMethod.php',
Allow linking to passphrase credential via remarkup Summary: Fixes T5421, add linking to passphrase credentials Test Plan: Open task, add a comment of '{K1}' where K1 is a passphrase credential. Preview and actual comment should be link to credential with the content of credential. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5421 Differential Revision: https://secure.phabricator.com/D9725
2014-06-25 23:58:56 +02:00
'PassphraseRemarkupRule' => 'applications/passphrase/remarkup/PassphraseRemarkupRule.php',
Rename PassphraseCredentialType subclasses for consistency Summary: Ref T5655. Test Plan: `arc unit` + `grep` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D13266
2015-06-14 06:11:55 +02:00
'PassphraseSSHGeneratedKeyCredentialType' => 'applications/passphrase/credentialtype/PassphraseSSHGeneratedKeyCredentialType.php',
Add "PassphraseKey" classes for code which needs to actually use credentials Summary: Ref T4122. These classes provide typed, checked access to credentials, so you can say "give me this password, and throw if anything is funky". Test Plan: Used in next revision. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7625
2013-11-23 00:23:10 +01:00
'PassphraseSSHKey' => 'applications/passphrase/keys/PassphraseSSHKey.php',
Rename PassphraseCredentialType subclasses for consistency Summary: Ref T5655. Test Plan: `arc unit` + `grep` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D13266
2015-06-14 06:11:55 +02:00
'PassphraseSSHPrivateKeyCredentialType' => 'applications/passphrase/credentialtype/PassphraseSSHPrivateKeyCredentialType.php',
'PassphraseSSHPrivateKeyFileCredentialType' => 'applications/passphrase/credentialtype/PassphraseSSHPrivateKeyFileCredentialType.php',
'PassphraseSSHPrivateKeyTextCredentialType' => 'applications/passphrase/credentialtype/PassphraseSSHPrivateKeyTextCredentialType.php',
Generate expected scheamta for Passphrase, Paste, Phlux, Phame Summary: Ref T1191. Nothing notable in these. Test Plan: Viewed web UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10528
2014-09-24 22:50:57 +02:00
'PassphraseSchemaSpec' => 'applications/passphrase/storage/PassphraseSchemaSpec.php',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseSecret' => 'applications/passphrase/storage/PassphraseSecret.php',
Add a "Token" Credential type Summary: Ref T9456. This is just a convenience type for things like API tokens, to make it harder for users to make mistakes and keep SSH keys out of the dropdown for "choose your API token". Test Plan: {F879820} Reviewers: chad Reviewed By: chad Subscribers: joshuaspence Maniphest Tasks: T9456 Differential Revision: https://secure.phabricator.com/D14284
2015-10-15 03:34:55 +02:00
'PassphraseTokenCredentialType' => 'applications/passphrase/credentialtype/PassphraseTokenCredentialType.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PasteConduitAPIMethod' => 'applications/paste/conduit/PasteConduitAPIMethod.php',
'PasteCreateConduitAPIMethod' => 'applications/paste/conduit/PasteCreateConduitAPIMethod.php',
Add some create mail handlers for paste and files Summary: Fixes T1144. Though actually I think T1144 wanted some handy way to email from the command-line / arc, this is cooler. :D Test Plan: set conf properly and then ./bin/mail receive-test --as btrahan --to pasties@phabricator.dev | README --> it worked...! couldn't test files as easily but verified exception thrown when I tried to test. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1144 Differential Revision: https://secure.phabricator.com/D6622
2013-07-30 22:26:55 +02:00
'PasteCreateMailReceiver' => 'applications/paste/mail/PasteCreateMailReceiver.php',
Paste: Add edit policy Summary: T5549 Test Plan: Set edit policy on paste, check that only users meeting the policy requirements can edit it. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5549 Differential Revision: https://secure.phabricator.com/D11097
2014-12-31 17:23:47 +01:00
'PasteDefaultEditCapability' => 'applications/paste/capability/PasteDefaultEditCapability.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'PasteDefaultViewCapability' => 'applications/paste/capability/PasteDefaultViewCapability.php',
Roughly generate transaction-oriented API methods from EditEngines Summary: Ref T5873. Ref T9132. This is really rough and feels pretty flimsy at the edges (missing validation, generality, modularity, clean error handling, etc) but gets us most of the way toward generating plausible "whatever.edit" Conduit API methods from EditEngines. These methods are full-power methods which can do everything the edit form can, automatically support the same range of operations, and update when new fields are added. Test Plan: - Used new `paste.edit` to create a new Paste. - Used new `paste.edit` to update an existing paste. - Applied a variety of different transactions. - Hit a reasonable set of errors. {F941144} {F941145} {F941146} {F941147} Reviewers: chad Reviewed By: chad Maniphest Tasks: T5873, T9132 Differential Revision: https://secure.phabricator.com/D14393
2015-11-03 17:45:00 +01:00
'PasteEditConduitAPIMethod' => 'applications/paste/conduit/PasteEditConduitAPIMethod.php',
Paste embeds look super cool Summary: Make Paste embeds look super cool Test Plan: {F35387} Reviewers: epriestley CC: aran, Korvin, chad, btrahan, AnhNhan Maniphest Tasks: T1770 Differential Revision: https://secure.phabricator.com/D5323
2013-03-13 14:44:27 +01:00
'PasteEmbedView' => 'applications/paste/view/PasteEmbedView.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PasteInfoConduitAPIMethod' => 'applications/paste/conduit/PasteInfoConduitAPIMethod.php',
Lift common code for transaction-based reply handlers into parent class Summary: Ref T7199. Essentially all of the reply handlers now apply transactions to something which implements PhabricatorApplicationTransactionInterface. We can share code between them by lifting this stuff into a superclass. First, convert paste. Also rename `PasteMockMailReceiver` to `PasteMailReceiver` (this got mis-copied from Pholio at some point, I think). Test Plan: Used `bin/mail receive-test` to send comments + `!unsubscribe` to pastes. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12236
2015-04-01 17:39:21 +02:00
'PasteMailReceiver' => 'applications/paste/mail/PasteMailReceiver.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PasteQueryConduitAPIMethod' => 'applications/paste/conduit/PasteQueryConduitAPIMethod.php',
Paste - add support for email replies and subscribers Summary: Email replies and subscribers seem to go hand in hand so deploy both at once. Test Plan: played around with bin/mail. Verified replies posted comments on the paste. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3650 Differential Revision: https://secure.phabricator.com/D6682
2013-08-06 02:11:46 +02:00
'PasteReplyHandler' => 'applications/paste/mail/PasteReplyHandler.php',
Implement a rough initial version of ApplicationSearch-driven Conduit read endpoints Summary: Ref T9964. See that task for some context and discussion. Ref T7715, which has the bigger picture here. Basically, I want Conduit read endpoints to be full-power, ApplicationSearch-driven endpoints, so that applications can: - Write one EditEngine and get web + conduit writes for free. - Write one SearchEngine and get web + conduit reads for free. I previously made some steps toward this, but this puts more of the structure in place. Test Plan: Viewed API console endpoint and read 20 pages of docs: {F1021961} Made various calls: with query keys, constraints, pagination, and limits. Viewed new {nav Config > Modules} page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7715, T9964 Differential Revision: https://secure.phabricator.com/D14743
2015-12-11 17:45:56 +01:00
'PasteSearchConduitAPIMethod' => 'applications/paste/conduit/PasteSearchConduitAPIMethod.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'PeopleBrowseUserDirectoryCapability' => 'applications/people/capability/PeopleBrowseUserDirectoryCapability.php',
People - add application policy on user creation Summary: Ref T6947. Test Plan: made the setting say only admin user a and noted admin user b lost access Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4137, T6947 Differential Revision: https://secure.phabricator.com/D11357
2015-01-13 00:18:16 +01:00
'PeopleCreateUsersCapability' => 'applications/people/capability/PeopleCreateUsersCapability.php',
Move PhabricatorHovercard to PHUIHovercard Summary: No UI changes, just some search and replace for UI consistency. Test Plan: Test person and object hovercards still work. UIExamples too. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15172
2016-02-03 17:26:30 +01:00
'PeopleHovercardEngineExtension' => 'applications/people/engineextension/PeopleHovercardEngineExtension.php',
Add a GC for user logs Summary: Fixes T4368. This is the last "obvious" table we have which we should be GC'ing but do not. It's about 1/12th of the data on `secure.phabricator.com`. This table stores logins, account creation, password resets, login attempts, etc, and is primarily useful if something sketchy happens so you can go back and review login activity. This data is not useful indefinitely, and there's no reason to retain it forever. Because you don't always know when something sketchy happened I've given this table a fairly long TTL (180 days), but we don't need limitless amounts of this data. Test Plan: Ran `phd debug garbage` and saw a reasonable amount of data get GC'd. This table already has an appropriate key. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4368 Differential Revision: https://secure.phabricator.com/D8128
2014-02-03 19:51:41 +01:00
'PeopleUserLogGarbageCollector' => 'applications/people/garbagecollector/PeopleUserLogGarbageCollector.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'Phabricator404Controller' => 'applications/base/controller/Phabricator404Controller.php',
Add Disqus, Facebook, Google, GitHub auth config; AWS config Summary: Also improve behavior for the "unknown config" warning. Test Plan: Looked at configs, went through unknown config workflow. Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4310
2013-01-01 23:09:29 +01:00
'PhabricatorAWSConfigOptions' => 'applications/config/option/PhabricatorAWSConfigOptions.php',
Fix controller-level access rules Summary: Ref T603. I had to partially revert this earlier because it accidentally blocked access to Conduit and File data for installs without "policy.allow-public", since the applications are available to "all users" but some endpoints actually need to be available even when not logged in. This readjusts the gating in the controller to properly apply application visibility restrictions, and then adds a giant pile of unit test coverage to make sure it sticks and all the weird cases are covered. Test Plan: - Added and executed unit tests. - Executed most of the tests manually, by using logged in / admin / public / disabled users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7211
2013-10-04 04:05:47 +02:00
'PhabricatorAccessControlTestCase' => 'applications/base/controller/__tests__/PhabricatorAccessControlTestCase.php',
Add an SSH access log Summary: Ref T4107. Ref T4189. This implements an SSH access log, similar to the HTTP access log. Test Plan: [Thu, 05 Dec 2013 13:45:41 -0800] 77841 orbital ::1 dweller epriestley epriestley git-receive-pack /diffusion/POEMS/ 0 324765 402 232 [Thu, 05 Dec 2013 13:45:48 -0800] 77860 orbital ::1 dweller epriestley epriestley git-receive-pack /diffusion/POEMS/ 0 325634 402 232 Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4107, T4189 Differential Revision: https://secure.phabricator.com/D7719
2013-12-06 02:00:48 +01:00
'PhabricatorAccessLog' => 'infrastructure/log/PhabricatorAccessLog.php',
Add "Developer" and "Access Log" config option groups, some types Summary: - Add a "developer" option group. - Add an "access log" option group. - Render the types "bool", "int" and "string" in a more tailored way. - Add a config check for dead config. Right now this serves as a "TODO" list of things that need to be migrated. Test Plan: Looked at config options, setup issues. Edited bool, int, string options. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4308
2013-01-01 23:09:17 +01:00
'PhabricatorAccessLogConfigOptions' => 'applications/config/option/PhabricatorAccessLogConfigOptions.php',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorAccountSettingsPanel' => 'applications/settings/panel/PhabricatorAccountSettingsPanel.php',
Modernize Paste Summary: - Add a PhabricatorApplication. - Make most of the views work well on tablets / phones. The actual "Create" form doesn't, but everything else is good -- need to make device-friendly form layouts before I can do the form. Test Plan: Will attach screenshots. Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3293
2012-08-15 19:45:06 +02:00
'PhabricatorActionListView' => 'view/layout/PhabricatorActionListView.php',
'PhabricatorActionView' => 'view/layout/PhabricatorActionView.php',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorActivitySettingsPanel' => 'applications/settings/panel/PhabricatorActivitySettingsPanel.php',
Move some files around Summary: Move some `PhabricatorPolicyRule` implementations to a subdirectory of the parent application. Test Plan: N/A Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14478
2015-11-16 20:26:13 +01:00
'PhabricatorAdministratorsPolicyRule' => 'applications/people/policyrule/PhabricatorAdministratorsPolicyRule.php',
Modularize Aphront exception handling Summary: Ref T1806. Ref T7173. Depends on D14047. Currently, all exception handling is in this big messy clump in `AphrontDefaultApplicationConfiguration`. Split it out into modular classes. This will let a future change add new classes in the Phacility cluster which intercept particular exceptions we care about and replaces the default, generic responses with more useful, tailored responses. Test Plan: {F777391} - Hit a Conduit error (made a method throw). - Hit an Ajax error (made comment preview throw). - Hit a high security error (tried to edit TOTP). - Hit a rate limiting error (added a bunch of email addresses). - Hit a policy error (tried to look at something with no permission). - Hit an arbitrary exception (made a randomc ontroller throw). Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14049
2015-09-03 19:04:42 +02:00
'PhabricatorAjaxRequestExceptionHandler' => 'aphront/handler/PhabricatorAjaxRequestExceptionHandler.php',
Implement storage of a host ID and a public key for authorizing Conduit between servers Summary: Ref T4209. This creates storage for public keys against authorized hosts, such that servers can be authorized to make Conduit calls as the omnipotent user. Servers are registered into this system by running the following command once: ``` bin/almanac register ``` NOTE: This doesn't implement authorization between servers, just the storage of public keys. Placing this against Almanac seemed like the most sensible place, since I'm imagining in future that the `register` command will accept more information (like the hostname of the server so it can be found in the service directory). Test Plan: Ran `bin/almanac register` and saw the host (and public key information) appear in the database. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4209 Differential Revision: https://secure.phabricator.com/D10400
2014-10-03 14:52:41 +02:00
'PhabricatorAlmanacApplication' => 'applications/almanac/application/PhabricatorAlmanacApplication.php',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorAmazonAuthProvider' => 'applications/auth/provider/PhabricatorAmazonAuthProvider.php',
Add local navigation to Differential Summary: Adds a flexible navigation menu to diffs that shows you your current position in the diff. Anticipating some "this is the best thing ever" and some "this is the wosrt thing ever" on this, but let's see how much pushback we get? It seems pretty good to me. Test Plan: Will attach screenshots. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1633, T1591 Differential Revision: https://secure.phabricator.com/D3355
2012-08-22 00:01:20 +02:00
'PhabricatorAnchorView' => 'view/layout/PhabricatorAnchorView.php',
Make `./bin/aphlict` behave more like a service. Summary: Fixes T5126. Provide `start`, `stop`, `restart`, `debug` and `status` workflows for `./bin/aphlict`. This makes it easier to manage Aphlict as if it were a service. Test Plan: ``` > sudo ./bin/aphlict status Aphlict is not running. > sudo ./bin/aphlict stop Aphlict is not running. > sudo ./bin/aphlict start Aphlict Server started. > sudo ./bin/aphlict status Aphlict (12880) is running. > sudo ./bin/aphlict restart Stopping Aphlict Server (12880)... Aphlict Server (12880) exited normally. Aphlict Server started. > sudo ./bin/aphlict stop Stopping Aphlict Server (12895)... Aphlict Server (12895) exited normally. > sudo ./bin/aphlict debug Starting Aphlict server in foreground... Launching server: $ node '/usr/src/phabricator/src/applications/aphlict/management/../../../../support/aphlict/server/aphlict_server.js' --port='22280' --admin='22281' --host='localhost' --user='aphlict' [Fri May 30 2014 09:56:14 GMT+0000 (UTC)] Started Server (PID 12911) ``` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5126 Differential Revision: https://secure.phabricator.com/D9226
2014-06-05 21:13:44 +02:00
'PhabricatorAphlictManagementDebugWorkflow' => 'applications/aphlict/management/PhabricatorAphlictManagementDebugWorkflow.php',
'PhabricatorAphlictManagementRestartWorkflow' => 'applications/aphlict/management/PhabricatorAphlictManagementRestartWorkflow.php',
'PhabricatorAphlictManagementStartWorkflow' => 'applications/aphlict/management/PhabricatorAphlictManagementStartWorkflow.php',
'PhabricatorAphlictManagementStatusWorkflow' => 'applications/aphlict/management/PhabricatorAphlictManagementStatusWorkflow.php',
'PhabricatorAphlictManagementStopWorkflow' => 'applications/aphlict/management/PhabricatorAphlictManagementStopWorkflow.php',
'PhabricatorAphlictManagementWorkflow' => 'applications/aphlict/management/PhabricatorAphlictManagementWorkflow.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorAphlictSetupCheck' => 'applications/notification/setup/PhabricatorAphlictSetupCheck.php',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorAphrontBarUIExample' => 'applications/uiexample/examples/PhabricatorAphrontBarUIExample.php',
Provide hasChildren() to replace isEmptyContent() Summary: Fixes T3698. Sometimes views need to render differently depending on whether they contain content or not. The existing approach for this is `isEmptyContent()`, which doesn't work well and is sort of hacky (it implies double-rendering content, which is not always free or side-effect free). Instead, provide a test for an element without children. This test is powerful enough to catch the easy cases of `null`, etc., and just do the expected thing, but will not catch a View which is reduced upon rendering. Since this is rare and we have no actual need for it today, just accept that as a limitation. Test Plan: Viewed Timeline and Feed UI examples. Viewed Feed (feed), Pholio (timelineview), and Differential (old transactionview). {F53915} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T3698 Differential Revision: https://secure.phabricator.com/D6718
2013-08-12 16:51:01 +02:00
'PhabricatorAphrontViewTestCase' => 'view/__tests__/PhabricatorAphrontViewTestCase.php',
Use ApplicationSearch in Applications application Summary: Ref T603. OMG SO META Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7197
2013-10-02 22:13:07 +02:00
'PhabricatorAppSearchEngine' => 'applications/meta/query/PhabricatorAppSearchEngine.php',
Add FactCursors and application fact datasources Summary: - Add PhabricatorApplication. This is a general class that I have grand designs for, but used here to allow applications to provide objects for analysis by the facts appliction. - Add FactCursors, to keep track of where iterators are. - Make the daemon do something sort of useful. - Add `bin/fact cursors` for showing and managing objects and cursors. - Add some options to `bin/fact analyze`. Test Plan: - `bin/fact cursors`, `bin/fact cursors --reset DifferentialRevision`, `bin/fact cursors --reset X` - `bin/fact analyze`, `bin/fact analyze --all`, `bin/fact analyze --iterator DifferentialRevision --skip-aggregates` - `bin/phd debug fact` Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3098
2012-07-30 19:43:49 +02:00
'PhabricatorApplication' => 'applications/base/PhabricatorApplication.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorApplicationApplicationPHIDType' => 'applications/meta/phid/PhabricatorApplicationApplicationPHIDType.php',
Begin moving Phabricator configuration into PHP Summary: Ref T2255. Ref T2221. Lay the groundwork to move configuration into PHP, so we can show descriptions in the web UI, do typechecking, disable application options when an application is uninstalled, etc. Test Plan: {F28421} {F28420} {F28422} Reviewers: codeblock, btrahan, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221, T2255 Differential Revision: https://secure.phabricator.com/D4306
2012-12-31 00:36:06 +01:00
'PhabricatorApplicationConfigOptions' => 'applications/config/option/PhabricatorApplicationConfigOptions.php',
Modularize application configuration panels Summary: Ref T7149. This is a few steps away, but: - Generally, I'd like to reduce the amount of "Config" configuration we have. - One good way to do this is to move it into UIs in Application configuration. We did this with email recently. - I think this was a great change and I'd like to keep moving in this direction. - T7149 touches configuration related to file storage engines. Although I'm not planning to fully move configuration into applications yet, it would be easier to debug and test if I could drop a read-only panel there to show engines. - So, modularize the config stuff so I can add a new panel without hard-coding it. Test Plan: - Added, edited, and deleted application emails. - Viewed non-email application detail pages. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12051
2015-03-12 21:28:37 +01:00
'PhabricatorApplicationConfigurationPanel' => 'applications/meta/panel/PhabricatorApplicationConfigurationPanel.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorApplicationConfigurationPanelTestCase' => 'applications/meta/panel/__tests__/PhabricatorApplicationConfigurationPanelTestCase.php',
Modernize global search typeahead datasource Summary: Ref T4420. Bring the global search up to date. Test Plan: Typed various things into global search. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9889
2014-07-18 00:48:36 +02:00
'PhabricatorApplicationDatasource' => 'applications/meta/typeahead/PhabricatorApplicationDatasource.php',
Application Detail View Summary: Added Applications Details View Applications Detail View Test Plan: In "Applications" application, clicked on each application to check whether the each application detail view is displayed. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4615
2013-01-24 21:13:31 +01:00
'PhabricatorApplicationDetailViewController' => 'applications/meta/controller/PhabricatorApplicationDetailViewController.php',
Allow application policies to be edited Summary: Ref T603. Enables: - Application policies can be edited. - Applications can define custom policies (this will be used for setting defaults, like "what is the default visibiltiy of new tasks", and meta-policies, like "who can create a task?"). Test Plan: Edited application policies. A future diff does more with custom policies. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7205
2013-10-03 21:40:08 +02:00
'PhabricatorApplicationEditController' => 'applications/meta/controller/PhabricatorApplicationEditController.php',
Provide contextual documentation explaining how to prefill ApplicationEditor create forms Summary: Ref T9132. Although forms do generally support prefilling right now, you have to guess how to do it. Provide an explicit action showing you which values are supported and how to prefill them. This is generated automatically when an application switches to ApplicationEditor. Test Plan: {F939804} {F939805} {F939806} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14392
2015-11-03 14:38:06 +01:00
'PhabricatorApplicationEditHTTPParameterHelpView' => 'applications/transactions/view/PhabricatorApplicationEditHTTPParameterHelpView.php',
Generate mail command documentation from active commands Summary: Ref T7199. This needs some polish and isn't reachable from the UI, but technically has all of the information. Test Plan: {F355899} {F355900} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12241
2015-04-01 16:36:16 +02:00
'PhabricatorApplicationEmailCommandsController' => 'applications/meta/controller/PhabricatorApplicationEmailCommandsController.php',
Add a meta-application Summary: - Adds a new "Applications" application. - Builds an application list via application config instead of via hard-coding, so we can move toward better concepts of installing/uninstalling applications, etc. - Applications indicate that they need attention with notice counts and brief status messages rathern than 50 giant tables of all sorts of app data. I want to try replacing the home screen with this screen, pretty much. Not sure if this is totally crazy or not. What does everyone else think? Test Plan: Will add screenshots. Reviewers: btrahan, chad, vrana, alanh Reviewed By: vrana CC: aran, davidreuss, champo Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3129
2012-08-02 23:07:21 +02:00
'PhabricatorApplicationLaunchView' => 'applications/meta/view/PhabricatorApplicationLaunchView.php',
Modularize application configuration panels Summary: Ref T7149. This is a few steps away, but: - Generally, I'd like to reduce the amount of "Config" configuration we have. - One good way to do this is to move it into UIs in Application configuration. We did this with email recently. - I think this was a great change and I'd like to keep moving in this direction. - T7149 touches configuration related to file storage engines. Although I'm not planning to fully move configuration into applications yet, it would be easier to debug and test if I could drop a read-only panel there to show engines. - So, modularize the config stuff so I can add a new panel without hard-coding it. Test Plan: - Added, edited, and deleted application emails. - Viewed non-email application detail pages. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12051
2015-03-12 21:28:37 +01:00
'PhabricatorApplicationPanelController' => 'applications/meta/controller/PhabricatorApplicationPanelController.php',
Use ApplicationSearch in Applications application Summary: Ref T603. OMG SO META Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7197
2013-10-02 22:13:07 +02:00
'PhabricatorApplicationQuery' => 'applications/meta/query/PhabricatorApplicationQuery.php',
Use delegation to generalize application search controllers Summary: Ref T2625. Lifts almost all of the search logic out of Paste controllers and into Search. This uses controller delegation for generalization. We use this in a few places, but don't use it very much yet. I think it's pretty reasonable as-is, but I might be able to make even more stuff free. There are some slightly rough edges around routes, still, but I want to hit Phame and Differential (which both have multiple application search engines) before trying to generalize that. Test Plan: Executed, browsed and managed Paste searches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6073
2013-05-30 23:09:02 +02:00
'PhabricatorApplicationSearchController' => 'applications/search/controller/PhabricatorApplicationSearchController.php',
Move paste search to generic search. Summary: Begin implementing generic application search and refactoring paste search. Test Plan: See if the paste search still works. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5621
2013-04-14 15:53:20 +02:00
'PhabricatorApplicationSearchEngine' => 'applications/search/engine/PhabricatorApplicationSearchEngine.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorApplicationSearchEngineTestCase' => 'applications/search/engine/__tests__/PhabricatorApplicationSearchEngineTestCase.php',
[Redesign] PhabricatorApplicationSearchResultView Summary: Ref T8099. This adds a new class which all search engines return for layout. I thought about this a number of ways, and I think this is the cleanest path. Each Engine can return whatever UI bits they needs, and AppSearch or Dashboard picks and lays the bits out as needed. In the AppSearch case, interfaces like Notifications, Calendar, Legalpad all need more custom layouts. I think this also leaves a resonable path forward for NUX as well. Also, not sure I implemented the class correctly, but assume thats easy to fix? Test Plan: Review and do a search in each application changed. Grep for all call sites. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T8099 Differential Revision: https://secure.phabricator.com/D13332
2015-06-19 12:46:20 +02:00
'PhabricatorApplicationSearchResultView' => 'applications/search/view/PhabricatorApplicationSearchResultView.php',
Add a meta-application Summary: - Adds a new "Applications" application. - Builds an application list via application config instead of via hard-coding, so we can move toward better concepts of installing/uninstalling applications, etc. - Applications indicate that they need attention with notice counts and brief status messages rathern than 50 giant tables of all sorts of app data. I want to try replacing the home screen with this screen, pretty much. Not sure if this is totally crazy or not. What does everyone else think? Test Plan: Will add screenshots. Reviewers: btrahan, chad, vrana, alanh Reviewed By: vrana CC: aran, davidreuss, champo Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3129
2012-08-02 23:07:21 +02:00
'PhabricatorApplicationStatusView' => 'applications/meta/view/PhabricatorApplicationStatusView.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorApplicationTestCase' => 'applications/base/__tests__/PhabricatorApplicationTestCase.php',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransaction' => 'applications/transactions/storage/PhabricatorApplicationTransaction.php',
'PhabricatorApplicationTransactionComment' => 'applications/transactions/storage/PhabricatorApplicationTransactionComment.php',
Allow ApplicationTransaction comments to be edited and deleted Summary: Allows you to edit or delete comments in appplications which support ApplicationTransactions. UI/UX stuff: - The dialogs are rough but I want to do a dialog design pass more generally, @chad has some mocks. - When you add new mentions via edit, they don't currently count as mentions. I'm not sure what I want to do about this. - When you edit or delete a comment, we do not publish any notifications about it. I think this is reasonable. - I didn't separate "delete" out versus "edit"; I assume it will be reasonably intuitive that deleting all the text deletes effectively deletes the comment. I also want to discourage deletion somewhat (we still show the transaction, just show that the comment has been deleted). Test Plan: Transaction view, note "Edit" and "Edited" links: {F26914} Edit view, has some design issues but I want to do a pass on dialogs in general: {F26915} History view: {F26913} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1082 Differential Revision: https://secure.phabricator.com/D4149
2012-12-11 23:01:51 +01:00
'PhabricatorApplicationTransactionCommentEditController' => 'applications/transactions/controller/PhabricatorApplicationTransactionCommentEditController.php',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionCommentEditor' => 'applications/transactions/editor/PhabricatorApplicationTransactionCommentEditor.php',
Allow ApplicationTransaction comments to be edited and deleted Summary: Allows you to edit or delete comments in appplications which support ApplicationTransactions. UI/UX stuff: - The dialogs are rough but I want to do a dialog design pass more generally, @chad has some mocks. - When you add new mentions via edit, they don't currently count as mentions. I'm not sure what I want to do about this. - When you edit or delete a comment, we do not publish any notifications about it. I think this is reasonable. - I didn't separate "delete" out versus "edit"; I assume it will be reasonably intuitive that deleting all the text deletes effectively deletes the comment. I also want to discourage deletion somewhat (we still show the transaction, just show that the comment has been deleted). Test Plan: Transaction view, note "Edit" and "Edited" links: {F26914} Edit view, has some design issues but I want to do a pass on dialogs in general: {F26915} History view: {F26913} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1082 Differential Revision: https://secure.phabricator.com/D4149
2012-12-11 23:01:51 +01:00
'PhabricatorApplicationTransactionCommentHistoryController' => 'applications/transactions/controller/PhabricatorApplicationTransactionCommentHistoryController.php',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionCommentQuery' => 'applications/transactions/query/PhabricatorApplicationTransactionCommentQuery.php',
Add a quote action to Differential and Maniphest Summary: Ref T4119. This is ugly for now, but technically works. The comment area and transaction log don't realy know about each other, so for the moment the linking is a bit manual. Differential/Maniphest are special cases anyway. Test Plan: {F149992} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4119 Differential Revision: https://secure.phabricator.com/D8957
2014-05-05 19:55:58 +02:00
'PhabricatorApplicationTransactionCommentQuoteController' => 'applications/transactions/controller/PhabricatorApplicationTransactionCommentQuoteController.php',
Transactions - add "view raw" action Summary: Use cutlery icon for hilarity. Ref T5768. Test Plan: made something with remarkup in it, used 'view raw' and saw the remarkup raw in a nice little dialogue. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5768 Differential Revision: https://secure.phabricator.com/D10183
2014-08-08 00:21:32 +02:00
'PhabricatorApplicationTransactionCommentRawController' => 'applications/transactions/controller/PhabricatorApplicationTransactionCommentRawController.php',
Allow users to remove their own comments, and administrators to remove any comment Summary: Fixes T4909. Adds a "remove" link next to the edit link, which permanently hides a comment. Addresses two use cases: - Allowing administrators to clean up spam. - Allowing users to try to put the genie back in the bottle if they post passwords or sensitive links, etc. The user who removed the comment is named in the removal text to enforce some level of administrative accountability. No data is deleted, but there's currently no method to restore these comments. We'll see if we need one. This is cheating a little bit by storing "removed" as "2" in the isDeleted field. This doesn't seem tooooo bad for now. Test Plan: - Removed some of my comments. - As an administrator, removed other users' comments. - Failed to view history of a removed comment. - Failed to edit a removed comment. - Failed to remove a removed comment. - Verified feed doesn't show the old comment after comment removal. Reviewers: btrahan Reviewed By: btrahan Subscribers: qgil, chad, epriestley Maniphest Tasks: T4909 Differential Revision: https://secure.phabricator.com/D8945
2014-05-05 19:55:32 +02:00
'PhabricatorApplicationTransactionCommentRemoveController' => 'applications/transactions/controller/PhabricatorApplicationTransactionCommentRemoveController.php',
Add previews to ApplicationTransaction Summary: Implements previews for Macros and Pholio. (Design is nonfinal -- kind of split the difference between `diff_full_view.png`, laziness, and space concerns. Next couple diffs will add more stuff here.) Test Plan: {F28055} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, vrana Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4246
2012-12-21 14:51:33 +01:00
'PhabricatorApplicationTransactionCommentView' => 'applications/transactions/view/PhabricatorApplicationTransactionCommentView.php',
Allow ApplicationTransaction comments to be edited and deleted Summary: Allows you to edit or delete comments in appplications which support ApplicationTransactions. UI/UX stuff: - The dialogs are rough but I want to do a dialog design pass more generally, @chad has some mocks. - When you add new mentions via edit, they don't currently count as mentions. I'm not sure what I want to do about this. - When you edit or delete a comment, we do not publish any notifications about it. I think this is reasonable. - I didn't separate "delete" out versus "edit"; I assume it will be reasonably intuitive that deleting all the text deletes effectively deletes the comment. I also want to discourage deletion somewhat (we still show the transaction, just show that the comment has been deleted). Test Plan: Transaction view, note "Edit" and "Edited" links: {F26914} Edit view, has some design issues but I want to do a pass on dialogs in general: {F26915} History view: {F26913} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1082 Differential Revision: https://secure.phabricator.com/D4149
2012-12-11 23:01:51 +01:00
'PhabricatorApplicationTransactionController' => 'applications/transactions/controller/PhabricatorApplicationTransactionController.php',
Transactions - make the details stuff generic and ajaxy Summary: Fixes T2213 Test Plan: Updated a pholio mock description. Observed that when I first showed details there was a round trip made. Toggled show / hide noting no more trips made to server. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T2213 Differential Revision: https://secure.phabricator.com/D6801
2013-08-23 01:45:14 +02:00
'PhabricatorApplicationTransactionDetailController' => 'applications/transactions/controller/PhabricatorApplicationTransactionDetailController.php',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionEditor' => 'applications/transactions/editor/PhabricatorApplicationTransactionEditor.php',
Add feed integration to generic transactions Summary: Publish feed stories, including from Pholio. Actual stories are somewhat garbage but it's all display-time; I'm going to do a pass on feed in general. Test Plan: {F26832} Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4140
2012-12-11 23:00:21 +01:00
'PhabricatorApplicationTransactionFeedStory' => 'applications/transactions/feed/PhabricatorApplicationTransactionFeedStory.php',
Integrate subscriptions with ApplicationTransactions Summary: Fixes T2214. For objects which support ApplicationTransaction, use ApplicationTransactions to apply subscription action changes. Principally, this makes clicking "Subscribe" / "Unsubscribe" appear correctly in the transaction log. Test Plan: Clicked "Subscribe" and "Unsubscribe" a on Macros and Mocks. Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2214 Differential Revision: https://secure.phabricator.com/D4986
2013-02-17 15:37:09 +01:00
'PhabricatorApplicationTransactionInterface' => 'applications/transactions/interface/PhabricatorApplicationTransactionInterface.php',
Add ApplicationTransaction handling for transactions with no effect Summary: When a user submits an action with no effect (like an empty comment, an "abandon" on an already-accepted revision, or a "close, resolved" on a closed task) we want to alert them that their action isn't effective. These warnings fall into two general buckets: - User is submitting two or more actions, and some aren't effective but some are. Prompt them to apply the effective actions only. - A special case of this is where the only effective action is a comment. We provide tailored text ("Post Comment") in this case. - User is submitting one action, which isn't effective. Tell them they're out of luck. - A special case of this is an empty comment. We provide tailored text in this case. By default, the transaction editor throws when transactions have no effect. The caller can then deal with this, or use `PhabricatorApplicationTransactionNoEffectResponse` to provide a standard dialog that gives the user information as above. For cases where we expect transactions to have no effect (notably, "edit" forms) we just continue on no-effect unconditionally. Also fix an issue where new, combined or filtered transactions would not be represented properly in the Ajax response (i.e., return final transactions from `applyTransactions()`), and translate some strings. Test Plan: - Submitted empty and nonempy comments in Macro and Pholio. - Submitted comments with new and existing "@mentions". - Submitted edits in both applications. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T912, T2104 Differential Revision: https://secure.phabricator.com/D4160
2012-12-12 02:27:40 +01:00
'PhabricatorApplicationTransactionNoEffectException' => 'applications/transactions/exception/PhabricatorApplicationTransactionNoEffectException.php',
'PhabricatorApplicationTransactionNoEffectResponse' => 'applications/transactions/response/PhabricatorApplicationTransactionNoEffectResponse.php',
Allow TransactionEditor to move publishing work to the daemons Summary: Ref T6367. This is similar to D11329, but not quite as ambitious. Allow Editors to implement `supportsWorkers()` and move their publishing work into a daemon. So far, only Paste supports this. Most of the complexity here is saving and restoring state across the barrier between the web process and the worker process, but I think this is ~90% of it and then we'll pick up a couple of random things in applications. I'm primarily trying to keep this as gradual as possible. Test Plan: - Published transactions with and without daemon support. - Looked at mail, feed. Reviewers: btrahan Reviewed By: btrahan Subscribers: fabe, epriestley Maniphest Tasks: T6367 Differential Revision: https://secure.phabricator.com/D13107
2015-06-02 02:16:27 +02:00
'PhabricatorApplicationTransactionPublishWorker' => 'applications/transactions/worker/PhabricatorApplicationTransactionPublishWorker.php',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionQuery' => 'applications/transactions/query/PhabricatorApplicationTransactionQuery.php',
Put inline previews in remarkup textareas Summary: Ref T3967. This gives us a reasonable baseline for doing remarkup previews inline in all contexts, and works in weird/constrained context including: - inline comments; - conpherence; and - custom fields. It would be nicer to go beyond this in contexts like Phame posts, but this is a start, at least. Test Plan: {F1040877} {F1040878} Reviewers: chad Reviewed By: chad Maniphest Tasks: T3967 Differential Revision: https://secure.phabricator.com/D14855
2015-12-22 20:32:07 +01:00
'PhabricatorApplicationTransactionRemarkupPreviewController' => 'applications/transactions/controller/PhabricatorApplicationTransactionRemarkupPreviewController.php',
Lift common code for transaction-based reply handlers into parent class Summary: Ref T7199. Essentially all of the reply handlers now apply transactions to something which implements PhabricatorApplicationTransactionInterface. We can share code between them by lifting this stuff into a superclass. First, convert paste. Also rename `PasteMockMailReceiver` to `PasteMailReceiver` (this got mis-copied from Pholio at some point, I think). Test Plan: Used `bin/mail receive-test` to send comments + `!unsubscribe` to pastes. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12236
2015-04-01 17:39:21 +02:00
'PhabricatorApplicationTransactionReplyHandler' => 'applications/transactions/replyhandler/PhabricatorApplicationTransactionReplyHandler.php',
Render application transactions via Ajax Summary: When possible, render application transactions via Ajax. Instead of reloading the page when the response returns, append new transactions to the transaction view. Scroll the window to the new transactions, animate them in, and clear the form to make this interaction feel reasonable. When editing transactions, fade them in but do not scroll to them (i.e., don't disrupt the user's position). Test Plan: Edited and appended transactions via Ajax. Observed fade in animations and scroll behavior. Clicked anchors to verify proper anchor accounting. Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1960 Differential Revision: https://secure.phabricator.com/D4151
2012-12-11 23:02:29 +01:00
'PhabricatorApplicationTransactionResponse' => 'applications/transactions/response/PhabricatorApplicationTransactionResponse.php',
Transactions - add pagination to application transactions Summary: Ref T4712. This adds pagination. Future diffs will need to deploy `buildTransactionTimeline` everywhere and massage this stuff as necessary if we hit any special cases. Test Plan: Set page size to "5" to make it need to paginate often. Verified proper transactions loaded in and the javascript actions worked. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10887
2014-12-02 22:10:29 +01:00
'PhabricatorApplicationTransactionShowOlderController' => 'applications/transactions/controller/PhabricatorApplicationTransactionShowOlderController.php',
Improve ApplicationTransaction behavior for poorly constructed transactions Summary: Ref T2222. Five very small improvements: - I hit this exception and it took a bit to understand which transaction was causing problems. Add an `Exception` subclass which does a better job of making the message debuggable. - The `oldValue` of a transaction may be `null`, legitimately (for example, changing the `repositoryPHID` for a revision from `null` to some valid PHID). Do a check to see if `setOldValue()` has been called, instead of a check for a `null` value. - Add an additional check for the other case (shouldn't have a value, but does). - When we're not generating a value, don't bother calling the code to generate it. The best case scenario is that it has no effect; any effect it might have (changing the value) is always wrong. - Maniphest didn't fall back to the parent correctly when computing this flag, so it got the wrong result for `CustomField` transactions. Test Plan: Resolved the issue I was hitting more easily, made updates to a `null`-valued custom field, and applied other normal sorts of transactions successfully. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4557, T2222 Differential Revision: https://secure.phabricator.com/D8401
2014-03-05 19:44:21 +01:00
'PhabricatorApplicationTransactionStructureException' => 'applications/transactions/exception/PhabricatorApplicationTransactionStructureException.php',
Prepare TransactionCommentQuery for extension Summary: Ref T2009. Ref T1460. The way Diffusion and Differential load inlines is horrible garbage right now: - Differential does an ad-hoc query to get the PHIDs, then does a real load to policy check. - Diffusion completely fakes things. In practice this is not a policy violation, but it's dangerous. Make TransactionCommentQuery extensible so we can subclass it and get the query building correctly in the right Query layer. Specifically, the Diffusion and Differential subclasses of this Query will add appropriate `withX()` methods to let us express the query in SQL. Test Plan: Loaded, previewed, edited, and submitted inlines in Differential and Diffusion Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2009, T1460 Differential Revision: https://secure.phabricator.com/D12026
2015-03-09 20:15:54 +01:00
'PhabricatorApplicationTransactionTemplatedCommentQuery' => 'applications/transactions/query/PhabricatorApplicationTransactionTemplatedCommentQuery.php',
Implement basic transaction detail blocks Summary: Some transactions (like editing configuration values, task descriptions, or Conpherence images) can't be simply explained and need an additional larger element to show them fully (like a text diff). Support change details like this in ApplicationTransactions. Implements the element in Config, so you can see changes. Test Plan: {F32974} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2213 Differential Revision: https://secure.phabricator.com/D4984
2013-02-17 15:37:02 +01:00
'PhabricatorApplicationTransactionTextDiffDetailView' => 'applications/transactions/view/PhabricatorApplicationTransactionTextDiffDetailView.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorApplicationTransactionTransactionPHIDType' => 'applications/transactions/phid/PhabricatorApplicationTransactionTransactionPHIDType.php',
Allow custom fields to have validation logic Summary: Ref T418. This is fairly messy, but basically: - Add a validation phase to TransactionEditor. - Add a validation phase to CustomField. - Bring it to StandardField. - Add validation logic for the int field. - Provide support in related classes. Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D7028
2013-09-19 00:31:58 +02:00
'PhabricatorApplicationTransactionValidationError' => 'applications/transactions/error/PhabricatorApplicationTransactionValidationError.php',
'PhabricatorApplicationTransactionValidationException' => 'applications/transactions/exception/PhabricatorApplicationTransactionValidationException.php',
Differential - return a better response for validation error cases Summary: Fixes T6989. Basically return a nice dialogue like we do for "NoEffect" transactions. This is a little prettier than the other dialogue was. Also, stop adding TYPE_EDGE as a transaction type as we end up having it 2x, which then makes the error get validated 2x. Test Plan: tried to add myself as a reviewer and got a nice error message. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6989 Differential Revision: https://secure.phabricator.com/D11448
2015-01-20 22:59:17 +01:00
'PhabricatorApplicationTransactionValidationResponse' => 'applications/transactions/response/PhabricatorApplicationTransactionValidationResponse.php',
Policy Transactions - add a details view for custom policy Summary: 'cuz those can be complicated. Fixes T4738. I needed to do a fair amount of heavy lifting to get the policy stuff rendering correctly. For now, I made this end point very one purpose and tried to make that clear. Test Plan: looked at some custom policies. see screenshots. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4738 Differential Revision: https://secure.phabricator.com/D8890
2014-04-29 18:42:54 +02:00
'PhabricatorApplicationTransactionValueController' => 'applications/transactions/controller/PhabricatorApplicationTransactionValueController.php',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorApplicationTransactionView' => 'applications/transactions/view/PhabricatorApplicationTransactionView.php',
Installation & Uninstallion of Applications Summary: Created Applications application which allows uninstallation & installation of application. Test Plan: In "Applications" application, clicked on uninstalled the application by cliking Uninstall and chekcing whether they are really uninstalled(Disabling URI & in appearance in the side pane). Then Clicked on the install button of the uninstalled application to check whether they are installed. Reviewers: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4715
2013-01-29 18:14:03 +01:00
'PhabricatorApplicationUninstallController' => 'applications/meta/controller/PhabricatorApplicationUninstallController.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorApplicationsApplication' => 'applications/meta/application/PhabricatorApplicationsApplication.php',
Initial Commint Summary: Created "Applications" application which lists all the installed applications in phabricator. Test Plan: Navigated to localphabricatorinstall.com/applications and check whether it actually shows the list of all installed applications. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2352 Differential Revision: https://secure.phabricator.com/D4548
2013-01-19 22:46:48 +01:00
'PhabricatorApplicationsController' => 'applications/meta/controller/PhabricatorApplicationsController.php',
'PhabricatorApplicationsListController' => 'applications/meta/controller/PhabricatorApplicationsListController.php',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorAsanaAuthProvider' => 'applications/auth/provider/PhabricatorAsanaAuthProvider.php',
Initial Asana sync for Differential Summary: Ref T2852. This is highly incomplete but seems structurally sound. Some additional context is available in the Google doc. - Add a workspace ID configuration. Without it, nothing else activates. - Add a worker which reacts to feed stories. - Feed stories about things which aren't Differential objects are ignored. - We load the revision, or fail permanently if we can't. - We get all the related user PHIDs (author, reviewers, CCs). - We check if any of them have linked Asana accounts, or fail permanently if they don't. - We check for an "ASANATASK" edge from the revision. - If we do not find one, we create a new task. - If we do find one, we load the task. - If we succeed, we check the chronological key of the most recent synchronized feed story ("cursor"). - If this story is the same or newer, we update the task to synchronize it to the current state of the revision. - If we fail to load the task, we fail permanently ("asana task has been deleted"). - We then publish the actual story text to the task. Not in yet: - Updating followers requires separate API calls which we don't do yet. - No subtasks yet. - No sync of open/closed state. Test Plan: {F47546} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6302
2013-06-26 01:33:16 +02:00
'PhabricatorAsanaConfigOptions' => 'applications/doorkeeper/option/PhabricatorAsanaConfigOptions.php',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorAsanaSubtaskHasObjectEdgeType' => 'applications/doorkeeper/edge/PhabricatorAsanaSubtaskHasObjectEdgeType.php',
'PhabricatorAsanaTaskHasObjectEdgeType' => 'applications/doorkeeper/edge/PhabricatorAsanaTaskHasObjectEdgeType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorAuditActionConstants' => 'applications/audit/constants/PhabricatorAuditActionConstants.php',
'PhabricatorAuditAddCommentController' => 'applications/audit/controller/PhabricatorAuditAddCommentController.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorAuditApplication' => 'applications/audit/application/PhabricatorAuditApplication.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorAuditCommentEditor' => 'applications/audit/editor/PhabricatorAuditCommentEditor.php',
'PhabricatorAuditCommitStatusConstants' => 'applications/audit/constants/PhabricatorAuditCommitStatusConstants.php',
'PhabricatorAuditController' => 'applications/audit/controller/PhabricatorAuditController.php',
Provide a transaction editor to perform Audit row writes Summary: Ref T4896. Replaces more custom stuff with standard stuff. In particular: - No more fake proxy writes; - no more fake detection of `@mentions`. For now, the old code still applies most of the effects and handles feed and email. Test Plan: - Added comments. - Added comments with inline comments. - Added just inline comments. - Added comments with Conduit. - Previewed comments. - Added CCs explicitly and with `@mentions`. - Added auditors. - Accepted a commit. Reviewers: joshuaspence, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4896 Differential Revision: https://secure.phabricator.com/D10109
2014-08-02 09:06:25 +02:00
'PhabricatorAuditEditor' => 'applications/audit/editor/PhabricatorAuditEditor.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorAuditInlineComment' => 'applications/audit/storage/PhabricatorAuditInlineComment.php',
'PhabricatorAuditListController' => 'applications/audit/controller/PhabricatorAuditListController.php',
'PhabricatorAuditListView' => 'applications/audit/view/PhabricatorAuditListView.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorAuditMailReceiver' => 'applications/audit/mail/PhabricatorAuditMailReceiver.php',
Provide a more flexible script for administrative management of audits Summary: Fixes T3679. This comes up every so often and the old script is extremely broad (nuke everything in a repository). Provide a more surgical tool. Test Plan: Ran a bunch of variations of the script and they all seemed to work OK. Reviewers: btrahan Reviewed By: btrahan CC: aran, staticshock Maniphest Tasks: T3679 Differential Revision: https://secure.phabricator.com/D6678
2013-08-05 19:35:01 +02:00
'PhabricatorAuditManagementDeleteWorkflow' => 'applications/audit/management/PhabricatorAuditManagementDeleteWorkflow.php',
'PhabricatorAuditManagementWorkflow' => 'applications/audit/management/PhabricatorAuditManagementWorkflow.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorAuditPreviewController' => 'applications/audit/controller/PhabricatorAuditPreviewController.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorAuditReplyHandler' => 'applications/audit/mail/PhabricatorAuditReplyHandler.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorAuditStatusConstants' => 'applications/audit/constants/PhabricatorAuditStatusConstants.php',
Add storage for new audit transactions and comments Summary: Ref T4896. This adds the new storage, without any code changes. This storage is substantially identical to the Differential storage, except that `changesetID` has been replaced by `pathID`. I've retained the properties intended to be used to implement T1460. They might not be quite right, but at least we'll be able to make any fixes consistently to both applications. For now, these fields are empty and ignored. Test Plan: Ran `./bin/storage upgrade`. Nothing calls this code yet. Reviewers: btrahan, joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T4896 Differential Revision: https://secure.phabricator.com/D10017
2014-07-25 02:59:43 +02:00
'PhabricatorAuditTransaction' => 'applications/audit/storage/PhabricatorAuditTransaction.php',
'PhabricatorAuditTransactionComment' => 'applications/audit/storage/PhabricatorAuditTransactionComment.php',
'PhabricatorAuditTransactionQuery' => 'applications/audit/query/PhabricatorAuditTransactionQuery.php',
Convert Audit comment rendering to standard infrastructure Summary: Ref T4896. Depends on D10055. This uses core rendering stuff for audit comments, and fixes all the wonkiness with inlines so we can actually land the migration. Test Plan: Viewed, previewed and edited various types of comments in Diffusion. Reviewers: chad, btrahan, joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T4896 Differential Revision: https://secure.phabricator.com/D10056
2014-07-29 00:01:43 +02:00
'PhabricatorAuditTransactionView' => 'applications/audit/view/PhabricatorAuditTransactionView.php',
Show account cards for external accounts on "linked accounts" screen and "link new account" Summary: Ref T1536. These can probably use some design tweaking and there's a bit of a bug with profile images for some providers, but generally seems to be in the right ballpark. Test Plan: {F46604} {F46605} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6210
2013-06-17 16:08:50 +02:00
'PhabricatorAuthAccountView' => 'applications/auth/view/PhabricatorAuthAccountView.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorAuthApplication' => 'applications/auth/application/PhabricatorAuthApplication.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorAuthAuthFactorPHIDType' => 'applications/auth/phid/PhabricatorAuthAuthFactorPHIDType.php',
Transactions - deploy buildTransactionTimeline against a few more applications Summary: Ref T4712. Thus far, it seems that most "non-standard" things can be done pretty easily in the controller. Aside from deploying, this diff had to fix a few bugs / missing implementations of stuff. (Notably, PhabricatorAuthProviderConfig, HeraldRule, PhabricatorSlowvotePoll, and AlmanacNetwork needed to implement PhabricatorApplicationTransactionInterface, PhabricatorAuthAuthProviderPHIDType had to be added, and a rendering bug in transactions of type PhabricatorOAuth2AuthProvider had to be fixed.) Test Plan: Almanac - looked at binding, device, network, and service view controllers and verified timeline displayed properly. Herald - looked at a rule and verified timeline. Slowvote - looked at a vote and verified timeline. Auth - looked at an auth provider (Facebook) and verified proper display of transactions within timeline. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10921
2014-12-02 23:33:59 +01:00
'PhabricatorAuthAuthProviderPHIDType' => 'applications/auth/phid/PhabricatorAuthAuthProviderPHIDType.php',
Add auth.querypublickeys to retrieve public keys Summary: Fixes T6484. I primarily need this to synchronize device public keys in the Phabricator cluster so the new stuff in T2783 works. Although, actually, maybe I don't really need it. But I wrote it anyway and it's desirable to have sooner or later. Test Plan: Ran method. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6484 Differential Revision: https://secure.phabricator.com/D11163
2015-02-11 00:44:21 +01:00
'PhabricatorAuthConduitAPIMethod' => 'applications/auth/conduit/PhabricatorAuthConduitAPIMethod.php',
Move all account link / unlink to new registration flow Summary: Ref T1536. Currently, we have separate panels for each link/unlink and separate controllers for OAuth vs LDAP. Instead, provide a single "External Accounts" panel which shows all linked accounts and allows you to link/unlink more easily. Move link/unlink over to a full externalaccount-based workflow. Test Plan: - Linked and unlinked OAuth accounts. - Linked and unlinked LDAP accounts. - Registered new accounts. - Exercised most/all of the error cases. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6189
2013-06-17 15:12:45 +02:00
'PhabricatorAuthConfirmLinkController' => 'applications/auth/controller/PhabricatorAuthConfirmLinkController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorAuthController' => 'applications/auth/controller/PhabricatorAuthController.php',
Add storage for Auth configuration in preparation for moving it into a web interface Summary: Ref T1536. Currently, we have about 40 auth-related configuration options. This is already roughly 20% of our config, and we want to add more providers. Additionally, we want to turn some of these auth options into multi-auth options (e.g., allow multiple Phabricator OAuth installs, or, theoretically multiple LDAP servers). I'm going to move this into a separate "Auth" tool with a minimal CLI (`bin/auth`) interface and a more full web interface. Roughly: - Administrators will use the app to manage authentication providers. - The `bin/auth` CLI will provide a safety hatch if you lock yourself out by disabling all usable providers somehow. - We'll migrate existing configuration into the app and remove it. General goals: - Make it much easier to configure authentication by providing an interface for it. - Make it easier to configure everything else by reducing the total number of available options. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6196
2013-06-17 19:48:41 +02:00
'PhabricatorAuthDAO' => 'applications/auth/storage/PhabricatorAuthDAO.php',
Allow AuthenticationProviderConfig to be enabled and disabled Summary: Ref T1536. Nothing too exciting here, one TODO about tailoring error messages. Test Plan: {F46403} {F46404} {F46405} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6204
2013-06-17 19:54:08 +02:00
'PhabricatorAuthDisableController' => 'applications/auth/controller/config/PhabricatorAuthDisableController.php',
Add "High Security" mode to support multi-factor auth Summary: Ref T4398. This is roughly a "sudo" mode, like GitHub has for accessing SSH keys, or Facebook has for managing credit cards. GitHub actually calls theirs "sudo" mode, but I think that's too technical for big parts of our audience. I've gone with "high security mode". This doesn't actually get exposed in the UI yet (and we don't have any meaningful auth factors to prompt the user for) but the workflow works overall. I'll go through it in a comment, since I need to arrange some screenshots. Test Plan: See guided walkthrough. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8851
2014-04-28 02:31:11 +02:00
'PhabricatorAuthDowngradeSessionController' => 'applications/auth/controller/PhabricatorAuthDowngradeSessionController.php',
Very rough edit workflow for AuthProvider configuration Summary: Ref T1536. Many rough / broken edges, but adds the rough skeleton of the provider edit workflow. Test Plan: {F46333} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6200
2013-06-17 19:52:38 +02:00
'PhabricatorAuthEditController' => 'applications/auth/controller/config/PhabricatorAuthEditController.php',
Add multi-factor auth and TOTP support Summary: Ref T4398. This is still pretty rough and isn't exposed in the UI yet, but basically works. Some missing features / areas for improvement: - Rate limiting attempts (see TODO). - Marking tokens used after they're used once (see TODO), maybe. I can't think of ways an attacker could capture a token without also capturing a session, offhand. - Actually turning this on (see TODO). - This workflow is pretty wordy. It would be nice to calm it down a bit. - But also add more help/context to help users figure out what's going on here, I think it's not very obvious if you don't already know what "TOTP" is. - Add admin tool to strip auth factors off an account ("Help, I lost my phone and can't log in!"). - Add admin tool to show users who don't have multi-factor auth? (so you can pester them) - Generate QR codes to make the transfer process easier (they're fairly complicated). - Make the "entering hi-sec" workflow actually check for auth factors and use them correctly. - Turn this on so users can use it. - Adding SMS as an option would be nice eventually. - Adding "password" as an option, maybe? TOTP feels fairly good to me. I'll post a couple of screens... Test Plan: - Added TOTP token with Google Authenticator. - Added TOTP token with Authy. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8875
2014-04-28 18:27:11 +02:00
'PhabricatorAuthFactor' => 'applications/auth/factor/PhabricatorAuthFactor.php',
'PhabricatorAuthFactorConfig' => 'applications/auth/storage/PhabricatorAuthFactorConfig.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorAuthFactorTestCase' => 'applications/auth/factor/__tests__/PhabricatorAuthFactorTestCase.php',
Require multiple auth factors to establish web sessions Summary: Ref T4398. This prompts users for multi-factor auth on login. Roughly, this introduces the idea of "partial" sessions, which we haven't finished constructing yet. In practice, this means the session has made it through primary auth but not through multi-factor auth. Add a workflow for bringing a partial session up to a full one. Test Plan: - Used Conduit. - Logged in as multi-factor user. - Logged in as no-factor user. - Tried to do non-login-things with a partial session. - Reviewed account activity logs. {F149295} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8922
2014-05-01 19:23:02 +02:00
'PhabricatorAuthFinishController' => 'applications/auth/controller/PhabricatorAuthFinishController.php',
Add "High Security" mode to support multi-factor auth Summary: Ref T4398. This is roughly a "sudo" mode, like GitHub has for accessing SSH keys, or Facebook has for managing credit cards. GitHub actually calls theirs "sudo" mode, but I think that's too technical for big parts of our audience. I've gone with "high security mode". This doesn't actually get exposed in the UI yet (and we don't have any meaningful auth factors to prompt the user for) but the workflow works overall. I'll go through it in a comment, since I need to arrange some screenshots. Test Plan: See guided walkthrough. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8851
2014-04-28 02:31:11 +02:00
'PhabricatorAuthHighSecurityRequiredException' => 'applications/auth/exception/PhabricatorAuthHighSecurityRequiredException.php',
'PhabricatorAuthHighSecurityToken' => 'applications/auth/data/PhabricatorAuthHighSecurityToken.php',
Add email invites to Phabricator (logic only) Summary: Ref T7152. This builds the core of email invites and implements all the hard logic for them, covering it with a pile of tests. There's no UI to create these yet, so users can't actually get invites (and administrators can't send them). This stuff is a complicated mess because there are so many interactions between accounts, email addresses, email verification, email primary-ness, and user verification. However, I think I got it right and got test coverage everwhere. The degree to which this is exception-driven is a little icky, but I think it's a reasonable way to get the testability we want while still making it hard for callers to get the flow wrong. In particular, I expect there to be at least two callers (one invite flow in the upstream, and one derived invite flow in Instances) so I believe there is merit in burying as much of this logic inside the Engine as is reasonably possible. Test Plan: Unit tests only. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11723
2015-02-10 01:12:36 +01:00
'PhabricatorAuthInvite' => 'applications/auth/storage/PhabricatorAuthInvite.php',
'PhabricatorAuthInviteAccountException' => 'applications/auth/exception/PhabricatorAuthInviteAccountException.php',
Add administrative invite interfaces Summary: Ref T7152. This implements the administrative UI for the upstream email invite workflow. Pieces of this will be reused in Instances to implement the instance invite workflow, although some of it is probably going to be a bit copy/pastey. This doesn't actually create or send invites yet, and they still can't be carried through registration. Test Plan: {F290970} {F290971} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11733
2015-02-11 15:05:53 +01:00
'PhabricatorAuthInviteAction' => 'applications/auth/data/PhabricatorAuthInviteAction.php',
'PhabricatorAuthInviteActionTableView' => 'applications/auth/view/PhabricatorAuthInviteActionTableView.php',
Add email invites to Phabricator (logic only) Summary: Ref T7152. This builds the core of email invites and implements all the hard logic for them, covering it with a pile of tests. There's no UI to create these yet, so users can't actually get invites (and administrators can't send them). This stuff is a complicated mess because there are so many interactions between accounts, email addresses, email verification, email primary-ness, and user verification. However, I think I got it right and got test coverage everwhere. The degree to which this is exception-driven is a little icky, but I think it's a reasonable way to get the testability we want while still making it hard for callers to get the flow wrong. In particular, I expect there to be at least two callers (one invite flow in the upstream, and one derived invite flow in Instances) so I believe there is merit in burying as much of this logic inside the Engine as is reasonably possible. Test Plan: Unit tests only. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11723
2015-02-10 01:12:36 +01:00
'PhabricatorAuthInviteController' => 'applications/auth/controller/PhabricatorAuthInviteController.php',
'PhabricatorAuthInviteDialogException' => 'applications/auth/exception/PhabricatorAuthInviteDialogException.php',
'PhabricatorAuthInviteEngine' => 'applications/auth/engine/PhabricatorAuthInviteEngine.php',
'PhabricatorAuthInviteException' => 'applications/auth/exception/PhabricatorAuthInviteException.php',
'PhabricatorAuthInviteInvalidException' => 'applications/auth/exception/PhabricatorAuthInviteInvalidException.php',
'PhabricatorAuthInviteLoginException' => 'applications/auth/exception/PhabricatorAuthInviteLoginException.php',
Add administrative invite interfaces Summary: Ref T7152. This implements the administrative UI for the upstream email invite workflow. Pieces of this will be reused in Instances to implement the instance invite workflow, although some of it is probably going to be a bit copy/pastey. This doesn't actually create or send invites yet, and they still can't be carried through registration. Test Plan: {F290970} {F290971} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11733
2015-02-11 15:05:53 +01:00
'PhabricatorAuthInvitePHIDType' => 'applications/auth/phid/PhabricatorAuthInvitePHIDType.php',
'PhabricatorAuthInviteQuery' => 'applications/auth/query/PhabricatorAuthInviteQuery.php',
Add email invites to Phabricator (logic only) Summary: Ref T7152. This builds the core of email invites and implements all the hard logic for them, covering it with a pile of tests. There's no UI to create these yet, so users can't actually get invites (and administrators can't send them). This stuff is a complicated mess because there are so many interactions between accounts, email addresses, email verification, email primary-ness, and user verification. However, I think I got it right and got test coverage everwhere. The degree to which this is exception-driven is a little icky, but I think it's a reasonable way to get the testability we want while still making it hard for callers to get the flow wrong. In particular, I expect there to be at least two callers (one invite flow in the upstream, and one derived invite flow in Instances) so I believe there is merit in burying as much of this logic inside the Engine as is reasonably possible. Test Plan: Unit tests only. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11723
2015-02-10 01:12:36 +01:00
'PhabricatorAuthInviteRegisteredException' => 'applications/auth/exception/PhabricatorAuthInviteRegisteredException.php',
Add administrative invite interfaces Summary: Ref T7152. This implements the administrative UI for the upstream email invite workflow. Pieces of this will be reused in Instances to implement the instance invite workflow, although some of it is probably going to be a bit copy/pastey. This doesn't actually create or send invites yet, and they still can't be carried through registration. Test Plan: {F290970} {F290971} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11733
2015-02-11 15:05:53 +01:00
'PhabricatorAuthInviteSearchEngine' => 'applications/auth/query/PhabricatorAuthInviteSearchEngine.php',
Add email invites to Phabricator (logic only) Summary: Ref T7152. This builds the core of email invites and implements all the hard logic for them, covering it with a pile of tests. There's no UI to create these yet, so users can't actually get invites (and administrators can't send them). This stuff is a complicated mess because there are so many interactions between accounts, email addresses, email verification, email primary-ness, and user verification. However, I think I got it right and got test coverage everwhere. The degree to which this is exception-driven is a little icky, but I think it's a reasonable way to get the testability we want while still making it hard for callers to get the flow wrong. In particular, I expect there to be at least two callers (one invite flow in the upstream, and one derived invite flow in Instances) so I believe there is merit in burying as much of this logic inside the Engine as is reasonably possible. Test Plan: Unit tests only. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11723
2015-02-10 01:12:36 +01:00
'PhabricatorAuthInviteTestCase' => 'applications/auth/factor/__tests__/PhabricatorAuthInviteTestCase.php',
'PhabricatorAuthInviteVerifyException' => 'applications/auth/exception/PhabricatorAuthInviteVerifyException.php',
Send emails for email invites Summary: Ref T7152. Ref T3554. - When an administrator clicks "send invites", queue tasks to send the invites. - Then, actually send the invites. - Make the links in the invites work properly. - Also provide `bin/worker execute` to make debugging one-off workers like this easier. - Clean up some UI, too. Test Plan: We now get as far as the exception which is a placeholder for a registration workflow. {F291213} {F291214} {F291215} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3554, T7152 Differential Revision: https://secure.phabricator.com/D11736
2015-02-11 15:06:09 +01:00
'PhabricatorAuthInviteWorker' => 'applications/auth/worker/PhabricatorAuthInviteWorker.php',
Move all account link / unlink to new registration flow Summary: Ref T1536. Currently, we have separate panels for each link/unlink and separate controllers for OAuth vs LDAP. Instead, provide a single "External Accounts" panel which shows all linked accounts and allows you to link/unlink more easily. Move link/unlink over to a full externalaccount-based workflow. Test Plan: - Linked and unlinked OAuth accounts. - Linked and unlinked LDAP accounts. - Registered new accounts. - Exercised most/all of the error cases. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6189
2013-06-17 15:12:45 +02:00
'PhabricatorAuthLinkController' => 'applications/auth/controller/PhabricatorAuthLinkController.php',
Add List/ApplicationSearch to AuthProviderConfig Summary: Ref T1536. Adds a list controller and ApplicationSearch integration for listing providers. Test Plan: {F46308} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6198
2013-06-17 19:50:43 +02:00
'PhabricatorAuthListController' => 'applications/auth/controller/config/PhabricatorAuthListController.php',
Generalize login flows for new registration Summary: Ref T1536. None of this code is reachable. `PhabricatorAuthLoginController` provides a completely generic login/link flow, similar to how D6155 provides a generic registration flow. `PhabricatorAuthProvider` wraps a `PhutilAuthAdapter` and glues the generic top-level flow to a concrete authentication provider. Test Plan: Static only, code isn't meaningfully reachable. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6159
2013-06-16 19:14:07 +02:00
'PhabricatorAuthLoginController' => 'applications/auth/controller/PhabricatorAuthLoginController.php',
Modularize generation of supplemental login messages Summary: Ref T9346. This mostly allows us to give users additional advice based on which instance they are trying to log in to in the Phacility cluster. It's also slightly more flexible than `auth.login-message` was, and maybe we'll add some more hooks here eventually. This feels like it's a sidegrade in complexity rather than really an improvement, but not too terrible. Test Plan: - Wrote the custom handler in T9346 to replicate old config functionality. - Wrote a smart handler for Phacility that can provide context-sensitive messages based on which OAuth client you're trying to use. See new message box at top (implementation in next diff): {F780375} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9346 Differential Revision: https://secure.phabricator.com/D14057
2015-09-04 19:34:39 +02:00
'PhabricatorAuthLoginHandler' => 'applications/auth/handler/PhabricatorAuthLoginHandler.php',
Implement "auth.logout" Conduit API method Summary: Ref T7303. Ref T7673. This implements an "auth.logout" which: - terminates all web sessions; - terminates the current OAuth token if called via OAuth; and - may always be called via OAuth. (Since it consumes an OAuth token, even a "malicious" OAuth application can't really be that much of a jerk with this: it can't continuously log you out, since calling the method once kills the token. The application would need to ask your permission again to get a fresh token.) The primary goal here is to let Phacility instances call this against the Phacility upstream, so that when you log out of an instance it also logs you out of your Phacility account (possibly with a checkbox or something). This also smooths over the session token code. Before this change, your sessions would get logged out but when you reloaded we'd tell you your session was invalid. Instead, try to clear the invalid session before telling the user there's an issue. I think that ssentially 100% of invalid sessions are a result of something in this vein (e.g., forced logout via Settings) nowadays, since the session code is generally stable and sane and has been for a long time. Test Plan: - Called `auth.logout` via console, got a reasonable logout experience. - Called `auth.logout` via OAuth. - Tried to make another call, verified OAuth token had been invalidated. - Verified web session had been invalidated. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7303, T7673 Differential Revision: https://secure.phabricator.com/D15594
2016-04-03 18:06:26 +02:00
'PhabricatorAuthLogoutConduitAPIMethod' => 'applications/auth/conduit/PhabricatorAuthLogoutConduitAPIMethod.php',
Begin modularizing main menu items Summary: Ref T10077. Ref T8918. The way the main menu is built is not very modular and fairly hacky. It assumes menus are provided by applications, but this isn't exactly true. Notably, the "Quick Create" menu is not per-application. The current method of building this menu is very inefficient (see T10077). Particularly, we have to build it //twice// because we need to build it once to render the item and then again to render the dropdown options. Start cleaning this up. This diff doesn't actually have any behavioral changes, since I can't swap the menu over until we get rid of all the other items and I haven't extended this to Notifications/Conpherence yet so it doesn't actually fix T8918. Test Plan: Viewed menus while logged in, logged out, in different applications, in desktop/mobile. Nothing appeared different. Reviewers: chad Reviewed By: chad Maniphest Tasks: T8918, T10077 Differential Revision: https://secure.phabricator.com/D14922
2016-01-01 13:26:36 +01:00
'PhabricatorAuthMainMenuBarExtension' => 'applications/auth/extension/PhabricatorAuthMainMenuBarExtension.php',
Work around lack of PKCS8 support in OSX ssh-keygen Summary: Ref T4209. Ref T6240. Ref T6238. See D10401 for original discussion. On OSX, `ssh-keygen` doesn't support PKCS8: - When we hit an issue with this, raise a more tailored message about it. - Allow the user to work around the problem with `auth cache-pkcs8 ...`, providing reasonable guidance / warnings. In practice, this only really matters very much for one key, which I'm just going to make the services extension cache automatically. So it's sort of moot, but good to have around for weird cases and to make testing easier. Test Plan: Hit error, cached key, got clean asymmetric auth. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4209, T6240, T6238 Differential Revision: https://secure.phabricator.com/D11021
2014-12-20 01:36:40 +01:00
'PhabricatorAuthManagementCachePKCS8Workflow' => 'applications/auth/management/PhabricatorAuthManagementCachePKCS8Workflow.php',
Provide `bin/auth ldap` for LDAP diagnostics Summary: Ref T1536. Test Plan: Ran `bin/auth ldap`. Reviewers: mbishopim3, chad Reviewed By: mbishopim3 CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6218
2013-06-17 22:26:25 +02:00
'PhabricatorAuthManagementLDAPWorkflow' => 'applications/auth/management/PhabricatorAuthManagementLDAPWorkflow.php',
Add `bin/auth list-factors` and `bin/auth strip` to remove multi-factor auth Summary: Ref T4398. The major goals here is to let administrators strip auth factors in two cases: - A user lost their phone and needs access restored to their account; or - an install previously used an API-based factor like SMS, but want to stop supporting it (this isn't possible today). Test Plan: - Used `bin/auth list-factors` to show installed factors. - Used `bin/auth strip` with various mixtures of flags to selectively choose and strip factors from accounts. - Also ran `bin/auth refresh` to verify refreshing OAuth tokens works (small `OAuth` vs `OAuth2` tweak). Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8909
2014-04-30 23:30:00 +02:00
'PhabricatorAuthManagementListFactorsWorkflow' => 'applications/auth/management/PhabricatorAuthManagementListFactorsWorkflow.php',
Add very basic `bin/auth` tool Summary: Ref T1536. This script basically exists to restore access if/when users shoot themselves in the foot by disabling all auth providers and can no longer log in. Test Plan: {F46411} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6205
2013-06-17 19:55:05 +02:00
'PhabricatorAuthManagementRecoverWorkflow' => 'applications/auth/management/PhabricatorAuthManagementRecoverWorkflow.php',
Add `bin/auth refresh` for debugging OAuth token refresh issues Summary: Ref T2852. Provide a script for inspecting/debugging OAuth token refresh. Test Plan: Ran `bin/auth refresh` with various arguments, saw token refreshes. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6276
2013-06-25 00:55:41 +02:00
'PhabricatorAuthManagementRefreshWorkflow' => 'applications/auth/management/PhabricatorAuthManagementRefreshWorkflow.php',
Add `bin/auth list-factors` and `bin/auth strip` to remove multi-factor auth Summary: Ref T4398. The major goals here is to let administrators strip auth factors in two cases: - A user lost their phone and needs access restored to their account; or - an install previously used an API-based factor like SMS, but want to stop supporting it (this isn't possible today). Test Plan: - Used `bin/auth list-factors` to show installed factors. - Used `bin/auth strip` with various mixtures of flags to selectively choose and strip factors from accounts. - Also ran `bin/auth refresh` to verify refreshing OAuth tokens works (small `OAuth` vs `OAuth2` tweak). Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8909
2014-04-30 23:30:00 +02:00
'PhabricatorAuthManagementStripWorkflow' => 'applications/auth/management/PhabricatorAuthManagementStripWorkflow.php',
OAuth - add concept of "trusted" clients that get auto redirects Summary: Fixes T7153. Test Plan: used `bin/auth trust-oauth-client` and `bin/auth untrust-oauth-client` to set the bit and verify error states. registered via oauth with `bin/auth trust-oauth-client` set and I did not have the confirmation screen registered via oauth with `bin/auth untrust-oauth-client` set and I did have the confirmation screen Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7153 Differential Revision: https://secure.phabricator.com/D11724
2015-02-09 23:23:49 +01:00
'PhabricatorAuthManagementTrustOAuthClientWorkflow' => 'applications/auth/management/PhabricatorAuthManagementTrustOAuthClientWorkflow.php',
Add `bin/auth unlimit` and clean up a TODO Summary: I stumbled across this TODO and was worried that there was a glaring hole in MFA that I'd somehow forgotten about, but the TODO is just out of date. These actions are rate limited properly by `PhabricatorAuthTryFactorAction`, which permits a maximum of 10 actions per hour. - Remove the TODO. - Add `bin/auth unlimit` to make it easier to reset rate limits if someone needs to do that for whatever reason. Test Plan: - Tried to brute force through MFA. - Got rate limited properly after 10 failures. - Reset rate limit with `bin/auth unlimit`. - Saw the expected number of actions clear. {F805288} Reviewers: chad Reviewed By: chad Subscribers: joshuaspence Differential Revision: https://secure.phabricator.com/D14105
2015-09-14 16:03:39 +02:00
'PhabricatorAuthManagementUnlimitWorkflow' => 'applications/auth/management/PhabricatorAuthManagementUnlimitWorkflow.php',
OAuth - add concept of "trusted" clients that get auto redirects Summary: Fixes T7153. Test Plan: used `bin/auth trust-oauth-client` and `bin/auth untrust-oauth-client` to set the bit and verify error states. registered via oauth with `bin/auth trust-oauth-client` set and I did not have the confirmation screen registered via oauth with `bin/auth untrust-oauth-client` set and I did have the confirmation screen Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7153 Differential Revision: https://secure.phabricator.com/D11724
2015-02-09 23:23:49 +01:00
'PhabricatorAuthManagementUntrustOAuthClientWorkflow' => 'applications/auth/management/PhabricatorAuthManagementUntrustOAuthClientWorkflow.php',
Add a "did verify email" event to Phabricator Summary: Ref T7152. Gives us an event hook so we can go make users a member of any instance they've been invited to as soon as they verify an email address. Test Plan: - Used `bin/auth verify` to trigger the event. - Build out the invite flow in rSERVICES. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11752
2015-02-11 23:39:06 +01:00
'PhabricatorAuthManagementVerifyWorkflow' => 'applications/auth/management/PhabricatorAuthManagementVerifyWorkflow.php',
Add very basic `bin/auth` tool Summary: Ref T1536. This script basically exists to restore access if/when users shoot themselves in the foot by disabling all auth providers and can no longer log in. Test Plan: {F46411} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6205
2013-06-17 19:55:05 +02:00
'PhabricatorAuthManagementWorkflow' => 'applications/auth/management/PhabricatorAuthManagementWorkflow.php',
Implement most of the administrative UI for approval queues Summary: Nothing fancy here, just: - UI to show users needing approval. - "Approve" and "Disable" actions. - Send "Approved" email on approve. - "Approve" edit + log operations. - "Wait for Approval" state for users who need approval. There's still no natural way for users to end up not-approved -- you have to write directly to the database. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7573
2013-11-13 20:24:18 +01:00
'PhabricatorAuthNeedsApprovalController' => 'applications/auth/controller/PhabricatorAuthNeedsApprovalController.php',
Allow installs to require multi-factor authentication for all users Summary: Ref T5089. Adds a `security.require-multi-factor-auth` which forces all users to enroll in MFA before they can use their accounts. Test Plan: Config: {F159750} Roadblock: {F159748} After configuration: {F159749} - Required MFA, got roadblocked, added MFA, got unblocked. - Removed MFA, got blocked again. - Used `bin/auth strip` to strip MFA, got blocked. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5089 Differential Revision: https://secure.phabricator.com/D9285
2014-06-04 01:50:27 +02:00
'PhabricatorAuthNeedsMultiFactorController' => 'applications/auth/controller/PhabricatorAuthNeedsMultiFactorController.php',
Add initial create screen for auth providers Summary: Ref T1536. Adds an initial "choose a provider type" screen for adding a new provider. This doesn't go anywhere yet. Test Plan: {F46316} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6199
2013-06-17 19:51:35 +02:00
'PhabricatorAuthNewController' => 'applications/auth/controller/config/PhabricatorAuthNewController.php',
Send old login code to the bottom of the sea Summary: Ref T1536. This is extremely reachable and changes the login code to the new stuff. Notes: - I've hard-disabled password registration since I want installs to explicitly flip it on via config if they want it. New installs will get it by default in the future, but old installs shouldn't have their auth options change. - Google doesn't let us change the redirect URI, so keep the old one working. - We need to keep a bit of LDAP around for now for LDAP import. - **Facebook:** This causes substantive changes in what login code is executed. Test Plan: - Logged in / logged out / registered, hit new flows. - Logged in with google. - Verified no password registration by default. Reviewers: btrahan, chad Reviewed By: chad CC: wez, nh, aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6222
2013-06-19 10:33:27 +02:00
'PhabricatorAuthOldOAuthRedirectController' => 'applications/auth/controller/PhabricatorAuthOldOAuthRedirectController.php',
Make password reset emails use one-time tokens Summary: Ref T4398. This code hadn't been touched in a while and had a few crufty bits. **One Time Resets**: Currently, password reset (and similar links) are valid for about 48 hours, but we always use one token to generate them (it's bound to the account). This isn't horrible, but it could be better, and it produces a lot of false positives on HackerOne. Instead, use TemporaryTokens to make each link one-time only and good for no more than 24 hours. **Coupling of Email Verification and One-Time Login**: Currently, one-time login links ("password reset links") are tightly bound to an email address, and using a link verifies that email address. This is convenient for "Welcome" emails, so the user doesn't need to go through two rounds of checking email in order to login, then very their email, then actually get access to Phabricator. However, for other types of these links (like those generated by `bin/auth recover`) there's no need to do any email verification. Instead, make the email verification part optional, and use it on welcome links but not other types of links. **Message Customization**: These links can come out of several workflows: welcome, password reset, username change, or `bin/auth recover`. Add a hint to the URI so the text on the page can be customized a bit to help users through the workflow. **Reset Emails Going to Main Account Email**: Previously, we would send password reset email to the user's primary account email. However, since we verify email coming from reset links this isn't correct and could allow a user to verify an email without actually controlling it. Since the user needs a real account in the first place this does not seem useful on its own, but might be a component in some other attack. The user might also no longer have access to their primary account, in which case this wouldn't be wrong, but would not be very useful. Mitigate this in two ways: - First, send to the actual email address the user entered, not the primary account email address. - Second, don't let these links verify emails: they're just login links. This primarily makes it more difficult for an attacker to add someone else's email to their account, send them a reset link, get them to login and implicitly verify the email by not reading very carefully, and then figure out something interesting to do (there's currently no followup attack here, but allowing this does seem undesirable). **Password Reset Without Old Password**: After a user logs in via email, we send them to the password settings panel (if passwords are enabled) with a code that lets them set a new password without knowing the old one. Previously, this code was static and based on the email address. Instead, issue a one-time code. **Jump Into Hisec**: Normally, when a user who has multi-factor auth on their account logs in, we prompt them for factors but don't put them in high security. You usually don't want to go do high-security stuff immediately after login, and it would be confusing and annoying if normal logins gave you a "YOU ARE IN HIGH SECURITY" alert bubble. However, if we're taking you to the password reset screen, we //do// want to put the user in high security, since that screen requires high security. If we don't do this, the user gets two factor prompts in a row. To accomplish this, we set a cookie when we know we're sending the user into a high security workflow. This cookie makes login finalization upgrade all the way from "partial" to "high security", instead of stopping halfway at "normal". This is safe because the user has just passed a factor check; the only reason we don't normally do this is to reduce annoyance. **Some UI Cleanup**: Some of this was using really old UI. Modernize it a bit. Test Plan: - **One Time Resets** - Used a reset link. - Tried to reuse a reset link, got denied. - Verified each link is different. - **Coupling of Email Verification and One-Time Login** - Verified that `bin/auth`, password reset, and username change links do not have an email verifying URI component. - Tried to tack one on, got denied. - Used the welcome email link to login + verify. - Tried to mutate the URI to not verify, or verify something else: got denied. - **Message Customization** - Viewed messages on the different workflows. They seemed OK. - **Reset Emails Going to Main Account Email** - Sent password reset email to non-primary email. - Received email at specified address. - Verified it does not verify the address. - **Password Reset Without Old Password** - Reset password without knowledge of old one after email reset. - Tried to do that without a key, got denied. - Tried to reuse a key, got denied. - **Jump Into Hisec** - Logged in with MFA user, got factor'd, jumped directly into hisec. - Logged in with non-MFA user, no factors, normal password reset. - **Some UI Cleanup** - Viewed new UI. - **Misc** - Created accounts, logged in with welcome link, got verified. - Changed a username, used link to log back in. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D9252
2014-05-22 19:41:00 +02:00
'PhabricatorAuthOneTimeLoginController' => 'applications/auth/controller/PhabricatorAuthOneTimeLoginController.php',
Modularize temporary token types Summary: Ref T10603. For LFS, we need to issue a new type of temporary token. This makes the temporary token code modular so applications can add new token types without modifying the Auth application. (I'm moving slowly here because it impacts authentication.) Test Plan: - Used `bin/auth recover` to get a one-time token from the CLI. - Used "Forgot your password?" to get a one-time token from the web UI. - Followed the web UI token to initiate a password reset, prompting generation of a password token. - Viewed these tokens in the web UI: {F1176908} - Revoked a token. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10603 Differential Revision: https://secure.phabricator.com/D15475
2016-03-16 13:17:41 +01:00
'PhabricatorAuthOneTimeLoginTemporaryTokenType' => 'applications/auth/tokentype/PhabricatorAuthOneTimeLoginTemporaryTokenType.php',
'PhabricatorAuthPasswordResetTemporaryTokenType' => 'applications/auth/tokentype/PhabricatorAuthPasswordResetTemporaryTokenType.php',
Generalize login flows for new registration Summary: Ref T1536. None of this code is reachable. `PhabricatorAuthLoginController` provides a completely generic login/link flow, similar to how D6155 provides a generic registration flow. `PhabricatorAuthProvider` wraps a `PhutilAuthAdapter` and glues the generic top-level flow to a concrete authentication provider. Test Plan: Static only, code isn't meaningfully reachable. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6159
2013-06-16 19:14:07 +02:00
'PhabricatorAuthProvider' => 'applications/auth/provider/PhabricatorAuthProvider.php',
Add storage for Auth configuration in preparation for moving it into a web interface Summary: Ref T1536. Currently, we have about 40 auth-related configuration options. This is already roughly 20% of our config, and we want to add more providers. Additionally, we want to turn some of these auth options into multi-auth options (e.g., allow multiple Phabricator OAuth installs, or, theoretically multiple LDAP servers). I'm going to move this into a separate "Auth" tool with a minimal CLI (`bin/auth`) interface and a more full web interface. Roughly: - Administrators will use the app to manage authentication providers. - The `bin/auth` CLI will provide a safety hatch if you lock yourself out by disabling all usable providers somehow. - We'll migrate existing configuration into the app and remove it. General goals: - Make it much easier to configure authentication by providing an interface for it. - Make it easier to configure everything else by reducing the total number of available options. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6196
2013-06-17 19:48:41 +02:00
'PhabricatorAuthProviderConfig' => 'applications/auth/storage/PhabricatorAuthProviderConfig.php',
Add List/ApplicationSearch to AuthProviderConfig Summary: Ref T1536. Adds a list controller and ApplicationSearch integration for listing providers. Test Plan: {F46308} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6198
2013-06-17 19:50:43 +02:00
'PhabricatorAuthProviderConfigController' => 'applications/auth/controller/config/PhabricatorAuthProviderConfigController.php',
Very rough edit workflow for AuthProvider configuration Summary: Ref T1536. Many rough / broken edges, but adds the rough skeleton of the provider edit workflow. Test Plan: {F46333} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6200
2013-06-17 19:52:38 +02:00
'PhabricatorAuthProviderConfigEditor' => 'applications/auth/editor/PhabricatorAuthProviderConfigEditor.php',
Add PhabricatorAuthProviderConfigQuery Summary: Ref T1536. See D6196. Code not called yet. Test Plan: Static checks only. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6197
2013-06-17 19:49:18 +02:00
'PhabricatorAuthProviderConfigQuery' => 'applications/auth/query/PhabricatorAuthProviderConfigQuery.php',
Add storage for Auth configuration in preparation for moving it into a web interface Summary: Ref T1536. Currently, we have about 40 auth-related configuration options. This is already roughly 20% of our config, and we want to add more providers. Additionally, we want to turn some of these auth options into multi-auth options (e.g., allow multiple Phabricator OAuth installs, or, theoretically multiple LDAP servers). I'm going to move this into a separate "Auth" tool with a minimal CLI (`bin/auth`) interface and a more full web interface. Roughly: - Administrators will use the app to manage authentication providers. - The `bin/auth` CLI will provide a safety hatch if you lock yourself out by disabling all usable providers somehow. - We'll migrate existing configuration into the app and remove it. General goals: - Make it much easier to configure authentication by providing an interface for it. - Make it easier to configure everything else by reducing the total number of available options. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6196
2013-06-17 19:48:41 +02:00
'PhabricatorAuthProviderConfigTransaction' => 'applications/auth/storage/PhabricatorAuthProviderConfigTransaction.php',
Add PhabricatorAuthProviderConfigQuery Summary: Ref T1536. See D6196. Code not called yet. Test Plan: Static checks only. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6197
2013-06-17 19:49:18 +02:00
'PhabricatorAuthProviderConfigTransactionQuery' => 'applications/auth/query/PhabricatorAuthProviderConfigTransactionQuery.php',
Add auth.querypublickeys to retrieve public keys Summary: Fixes T6484. I primarily need this to synchronize device public keys in the Phabricator cluster so the new stuff in T2783 works. Although, actually, maybe I don't really need it. But I wrote it anyway and it's desirable to have sooner or later. Test Plan: Ran method. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6484 Differential Revision: https://secure.phabricator.com/D11163
2015-02-11 00:44:21 +01:00
'PhabricatorAuthQueryPublicKeysConduitAPIMethod' => 'applications/auth/conduit/PhabricatorAuthQueryPublicKeysConduitAPIMethod.php',
New Registration Workflow Summary: Currently, registration and authentication are pretty messy. Two concrete problems: - The `PhabricatorLDAPRegistrationController` and `PhabricatorOAuthDefaultRegistrationController` controllers are giant copy/pastes of one another. This is really bad. - We can't practically implement OpenID because we can't reissue the authentication request. Additionally, the OAuth registration controller can be replaced wholesale by config, which is a huge API surface area and a giant mess. Broadly, the problem right now is that registration does too much: we hand it some set of indirect credentials (like OAuth tokens) and expect it to take those the entire way to a registered user. Instead, break registration into smaller steps: - User authenticates with remote service. - Phabricator pulls information (remote account ID, username, email, real name, profile picture, etc) from the remote service and saves it as `PhabricatorUserCredentials`. - Phabricator hands the `PhabricatorUserCredentials` to the registration form, which is agnostic about where they originate from: it can process LDAP credentials, OAuth credentials, plain old email credentials, HTTP basic auth credentials, etc. This doesn't do anything yet -- there is no way to create credentials objects (and no storage patch), but I wanted to get any initial feedback, especially about the event call for T2394. In particular, I think the implementation would look something like this: $profile = $event->getValue('profile') $username = $profile->getDefaultUsername(); $is_employee = is_this_a_facebook_employee($username); if (!$is_employee) { throw new Exception("You are not employed at Facebook."); } $fbid = get_fbid_for_facebook_username($username); $profile->setDefaultEmail($fbid); $profile->setCanEditUsername(false); $profile->setCanEditEmail(false); $profile->setCanEditRealName(false); $profile->setShouldVerifyEmail(true); Seem reasonable? Test Plan: N/A yet, probably fatals. Reviewers: vrana, btrahan, codeblock, chad Reviewed By: btrahan CC: aran, asherkin, nh, wez Maniphest Tasks: T1536, T2394 Differential Revision: https://secure.phabricator.com/D4647
2013-06-16 19:13:49 +02:00
'PhabricatorAuthRegisterController' => 'applications/auth/controller/PhabricatorAuthRegisterController.php',
Add an explicit temporary token management page to Settings Summary: Ref T5506. This makes it easier to understand and manage temporary tokens. Eventually this could be more user-friendly, since it's relatively difficult to understand what this screen means. My short-term goal is just to make the next change easier to implement and test. The next diff will close a small security weakness: if you change your email address, password reset links which were sent to the old address are still valid. Although an attacker would need substantial access to exploit this (essentially, it would just make it easier for them to re-compromise an already compromised account), it's a bit surprising. In the next diff, email address changes will invalidate outstanding password reset links. Test Plan: - Viewed outstanding tokens. - Added tokens to the list by making "Forgot your password?" requests. - Revoked tokens individually. - Revoked all tokens. - Tried to use a revoked token. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5506 Differential Revision: https://secure.phabricator.com/D10133
2014-08-04 21:04:13 +02:00
'PhabricatorAuthRevokeTokenController' => 'applications/auth/controller/PhabricatorAuthRevokeTokenController.php',
Move SSHKey table to Auth database Summary: Ref T5833. Since these will no longer be bound specifically to users, bring them to a more central location. Test Plan: - Edited SSH keys. - Ran `bin/ssh-auth` and `bin/ssh-auth-key`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10791
2014-11-06 21:37:22 +01:00
'PhabricatorAuthSSHKey' => 'applications/auth/storage/PhabricatorAuthSSHKey.php',
Separate SSH key management from the settings panel Summary: Ref T5833. I want to add SSH keys to Almanac devices, but the edit workflows for them are currently bound tightly to users. Instead, decouple key management from users and the settings panel. Test Plan: - Uploaded, generated, edited and deleted SSH keys. - Hit missing name, missing key, bad key format, duplicate key errors. - Edited/generated/deleted/etc keys for a bot user as an administrator. - Got HiSec'd on everything. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10824
2014-11-11 17:18:26 +01:00
'PhabricatorAuthSSHKeyController' => 'applications/auth/controller/PhabricatorAuthSSHKeyController.php',
'PhabricatorAuthSSHKeyDeleteController' => 'applications/auth/controller/PhabricatorAuthSSHKeyDeleteController.php',
'PhabricatorAuthSSHKeyEditController' => 'applications/auth/controller/PhabricatorAuthSSHKeyEditController.php',
'PhabricatorAuthSSHKeyGenerateController' => 'applications/auth/controller/PhabricatorAuthSSHKeyGenerateController.php',
Update library map.
2015-12-19 20:55:59 +01:00
'PhabricatorAuthSSHKeyPHIDType' => 'applications/auth/phid/PhabricatorAuthSSHKeyPHIDType.php',
Add a query/policy layer on top of SSH keys for Almanac Summary: Ref T5833. Currently, SSH keys are associated only with users, and are a bit un-modern. I want to let Almanac Devices have SSH keys so devices in a cluster can identify to one another. For example, with hosted installs, initialization will go something like this: - A request comes in for `company.phacility.com`. - A SiteSource (from D10787) makes a Conduit call to Almanac on the master install to check if `company` is a valid install and pull config if it is. - This call can be signed with an SSH key which identifies a trusted Almanac Device. In the cluster case, a web host can make an authenticated call to a repository host with similar key signing. To move toward this, put a proper Query class on top of SSH key access (this diff). In following diffs, I'll: - Rename `userPHID` to `objectPHID`. - Move this to the `auth` database. - Provide UI for device/key association. An alternative approach would be to build some kind of special token layer in Conduit, but I think that would be a lot harder to manage in the hosting case. This gives us a more direct attack on trusting requests from machines and recognizing machines as first (well, sort of second-class) actors without needing things like fake user accounts. Test Plan: - Added and removed SSH keys. - Added and removed SSH keys from a bot account. - Tried to edit an unonwned SSH key (denied). - Ran `bin/ssh-auth`, got sensible output. - Ran `bin/ssh-auth-key`, got sensible output. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10790
2014-11-06 21:37:02 +01:00
'PhabricatorAuthSSHKeyQuery' => 'applications/auth/query/PhabricatorAuthSSHKeyQuery.php',
Allow Almanac devices to have SSH keys Summary: Ref T5833. Expose a key management interface for Almanac devices. Test Plan: {F231962} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10825
2014-11-11 17:20:08 +01:00
'PhabricatorAuthSSHKeyTableView' => 'applications/auth/view/PhabricatorAuthSSHKeyTableView.php',
Separate SSH key management from the settings panel Summary: Ref T5833. I want to add SSH keys to Almanac devices, but the edit workflows for them are currently bound tightly to users. Instead, decouple key management from users and the settings panel. Test Plan: - Uploaded, generated, edited and deleted SSH keys. - Hit missing name, missing key, bad key format, duplicate key errors. - Edited/generated/deleted/etc keys for a bot user as an administrator. - Got HiSec'd on everything. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10824
2014-11-11 17:18:26 +01:00
'PhabricatorAuthSSHPublicKey' => 'applications/auth/sshkey/PhabricatorAuthSSHPublicKey.php',
Add an "active login sessions" table to Settings Summary: Ref T4310. Ref T3720. Partly, this makes it easier for users to understand login sessions. Partly, it makes it easier for me to make changes to login sessions for T4310 / T3720 without messing anything up. Test Plan: {F101512} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3720, T4310 Differential Revision: https://secure.phabricator.com/D7954
2014-01-14 20:05:45 +01:00
'PhabricatorAuthSession' => 'applications/auth/storage/PhabricatorAuthSession.php',
Separate session management from PhabricatorUser Summary: Ref T4310. Ref T3720. Session operations are currently part of PhabricatorUser. This is more tightly coupled than needbe, and makes it difficult to establish login sessions for non-users. Move all the session management code to a `SessionEngine`. Test Plan: - Viewed sessions. - Regenerated Conduit certificate. - Verified Conduit sessions were destroyed. - Logged out. - Logged in. - Ran conduit commands. - Viewed sessions again. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4310, T3720 Differential Revision: https://secure.phabricator.com/D7962
2014-01-14 22:22:27 +01:00
'PhabricatorAuthSessionEngine' => 'applications/auth/engine/PhabricatorAuthSessionEngine.php',
Add a session engine extension point Summary: Ref T7673. This is really just so I can force admin.phacility.com logout when you log out of an instance, but there are a few other things we could move here eventually, like the WILLREGISTERUSER event. Test Plan: Logged out of an instance, got logged out of parent (see next change). Reviewers: chad Reviewed By: chad Maniphest Tasks: T7673 Differential Revision: https://secure.phabricator.com/D15629
2016-04-03 19:04:10 +02:00
'PhabricatorAuthSessionEngineExtension' => 'applications/auth/engine/PhabricatorAuthSessionEngineExtension.php',
'PhabricatorAuthSessionEngineExtensionModule' => 'applications/auth/engine/PhabricatorAuthSessionEngineExtensionModule.php',
Expire and garbage collect unused sessions Summary: Ref T3720. Ref T4310. Currently, we limit the maximum number of concurrent sessions of each type. This is primarily because sessions predate garbage collection and we had no way to prevent the session table from growing fairly quickly and without bound unless we did this. Now that we have GC (and it's modular!) we can just expire unused sessions after a while and throw them away: - Add a `sessionExpires` column to the table, with a key. - Add a GC for old sessions. - When we establish a session, set `sessionExpires` to the current time plus the session TTL. - When a user uses a session and has used up more than 20% of the time on it, extend the session. In addition to this, we could also rotate sessions, but I think that provides very little value. If we do want to implement it, we should hold it until after T3720 / T4310. Test Plan: - Ran schema changes. - Looked at database. - Tested GC: - Started GC. - Set expires on one row to the past. - Restarted GC. - Verified GC nuked the session. - Logged in. - Logged out. - Ran Conduit method. - Tested refresh: - Set threshold to 0.0001% instead of 20%. - Loaded page. - Saw a session extension ever few page loads. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4310, T3720 Differential Revision: https://secure.phabricator.com/D7976
2014-01-15 22:56:16 +01:00
'PhabricatorAuthSessionGarbageCollector' => 'applications/auth/garbagecollector/PhabricatorAuthSessionGarbageCollector.php',
Add an "active login sessions" table to Settings Summary: Ref T4310. Ref T3720. Partly, this makes it easier for users to understand login sessions. Partly, it makes it easier for me to make changes to login sessions for T4310 / T3720 without messing anything up. Test Plan: {F101512} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3720, T4310 Differential Revision: https://secure.phabricator.com/D7954
2014-01-14 20:05:45 +01:00
'PhabricatorAuthSessionQuery' => 'applications/auth/query/PhabricatorAuthSessionQuery.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorAuthSetupCheck' => 'applications/config/check/PhabricatorAuthSetupCheck.php',
Provide start screen and full registration flow on the new auth stuff Summary: Ref T1536. Code is intentionally made unreachable (see PhabricatorAuthProviderOAuthFacebook->isEnabled()). This adds: - A provider-driven "start" screen (this has the list of ways you can login/register). - Registration actually works. - Facebook OAuth works. @chad, do you have any design ideas on the start screen? I think we poked at it before, but the big issue was that there were a limitless number of providers. Today, we have: - Password - LDAP - Facebook - GitHub - Phabricator - Disqus - Google We plan to add: - Asana - An arbitrary number of additional instances of Phabricator Users want to add: - OpenID - Custom providers And I'd like to have these at some point: - Stripe - WePay - Amazon - Bitbucket So basically any UI for this has to accommodate 300 zillion auth options. I don't think we need to solve any UX problems here (realistically, installs enable 1-2 auth options and users don't actually face an overwhelming number of choices) but making the login forms less ugly would be nice. No combination of prebuilt elements seems to look very good for this use case. Test Plan: Registered a new acount with Facebook. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6161
2013-06-16 19:15:16 +02:00
'PhabricatorAuthStartController' => 'applications/auth/controller/PhabricatorAuthStartController.php',
Formally modularize MFA/TOTP tokens, provide a module panel for temporary tokens Summary: Ref T10603. We have a couple of sort of ad-hoc tokens, so start formalizing them. First up is MFA tokens. Also adds a new config module panel for these. Test Plan: - Added MFA. - Added MFA, intentionally fumbled the input, completed the workflow. - Removed MFA. - Viewed tokens, saw MFA sync tokens. - Viewed new module config panel. {F1177014} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10603 Differential Revision: https://secure.phabricator.com/D15479
2016-03-16 14:17:31 +01:00
'PhabricatorAuthTOTPKeyTemporaryTokenType' => 'applications/auth/factor/PhabricatorAuthTOTPKeyTemporaryTokenType.php',
Add "temporary tokens" to auth, for SMS codes, TOTP codes, reset codes, etc Summary: Ref T4398. We have several auth-related systems which require (or are improved by) the ability to hand out one-time codes which expire after a short period of time. In particular, these are: - SMS multi-factor: we need to be able to hand out one-time codes for this in order to prove the user has the phone. - Password reset emails: we use a time-based rotating token right now, but we could improve this with a one-time token, so once you reset your password the link is dead. - TOTP auth: we don't need to verify/invalidate keys, but can improve security by doing so. This adds a generic one-time code storage table, and strengthens the TOTP enrollment process by using it. Specifically, you can no longer edit the enrollment form (the one with a QR code) to force your own key as the TOTP key: only keys Phabricator generated are accepted. This has no practical security impact, but generally helps raise the barrier potential attackers face. Followup changes will use this for reset emails, then implement SMS multi-factor. Test Plan: - Enrolled in TOTP multi-factor auth. - Submitted an error in the form, saw the same key presented. - Edited the form with web tools to provide a different key, saw it reject and the server generate an alternate. - Change the expiration to 5 seconds instead of 1 hour, submitted the form over and over again, saw it cycle the key after 5 seconds. - Looked at the database and saw the tokens I expected. - Ran the GC and saw all the 5-second expiry tokens get cleaned up. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D9217
2014-05-20 20:43:45 +02:00
'PhabricatorAuthTemporaryToken' => 'applications/auth/storage/PhabricatorAuthTemporaryToken.php',
'PhabricatorAuthTemporaryTokenGarbageCollector' => 'applications/auth/garbagecollector/PhabricatorAuthTemporaryTokenGarbageCollector.php',
'PhabricatorAuthTemporaryTokenQuery' => 'applications/auth/query/PhabricatorAuthTemporaryTokenQuery.php',
Modularize temporary token types Summary: Ref T10603. For LFS, we need to issue a new type of temporary token. This makes the temporary token code modular so applications can add new token types without modifying the Auth application. (I'm moving slowly here because it impacts authentication.) Test Plan: - Used `bin/auth recover` to get a one-time token from the CLI. - Used "Forgot your password?" to get a one-time token from the web UI. - Followed the web UI token to initiate a password reset, prompting generation of a password token. - Viewed these tokens in the web UI: {F1176908} - Revoked a token. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10603 Differential Revision: https://secure.phabricator.com/D15475
2016-03-16 13:17:41 +01:00
'PhabricatorAuthTemporaryTokenType' => 'applications/auth/tokentype/PhabricatorAuthTemporaryTokenType.php',
Formally modularize MFA/TOTP tokens, provide a module panel for temporary tokens Summary: Ref T10603. We have a couple of sort of ad-hoc tokens, so start formalizing them. First up is MFA tokens. Also adds a new config module panel for these. Test Plan: - Added MFA. - Added MFA, intentionally fumbled the input, completed the workflow. - Removed MFA. - Viewed tokens, saw MFA sync tokens. - Viewed new module config panel. {F1177014} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10603 Differential Revision: https://secure.phabricator.com/D15479
2016-03-16 14:17:31 +01:00
'PhabricatorAuthTemporaryTokenTypeModule' => 'applications/auth/tokentype/PhabricatorAuthTemporaryTokenTypeModule.php',
Allow users to terminate login sessions Summary: This is partly a good feature, and partly should reduce false positives on HackerOne reporting things vaguely related to this. Allow a user to terminate login sessions from the settings panel. Test Plan: - Terminated a session. - Terminated all sessions. - Tried to terminate all sessions again. - Logged in with two browsers, terminated the other browser's session, reloaded, got kicked out. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8556
2014-03-17 23:02:01 +01:00
'PhabricatorAuthTerminateSessionController' => 'applications/auth/controller/PhabricatorAuthTerminateSessionController.php',
Rate limit multi-factor actions Summary: Ref T4398. Prevent users from brute forcing multi-factor auth by rate limiting attempts. This slightly refines the rate limiting to allow callers to check for a rate limit without adding points, and gives users credit for successfully completing an auth workflow. Test Plan: Tried to enter hisec with bad credentials 11 times in a row, got rate limited. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8911
2014-04-30 23:30:31 +02:00
'PhabricatorAuthTryFactorAction' => 'applications/auth/action/PhabricatorAuthTryFactorAction.php',
Move all account link / unlink to new registration flow Summary: Ref T1536. Currently, we have separate panels for each link/unlink and separate controllers for OAuth vs LDAP. Instead, provide a single "External Accounts" panel which shows all linked accounts and allows you to link/unlink more easily. Move link/unlink over to a full externalaccount-based workflow. Test Plan: - Linked and unlinked OAuth accounts. - Linked and unlinked LDAP accounts. - Registered new accounts. - Exercised most/all of the error cases. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6189
2013-06-17 15:12:45 +02:00
'PhabricatorAuthUnlinkController' => 'applications/auth/controller/PhabricatorAuthUnlinkController.php',
Implement new auth login flow and login validation controller Summary: Ref T1536. None of this code is reachable. Implements new-auth login (so you can actually login) and login validation (which checks that cookies were set correctly). Test Plan: Manually enabled FB auth, went through the auth flow to login/logout. Manually hit most of the validation errors. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6162
2013-06-16 19:15:33 +02:00
'PhabricatorAuthValidateController' => 'applications/auth/controller/PhabricatorAuthValidateController.php',
First go at Authentication config options. Test Plan: Looked at them in the web UI. Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4355
2013-01-07 21:48:39 +01:00
'PhabricatorAuthenticationConfigOptions' => 'applications/config/option/PhabricatorAuthenticationConfigOptions.php',
Make it much easier to add one-off event listeners Summary: Ref T4657. Right now, you have to muck with `events.listeners` to install listeners. Instead, automatically install all subclasses of AutoEventListener. Primarily, this makes it easier to resolve requests with "drop this file in `src/extensions/`, no warranty", which seems to have worked well so far in resolving things like custom remarkup rules, etc. Test Plan: - Added such a listener, had it autoregister. - Clicked around and saw the effects of normal listeners. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4657 Differential Revision: https://secure.phabricator.com/D9262
2014-05-23 00:19:28 +02:00
'PhabricatorAutoEventListener' => 'infrastructure/events/PhabricatorAutoEventListener.php',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgeHasRecipientEdgeType' => 'applications/badges/edge/PhabricatorBadgeHasRecipientEdgeType.php',
'PhabricatorBadgesApplication' => 'applications/badges/application/PhabricatorBadgesApplication.php',
Add PhabricatorBadgeArchiveController Summary: Allows archive and activate on badges from action list. Ref T9414 Test Plan: Archive, Activate, New, Edit Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9414 Differential Revision: https://secure.phabricator.com/D14727
2015-12-09 22:26:26 +01:00
'PhabricatorBadgesArchiveController' => 'applications/badges/controller/PhabricatorBadgesArchiveController.php',
Converting badge recipients from Edge to BadgeAward table Summary: Ref T8996, Convert badge recipients from Edges to actual BadgeAward objects Test Plan: Create badge, award it to recipient. Make sure adding/removing recipients works. (Still need to migrate exisiting recipients to new table and need to create activity feed blurbs) Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: chad, Korvin Maniphest Tasks: T8996 Differential Revision: https://secure.phabricator.com/D15014
2016-01-13 20:33:46 +01:00
'PhabricatorBadgesAward' => 'applications/badges/storage/PhabricatorBadgesAward.php',
Allow awarding Badges from the profile Summary: [WIP] Allows awarding a badge from a user profile. Unsure of the interactions here if a user can't award any badges, or if we should just hide this. Fixes T10688 Fixes T10318 Test Plan: Award some badges. Steal them back. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T10318, T10688 Differential Revision: https://secure.phabricator.com/D15544
2016-03-31 22:39:06 +02:00
'PhabricatorBadgesAwardController' => 'applications/badges/controller/PhabricatorBadgesAwardController.php',
Converting badge recipients from Edge to BadgeAward table Summary: Ref T8996, Convert badge recipients from Edges to actual BadgeAward objects Test Plan: Create badge, award it to recipient. Make sure adding/removing recipients works. (Still need to migrate exisiting recipients to new table and need to create activity feed blurbs) Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: chad, Korvin Maniphest Tasks: T8996 Differential Revision: https://secure.phabricator.com/D15014
2016-01-13 20:33:46 +01:00
'PhabricatorBadgesAwardQuery' => 'applications/badges/query/PhabricatorBadgesAwardQuery.php',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesBadge' => 'applications/badges/storage/PhabricatorBadgesBadge.php',
Make badges searchable by name Summary: Closes T10690 Test Plan: Open Badges application, go to Advanced Search, search for a badge by its name and see result. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Maniphest Tasks: T10690 Differential Revision: https://secure.phabricator.com/D15656
2016-04-07 21:12:34 +02:00
'PhabricatorBadgesBadgeNameNgrams' => 'applications/badges/storage/PhabricatorBadgesBadgeNameNgrams.php',
Add commenting to Badges Summary: Fixes T8949. Adds the ability to render honors on those who have fought and received badges of distinction and honor. Test Plan: Write 'asdf'. See 'asdf'. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T8949 Differential Revision: https://secure.phabricator.com/D13704
2015-07-24 19:56:08 +02:00
'PhabricatorBadgesCommentController' => 'applications/badges/controller/PhabricatorBadgesCommentController.php',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesController' => 'applications/badges/controller/PhabricatorBadgesController.php',
'PhabricatorBadgesCreateCapability' => 'applications/badges/capability/PhabricatorBadgesCreateCapability.php',
'PhabricatorBadgesDAO' => 'applications/badges/storage/PhabricatorBadgesDAO.php',
First stab at a badges typeahead Summary: Ref T10702 Test Plan: Open a user profile, attempt to award an archived or previously awarded badge, badges dialog should provide a typeahead, and the suggestions should offer details about whether a badge is archived or already awarded. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T10702 Differential Revision: https://secure.phabricator.com/D15665
2016-04-09 20:40:02 +02:00
'PhabricatorBadgesDatasource' => 'applications/badges/typeahead/PhabricatorBadgesDatasource.php',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesDefaultEditCapability' => 'applications/badges/capability/PhabricatorBadgesDefaultEditCapability.php',
Add `badges.edit` and `badges.search` to Conduit API Summary: Ref T10671 Test Plan: Open Conduit application, open `badges.edit` or `badges.search`, create, edit, or query for a badge. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T10671 Differential Revision: https://secure.phabricator.com/D15622
2016-04-05 20:21:44 +02:00
'PhabricatorBadgesEditConduitAPIMethod' => 'applications/badges/conduit/PhabricatorBadgesEditConduitAPIMethod.php',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesEditController' => 'applications/badges/controller/PhabricatorBadgesEditController.php',
Convert Badges to use EditEngine Summary: Moves Badges over to EditEngine Test Plan: Create a new Badge, Edit a Badge Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14771
2016-01-01 17:12:13 +01:00
'PhabricatorBadgesEditEngine' => 'applications/badges/editor/PhabricatorBadgesEditEngine.php',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesEditRecipientsController' => 'applications/badges/controller/PhabricatorBadgesEditRecipientsController.php',
'PhabricatorBadgesEditor' => 'applications/badges/editor/PhabricatorBadgesEditor.php',
Provide a "PHUIFormIconSetControl" Summary: Ref T9992. This is a step on the path to getting EditEngine working in Badges, Projects and Calendar. This doesn't add a new `EditField` for icons yet, just standardizes the old stuff. New stuff is more general and I saved 150 lines of code. I put the endpoint in Files because the similar "choose a profile picture" endpoint will definitely go there, and this endpoint might eventually feature, like, "draw your own icon~~" or something. Test Plan: - Created events, projects and badges with custom icons. - Edited events, projects and badges, changing their icons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9992 Differential Revision: https://secure.phabricator.com/D14799
2015-12-16 16:53:13 +01:00
'PhabricatorBadgesIconSet' => 'applications/badges/icon/PhabricatorBadgesIconSet.php',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesListController' => 'applications/badges/controller/PhabricatorBadgesListController.php',
Add MAILTAGs to Badges Summary: Still doesn't mail yet, but the settings now show up. Test Plan: View email settings, see Badges options. Reviewers: eadler, epriestley Reviewed By: eadler, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13712
2015-07-25 22:34:43 +02:00
'PhabricatorBadgesMailReceiver' => 'applications/badges/mail/PhabricatorBadgesMailReceiver.php',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesPHIDType' => 'applications/badges/phid/PhabricatorBadgesPHIDType.php',
Converting badge quality property from color to an integer representation for later sorting purposes Summary: Ref T9007 Test Plan: Create badges, update quality, search by quality without change of functionality. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T9007 Differential Revision: https://secure.phabricator.com/D15551
2016-03-31 02:07:27 +02:00
'PhabricatorBadgesQuality' => 'applications/badges/constants/PhabricatorBadgesQuality.php',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesQuery' => 'applications/badges/query/PhabricatorBadgesQuery.php',
'PhabricatorBadgesRecipientsListView' => 'applications/badges/view/PhabricatorBadgesRecipientsListView.php',
'PhabricatorBadgesRemoveRecipientsController' => 'applications/badges/controller/PhabricatorBadgesRemoveRecipientsController.php',
Add MAILTAGs to Badges Summary: Still doesn't mail yet, but the settings now show up. Test Plan: View email settings, see Badges options. Reviewers: eadler, epriestley Reviewed By: eadler, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13712
2015-07-25 22:34:43 +02:00
'PhabricatorBadgesReplyHandler' => 'applications/badges/mail/PhabricatorBadgesReplyHandler.php',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesSchemaSpec' => 'applications/badges/storage/PhabricatorBadgesSchemaSpec.php',
Add `badges.edit` and `badges.search` to Conduit API Summary: Ref T10671 Test Plan: Open Conduit application, open `badges.edit` or `badges.search`, create, edit, or query for a badge. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T10671 Differential Revision: https://secure.phabricator.com/D15622
2016-04-05 20:21:44 +02:00
'PhabricatorBadgesSearchConduitAPIMethod' => 'applications/badges/conduit/PhabricatorBadgesSearchConduitAPIMethod.php',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesSearchEngine' => 'applications/badges/query/PhabricatorBadgesSearchEngine.php',
'PhabricatorBadgesTransaction' => 'applications/badges/storage/PhabricatorBadgesTransaction.php',
Add commenting to Badges Summary: Fixes T8949. Adds the ability to render honors on those who have fought and received badges of distinction and honor. Test Plan: Write 'asdf'. See 'asdf'. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T8949 Differential Revision: https://secure.phabricator.com/D13704
2015-07-24 19:56:08 +02:00
'PhabricatorBadgesTransactionComment' => 'applications/badges/storage/PhabricatorBadgesTransactionComment.php',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesTransactionQuery' => 'applications/badges/query/PhabricatorBadgesTransactionQuery.php',
'PhabricatorBadgesViewController' => 'applications/badges/controller/PhabricatorBadgesViewController.php',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorBarePageUIExample' => 'applications/uiexample/examples/PhabricatorBarePageUIExample.php',
Separate "PhabricatorBarePageView" out of "PhabricatorStandardPageView" Summary: For Phame, we really want more than a chromeless page -- it shouldn't have Javelin or Phabricator styles on it. Pull the bare infrastructure out of StandardPageView and make it available as BarePageView. Test Plan: Viewed bare page in UIExamples, various non-bare pages. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3711
2012-10-16 19:33:47 +02:00
'PhabricatorBarePageView' => 'view/page/PhabricatorBarePageView.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorBaseURISetupCheck' => 'applications/config/check/PhabricatorBaseURISetupCheck.php',
Implement bcrypt hasher, transparent login upgrade, and explicit upgrade for passwords Summary: Ref T4443. - Add a `password_hash()`-based bcrypt hasher if `password_hash()` is available. - When a user logs in using a password, upgrade their password to the strongest available hash format. - On the password settings page: - Warn the user if their password uses any algorithm other than the strongest one. - Show the algorithm the password uses. - Show the best available algorithm. Test Plan: As an md5 user, viewed password settings page and saw a warning. Logged out. Logged in, got upgraded, no more warning. Changed password, verified database rehash. Logged out, logged in. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4443 Differential Revision: https://secure.phabricator.com/D8270
2014-02-18 20:03:56 +01:00
'PhabricatorBcryptPasswordHasher' => 'infrastructure/util/password/PhabricatorBcryptPasswordHasher.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorBinariesSetupCheck' => 'applications/config/check/PhabricatorBinariesSetupCheck.php',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorBitbucketAuthProvider' => 'applications/auth/provider/PhabricatorBitbucketAuthProvider.php',
Begin lifting column layout logic out of ColumnPositionQuery Summary: Ref T10010. This is a precursor to D15171, which I'll eventually rebuild on top of these changes. Currently, ColumnPositionQuery does a lot of "column layout" stuff that's very similar to the Milestone/Subproject stuff that needs to happen in D15171. The current approach there ended up splitting this layout stuff across two unrelated classes (ColumnPositionQuery + BoardViewController), neither of which is a particularly great place to do it -- the Query is too low-level, and the Controller is too high-level. Instead, introduce a new "LayoutEngine" which does all this layout stuff. Swap two of the four places that we query this stuff over to the new engine: - "Project (Column)" on tasks. - Transaction generation when moving cards. These sites aren't swapped by this diff, but will be by the next one: - Actually applying transactions. - Main layout for boards (this could swap easily now, but applying transactions currently relies on position writes having taken place, so it can't swap until the other one swaps). Once everything is swapped over, I should be able to add the D15171 logic to LayoutEngine instead of BoardViewController and end up with a cleaner approach overall. One particularly benefit is that //looking// at a board won't do a bunch of position writes anymore, which wasn't a big deal, but which I was a bit uneasy with. Test Plan: - Viewed tasks that are on boards, saw column annotations in project list. - Moved cards between columns on a board. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D15174
2016-02-03 18:39:17 +01:00
'PhabricatorBoardLayoutEngine' => 'applications/project/engine/PhabricatorBoardLayoutEngine.php',
Add storage and read logic for workboard card cover photos Summary: No way to set photos yet, but if you magic them in they work. Primarily, this consolidates rendering logic so the move + edit + view controllers all run the same code to do tags / cover photos. Test Plan: {F1095870} Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15201
2016-02-06 22:02:13 +01:00
'PhabricatorBoardRenderingEngine' => 'applications/project/engine/PhabricatorBoardRenderingEngine.php',
Rewrite workboards to have way more bugs Summary: Ref T4900. Briefly: - Much more layout and rendering is now done in Javascript. - This should otherwise be identical to the behavior at HEAD, except that: - editing a task and removing the current board from it no longer removes the task; and - points still don't work. However, this can now plausibly support realtime workboard updates and other complex state-based behaviors like points calculations in a future change. Test Plan: - Changed card covers. - Moved cards. - Sorted board by priority and natural. - Added new cards. - Edited cards in place. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4900 Differential Revision: https://secure.phabricator.com/D15234
2016-02-10 14:59:46 +01:00
'PhabricatorBoardResponseEngine' => 'applications/project/engine/PhabricatorBoardResponseEngine.php',
Port "Allow Dangerous Changes" to new Manage UI Summary: Ref T10748. Brings this forward in the UI and EditEngine. Test Plan: - Edited via Conduit. - Viewed via Manage UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15805
2016-04-27 01:02:57 +02:00
'PhabricatorBoolEditField' => 'applications/transactions/editfield/PhabricatorBoolEditField.php',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorBot' => 'infrastructure/daemon/bot/PhabricatorBot.php',
Formalize targets (users and channel) into objects Summary: Make users/channels/rooms into objects, so we can later sort out stuff like Campfire user IDs, Phabricator vs chat accounts, etc. The only change here is that I removed output buffering from the macro handler. We should move throttling/buffering to adapters instead and have it apply globally. Test Plan: Ran IRC and Campfire bots and interacted with them. Reviewers: indiefan Reviewed By: indiefan CC: aran Differential Revision: https://secure.phabricator.com/D4924
2013-02-14 14:13:38 +01:00
'PhabricatorBotChannel' => 'infrastructure/daemon/bot/target/PhabricatorBotChannel.php',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorBotDebugLogHandler' => 'infrastructure/daemon/bot/handler/PhabricatorBotDebugLogHandler.php',
'PhabricatorBotFeedNotificationHandler' => 'infrastructure/daemon/bot/handler/PhabricatorBotFeedNotificationHandler.php',
Added Flowdock protocol adapter for the bot. Refactored campfire bot into a base streaming protocol adapter for common functionality. Summary: First pass. Flowdock supports interesting message types (like replies to messages), but for now implementing a standard messaging interface. Test Plan: Ran both a Flowdock bot and a Campfire bot. Made sure both still connected and responded properly to the Object Handler. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4983
2013-02-16 05:24:23 +01:00
'PhabricatorBotFlowdockProtocolAdapter' => 'infrastructure/daemon/bot/adapter/PhabricatorBotFlowdockProtocolAdapter.php',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorBotHandler' => 'infrastructure/daemon/bot/handler/PhabricatorBotHandler.php',
'PhabricatorBotLogHandler' => 'infrastructure/daemon/bot/handler/PhabricatorBotLogHandler.php',
'PhabricatorBotMacroHandler' => 'infrastructure/daemon/bot/handler/PhabricatorBotMacroHandler.php',
'PhabricatorBotMessage' => 'infrastructure/daemon/bot/PhabricatorBotMessage.php',
'PhabricatorBotObjectNameHandler' => 'infrastructure/daemon/bot/handler/PhabricatorBotObjectNameHandler.php',
'PhabricatorBotSymbolHandler' => 'infrastructure/daemon/bot/handler/PhabricatorBotSymbolHandler.php',
Formalize targets (users and channel) into objects Summary: Make users/channels/rooms into objects, so we can later sort out stuff like Campfire user IDs, Phabricator vs chat accounts, etc. The only change here is that I removed output buffering from the macro handler. We should move throttling/buffering to adapters instead and have it apply globally. Test Plan: Ran IRC and Campfire bots and interacted with them. Reviewers: indiefan Reviewed By: indiefan CC: aran Differential Revision: https://secure.phabricator.com/D4924
2013-02-14 14:13:38 +01:00
'PhabricatorBotTarget' => 'infrastructure/daemon/bot/target/PhabricatorBotTarget.php',
'PhabricatorBotUser' => 'infrastructure/daemon/bot/target/PhabricatorBotUser.php',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorBotWhatsNewHandler' => 'infrastructure/daemon/bot/handler/PhabricatorBotWhatsNewHandler.php',
Update Phabricator to work with more modular translations Summary: Ref T7152. Ref T1139. This updates Phabricator so third-party libraries can translate their own stuff. Also: - Hide "All Caps" when not in development mode, since some users have found this a little confusing. - With other changes, adds a "Raw Strings" mode (development mode only). - Add an example silly translation to make sure the serious business flag works. - Add a basic British English translation. - Simplify handling of translation overrides. Test Plan: - Flipped serious business / development on and off and saw silly/development translations drop off. - Switched to "All Caps" and saw all caps. - Switched to Very English, Wow! - Switched to British english and saw "colour". Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152, T1139 Differential Revision: https://secure.phabricator.com/D11747
2015-02-11 22:02:35 +01:00
'PhabricatorBritishEnglishTranslation' => 'infrastructure/internationalization/translation/PhabricatorBritishEnglishTranslation.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'PhabricatorBuiltinPatchList' => 'infrastructure/storage/patch/PhabricatorBuiltinPatchList.php',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorBulkContentSource' => 'infrastructure/daemon/contentsource/PhabricatorBulkContentSource.php',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorBusyUIExample' => 'applications/uiexample/examples/PhabricatorBusyUIExample.php',
Add a generic multistep Markup cache Summary: The immediate issue this addresses is T1366, adding a rendering cache to Phriction. For wiki pages with code blocks especially, rerendering them each time is expensive. The broader issue is that out markup caches aren't very good right now. They have three major problems: **Problem 1: the data is stored in the wrong place.** We currently store remarkup caches on objects. This means we're always loading it and passing it around even when we don't need it, can't genericize cache management code (e.g., have one simple script to drop/GC caches), need to update authoritative rows to clear caches, and can't genericize rendering code since each object is different. To solve this, I created a dedicated cache database that I plan to move all markup caches to use. **Problem 2: time-variant rules break when cached.** Some rules like `**bold**` are time-invariant and always produce the same output, but some rules like `{Tnnn}` and `@username` are variant and may render differently (because a task was closed or a user is on vacation). Currently, we cache the raw output, so these time-variant rules get locked at whatever values they had when they were first rendered. This is the main reason Phriction doesn't have a cache right now -- I wanted `{Tnnn}` rules to reflect open/closed tasks. To solve this, I split markup into a "preprocessing" phase (which does all the parsing and evaluates all time-invariant rules) and a "postprocessing" phase (which evaluates time-variant rules only). The preprocessing phase is most of the expense (and, notably, includes syntax highlighting) so this is nearly as good as caching the final output. I did most of the work here in D737 / D738, but we never moved to use it in Phabricator -- we currently just do the two operations serially in all cases. This diff splits them apart and caches the output of preprocessing only, so we benefit from caching but also get accurate time-variant rendering. **Problem 3: cache access isn't batched/pipelined optimally.** When we're rendering a list of markup blocks, we should be able to batch datafetching better than we do. D738 helped with this (fetching is batched within a single hunk of markup) and this improves batching on cache access. We could still do better here, but this is at least a step forward. Also fixes a bug with generating a link in the Phriction history interface ($uri gets clobbered). I'm using PHP serialization instead of JSON serialization because Remarkup does some stuff with non-ascii characters that might not survive JSON. Test Plan: - Created a Phriction document and verified that previews don't go to cache (no rows appear in the cache table). - Verified that published documents come out of cache. - Verified that caches generate/regenerate correctly, time-variant rules render properly and old documents hit the right caches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1366 Differential Revision: https://secure.phabricator.com/D2945
2012-07-10 00:20:56 +02:00
'PhabricatorCacheDAO' => 'applications/cache/storage/PhabricatorCacheDAO.php',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorCacheGeneralGarbageCollector' => 'applications/cache/garbagecollector/PhabricatorCacheGeneralGarbageCollector.php',
Provide 'bin/cache', for managing caches Summary: See <https://github.com/facebook/phabricator/issues/323>. We have a very old cache management script which doesn't purge all the modern caches (and does purge some caches which are no longer in use). Update it so it purges all the modern caches (remarkup, general, changeset), no longer purges outdated caches, and is easier to use. Also delete a lot of "this script has moved" scripts from the last few rounds of similar cleanup, I believe all of these have been in master for at least several months, which should be enough time for users to get used to the new stuff. Test Plan: Ran `bin/cache` with various arguments. Verified caches were purged. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5978
2013-05-20 19:16:35 +02:00
'PhabricatorCacheManagementPurgeWorkflow' => 'applications/cache/management/PhabricatorCacheManagementPurgeWorkflow.php',
'PhabricatorCacheManagementWorkflow' => 'applications/cache/management/PhabricatorCacheManagementWorkflow.php',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorCacheMarkupGarbageCollector' => 'applications/cache/garbagecollector/PhabricatorCacheMarkupGarbageCollector.php',
Generate reasonable expected schemata for Cache tables Summary: Ref T1191. Notable: - Rename `blob` to `bytes` for clarity. - Introduce raw schema specs. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10501
2014-09-18 17:36:22 +02:00
'PhabricatorCacheSchemaSpec' => 'applications/cache/storage/PhabricatorCacheSchemaSpec.php',
Emit cache setup issues from cache specs Summary: Ref T5501. Currently, we emit some bad warnings about, e.g., "apc.stat" on PHP 5.5+ systems with OPcache, where the warnings are not relevant. Generate and raise warnings out of the CacheSpec pipeline so we only run relevant code. Test Plan: Faked various warnings and saw them render correctly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5501 Differential Revision: https://secure.phabricator.com/D12318
2015-04-08 20:31:01 +02:00
'PhabricatorCacheSetupCheck' => 'applications/config/check/PhabricatorCacheSetupCheck.php',
Restructure cache checks to improve modularity Summary: Ref T5501. This code was headed down a bad road; dump an indirection layer between rendering and data gatehring. In particular, this will make it much easier to lift these issues into setup warnings eventually. Test Plan: Viewed cache status page. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5501 Differential Revision: https://secure.phabricator.com/D12315
2015-04-07 23:38:03 +02:00
'PhabricatorCacheSpec' => 'applications/cache/spec/PhabricatorCacheSpec.php',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorCacheTTLGarbageCollector' => 'applications/cache/garbagecollector/PhabricatorCacheTTLGarbageCollector.php',
Add a "setup" cache Summary: See T2062. This cache allows us to essentially implement this sort of block: if (this_code_has_not_run_since_the_last_server_restart()) { ... } This will let us do setup checks automatically (i.e., without a specialized setup mode) without imposing hundreds of milliseconds of `git submodule status` and similar checks on every page load, even if an install does not have APC. Broadly, the major goals here are: - Reduce user errors and support costs related to misconfiguration (e.g., failure to update submodules). - Simplify setup and configuration (remove 'phabricator.setup', remove/reduce PHABRICATOR_ENV). - Move as much configuration to the web as possible (required for SaaS). Test Plan: Added this block to webroot/index.php: $cache = PhabricatorCaches::getSetupCache(); $result = $cache->getKeys(array('x')); if (empty($result['x'])) { phlog('Cache miss + set.'); $cache->setKeys(array('x' => 'y')); } else { phlog('Cache hit.'); } Verified it used APC correctly. Disabled APC and verified it degraded to a reasonable disk-based behavior. If we miss both of these we end up with no actual caching, but that's the best we can do. This code will also run too early in setup for it to be appropriate to raise exceptions out of this pathway -- later on, we can raise a warning that APC is not installed. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2227, T2062 Differential Revision: https://secure.phabricator.com/D4281
2012-12-25 15:09:51 +01:00
'PhabricatorCaches' => 'applications/cache/PhabricatorCaches.php',
Introduce a request cache mechanism Summary: Ref T8424. This adds a standard KeyValueCache to serve as a request cache. In particular, I need to cache Spaces (they are frequently accessed, sometimes by multiple viewers) but not have them survive longer than the scope of one request. This request cache is explicitly destroyed by each web request and each daemon request. In the very long term, building this kind of construct supports reusing PHP interpreters to run web requests (see some discussion in T2312). Test Plan: - Added and executed unit tests. - Ran every daemon. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8424 Differential Revision: https://secure.phabricator.com/D13153
2015-06-05 02:27:31 +02:00
'PhabricatorCachesTestCase' => 'applications/cache/__tests__/PhabricatorCachesTestCase.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorCalendarApplication' => 'applications/calendar/application/PhabricatorCalendarApplication.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorCalendarController' => 'applications/calendar/controller/PhabricatorCalendarController.php',
'PhabricatorCalendarDAO' => 'applications/calendar/storage/PhabricatorCalendarDAO.php',
Rename PhabricatorUserStatus to PhabricatorCalendarEvent Summary: Ref T4375. We never join this table, so this is a pretty straight find/replace. Test Plan: Browsed around Calendar, verified that nothing seemed broken. Saw my red dot in other apps. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8145
2014-02-06 19:07:29 +01:00
'PhabricatorCalendarEvent' => 'applications/calendar/storage/PhabricatorCalendarEvent.php',
Canceling calendar events should deactivate the event Summary: Closes T7943, Canceling calendar event should deactivate the event instead of destroying data. Test Plan: Create an event, cancel it, see changed status icon, query for active events, event should not appear, query for deactivated events, event should appear in results. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7943 Differential Revision: https://secure.phabricator.com/D12604
2015-04-29 17:39:39 +02:00
'PhabricatorCalendarEventCancelController' => 'applications/calendar/controller/PhabricatorCalendarEventCancelController.php',
Calendar events should support comments Summary: Closes T7956, Calendar events should support comments. Test Plan: Open event, add comment, save, comment should appear in timeline. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7956 Differential Revision: https://secure.phabricator.com/D12640
2015-05-01 02:38:04 +02:00
'PhabricatorCalendarEventCommentController' => 'applications/calendar/controller/PhabricatorCalendarEventCommentController.php',
Rescheduling events by dragging them in day view Summary: Ref T8300, Rescheduling events by dragging them in day view Test Plan: Open day view, drag events, observe them reschedule. Reviewers: chad, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T8300 Differential Revision: https://secure.phabricator.com/D12988
2015-05-24 04:47:23 +02:00
'PhabricatorCalendarEventDragController' => 'applications/calendar/controller/PhabricatorCalendarEventDragController.php',
Rename "status" to "event" in most URIs / classes / etc Summary: Ref T4375. This doesn't get everything (I figure I'll clean up the actual UI strings when I touch the UIs) but should get the bulk of the URIs and class names and stuff. Test Plan: Clicked every calendar-related link I could find/grep, they all still seem to work. URIs now say "event". Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8147
2014-02-06 19:10:07 +01:00
'PhabricatorCalendarEventEditController' => 'applications/calendar/controller/PhabricatorCalendarEventEditController.php',
T5464, ApplicationTransactions for calendar events Summary: Closes T5464, Implement ApplicationTransactions in Calendar. Test Plan: Create a calendar event, update calendar event, detail view of event should show update history. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: johnny-bit, Korvin, epriestley Maniphest Tasks: T5464 Differential Revision: https://secure.phabricator.com/D12586
2015-04-28 15:26:48 +02:00
'PhabricatorCalendarEventEditor' => 'applications/calendar/editor/PhabricatorCalendarEventEditor.php',
Users should be able to rsvp to event via email Summary: Closes T7957, Users should be able to rsvp to event via email. Test Plan: Create event, open invitee email, reply to email w/ !rsvp yes, refresh event, invitee should show as attending. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7957 Differential Revision: https://secure.phabricator.com/D12651
2015-05-02 04:01:29 +02:00
'PhabricatorCalendarEventEmailCommand' => 'applications/calendar/command/PhabricatorCalendarEventEmailCommand.php',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorCalendarEventFulltextEngine' => 'applications/calendar/search/PhabricatorCalendarEventFulltextEngine.php',
Calendar events should now auto-invite the creator Summary: Closes T7935, Calendar events should now auto-invite the creator. Test Plan: Create event, save, event should now show creator as an invitee. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7935 Differential Revision: https://secure.phabricator.com/D12613
2015-04-29 22:51:09 +02:00
'PhabricatorCalendarEventInvitee' => 'applications/calendar/storage/PhabricatorCalendarEventInvitee.php',
'PhabricatorCalendarEventInviteeQuery' => 'applications/calendar/query/PhabricatorCalendarEventInviteeQuery.php',
Ability to join or decline an event Summary: Ref T7986, Ability to join or decline an event. Test Plan: Open Calendar event, join event, Invitee list should update. Decline event, invitee list should remove you. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7986 Differential Revision: https://secure.phabricator.com/D12618
2015-04-30 03:18:27 +02:00
'PhabricatorCalendarEventJoinController' => 'applications/calendar/controller/PhabricatorCalendarEventJoinController.php',
Rename "status" to "event" in most URIs / classes / etc Summary: Ref T4375. This doesn't get everything (I figure I'll clean up the actual UI strings when I touch the UIs) but should get the bulk of the URIs and class names and stuff. Test Plan: Clicked every calendar-related link I could find/grep, they all still seem to work. URIs now say "event". Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8147
2014-02-06 19:10:07 +01:00
'PhabricatorCalendarEventListController' => 'applications/calendar/controller/PhabricatorCalendarEventListController.php',
Calendar event transaction emails without reply handling Summary: Ref T7957, Calendar event transaction emails without reply handling. Test Plan: Create event, invitees should get email. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7957 Differential Revision: https://secure.phabricator.com/D12645
2015-05-01 22:26:07 +02:00
'PhabricatorCalendarEventMailReceiver' => 'applications/calendar/mail/PhabricatorCalendarEventMailReceiver.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorCalendarEventPHIDType' => 'applications/calendar/phid/PhabricatorCalendarEventPHIDType.php',
Use a modern query object to query Calendar events Summary: Ref T4375. Calendar uses oldschool `loadOneWhere()` calls. Make CalendarEvent policy-aware, do the edit/delete policy checks through the policy framework, and use modern query infrastructure. Test Plan: - Viewed calendar; - created, edited, deleted event; - viewed calendar tab in Conpherence. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8146
2014-02-06 19:07:42 +01:00
'PhabricatorCalendarEventQuery' => 'applications/calendar/query/PhabricatorCalendarEventQuery.php',
Users should be able to rsvp to event via email Summary: Closes T7957, Users should be able to rsvp to event via email. Test Plan: Create event, open invitee email, reply to email w/ !rsvp yes, refresh event, invitee should show as attending. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7957 Differential Revision: https://secure.phabricator.com/D12651
2015-05-02 04:01:29 +02:00
'PhabricatorCalendarEventRSVPEmailCommand' => 'applications/calendar/command/PhabricatorCalendarEventRSVPEmailCommand.php',
Use ApplicationSearch in the calendar event list view Summary: Ref T4375. Basic ApplicationSearch integration to power this more flexibly. Test Plan: {F108762} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8148
2014-02-06 19:10:18 +01:00
'PhabricatorCalendarEventSearchEngine' => 'applications/calendar/query/PhabricatorCalendarEventSearchEngine.php',
T5464, ApplicationTransactions for calendar events Summary: Closes T5464, Implement ApplicationTransactions in Calendar. Test Plan: Create a calendar event, update calendar event, detail view of event should show update history. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: johnny-bit, Korvin, epriestley Maniphest Tasks: T5464 Differential Revision: https://secure.phabricator.com/D12586
2015-04-28 15:26:48 +02:00
'PhabricatorCalendarEventTransaction' => 'applications/calendar/storage/PhabricatorCalendarEventTransaction.php',
'PhabricatorCalendarEventTransactionComment' => 'applications/calendar/storage/PhabricatorCalendarEventTransactionComment.php',
'PhabricatorCalendarEventTransactionQuery' => 'applications/calendar/query/PhabricatorCalendarEventTransactionQuery.php',
Give Calendar events a more modern view/detail page Summary: Ref T4375. Very basic, but gives us a more standard place to put edit/delete operations. Test Plan: {F108765} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8149
2014-02-06 19:10:27 +01:00
'PhabricatorCalendarEventViewController' => 'applications/calendar/controller/PhabricatorCalendarEventViewController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorCalendarHoliday' => 'applications/calendar/storage/PhabricatorCalendarHoliday.php',
'PhabricatorCalendarHolidayTestCase' => 'applications/calendar/storage/__tests__/PhabricatorCalendarHolidayTestCase.php',
Provide a "PHUIFormIconSetControl" Summary: Ref T9992. This is a step on the path to getting EditEngine working in Badges, Projects and Calendar. This doesn't add a new `EditField` for icons yet, just standardizes the old stuff. New stuff is more general and I saved 150 lines of code. I put the endpoint in Files because the similar "choose a profile picture" endpoint will definitely go there, and this endpoint might eventually feature, like, "draw your own icon~~" or something. Test Plan: - Created events, projects and badges with custom icons. - Edited events, projects and badges, changing their icons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9992 Differential Revision: https://secure.phabricator.com/D14799
2015-12-16 16:53:13 +01:00
'PhabricatorCalendarIconSet' => 'applications/calendar/icon/PhabricatorCalendarIconSet.php',
Calendar event monograms, part 3. Remarkup for calendar event monograms. Summary: Ref T7928, Calendar event monograms, part 3. Remarkup for calendar event monograms. Test Plan: Create calendar event, open a maniphest task, add 'E{id}' and preview should show a hovertag for event that links to event. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7928 Differential Revision: https://secure.phabricator.com/D12580
2015-04-27 23:27:34 +02:00
'PhabricatorCalendarRemarkupRule' => 'applications/calendar/remarkup/PhabricatorCalendarRemarkupRule.php',
Calendar event transaction emails without reply handling Summary: Ref T7957, Calendar event transaction emails without reply handling. Test Plan: Create event, invitees should get email. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7957 Differential Revision: https://secure.phabricator.com/D12645
2015-05-01 22:26:07 +02:00
'PhabricatorCalendarReplyHandler' => 'applications/calendar/mail/PhabricatorCalendarReplyHandler.php',
Create Edge tables in phabricator_calendar db. Summary: Closes T7945, phabricator_calendar db should now have Edge tables. Test Plan: Use phabricator_calendar db in mysql, show create table edge, verify edge tables are present. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7945 Differential Revision: https://secure.phabricator.com/D12584
2015-04-28 01:35:55 +02:00
'PhabricatorCalendarSchemaSpec' => 'applications/calendar/storage/PhabricatorCalendarSchemaSpec.php',
First (rough) pass at campfire protocol adapter for bot. Summary: Decided the best approach for refactoring the message/command stuff would be to actually start implementing the campfire adapter to get a better idea of what the abstractions should look like. It feels awkward and unwieldy trying to maintain the irc command interface (notice the message instantiation in the `processReadBuffer()` method. However, i'm still not clear what the best approach is without requiring a re-write of nearly all the existing handlers and defining essentially a custom dsl on top of irc's. I suppose given that alternative, implementing to irc's dsl doesn't sound all that bad. Just feels like poor coupling. Also, I know that there is some http stuff in libphutil's futures library, but the https future is shit and I need to do some custom curlopt stuff I wasn't sure how to do with that. But if you think this should be refactored, let me know. I tested this with the ObjectHandler (messages with DXXX initiate the bot to respond with the title/link just as with irc), but beyond that, I haven't tried any of the other handlers, so if there are complications you think i'm going to run into, just let me know (this is one of the reasons for requesting review early on). Also, this diff is against my last one, even though that hasn't been merged down yet. It was starting to get large and I'd prefer to keep to two conversations separate. Fixing some lint issues. Test Plan: Ran the bot with the Object Handler in campfire and observed it behaving properly. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4830
2013-02-07 15:31:29 +01:00
'PhabricatorCampfireProtocolAdapter' => 'infrastructure/daemon/bot/adapter/PhabricatorCampfireProtocolAdapter.php',
Make Celerity a real application Summary: Ref T5702. This primarily gets URI routing out of Aphront and into an Application, for consistency. Test Plan: Loaded some pages, got static resources. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D10696
2014-10-13 20:17:23 +02:00
'PhabricatorCelerityApplication' => 'applications/celerity/application/PhabricatorCelerityApplication.php',
Add an acceptance test for Celerity maps Summary: Fixes T5374. Add an acceptance test to the `PhabricatorInfrastructureTestCase` class which fails if a Celerity map is not up-to-date. In order to achieve this, a lot of code used to generate Celerity maps was transferred from `CelerityManagementMapWorkflow` to `CelerityResourceMap` and `CelerityResourceMapGenerator`. Test Plan: Ran `arc unit` and noticed that all tests passed. Modified a JavaScript file and ran `arc unit` again (without running `./bin/celerity map`)... this time the test failed, as expected. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5374 Differential Revision: https://secure.phabricator.com/D9817
2014-09-22 10:50:20 +02:00
'PhabricatorCelerityTestCase' => '__tests__/PhabricatorCelerityTestCase.php',
Add unit tests for Git change parsers Summary: Ref T4327. Adds some basic tests to the Git parser for a set of common operations (add, change, move, copy, directory, symlink, propchange). Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D8012
2014-01-20 22:14:04 +01:00
'PhabricatorChangeParserTestCase' => 'applications/repository/worker/__tests__/PhabricatorChangeParserTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorChangesetResponse' => 'infrastructure/diff/PhabricatorChangesetResponse.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorChatLogApplication' => 'applications/chatlog/application/PhabricatorChatLogApplication.php',
Added a new storage object Summary: Added a new storage object. Created PhabricatorChagLogChannel Test Plan: Will be specified by Evan :P Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4943
2013-02-14 13:10:42 +01:00
'PhabricatorChatLogChannel' => 'applications/chatlog/storage/PhabricatorChatLogChannel.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorChatLogChannelListController' => 'applications/chatlog/controller/PhabricatorChatLogChannelListController.php',
'PhabricatorChatLogChannelLogController' => 'applications/chatlog/controller/PhabricatorChatLogChannelLogController.php',
Modernize chatlog a bit Summary: Ref T4786. This doesn't fully fix the issue since there's no way to make channels public yet, but gets some of the infrastructure more up to date. - Allow public access to the list and log controllers. - Implement proper policy checks in the Events (this has no practical impact on the only controller that loads this stuff, it's just for general/future purposes). - Remove a old-style unused method for building page frames. Test Plan: Viewed log list and log details as logged-in and logged out users. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4786 Differential Revision: https://secure.phabricator.com/D8746
2014-04-10 20:45:21 +02:00
'PhabricatorChatLogChannelQuery' => 'applications/chatlog/query/PhabricatorChatLogChannelQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorChatLogController' => 'applications/chatlog/controller/PhabricatorChatLogController.php',
'PhabricatorChatLogDAO' => 'applications/chatlog/storage/PhabricatorChatLogDAO.php',
'PhabricatorChatLogEvent' => 'applications/chatlog/storage/PhabricatorChatLogEvent.php',
Modernize chatlog a bit Summary: Ref T4786. This doesn't fully fix the issue since there's no way to make channels public yet, but gets some of the infrastructure more up to date. - Allow public access to the list and log controllers. - Implement proper policy checks in the Events (this has no practical impact on the only controller that loads this stuff, it's just for general/future purposes). - Remove a old-style unused method for building page frames. Test Plan: Viewed log list and log details as logged-in and logged out users. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4786 Differential Revision: https://secure.phabricator.com/D8746
2014-04-10 20:45:21 +02:00
'PhabricatorChatLogQuery' => 'applications/chatlog/query/PhabricatorChatLogQuery.php',
Add a chunking storage engine for files Summary: Ref T7149. This isn't complete and isn't active yet, but does basically work. I'll shore it up in the next few diffs. The new workflow goes like this: > Client, file.allocate(): I'd like to upload a file with length L, metadata M, and hash H. Then the server returns `upload` (a boolean) and `filePHID` (a PHID). These mean: | upload | filePHID | means | |---|---|---| | false | false | Server can't accept file. | false | true | File data already known, file created from hash. | true | false | Just upload normally. | true | true | Query chunks to start or resume a chunked upload. All but the last case are uninteresting and work like exising uploads with `file.uploadhash` (which we can eventually deprecate). In the last case: > Client, file.querychunks(): Give me a list of chunks that I should upload. This returns all the chunks for the file. Chunks have a start byte, an end byte, and a "complete" flag to indicate that the server already has the data. Then, the client fills in chunks by sending them: > Client, file.uploadchunk(): Here is the data for one chunk. This stuff doesn't work yet or has some caveats: - I haven't tested resume much. - Files need an "isPartial()" flag for partial uploads, and the UI needs to respect it. - The JS client needs to become chunk-aware. - Chunk size is set crazy low to make testing easier. - Some debugging flags that I'll remove soon-ish. - Downloading works, but still streams the whole file into memory. - This storage engine is disabled by default (hardcoded as a unit test engine) because it's still sketchy. - Need some code to remove the "isParital" flag when the last chunk is uploaded. - Maybe do checksumming on chunks. Test Plan: - Hacked up `arc upload` (see next diff) to be chunk-aware and uploaded a readme in 18 32-byte chunks. Then downloaded it. Got the same file back that I uploaded. - File UI now shows some basic chunk info for chunked files: {F336434} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12060
2015-03-13 19:30:02 +01:00
'PhabricatorChunkedFileStorageEngine' => 'applications/files/engine/PhabricatorChunkedFileStorageEngine.php',
Add `cluster.addresses` and require membership before accepting cluster authentication tokens Summary: Ref T2783. Ref T6706. - Add `cluster.addresses`. This is a whitelist of CIDR blocks which define cluster hosts. - When we recieve a request that has a cluster-based authentication token, require the cluster to be configured and require the remote address to be a cluster member before we accept it. - This provides a general layer of security for these mechanisms. - In particular, it means they do not work by default on unconfigured hosts. - When cluster addresses are configured, and we receive a request //to// an address not on the list, reject it. - This provides a general layer of security for getting the Ops side of cluster configuration correct. - If cluster nodes have public IPs and are listening on them, we'll reject requests. - Basically, this means that any requests which bypass the LB get rejected. Test Plan: - With addresses not configured, tried to make requests; rejected for using a cluster auth mechanism. - With addresses configred wrong, tried to make requests; rejected for sending from (or to) an address outside of the cluster. - With addresses configured correctly, made valid requests. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6706, T2783 Differential Revision: https://secure.phabricator.com/D11159
2015-01-03 00:13:41 +01:00
'PhabricatorClusterConfigOptions' => 'applications/config/option/PhabricatorClusterConfigOptions.php',
Lay `cluster.databases` configuration groundwork for database clustering Summary: Ref T4571. This adds a new option which allows you to upgrade your one-host configuration to a multi-host configuration by configuring it. Doing this currently does nothing. I wrote a lot of words about what it is //supposed// to do in the future, though. Test Plan: - Tried to configure the option in all the possible bad ways, got errors. - Read documentation. Reviewers: chad Reviewed By: chad Subscribers: eadler Maniphest Tasks: T4571 Differential Revision: https://secure.phabricator.com/D15663
2016-04-09 14:41:08 +02:00
'PhabricatorClusterDatabasesConfigOptionType' => 'infrastructure/cluster/PhabricatorClusterDatabasesConfigOptionType.php',
When no master database is configured, automatically degrade to read-only mode Summary: Ref T4571. If `cluster.databases` is configured but only has replicas, implicitly drop to read-only mode and send writes to a replica. Test Plan: - Disabled the `master`, saw Phabricator automatically degrade into read-only mode against replicas. - (Also tested: explicit read-only mode, non-cluster mode, properly configured cluster mode). Reviewers: chad Reviewed By: chad Maniphest Tasks: T4571 Differential Revision: https://secure.phabricator.com/D15672
2016-04-10 14:10:06 +02:00
'PhabricatorClusterException' => 'infrastructure/cluster/PhabricatorClusterException.php',
'PhabricatorClusterExceptionHandler' => 'infrastructure/cluster/PhabricatorClusterExceptionHandler.php',
Automatically degrade to read-only mode when unable to connect to the master Summary: Ref T4571. If we fail to connect to the master, automatically try to degrade into a temporary read-only mode ("UNREACHABLE") for the remainder of the request, if possible. If the request was something like "load the homepage", that'll work fine. If it was something like "submit a comment", there's nothing we can do and we just have to fail. Detecting this condition imposes a performance penalty: every request checks the connection and gives the database a long time to respond, since we don't want to drop writes unless we have to. So the degraded mode works, but it's really slow, and may perpetuate the problem if the root issue is load-related. This lays the groundwork for improving this case by degrading futher into a "SEVERED" mode which will persist across requests. In the future, if several requests in a short period of time fail, we'll sever the database host and refuse to try to connect to it for a little while, connecting directly to replicas instead (basically, we're "health checking" the master, like a load balancer would health check a web application server). This will give us a better (much faster) degraded mode in a major service disruption, and reduce load on the master if the root cause is load-related, giving it a better chance of recovering on its own. Test Plan: - Disabled master in config by changing the host/username, got degraded automatically to UNREACAHBLE mode immediately. - Faked full SEVERED mode, requests hit replicas and put me in the mode properly. - Made stuff work, hit some good pages. - Hit some non-cluster pages. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4571 Differential Revision: https://secure.phabricator.com/D15674
2016-04-10 14:51:34 +02:00
'PhabricatorClusterImpossibleWriteException' => 'infrastructure/cluster/PhabricatorClusterImpossibleWriteException.php',
When no master database is configured, automatically degrade to read-only mode Summary: Ref T4571. If `cluster.databases` is configured but only has replicas, implicitly drop to read-only mode and send writes to a replica. Test Plan: - Disabled the `master`, saw Phabricator automatically degrade into read-only mode against replicas. - (Also tested: explicit read-only mode, non-cluster mode, properly configured cluster mode). Reviewers: chad Reviewed By: chad Maniphest Tasks: T4571 Differential Revision: https://secure.phabricator.com/D15672
2016-04-10 14:10:06 +02:00
'PhabricatorClusterImproperWriteException' => 'infrastructure/cluster/PhabricatorClusterImproperWriteException.php',
Automatically degrade to read-only mode when unable to connect to the master Summary: Ref T4571. If we fail to connect to the master, automatically try to degrade into a temporary read-only mode ("UNREACHABLE") for the remainder of the request, if possible. If the request was something like "load the homepage", that'll work fine. If it was something like "submit a comment", there's nothing we can do and we just have to fail. Detecting this condition imposes a performance penalty: every request checks the connection and gives the database a long time to respond, since we don't want to drop writes unless we have to. So the degraded mode works, but it's really slow, and may perpetuate the problem if the root issue is load-related. This lays the groundwork for improving this case by degrading futher into a "SEVERED" mode which will persist across requests. In the future, if several requests in a short period of time fail, we'll sever the database host and refuse to try to connect to it for a little while, connecting directly to replicas instead (basically, we're "health checking" the master, like a load balancer would health check a web application server). This will give us a better (much faster) degraded mode in a major service disruption, and reduce load on the master if the root cause is load-related, giving it a better chance of recovering on its own. Test Plan: - Disabled master in config by changing the host/username, got degraded automatically to UNREACAHBLE mode immediately. - Faked full SEVERED mode, requests hit replicas and put me in the mode properly. - Made stuff work, hit some good pages. - Hit some non-cluster pages. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4571 Differential Revision: https://secure.phabricator.com/D15674
2016-04-10 14:51:34 +02:00
'PhabricatorClusterStrandedException' => 'infrastructure/cluster/PhabricatorClusterStrandedException.php',
Roughly implement milestone columns on workboards Summary: Ref T10010. These aren't perfect but I think (?) they aren't horribly broken. - When a project is a parent project, destroy (as far as the user can tell) any custom columns. - When a project has milestones, automatically generate columns on the project's workboard (if it has a workboard). - When you move tasks between milestones, add the proper milestone tag. - When you move tasks out of milestones back into the backlog, add the proper parent project tag. - (Plenty of UI / design stuff to adjust.) Test Plan: - Dragged stuff between milestone columns. - Used a normal workboard. - Wasn't able to find any egregiously bad cases that did anything terrible. {F1088224} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D15171
2016-02-02 18:53:18 +01:00
'PhabricatorColumnProxyInterface' => 'applications/project/interface/PhabricatorColumnProxyInterface.php',
Expose column positions via maniphest.edit Summary: Ref T5214. Fixes T10486. Ref T6027. This exposes the `TYPE_COLUMNS` transaction in a usable way via API, and fixes the interactions via prefilling. Test Plan: - Created tasks directly into columns via API. - Moved tasks between columns via API. - Used `?column=...` to try to create a template task with valid and bogus column PHIDs. Reviewers: chad Reviewed By: chad Subscribers: AmyLewis Maniphest Tasks: T5214, T6027, T10486 Differential Revision: https://secure.phabricator.com/D15636
2016-04-06 13:37:01 +02:00
'PhabricatorColumnsEditField' => 'applications/transactions/editfield/PhabricatorColumnsEditField.php',
Fully modularize DestructionEngine Summary: Ref T9979. Convert all DestructionEngine behaviors to extensions. Test Plan: {F1033244} Destroyed an object, verifying: - Herald transcripts were destroyed; - edges were destroyed; - flags were destroyed; - tokens were destroyed; - transactions were destroyed; - worker tasks were cancelled. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14832
2015-12-20 17:11:59 +01:00
'PhabricatorCommentEditEngineExtension' => 'applications/transactions/engineextension/PhabricatorCommentEditEngineExtension.php',
Support comments as an EditEngine field Summary: Ref T9132. This adds an automatic "Comments" field, like the Subscribers/Projects/Policy fields. The primary goals here are: - Allow users to make comments via Conduit. - In the future, get stackable action support. As a side effect, this also allows you to put comments on create forms. This is a little silly but seems fine, and may be relevant on edit forms (which I'm not 100% sure how I want to handle yet). I've just hidden them by default for now. Test Plan: {F976036} {F976037} {F976038} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14515
2015-11-18 23:11:21 +01:00
'PhabricatorCommentEditField' => 'applications/transactions/editfield/PhabricatorCommentEditField.php',
'PhabricatorCommentEditType' => 'applications/transactions/edittype/PhabricatorCommentEditType.php',
Add CustomField to Diffusion and add a "branches" field Summary: Ref T4588. Request from @zeeg. Adds a "BRANCHES" field to commit emails, so the branches the commit appears on are shown. I've implemented this with CustomField, but in a very light way. Test Plan: Used `scripts/repository/reparse.php --herald` to generate mail, got a BRANCHES section where applicable. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley, zeeg Maniphest Tasks: T4588 Differential Revision: https://secure.phabricator.com/D8501
2014-03-12 19:30:33 +01:00
'PhabricatorCommitBranchesField' => 'applications/repository/customfield/PhabricatorCommitBranchesField.php',
'PhabricatorCommitCustomField' => 'applications/repository/customfield/PhabricatorCommitCustomField.php',
show merged commits in herald emails for merge commits Summary: Includes a new Block in Herad emails which tells the user about which commits were merged in a merge commit Otherwise the email would just say "Merge branch XYZ". Ref T8295 Test Plan: imported various commits (and merges) and watched resulting herald emails for all of them Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T8295 Differential Revision: https://secure.phabricator.com/D12993
2015-05-25 13:49:12 +02:00
'PhabricatorCommitMergedCommitsField' => 'applications/repository/customfield/PhabricatorCommitMergedCommitsField.php',
Add repository to audit emails Summary: This is vaguely related to T5791. Add a "REPOSITORY" header to audit emails so that they can be filtered in Gmail. Test Plan: Commented on an audit and used `./bin/mail show-outbound` to inspect outbound email. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: fabe, Korvin, epriestley Differential Revision: https://secure.phabricator.com/D12997
2015-05-25 14:43:42 +02:00
'PhabricatorCommitRepositoryField' => 'applications/repository/customfield/PhabricatorCommitRepositoryField.php',
Audit - move over to application search Summary: ...also kills off "PhabricatorAuditCommitQuery" and "PhabricatorAuditQuery", by moving the work to "DiffusionCommitQuery". Generally cleans up some code around the joint on this too. Also provides policies for audit requests, which is basically the policy for the underlying commit. Fixes T4715. (For the TODO I added about files, I just grabbed T4713.) Test Plan: Audit: verified the three default views all showed the correct things, including highligthing. did some custom queries and got the correct results. Diffusion: verified "blame view" still worked. verified paths were highlighted for packages i owned. Home: verified audit boxes showed up with proper commits w/ audits bin/audit: played around with it via --dry-run and got the right audits back Reviewers: epriestley Reviewed By: epriestley Subscribers: chad, epriestley, Korvin Maniphest Tasks: T4715 Differential Revision: https://secure.phabricator.com/D8805
2014-04-27 18:43:05 +02:00
'PhabricatorCommitSearchEngine' => 'applications/audit/query/PhabricatorCommitSearchEngine.php',
Add a "tags" field to Diffusion commit Summary: - Fixes T4588. - See D8501. - Adds a "Tags" field for Herald commit emails. - Fixes a bug in `tagsquery` when filtering by commit name. - Make `tagsquery` just return nothing instead of fataling against Mercurial/Subversion. Test Plan: Used `bin/repository/reparse.php --herald` to exercise this code. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4588 Differential Revision: https://secure.phabricator.com/D8502
2014-03-12 19:30:52 +01:00
'PhabricatorCommitTagsField' => 'applications/repository/customfield/PhabricatorCommitTagsField.php',
Add a common password blacklist Summary: Fixes T4143. This mitigates the "use a botnet to slowly try to login to every user account using the passwords '1234', 'password', 'asdfasdf', ..." attack, like the one that hit GitHub. (I also donated some money to Openwall as a thanks for compiling this wordlist.) Test Plan: - Tried to register with a weak password; registered with a strong password. - Tried to set VCS password to a weak password; set VCS password to a strong password. - Tried to change password to a weak password; changed password to a strong password. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T4143 Differential Revision: https://secure.phabricator.com/D8048
2014-01-23 23:01:18 +01:00
'PhabricatorCommonPasswords' => 'applications/auth/constants/PhabricatorCommonPasswords.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorConduitAPIController' => 'applications/conduit/controller/PhabricatorConduitAPIController.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorConduitApplication' => 'applications/conduit/application/PhabricatorConduitApplication.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorConduitCertificateToken' => 'applications/conduit/storage/PhabricatorConduitCertificateToken.php',
Write some basic "dealing with Conduit changes" documentation Summary: Ref T9980. No magic here, just write a little bit about how to find outdated callers. Update the technical doc. Also: - Fix an unrelated bug where you couldn't leave comments if an object had missing, required, custom fields. - Restore the ConduitConnectionLog table so `bin/storage adjust` doesn't complain. Test Plan: Read docs. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9980 Differential Revision: https://secure.phabricator.com/D14784
2015-12-14 23:36:47 +01:00
'PhabricatorConduitConnectionLog' => 'applications/conduit/storage/PhabricatorConduitConnectionLog.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorConduitConsoleController' => 'applications/conduit/controller/PhabricatorConduitConsoleController.php',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorConduitContentSource' => 'infrastructure/contentsource/PhabricatorConduitContentSource.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorConduitController' => 'applications/conduit/controller/PhabricatorConduitController.php',
'PhabricatorConduitDAO' => 'applications/conduit/storage/PhabricatorConduitDAO.php',
Support editing statuses and paths in Owners via Conduit API Summary: Ref T9964. Fixes T9752. Provides API access to enable/disable packages and change their paths. Test Plan: - Changed status via Conduit. - Changed paths via Conduit. - Tried to change a path use a nonsense/bogus repository PHID, got an error. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9752, T9964 Differential Revision: https://secure.phabricator.com/D14790
2015-12-15 18:11:11 +01:00
'PhabricatorConduitEditField' => 'applications/transactions/editfield/PhabricatorConduitEditField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorConduitListController' => 'applications/conduit/controller/PhabricatorConduitListController.php',
'PhabricatorConduitLogController' => 'applications/conduit/controller/PhabricatorConduitLogController.php',
Mostly modernize Conduit logs Summary: - Add GC support to conduit logs. - Add Query support to conduit logs. - Record the actual user PHID. - Show client name. - Support querying by specific method, so I can link to this from a setup issue. @wez, this migration may not be fast. It took about 8 seconds for me to migrate 800,000 rows in the `conduit_methodcalllog` table. This adds a GC which should keep the table at a more manageable size in the future. You can safely delete all data older than 30 days from this table, although you should do it by `id` instead of `dateCreated` since there's no key on `dateCreated` until this patch. Test Plan: - Ran GC. - Looked at log UI. - Ran Conduit methods. Reviewers: btrahan Reviewed By: btrahan CC: wez, aran Differential Revision: https://secure.phabricator.com/D6332
2013-07-01 21:37:34 +02:00
'PhabricatorConduitLogQuery' => 'applications/conduit/query/PhabricatorConduitLogQuery.php',
Move ConduitLogs to ApplicationSearch Summary: Ref T9980. Start making this UI more useful and powerful so we can give administrators a better toolset for reacting to API changes. Fixes T9755. We were logging the caller, just not rendering it properly. Test Plan: {F1025799} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9755, T9980 Differential Revision: https://secure.phabricator.com/D14779
2015-12-14 21:27:57 +01:00
'PhabricatorConduitLogSearchEngine' => 'applications/conduit/query/PhabricatorConduitLogSearchEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorConduitMethodCallLog' => 'applications/conduit/storage/PhabricatorConduitMethodCallLog.php',
Modernize most Conduit console interfaces Summary: Ref T603. Ref T2625. Long chain of "doing the right thing" here: I want to clean this up, so I can clean up the Conduit logs, so I can add a setup issue for deprecated method calls, so I can remove deprecated methods, so I can get rid of `DifferentialRevisionListData`, so I can make Differntial policy-aware. Adds modern infrastructure and UI to all of the Conduit interfaces (except only partially for the logs, that will be the next diff). Test Plan: {F48201} {F48202} {F48203} {F48204} {F48206} This will get further updates in the next diff: {F48205} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6331
2013-07-01 21:36:34 +02:00
'PhabricatorConduitMethodQuery' => 'applications/conduit/query/PhabricatorConduitMethodQuery.php',
Modularize Aphront exception handling Summary: Ref T1806. Ref T7173. Depends on D14047. Currently, all exception handling is in this big messy clump in `AphrontDefaultApplicationConfiguration`. Split it out into modular classes. This will let a future change add new classes in the Phacility cluster which intercept particular exceptions we care about and replaces the default, generic responses with more useful, tailored responses. Test Plan: {F777391} - Hit a Conduit error (made a method throw). - Hit an Ajax error (made comment preview throw). - Hit a high security error (tried to edit TOTP). - Hit a rate limiting error (added a bunch of email addresses). - Hit a policy error (tried to look at something with no permission). - Hit an arbitrary exception (made a randomc ontroller throw). Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14049
2015-09-03 19:04:42 +02:00
'PhabricatorConduitRequestExceptionHandler' => 'aphront/handler/PhabricatorConduitRequestExceptionHandler.php',
Implement a rough initial version of ApplicationSearch-driven Conduit read endpoints Summary: Ref T9964. See that task for some context and discussion. Ref T7715, which has the bigger picture here. Basically, I want Conduit read endpoints to be full-power, ApplicationSearch-driven endpoints, so that applications can: - Write one EditEngine and get web + conduit writes for free. - Write one SearchEngine and get web + conduit reads for free. I previously made some steps toward this, but this puts more of the structure in place. Test Plan: Viewed API console endpoint and read 20 pages of docs: {F1021961} Made various calls: with query keys, constraints, pagination, and limits. Viewed new {nav Config > Modules} page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7715, T9964 Differential Revision: https://secure.phabricator.com/D14743
2015-12-11 17:45:56 +01:00
'PhabricatorConduitResultInterface' => 'applications/conduit/interface/PhabricatorConduitResultInterface.php',
Modernize most Conduit console interfaces Summary: Ref T603. Ref T2625. Long chain of "doing the right thing" here: I want to clean this up, so I can clean up the Conduit logs, so I can add a setup issue for deprecated method calls, so I can remove deprecated methods, so I can get rid of `DifferentialRevisionListData`, so I can make Differntial policy-aware. Adds modern infrastructure and UI to all of the Conduit interfaces (except only partially for the logs, that will be the next diff). Test Plan: {F48201} {F48202} {F48203} {F48204} {F48206} This will get further updates in the next diff: {F48205} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6331
2013-07-01 21:36:34 +02:00
'PhabricatorConduitSearchEngine' => 'applications/conduit/query/PhabricatorConduitSearchEngine.php',
Formalize custom Conduit fields on objects Summary: Ref T9964. This just adds more structure to application fields, to make it harder to make typos and easier to validate them later. Test Plan: Viewed APIs, called some APIs, saw good documentation and correct results. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14776
2015-12-14 15:42:21 +01:00
'PhabricatorConduitSearchFieldSpecification' => 'applications/conduit/interface/PhabricatorConduitSearchFieldSpecification.php',
Accept Conduit tokens as an authentication mechanism Summary: - Ref T5955. Accept the tokens introduced in D10985 as an authentication token. - Ref T3628. Permit simple `curl`-compatible decoding of parameters. Test Plan: - Ran some sensible `curl` API commands: ``` epriestley@orbital ~/dev/phabricator $ curl -g "http://local.phacility.com/api/user.whoami?api.token=api-f7dfpoyelk4mmz6vxcueb6hcbtbk" ; echo {"result":{"phid":"PHID-USER-cvfydnwadpdj7vdon36z","userName":"admin","realName":"asdf","image":"http:\/\/local.phacility.com\/res\/1410737307T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/local.phacility.com\/p\/admin\/","roles":["admin","verified","approved","activated"]},"error_code":null,"error_info":null} ``` ``` epriestley@orbital ~/dev/phabricator $ curl -g "http://local.phacility.com/api/differential.query?api.token=api-f7dfpoyelk4mmz6vxcueb6hcbtbk&ids[]=1" ; echo {"result":[{"id":"1","phid":"PHID-DREV-v3a67ixww3ccg5lqbxee","title":"zxcb","uri":"http:\/\/local.phacility.com\/D1","dateCreated":"1418405590","dateModified":"1418405590","authorPHID":"PHID-USER-cvfydnwadpdj7vdon36z","status":"0","statusName":"Needs Review","branch":null,"summary":"","testPlan":"zxcb","lineCount":"6","activeDiffPHID":"PHID-DIFF-pzbtc5rw6pe5j2kxtlr2","diffs":["1"],"commits":[],"reviewers":[],"ccs":[],"hashes":[],"auxiliary":{"phabricator:projects":[],"phabricator:depends-on":[],"organization.sqlmigration":null},"arcanistProjectPHID":null,"repositoryPHID":null,"sourcePath":null}],"error_code":null,"error_info":null} ``` - Ran older-style commands like `arc list` against the local install. - Ran commands via web console. - Added and ran a unit test to make sure nothing is using forbidden parameter names. - Terminated a token and verified it no longer works. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3628, T5955 Differential Revision: https://secure.phabricator.com/D10986
2014-12-15 20:14:41 +01:00
'PhabricatorConduitTestCase' => '__tests__/PhabricatorConduitTestCase.php',
Add Conduit Tokens to make authentication in Conduit somewhat more sane Summary: Ref T5955. Summary of intended changes: **Improve Granularity of Authorization**: Currently, users have one Conduit Certificate. This isn't very flexible, and means that you can't ever generate an API token with limited permissions or IP block controls (see T6706). This moves toward a world where you can generate multiple tokens, revoke them individually, and assign disparate privileges to them. **Standardize Token Management**: This moves Conduit to work the same way that sessions, OAuth authorizations, and temporary tokens already work, instead of being this crazy bizarre mess. **Make Authentication Faster**: Authentication currently requires a handshake (conduit.connect) to establish a session, like the web UI. This is unnecessary from a security point of view and puts an extra round trip in front of all Conduit activity. Essentially no other API anywhere works like this. **Make Authentication Simpler**: The handshake is complex, and involves deriving hashes. The session is also complex, and creates issues like T4377. Handshake and session management require different inputs. **Make Token Management Simpler**: The certificate is this huge long thing right now, which is not necessary from a security perspective. There are separate Arcanist handshake tokens, but they have a different set of issues. We can move forward to a token management world where neither of these problems exist. **Lower Protocol Barrier**: The simplest possible API client is very complex right now. It should be `curl`. Simplifying authentication is a necessary step toward this. **Unblock T2783**: T2783 is blocked on nodes in the cluster making authenticated API calls to other nodes. This provides a simpler way forward than the handshake mess (or enormous-hack-mess) which would currently be required. Test Plan: - Generated tokens. - Generated tokens for a bot account. - Terminated tokens (and for a bot account). - Terminated all tokens (and for a bot account). - Ran GC and saw it reap all the expired tokens. NOTE: These tokens can not actually be used to authenticate yet! {F249658} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5955 Differential Revision: https://secure.phabricator.com/D10985
2014-12-15 20:14:23 +01:00
'PhabricatorConduitToken' => 'applications/conduit/storage/PhabricatorConduitToken.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorConduitTokenController' => 'applications/conduit/controller/PhabricatorConduitTokenController.php',
Add Conduit Tokens to make authentication in Conduit somewhat more sane Summary: Ref T5955. Summary of intended changes: **Improve Granularity of Authorization**: Currently, users have one Conduit Certificate. This isn't very flexible, and means that you can't ever generate an API token with limited permissions or IP block controls (see T6706). This moves toward a world where you can generate multiple tokens, revoke them individually, and assign disparate privileges to them. **Standardize Token Management**: This moves Conduit to work the same way that sessions, OAuth authorizations, and temporary tokens already work, instead of being this crazy bizarre mess. **Make Authentication Faster**: Authentication currently requires a handshake (conduit.connect) to establish a session, like the web UI. This is unnecessary from a security point of view and puts an extra round trip in front of all Conduit activity. Essentially no other API anywhere works like this. **Make Authentication Simpler**: The handshake is complex, and involves deriving hashes. The session is also complex, and creates issues like T4377. Handshake and session management require different inputs. **Make Token Management Simpler**: The certificate is this huge long thing right now, which is not necessary from a security perspective. There are separate Arcanist handshake tokens, but they have a different set of issues. We can move forward to a token management world where neither of these problems exist. **Lower Protocol Barrier**: The simplest possible API client is very complex right now. It should be `curl`. Simplifying authentication is a necessary step toward this. **Unblock T2783**: T2783 is blocked on nodes in the cluster making authenticated API calls to other nodes. This provides a simpler way forward than the handshake mess (or enormous-hack-mess) which would currently be required. Test Plan: - Generated tokens. - Generated tokens for a bot account. - Terminated tokens (and for a bot account). - Terminated all tokens (and for a bot account). - Ran GC and saw it reap all the expired tokens. NOTE: These tokens can not actually be used to authenticate yet! {F249658} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5955 Differential Revision: https://secure.phabricator.com/D10985
2014-12-15 20:14:23 +01:00
'PhabricatorConduitTokenEditController' => 'applications/conduit/controller/PhabricatorConduitTokenEditController.php',
Add conduit.getcapabilities and a modern CLI handshake workflow Summary: Ref T5955. - Add `conduit.getcapabilities` to help arc (and other clients) determine formats, protocols, etc., the server supports. - Fixes T3117. Add a more modern version of the handshake workflow that allows all generated tokens to remain valid for an hour. - Generally, add a CLI token type. This token type expires after an hour when generated, then becomes permanent if used. Test Plan: - See D10988. - Ran `conduit.getcapabilities` and inspected output. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3117, T5955 Differential Revision: https://secure.phabricator.com/D10989
2014-12-15 20:14:53 +01:00
'PhabricatorConduitTokenHandshakeController' => 'applications/conduit/controller/PhabricatorConduitTokenHandshakeController.php',
Add Conduit Tokens to make authentication in Conduit somewhat more sane Summary: Ref T5955. Summary of intended changes: **Improve Granularity of Authorization**: Currently, users have one Conduit Certificate. This isn't very flexible, and means that you can't ever generate an API token with limited permissions or IP block controls (see T6706). This moves toward a world where you can generate multiple tokens, revoke them individually, and assign disparate privileges to them. **Standardize Token Management**: This moves Conduit to work the same way that sessions, OAuth authorizations, and temporary tokens already work, instead of being this crazy bizarre mess. **Make Authentication Faster**: Authentication currently requires a handshake (conduit.connect) to establish a session, like the web UI. This is unnecessary from a security point of view and puts an extra round trip in front of all Conduit activity. Essentially no other API anywhere works like this. **Make Authentication Simpler**: The handshake is complex, and involves deriving hashes. The session is also complex, and creates issues like T4377. Handshake and session management require different inputs. **Make Token Management Simpler**: The certificate is this huge long thing right now, which is not necessary from a security perspective. There are separate Arcanist handshake tokens, but they have a different set of issues. We can move forward to a token management world where neither of these problems exist. **Lower Protocol Barrier**: The simplest possible API client is very complex right now. It should be `curl`. Simplifying authentication is a necessary step toward this. **Unblock T2783**: T2783 is blocked on nodes in the cluster making authenticated API calls to other nodes. This provides a simpler way forward than the handshake mess (or enormous-hack-mess) which would currently be required. Test Plan: - Generated tokens. - Generated tokens for a bot account. - Terminated tokens (and for a bot account). - Terminated all tokens (and for a bot account). - Ran GC and saw it reap all the expired tokens. NOTE: These tokens can not actually be used to authenticate yet! {F249658} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5955 Differential Revision: https://secure.phabricator.com/D10985
2014-12-15 20:14:23 +01:00
'PhabricatorConduitTokenQuery' => 'applications/conduit/query/PhabricatorConduitTokenQuery.php',
'PhabricatorConduitTokenTerminateController' => 'applications/conduit/controller/PhabricatorConduitTokenTerminateController.php',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorConduitTokensSettingsPanel' => 'applications/conduit/settings/PhabricatorConduitTokensSettingsPanel.php',
Move "show all config" from DarkConsole to /config/ Summary: Currently, we have a "config" panel in DarkConsole. It's useful to have a table of all effective config values, but it doesn't need to be in DarkConsole. Move it to Config instead. Basically: - You don't need to activate DarkConsole to see it anymore; - now visible only to admins; - respects config mask/hide; - somewhat prettier; - links to config edit; - no longer ships down on every DarkConsole request with a giant table of rarely-used data. Test Plan: Looked at the table. Looked at lack of table in darkconsole. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4473
2013-01-16 20:10:41 +01:00
'PhabricatorConfigAllController' => 'applications/config/controller/PhabricatorConfigAllController.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorConfigApplication' => 'applications/config/application/PhabricatorConfigApplication.php',
Add a very basic cache status page Summary: Ref T5501. This is just getting version detection and availability right, probably. Eventually, this will get lifted up a bit and "$remedy" will turn into setup issues (or maybe one setup issue saying "your cache setup is messed up, click here to understand why"). Test Plan: {F362935} I intend to shove these up to production one-by-one since production is APC and local is Opcache + APCu. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5501 Differential Revision: https://secure.phabricator.com/D12314
2015-04-07 23:28:20 +02:00
'PhabricatorConfigCacheController' => 'applications/config/controller/PhabricatorConfigCacheController.php',
Add a "Database Cluster Status" console in Config Summary: Ref T4571. The configuration option still doesn't do anything, but add a status panel for basic setup monitoring. Test Plan: Here's what a good version looks like: {F1212291} Also faked most of the errors it can detect and got helpful diagnostic messages like this: {F1212292} Reviewers: chad Reviewed By: chad Maniphest Tasks: T4571 Differential Revision: https://secure.phabricator.com/D15667
2016-04-10 00:21:29 +02:00
'PhabricatorConfigClusterDatabasesController' => 'applications/config/controller/PhabricatorConfigClusterDatabasesController.php',
Complete modernization of Aphlict configuration Summary: Fixes T10697. This finishes bringing the rest of the config up to cluster power levels. Phabricator is now given an arbitrarily long list of notification servers. Each Aphlict server is given an arbitrarily long list of ports to run services on. Users are free to make them meet in the middle by proxying whatever they want to whatever else they want. This should also accommodate clustering fairly easily in the future. Also rewrote the status UI and changed a million other things. :boar: Test Plan: {F1217864} {F1217865} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10697 Differential Revision: https://secure.phabricator.com/D15703
2016-04-13 21:07:48 +02:00
'PhabricatorConfigClusterNotificationsController' => 'applications/config/controller/PhabricatorConfigClusterNotificationsController.php',
Add a "Repository Servers" cluster administration panel Summary: Ref T4292. This adds a new high-level overview panel. Test Plan: {F1238854} Reviewers: chad Reviewed By: chad Maniphest Tasks: T4292 Differential Revision: https://secure.phabricator.com/D15772
2016-04-20 20:06:13 +02:00
'PhabricatorConfigClusterRepositoriesController' => 'applications/config/controller/PhabricatorConfigClusterRepositoriesController.php',
Begin standardizing garbage collectors Summary: Ref T9494. Improve support infrastructure for garbage collectors. Test Plan: - Ran `bin/phd debug trigger`, saw collectors execute. {F857852} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9494 Differential Revision: https://secure.phabricator.com/D14218
2015-10-02 01:58:43 +02:00
'PhabricatorConfigCollectorsModule' => 'applications/config/module/PhabricatorConfigCollectorsModule.php',
Add a UI for reviewing database schemata Summary: Ref T1191. Plan here is: - Build a tool showing the current schemata status (this diff). - Have it compare the current status to the desired status (partly here, mostly in future diffs). - Then add a migration tool, and eventually a setup issue to tell people to run it. Test Plan: Reviewed current schemata. {F204492} {F204493} {F204494} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10494
2014-09-18 17:22:18 +02:00
'PhabricatorConfigColumnSchema' => 'applications/config/schema/PhabricatorConfigColumnSchema.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorConfigConfigPHIDType' => 'applications/config/phid/PhabricatorConfigConfigPHIDType.php',
Start of a config web interface. Summary: This is somewhat clowny, particularly in how it handles JSON encode/decode, but I've commented why I did things the way I did. The goal is to store minified JSON but show pretty-printed JSON where possible, to the user editing it. Test Plan: * Went to /config/ and saw a list of keys from the `default` config. * Clicked on one of them, submitted the default value successfully. * Changed the value to invalid JSON and got a decent error. * Changed the value to valid JSON and checked the DB to confirm it saved. * Confirmed the DB values were minified. * Confirmed the user-facing values were pretty-printed where they could be. * Confirmed that PHIDs were getting assigned properly and that isDeleted properly defaulted to false/0. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2246 Differential Revision: https://secure.phabricator.com/D4290
2012-12-28 00:20:09 +01:00
'PhabricatorConfigController' => 'applications/config/controller/PhabricatorConfigController.php',
Automatically build all Lisk schemata Summary: Ref T1191. Now that the whole database is covered, we don't need to do as much work to build expected schemata. Doing them database-by-database was helpful in converting, but is just reudndant work now. Instead of requiring every application to build its Lisk objects, just build all Lisk objects. I removed `harbormaster.lisk_counter` because it is unused. It would be nice to autogenerate edge schemata, too, but that's a little trickier. Test Plan: Database setup issues are all green. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley, hach-que Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10620
2014-10-02 18:51:20 +02:00
'PhabricatorConfigCoreSchemaSpec' => 'applications/config/schema/PhabricatorConfigCoreSchemaSpec.php',
Add a UI for reviewing database schemata Summary: Ref T1191. Plan here is: - Build a tool showing the current schemata status (this diff). - Have it compare the current status to the desired status (partly here, mostly in future diffs). - Then add a migration tool, and eventually a setup issue to tell people to run it. Test Plan: Reviewed current schemata. {F204492} {F204493} {F204494} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10494
2014-09-18 17:22:18 +02:00
'PhabricatorConfigDatabaseController' => 'applications/config/controller/PhabricatorConfigDatabaseController.php',
Load all keys, support unique keys, and provide an "all issues" view Summary: Ref T1191. Three parts: - The old way of getting key information only got primary / unique / foreign keys, not all keys. Use `SHOW INDEXES` to get all keys instead. - Track key uniqueness and raise warnings about it. - Add a new "all issues" view to show an expanded, flat view of all issues. This is just an easier way to get a list so you don't have to dig around in the hierarchical view. Test Plan: {F206351} {F206352} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10525
2014-09-19 20:46:30 +02:00
'PhabricatorConfigDatabaseIssueController' => 'applications/config/controller/PhabricatorConfigDatabaseIssueController.php',
Add a UI for reviewing database schemata Summary: Ref T1191. Plan here is: - Build a tool showing the current schemata status (this diff). - Have it compare the current status to the desired status (partly here, mostly in future diffs). - Then add a migration tool, and eventually a setup issue to tell people to run it. Test Plan: Reviewed current schemata. {F204492} {F204493} {F204494} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10494
2014-09-18 17:22:18 +02:00
'PhabricatorConfigDatabaseSchema' => 'applications/config/schema/PhabricatorConfigDatabaseSchema.php',
Add database configuration source to the source stack Summary: Read configuration from the new database source. This adds an extra MySQL connect + query to every page. They're very cheap so I think we can suffer them for now, but I'd like to put cache in front of this at some point. The difficulties are: - If we use APC, multi-frontend installs (Facebook) can't dirty it (major problem), and the CLI can't dirty it (fine for now, maybe a major problem later). - If we use Memcache, we need to add config stuff. - We could use APC in all non-Facebook installs if we can make it dirtyable from the CLI, but I don't see a reasonable way to do that. - We don't have any other caches which are faster than the database. So I'll probably implement Memcache support at some point, although this is a lame excuse for it. Test Plan: Added some config values via web UI, saw them active on the install. Reviewers: btrahan, codeblock, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221 Differential Revision: https://secure.phabricator.com/D4296
2013-01-18 00:10:21 +01:00
'PhabricatorConfigDatabaseSource' => 'infrastructure/env/PhabricatorConfigDatabaseSource.php',
Load all keys, support unique keys, and provide an "all issues" view Summary: Ref T1191. Three parts: - The old way of getting key information only got primary / unique / foreign keys, not all keys. Use `SHOW INDEXES` to get all keys instead. - Track key uniqueness and raise warnings about it. - Add a new "all issues" view to show an expanded, flat view of all issues. This is just an easier way to get a list so you don't have to dig around in the hierarchical view. Test Plan: {F206351} {F206352} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10525
2014-09-19 20:46:30 +02:00
'PhabricatorConfigDatabaseStatusController' => 'applications/config/controller/PhabricatorConfigDatabaseStatusController.php',
Show all configuration defaults when editing configuration Summary: Show the value for all loaded configuration sources. Test Plan: {F28469} {F28470} {F28471} Reviewers: btrahan, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4312
2013-01-01 23:10:33 +01:00
'PhabricatorConfigDefaultSource' => 'infrastructure/env/PhabricatorConfigDefaultSource.php',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorConfigDictionarySource' => 'infrastructure/env/PhabricatorConfigDictionarySource.php',
Modularize config modules + add edges, phid modules Summary: Fixes T6859. Adds a readout in `/config/` of installed edge and PHID types. See also D13626. Test Plan: {F643222} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T6859 Differential Revision: https://secure.phabricator.com/D13662
2015-07-21 02:08:37 +02:00
'PhabricatorConfigEdgeModule' => 'applications/config/module/PhabricatorConfigEdgeModule.php',
Start of a config web interface. Summary: This is somewhat clowny, particularly in how it handles JSON encode/decode, but I've commented why I did things the way I did. The goal is to store minified JSON but show pretty-printed JSON where possible, to the user editing it. Test Plan: * Went to /config/ and saw a list of keys from the `default` config. * Clicked on one of them, submitted the default value successfully. * Changed the value to invalid JSON and got a decent error. * Changed the value to valid JSON and checked the DB to confirm it saved. * Confirmed the DB values were minified. * Confirmed the user-facing values were pretty-printed where they could be. * Confirmed that PHIDs were getting assigned properly and that isDeleted properly defaulted to false/0. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2246 Differential Revision: https://secure.phabricator.com/D4290
2012-12-28 00:20:09 +01:00
'PhabricatorConfigEditController' => 'applications/config/controller/PhabricatorConfigEditController.php',
Use transactions to show edit history for Configuration Summary: Use ApplicationTransactions in Config to create an edit history. Resolves T2256. Test Plan: {F28477} Reviewers: btrahan, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2256 Differential Revision: https://secure.phabricator.com/D4314
2013-01-02 03:14:41 +01:00
'PhabricatorConfigEditor' => 'applications/config/editor/PhabricatorConfigEditor.php',
Start of a config web interface. Summary: This is somewhat clowny, particularly in how it handles JSON encode/decode, but I've commented why I did things the way I did. The goal is to store minified JSON but show pretty-printed JSON where possible, to the user editing it. Test Plan: * Went to /config/ and saw a list of keys from the `default` config. * Clicked on one of them, submitted the default value successfully. * Changed the value to invalid JSON and got a decent error. * Changed the value to valid JSON and checked the DB to confirm it saved. * Confirmed the DB values were minified. * Confirmed the user-facing values were pretty-printed where they could be. * Confirmed that PHIDs were getting assigned properly and that isDeleted properly defaulted to false/0. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2246 Differential Revision: https://secure.phabricator.com/D4290
2012-12-28 00:20:09 +01:00
'PhabricatorConfigEntry' => 'applications/config/storage/PhabricatorConfigEntry.php',
'PhabricatorConfigEntryDAO' => 'applications/config/storage/PhabricatorConfigEntryDAO.php',
Convert config to application PHIDs Summary: Ref T2715. Test Plan: Used `phid.query` to load config entries. Edited config entries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6520
2013-07-22 00:04:21 +02:00
'PhabricatorConfigEntryQuery' => 'applications/config/query/PhabricatorConfigEntryQuery.php',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorConfigFileSource' => 'infrastructure/env/PhabricatorConfigFileSource.php',
Begin moving Phabricator configuration into PHP Summary: Ref T2255. Ref T2221. Lay the groundwork to move configuration into PHP, so we can show descriptions in the web UI, do typechecking, disable application options when an application is uninstalled, etc. Test Plan: {F28421} {F28420} {F28422} Reviewers: codeblock, btrahan, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221, T2255 Differential Revision: https://secure.phabricator.com/D4306
2012-12-31 00:36:06 +01:00
'PhabricatorConfigGroupController' => 'applications/config/controller/PhabricatorConfigGroupController.php',
Modularize complex HTTP parameter types Summary: Ref T9132. We have several places in the code that sometimes need to parse complex types. For example, we accept all of these in ApplicationSearch and now in ApplicationEditor: > /?subscribers=cat,dog > /?subscribers=PHID-USER-1111 > /?subscribers[]=cat&subscribers[]=PHID-USER-2222 ..etc. The logic to parse this stuff isn't too complex, but it isn't trivial either. Right now it lives in some odd places. Notably, `PhabricatorApplicationSearchEngine` has some weird helper methods for this stuff. Rather than give `EditEngine` the same set of weird helper methods, pull all this stuff out into "HTTPParameterTypes". Future diffs will add "Projects" and "Users" types where all the custom parsing/lookup logic can live. Then eventually the Search stuff can reuse these. Generally, this just breaks the code up into smaller pieces that have more specific responsibilities. Test Plan: {F944142} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14402
2015-11-04 14:05:10 +01:00
'PhabricatorConfigHTTPParameterTypesModule' => 'applications/config/module/PhabricatorConfigHTTPParameterTypesModule.php',
Settings History Summary: Shows a timeline of all modified settings Fixes T6545 Will show all settings (no pagination, should be not so difficult to add if needed but most installs won't have hundreds of settings changes) I'm not happy by how the PhabricatorConfigTransaction object is instructed to render the config keys but i don't see any other reasonable way. We could always show the keys though. Test Plan: Changed settings and called the history page Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6545 Differential Revision: https://secure.phabricator.com/D11088
2015-01-01 15:51:44 +01:00
'PhabricatorConfigHistoryController' => 'applications/config/controller/PhabricatorConfigHistoryController.php',
Button to ignore setup issues + refractoring Summary: T2381 Test Plan: Click on the ignore link in /config/issue/ and respond to the dialog box. Also, test uninstalling and reinstalling an application in the web UI (to verify that refractoring didn't break anything). Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2381 Differential Revision: https://secure.phabricator.com/D5234
2013-03-06 23:14:09 +01:00
'PhabricatorConfigIgnoreController' => 'applications/config/controller/PhabricatorConfigIgnoreController.php',
Detect and raise setup warnings from within Phabricator Summary: This is basicaly a light version of D4286. The major problem with D4286 is that it's a huge leap and completely replaces the setup process in one step. Instead, I want to do this: - Add the post-setup warnings (yellow bar with "6 unresolved warnings..."). - Copy all setup checks into post-setup warnings (so every check has an old-style check and a new-style check). - Run that for a little bit and make sure it's stable. - Implement fatal post-setup checks (the red screen, vs the yellow bar). - Run that for a little bit. - Nuke setup mode and delete all the old checks. This should give us a bunch of very gradual steps toward the brave new world of simpler setup. Test Plan: - Faked APC setup failures, saw warnings raise. - Verified that this runs after restart (get + set). - Verified that this costs us only one cache hit after first-run (get only). Reviewers: btrahan, codeblock, vrana, chad Reviewed By: codeblock CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4295
2012-12-30 15:37:49 +01:00
'PhabricatorConfigIssueListController' => 'applications/config/controller/PhabricatorConfigIssueListController.php',
'PhabricatorConfigIssueViewController' => 'applications/config/controller/PhabricatorConfigIssueViewController.php',
Fix error in `PhabricatorSetupIssueView` Summary: - Move `prettyPrintJSON()` and make it static. - Use it from `PhabricatorSetupIssueView` - Update other `config/` places that use it to call it from the new class. This fixes a bug in `PhabricatorSetupIssueView` which showed up if the value was an array and couldn't be rendered by `phutil_escape_html()`. Test Plan: - Rendered some config options. - Went to /config/issue/config.unknown.phame.skins/ without error. Reviewers: epriestley, btrahan, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4411
2013-01-12 00:28:33 +01:00
'PhabricatorConfigJSON' => 'applications/config/json/PhabricatorConfigJSON.php',
Make Maniphest task statuses user configurable Summary: Fixes T1812. Moves the internal configuration into public space and documents it. Test Plan: - Tried to set it to some invalid stuff. - Set it to various valid things. - Browsed around, changed statuses, filtered statuses, viewed statuses, merged duplictes, examined transaction record, created tasks. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1812 Differential Revision: https://secure.phabricator.com/D8585
2014-03-25 22:05:36 +01:00
'PhabricatorConfigJSONOptionType' => 'applications/config/custom/PhabricatorConfigJSONOptionType.php',
Support key schemata and column nullability Summary: Ref T1191. The major issue motivation here is that InnoDB keys have a maximum length of 767 bytes. When we move `utf8` colums to `utf8mb4` columns, they'll jump from 3 bytes per character to 4 bytes per character, which may make some indexes too long. Add key schema to help spot this. Also add nullability since it doesn't hurt. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10499
2014-09-18 17:32:21 +02:00
'PhabricatorConfigKeySchema' => 'applications/config/schema/PhabricatorConfigKeySchema.php',
Start of a config web interface. Summary: This is somewhat clowny, particularly in how it handles JSON encode/decode, but I've commented why I did things the way I did. The goal is to store minified JSON but show pretty-printed JSON where possible, to the user editing it. Test Plan: * Went to /config/ and saw a list of keys from the `default` config. * Clicked on one of them, submitted the default value successfully. * Changed the value to invalid JSON and got a decent error. * Changed the value to valid JSON and checked the DB to confirm it saved. * Confirmed the DB values were minified. * Confirmed the user-facing values were pretty-printed where they could be. * Confirmed that PHIDs were getting assigned properly and that isDeleted properly defaulted to false/0. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2246 Differential Revision: https://secure.phabricator.com/D4290
2012-12-28 00:20:09 +01:00
'PhabricatorConfigListController' => 'applications/config/controller/PhabricatorConfigListController.php',
Add a local configuration source and a non-environmental ENV config source Summary: See discussion in T2221. Before we can move configuration to the database, we have a bootstrapping problem: we need database credentials to live //somewhere// if we can't guess them (and we can only really guess localhost / root / no password). Some options for this are: - Have them live in ENV variables. - These are often somewhat unfamiliar to users. - Scripts would become a huge pain -- you'd have to dump a bunch of stuff into ENV. - Some environments have limited ability to set ENV vars. - SSH is also a pain. - Have them live in a normal config file. - This probably isn't really too awful, but: - Since we deploy/upgrade with git, we can't currently let them edit a file which already exists, or their working copy will become dirty. - So they have to copy or create a file, then edit it. - The biggest issue I have with this is that it will be difficult to give specific, easily-followed directions from Setup. The instructions need to be like "Copy template.conf.php to real.conf.php, then edit these keys: x, y, z". This isn't as easy to follow as "run script Y". - Have them live in an abnormal config file with script access (this diff). - I think this is a little better than a normal config file, because we can tell users 'run phabricator/bin/config set mysql.user phabricator' and such, which is easier to follow than editing a config file. I think this is only a marginal improvement over a normal config file and am open to arguments against this approach, but I think it will be a little easier for users to deal with than a normal config file. In most cases they should only need to store three values in this file -- db user/host/pass -- since once we have those we can bootstrap everything else. Normal config files also aren't going away for more advanced users, we're just offering a simple alternative for most users. This also adds an ENVIRONMENT file as an alternative to PHABRICATOR_ENV. This is just a simple way to specify the environment if you don't have convenient access to env vars. Test Plan: Ran `config set x y`, verified writes. Wrote to ENVIRONMENT, ran `PHABRICATOR_ENV= ./bin/repository`. Reviewers: btrahan, vrana, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2221 Differential Revision: https://secure.phabricator.com/D4294
2012-12-30 15:16:15 +01:00
'PhabricatorConfigLocalSource' => 'infrastructure/env/PhabricatorConfigLocalSource.php',
Increase the power of `bin/config` Summary: Fixes T2254. Make the CLI for config more powerful: - Add validation for `set`. - Add `get`. - Add `list`. - Add `delete`. The `get` command produces fairly verbose JSON to support flags like `--all`, or `--source database` later. The other commands are straightforward. Test Plan: Tested `config set`: $ ./bin/config set Usage Exception: Specify a configuration key and a value to set it to. $ ./bin/config set x Usage Exception: Specify a value to set the key 'x' to. $ ./bin/config set phabricator.base-uri Usage Exception: Specify a value to set the key 'phabricator.base-uri' to. $ ./bin/config set phabricator.base-uri x Usage Exception: Config option 'phabricator.base-uri' is invalid. The URI must start with 'http://' or 'https://'. $ ./bin/config set phabricator.base-uri http://x Usage Exception: Config option 'phabricator.base-uri' is invalid. The URI must contain a dot ('.'), like 'http://example.com/', not just a bare name like 'http://example/'. Some web browsers will not set cookies on domains with no TLD. $ ./bin/config set phabricator.base-uri http://x.com Set 'phabricator.base-uri' in local configuration. $ Tested `config get`: $ ./bin/config get pygments.enabled { "config" : [] } $ ./bin/config set pygments.enabled true Set 'pygments.enabled' in local configuration. $ ./bin/config get pygments.enabled { "config" : [ { "key" : "pygments.enabled", "source" : "local", "value" : true } ] } $ Tested `config delete`: $ ./bin/config delete Usage Exception: Specify a configuration key to delete. $ ./bin/config delete x x Usage Exception: Too many arguments: expected one key. $ ./bin/config delete x Usage Exception: No such configuration key 'x'! Use `config list` to list all keys. $ ./bin/config delete pygments.enabled Deleted 'pygments.enabled' from local configuration. $ ./bin/config delete pygments.enabled Usage Exception: Configuration key 'pygments.enabled' is not set in local configuration! $ Tested `config list`: $ ./bin/config list account.editable account.minimum-password-length amazon-ec2.access-key amazon-ec2.secret-key amazon-s3.access-key amazon-s3.endpoint amazon-s3.secret-key amazon-ses.access-key amazon-ses.secret-key aphront.default-application-configuration-class audit.can-author-close-audit auth.email-domains auth.login-message auth.password-auth-enabled auth.require-email-verification auth.sessions.conduit auth.sessions.web auth.sshkeys.enabled cache.enable-deflate celerity.force-disk-reads celerity.minify celerity.resource-hash celerity.resource-path config.hide config.lock config.mask controller.oauth-registration darkconsole.always-on darkconsole.enabled debug.profile-rate debug.stop-on-redirect differential.allow-reopen differential.allow-self-accept differential.always-allow-close differential.anonymous-access differential.custom-remarkup-block-rules differential.custom-remarkup-rules differential.days-fresh differential.days-stale differential.enable-email-accept differential.expose-emails-prudently differential.field-selector differential.generated-paths differential.require-test-plan-field differential.revision-custom-detail-renderer differential.show-host-field differential.show-test-plan-field differential.whitespace-matters disqus.application-id disqus.application-secret disqus.auth-enabled disqus.auth-permanent disqus.registration-enabled disqus.shortname environment.append-paths events.listeners facebook.application-id facebook.application-secret facebook.auth-enabled facebook.auth-permanent facebook.registration-enabled facebook.require-https-auth feed.http-hooks feed.public files.image-mime-types files.viewable-mime-types gcdaemon.ttl.daemon-logs gcdaemon.ttl.differential-parse-cache gcdaemon.ttl.general-cache gcdaemon.ttl.herald-transcripts gcdaemon.ttl.markup-cache gcdaemon.ttl.task-archive github.application-id github.application-secret github.auth-enabled github.auth-permanent github.registration-enabled google.application-id google.application-secret google.auth-enabled google.auth-permanent google.registration-enabled ldap.activedirectory_domain ldap.anonymous-user-name ldap.anonymous-user-password ldap.auth-enabled ldap.base_dn ldap.hostname ldap.port ldap.real_name_attributes ldap.referrals ldap.search-first ldap.search_attribute ldap.start-tls ldap.username-attribute ldap.version load-libraries log.access.format log.access.path maniphest.custom-fields maniphest.custom-task-extensions-class maniphest.default-priority maniphest.enabled metamta.can-send-as-user metamta.default-address metamta.differential.attach-patches metamta.differential.inline-patches metamta.differential.patch-format metamta.differential.reply-handler metamta.differential.reply-handler-domain metamta.differential.subject-prefix metamta.differential.unified-comment-context metamta.diffusion.attach-patches metamta.diffusion.byte-limit metamta.diffusion.inline-patches metamta.diffusion.reply-handler metamta.diffusion.reply-handler-domain metamta.diffusion.subject-prefix metamta.diffusion.time-limit metamta.domain metamta.herald.show-hints metamta.insecure-auth-with-reply-to metamta.macro.reply-handler-domain metamta.macro.subject-prefix metamta.mail-adapter metamta.maniphest.default-public-author metamta.maniphest.public-create-email metamta.maniphest.reply-handler metamta.maniphest.reply-handler-domain metamta.maniphest.subject-prefix metamta.one-mail-per-recipient metamta.package.reply-handler metamta.package.subject-prefix metamta.pholio.reply-handler-domain metamta.pholio.subject-prefix metamta.placeholder-to-recipient metamta.precedence-bulk metamta.public-replies metamta.re-prefix metamta.recipients.show-hints metamta.reply.show-hints metamta.send-immediately metamta.single-reply-handler-prefix metamta.user-address-format metamta.vary-subjects mysql.configuration-provider mysql.host mysql.implementation mysql.pass mysql.user notification.client-uri notification.debug notification.enabled notification.log notification.pidfile notification.server-uri notification.user phabricator.application-id phabricator.application-secret phabricator.auth-enabled phabricator.auth-permanent phabricator.base-uri phabricator.csrf-key phabricator.env phabricator.mail-key phabricator.oauth-uri phabricator.production-uri phabricator.registration-enabled phabricator.serious-business phabricator.setup phabricator.show-beta-applications phabricator.show-error-callout phabricator.show-stack-traces phabricator.timezone phame.skins phd.log-directory phd.pid-directory phd.start-taskmasters phd.trace phd.verbose phid.external-loaders phpmailer.mailer phpmailer.smtp-host phpmailer.smtp-password phpmailer.smtp-port phpmailer.smtp-protocol phpmailer.smtp-user phriction.enabled policy.allow-public pygments.dropdown-choices pygments.enabled recaptcha.enabled recaptcha.private-key recaptcha.public-key remarkup.enable-embedded-youtube repository.default-local-path search.elastic.host search.engine-selector security.alternate-file-domain security.hmac-key security.require-https sendgrid.api-key sendgrid.api-user storage.default-namespace storage.engine-selector storage.local-disk.path storage.mysql-engine.max-size storage.s3.bucket storage.upload-size-limit style.monospace syntax-highlighter.engine syntax.filemap test.value tokenizer.ondemand translation.override translation.provider uri.allowed-protocols $ Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2254 Differential Revision: https://secure.phabricator.com/D4570
2013-01-22 00:27:42 +01:00
'PhabricatorConfigManagementDeleteWorkflow' => 'applications/config/management/PhabricatorConfigManagementDeleteWorkflow.php',
'PhabricatorConfigManagementGetWorkflow' => 'applications/config/management/PhabricatorConfigManagementGetWorkflow.php',
'PhabricatorConfigManagementListWorkflow' => 'applications/config/management/PhabricatorConfigManagementListWorkflow.php',
Allow bin/config to affect database configuration and migrate between local and database configuration Summary: Fixes T4018. Basically hits the bullet points in that task description except the "ideally" one. Test Plan: ran bin/config migrate and saw sensible output. ``` ~> ./bin/config migrate Migrating file-based config to more modern config... Skipping config of source type PhabricatorConfigDatabaseSource... Skipping config of source type PhabricatorConfigLocalSource... Skipping config of source type PhabricatorConfigDefaultSource... Done. Migrated 0 keys. ``` Reviewers: epriestley Reviewed By: epriestley Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T4018 Differential Revision: https://secure.phabricator.com/D10490
2014-10-09 01:15:05 +02:00
'PhabricatorConfigManagementMigrateWorkflow' => 'applications/config/management/PhabricatorConfigManagementMigrateWorkflow.php',
Increase the power of `bin/config` Summary: Fixes T2254. Make the CLI for config more powerful: - Add validation for `set`. - Add `get`. - Add `list`. - Add `delete`. The `get` command produces fairly verbose JSON to support flags like `--all`, or `--source database` later. The other commands are straightforward. Test Plan: Tested `config set`: $ ./bin/config set Usage Exception: Specify a configuration key and a value to set it to. $ ./bin/config set x Usage Exception: Specify a value to set the key 'x' to. $ ./bin/config set phabricator.base-uri Usage Exception: Specify a value to set the key 'phabricator.base-uri' to. $ ./bin/config set phabricator.base-uri x Usage Exception: Config option 'phabricator.base-uri' is invalid. The URI must start with 'http://' or 'https://'. $ ./bin/config set phabricator.base-uri http://x Usage Exception: Config option 'phabricator.base-uri' is invalid. The URI must contain a dot ('.'), like 'http://example.com/', not just a bare name like 'http://example/'. Some web browsers will not set cookies on domains with no TLD. $ ./bin/config set phabricator.base-uri http://x.com Set 'phabricator.base-uri' in local configuration. $ Tested `config get`: $ ./bin/config get pygments.enabled { "config" : [] } $ ./bin/config set pygments.enabled true Set 'pygments.enabled' in local configuration. $ ./bin/config get pygments.enabled { "config" : [ { "key" : "pygments.enabled", "source" : "local", "value" : true } ] } $ Tested `config delete`: $ ./bin/config delete Usage Exception: Specify a configuration key to delete. $ ./bin/config delete x x Usage Exception: Too many arguments: expected one key. $ ./bin/config delete x Usage Exception: No such configuration key 'x'! Use `config list` to list all keys. $ ./bin/config delete pygments.enabled Deleted 'pygments.enabled' from local configuration. $ ./bin/config delete pygments.enabled Usage Exception: Configuration key 'pygments.enabled' is not set in local configuration! $ Tested `config list`: $ ./bin/config list account.editable account.minimum-password-length amazon-ec2.access-key amazon-ec2.secret-key amazon-s3.access-key amazon-s3.endpoint amazon-s3.secret-key amazon-ses.access-key amazon-ses.secret-key aphront.default-application-configuration-class audit.can-author-close-audit auth.email-domains auth.login-message auth.password-auth-enabled auth.require-email-verification auth.sessions.conduit auth.sessions.web auth.sshkeys.enabled cache.enable-deflate celerity.force-disk-reads celerity.minify celerity.resource-hash celerity.resource-path config.hide config.lock config.mask controller.oauth-registration darkconsole.always-on darkconsole.enabled debug.profile-rate debug.stop-on-redirect differential.allow-reopen differential.allow-self-accept differential.always-allow-close differential.anonymous-access differential.custom-remarkup-block-rules differential.custom-remarkup-rules differential.days-fresh differential.days-stale differential.enable-email-accept differential.expose-emails-prudently differential.field-selector differential.generated-paths differential.require-test-plan-field differential.revision-custom-detail-renderer differential.show-host-field differential.show-test-plan-field differential.whitespace-matters disqus.application-id disqus.application-secret disqus.auth-enabled disqus.auth-permanent disqus.registration-enabled disqus.shortname environment.append-paths events.listeners facebook.application-id facebook.application-secret facebook.auth-enabled facebook.auth-permanent facebook.registration-enabled facebook.require-https-auth feed.http-hooks feed.public files.image-mime-types files.viewable-mime-types gcdaemon.ttl.daemon-logs gcdaemon.ttl.differential-parse-cache gcdaemon.ttl.general-cache gcdaemon.ttl.herald-transcripts gcdaemon.ttl.markup-cache gcdaemon.ttl.task-archive github.application-id github.application-secret github.auth-enabled github.auth-permanent github.registration-enabled google.application-id google.application-secret google.auth-enabled google.auth-permanent google.registration-enabled ldap.activedirectory_domain ldap.anonymous-user-name ldap.anonymous-user-password ldap.auth-enabled ldap.base_dn ldap.hostname ldap.port ldap.real_name_attributes ldap.referrals ldap.search-first ldap.search_attribute ldap.start-tls ldap.username-attribute ldap.version load-libraries log.access.format log.access.path maniphest.custom-fields maniphest.custom-task-extensions-class maniphest.default-priority maniphest.enabled metamta.can-send-as-user metamta.default-address metamta.differential.attach-patches metamta.differential.inline-patches metamta.differential.patch-format metamta.differential.reply-handler metamta.differential.reply-handler-domain metamta.differential.subject-prefix metamta.differential.unified-comment-context metamta.diffusion.attach-patches metamta.diffusion.byte-limit metamta.diffusion.inline-patches metamta.diffusion.reply-handler metamta.diffusion.reply-handler-domain metamta.diffusion.subject-prefix metamta.diffusion.time-limit metamta.domain metamta.herald.show-hints metamta.insecure-auth-with-reply-to metamta.macro.reply-handler-domain metamta.macro.subject-prefix metamta.mail-adapter metamta.maniphest.default-public-author metamta.maniphest.public-create-email metamta.maniphest.reply-handler metamta.maniphest.reply-handler-domain metamta.maniphest.subject-prefix metamta.one-mail-per-recipient metamta.package.reply-handler metamta.package.subject-prefix metamta.pholio.reply-handler-domain metamta.pholio.subject-prefix metamta.placeholder-to-recipient metamta.precedence-bulk metamta.public-replies metamta.re-prefix metamta.recipients.show-hints metamta.reply.show-hints metamta.send-immediately metamta.single-reply-handler-prefix metamta.user-address-format metamta.vary-subjects mysql.configuration-provider mysql.host mysql.implementation mysql.pass mysql.user notification.client-uri notification.debug notification.enabled notification.log notification.pidfile notification.server-uri notification.user phabricator.application-id phabricator.application-secret phabricator.auth-enabled phabricator.auth-permanent phabricator.base-uri phabricator.csrf-key phabricator.env phabricator.mail-key phabricator.oauth-uri phabricator.production-uri phabricator.registration-enabled phabricator.serious-business phabricator.setup phabricator.show-beta-applications phabricator.show-error-callout phabricator.show-stack-traces phabricator.timezone phame.skins phd.log-directory phd.pid-directory phd.start-taskmasters phd.trace phd.verbose phid.external-loaders phpmailer.mailer phpmailer.smtp-host phpmailer.smtp-password phpmailer.smtp-port phpmailer.smtp-protocol phpmailer.smtp-user phriction.enabled policy.allow-public pygments.dropdown-choices pygments.enabled recaptcha.enabled recaptcha.private-key recaptcha.public-key remarkup.enable-embedded-youtube repository.default-local-path search.elastic.host search.engine-selector security.alternate-file-domain security.hmac-key security.require-https sendgrid.api-key sendgrid.api-user storage.default-namespace storage.engine-selector storage.local-disk.path storage.mysql-engine.max-size storage.s3.bucket storage.upload-size-limit style.monospace syntax-highlighter.engine syntax.filemap test.value tokenizer.ondemand translation.override translation.provider uri.allowed-protocols $ Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2254 Differential Revision: https://secure.phabricator.com/D4570
2013-01-22 00:27:42 +01:00
'PhabricatorConfigManagementSetWorkflow' => 'applications/config/management/PhabricatorConfigManagementSetWorkflow.php',
'PhabricatorConfigManagementWorkflow' => 'applications/config/management/PhabricatorConfigManagementWorkflow.php',
Modularize config modules + add edges, phid modules Summary: Fixes T6859. Adds a readout in `/config/` of installed edge and PHID types. See also D13626. Test Plan: {F643222} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T6859 Differential Revision: https://secure.phabricator.com/D13662
2015-07-21 02:08:37 +02:00
'PhabricatorConfigModule' => 'applications/config/module/PhabricatorConfigModule.php',
'PhabricatorConfigModuleController' => 'applications/config/controller/PhabricatorConfigModuleController.php',
Begin moving Phabricator configuration into PHP Summary: Ref T2255. Ref T2221. Lay the groundwork to move configuration into PHP, so we can show descriptions in the web UI, do typechecking, disable application options when an application is uninstalled, etc. Test Plan: {F28421} {F28420} {F28422} Reviewers: codeblock, btrahan, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221, T2255 Differential Revision: https://secure.phabricator.com/D4306
2012-12-31 00:36:06 +01:00
'PhabricatorConfigOption' => 'applications/config/option/PhabricatorConfigOption.php',
Allow configuration to have custom UI types Summary: Ref T1703. This sets the stage for (but does not yet implement) custom UI types for config. In particular, a draggable list for custom fields. I might make all the builtin types go through this at some point too, but don't really want to bother for the moment. It would be very slightly cleaner but woudn't get us much of anything. Test Plan: UI now renders via custom code, although that code does nothing (produces an unadorned text field): {F45693} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6154
2013-06-07 21:36:18 +02:00
'PhabricatorConfigOptionType' => 'applications/config/custom/PhabricatorConfigOptionType.php',
Modularize config modules + add edges, phid modules Summary: Fixes T6859. Adds a readout in `/config/` of installed edge and PHID types. See also D13626. Test Plan: {F643222} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T6859 Differential Revision: https://secure.phabricator.com/D13662
2015-07-21 02:08:37 +02:00
'PhabricatorConfigPHIDModule' => 'applications/config/module/PhabricatorConfigPHIDModule.php',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorConfigProxySource' => 'infrastructure/env/PhabricatorConfigProxySource.php',
Add dialog to purge opcode/data caches Summary: Reachable via the cache config page, restricted to admins only. This makes it convenient to hotfix phabricator without requiring a restart. Test Plan: - Local dev machine doesn't have apc, so I get the not installed message. - Faked the name and isEnabled parameters, verified dialog shows up as expected. - Didn't test clear code Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: tycho.tatitscheff, joshuaspence, Korvin Differential Revision: https://secure.phabricator.com/D14064
2015-09-10 23:18:52 +02:00
'PhabricatorConfigPurgeCacheController' => 'applications/config/controller/PhabricatorConfigPurgeCacheController.php',
Modularize Aphront exception handling Summary: Ref T1806. Ref T7173. Depends on D14047. Currently, all exception handling is in this big messy clump in `AphrontDefaultApplicationConfiguration`. Split it out into modular classes. This will let a future change add new classes in the Phacility cluster which intercept particular exceptions we care about and replaces the default, generic responses with more useful, tailored responses. Test Plan: {F777391} - Hit a Conduit error (made a method throw). - Hit an Ajax error (made comment preview throw). - Hit a high security error (tried to edit TOTP). - Hit a rate limiting error (added a bunch of email addresses). - Hit a policy error (tried to look at something with no permission). - Hit an arbitrary exception (made a randomc ontroller throw). Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14049
2015-09-03 19:04:42 +02:00
'PhabricatorConfigRequestExceptionHandlerModule' => 'applications/config/module/PhabricatorConfigRequestExceptionHandlerModule.php',
Port extension checks to new-style setup Summary: - Allow new-style setup to raise fatal setup errors. - Port extension checks to new-style setup as fatal errors. - When fatal errors are raised, abort setup and show them in a chrome-free response. Test Plan: {F29981} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4587
2013-01-23 00:16:26 +01:00
'PhabricatorConfigResponse' => 'applications/config/response/PhabricatorConfigResponse.php',
Add a UI for reviewing database schemata Summary: Ref T1191. Plan here is: - Build a tool showing the current schemata status (this diff). - Have it compare the current status to the desired status (partly here, mostly in future diffs). - Then add a migration tool, and eventually a setup issue to tell people to run it. Test Plan: Reviewed current schemata. {F204492} {F204493} {F204494} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10494
2014-09-18 17:22:18 +02:00
'PhabricatorConfigSchemaQuery' => 'applications/config/schema/PhabricatorConfigSchemaQuery.php',
Generate expected and comparison schemata Summary: Ref T1191. This builds on the "view of the database as it exists" by building a view of the database as it is expected to exist (this is mostly empty for now) and comparing the two. We now render a view of the "comparison schema", which is the actual schema merged with the expected schema and annotated with the differences. (I'm merging them like this because it makes it easier to handle both "missing" and "surpulus" warnings in a consistent way. If we tried to annotate just the actual or expected schema, the absence of components which are expected to exist is messy to handle.) Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10496
2014-09-18 17:22:54 +02:00
'PhabricatorConfigSchemaSpec' => 'applications/config/schema/PhabricatorConfigSchemaSpec.php',
Add a UI for reviewing database schemata Summary: Ref T1191. Plan here is: - Build a tool showing the current schemata status (this diff). - Have it compare the current status to the desired status (partly here, mostly in future diffs). - Then add a migration tool, and eventually a setup issue to tell people to run it. Test Plan: Reviewed current schemata. {F204492} {F204493} {F204494} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10494
2014-09-18 17:22:18 +02:00
'PhabricatorConfigServerSchema' => 'applications/config/schema/PhabricatorConfigServerSchema.php',
Modularize config modules + add edges, phid modules Summary: Fixes T6859. Adds a readout in `/config/` of installed edge and PHID types. See also D13626. Test Plan: {F643222} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T6859 Differential Revision: https://secure.phabricator.com/D13662
2015-07-21 02:08:37 +02:00
'PhabricatorConfigSiteModule' => 'applications/config/module/PhabricatorConfigSiteModule.php',
Add an extensible "SiteSource" for configuration Summary: Fixes T2792. This adds a pluggable configuration layer between all the stuff on disk (local/file) and the runtime configurable stuff (database). An install can subclass this source and: - For Phacility, query a remote service (like Almanac) to retrieve hostname-based configuration, allowing one install to serve multiple instances. - Maybe for Phacility, query a remote service (like Phlux) to retrieve sitevar-like configuration (e.g., put everything in readonly mode to deal with a maintenance issue?). Not sure if we'll do this or not. We might just nuke Phlux since Almanac is sort-of-a-superset of it for our purposes. - For third parties, query some other remote service if that makes config management easier. In particular, it would theoretically let you put locked config in Zookeeper or whatever else you want. Test Plan: Added a fake source and saw it inject configuration. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2792 Differential Revision: https://secure.phabricator.com/D10787
2014-11-06 00:30:40 +01:00
'PhabricatorConfigSiteSource' => 'infrastructure/env/PhabricatorConfigSiteSource.php',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorConfigSource' => 'infrastructure/env/PhabricatorConfigSource.php',
'PhabricatorConfigStackSource' => 'infrastructure/env/PhabricatorConfigStackSource.php',
Generate expected and comparison schemata Summary: Ref T1191. This builds on the "view of the database as it exists" by building a view of the database as it is expected to exist (this is mostly empty for now) and comparing the two. We now render a view of the "comparison schema", which is the actual schema merged with the expected schema and annotated with the differences. (I'm merging them like this because it makes it easier to handle both "missing" and "surpulus" warnings in a consistent way. If we tried to annotate just the actual or expected schema, the absence of components which are expected to exist is messy to handle.) Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10496
2014-09-18 17:22:54 +02:00
'PhabricatorConfigStorageSchema' => 'applications/config/schema/PhabricatorConfigStorageSchema.php',
Add a UI for reviewing database schemata Summary: Ref T1191. Plan here is: - Build a tool showing the current schemata status (this diff). - Have it compare the current status to the desired status (partly here, mostly in future diffs). - Then add a migration tool, and eventually a setup issue to tell people to run it. Test Plan: Reviewed current schemata. {F204492} {F204493} {F204494} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10494
2014-09-18 17:22:18 +02:00
'PhabricatorConfigTableSchema' => 'applications/config/schema/PhabricatorConfigTableSchema.php',
Use transactions to show edit history for Configuration Summary: Use ApplicationTransactions in Config to create an edit history. Resolves T2256. Test Plan: {F28477} Reviewers: btrahan, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2256 Differential Revision: https://secure.phabricator.com/D4314
2013-01-02 03:14:41 +01:00
'PhabricatorConfigTransaction' => 'applications/config/storage/PhabricatorConfigTransaction.php',
'PhabricatorConfigTransactionQuery' => 'applications/config/query/PhabricatorConfigTransactionQuery.php',
Allow configuration to be explicitly validated, including validation of complex attributes Summary: - Allows us to implement setup warnings for edits which don't go through the web UI, e.g. "you edited a config file and set value X to something goofy". - Allows us to implement more sophisticated validations, beyond basic type checks (e.g., "phabricator.base-uri" must be a URI). - Fixes T358 (or, close enough -- fixes it for all options which have been migrated as per T2255. Test Plan: Set "darkconsole.enabled" to "xyz" in my config, observed setup warning. Added fake validation, observed web UI edit error. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255, T358 Differential Revision: https://secure.phabricator.com/D4315
2013-01-02 03:15:03 +01:00
'PhabricatorConfigValidationException' => 'applications/config/exception/PhabricatorConfigValidationException.php',
Move version numbers to a dedicated "Versions" panel Summary: Currently, Version numbers are sort of randomly shown on "All Settings" beacuse we didn't have any better place to put them. Now that we have modules, expose them as a config module. Test Plan: {F906426} Grepped for "all settings" to look for other references to the old location, but didn't get any relevant hits. Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D14327
2015-10-24 17:13:22 +02:00
'PhabricatorConfigVersionsModule' => 'applications/config/module/PhabricatorConfigVersionsModule.php',
First version of "Quest Tracker" Home NUX Summary: Ref T5317. General idea here is that Dashboards are replacing the home page soon. We think they'll do a good job for normal users, but they aren't very good for new administrators who have just completed an install. In this case, any dashboard we put there by default will be empty and not very useful or helpful. It's also technically a bit messy to build objects by default. Instead, give new administrators a "Quest Tracker" UI to help them get through things. When they're done with setup steps, they build a dashboard and install it to replace the home page. They can add install-specific welcome messages during this process, so hopefully this will also ease onboarding for non-administrator users. For now, you have to go to Config > Welcome Screen explicitly to see this UI. We can tweak/test it for a bit before replacing the home page. Test Plan: {F169226} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T5317 Differential Revision: https://secure.phabricator.com/D9660
2014-06-23 18:37:51 +02:00
'PhabricatorConfigWelcomeController' => 'applications/config/controller/PhabricatorConfigWelcomeController.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorConpherenceApplication' => 'applications/conpherence/application/PhabricatorConpherenceApplication.php',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorConpherencePreferencesSettingsPanel' => 'applications/settings/panel/PhabricatorConpherencePreferencesSettingsPanel.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorConpherenceThreadPHIDType' => 'applications/conpherence/phid/PhabricatorConpherenceThreadPHIDType.php',
Move DarkConsole to an application Summary: Ref T5702. Primarily, this gets the custom DarkConsole URI routes out of the Aphront core and into an Application, like almost all other routes. Test Plan: Used DarkConsole. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D10695
2014-10-13 20:17:09 +02:00
'PhabricatorConsoleApplication' => 'applications/console/application/PhabricatorConsoleApplication.php',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorConsoleContentSource' => 'infrastructure/contentsource/PhabricatorConsoleContentSource.php',
'PhabricatorContentSource' => 'infrastructure/contentsource/PhabricatorContentSource.php',
'PhabricatorContentSourceModule' => 'infrastructure/contentsource/PhabricatorContentSourceModule.php',
'PhabricatorContentSourceView' => 'infrastructure/contentsource/PhabricatorContentSourceView.php',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorContributedToObjectEdgeType' => 'applications/transactions/edges/PhabricatorContributedToObjectEdgeType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorController' => 'applications/base/controller/PhabricatorController.php',
Consolidate use of magical cookie name strings Summary: Ref T4339. We have more magical cookie names than we should, move them all to a central location. Test Plan: Registered, logged in, linked account, logged out. See inlines. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4339 Differential Revision: https://secure.phabricator.com/D8041
2014-01-23 23:01:35 +01:00
'PhabricatorCookies' => 'applications/auth/constants/PhabricatorCookies.php',
Add "Core" config, with complex validation Summary: This is more or less a copy of the validation which lives in `webroot/index.php` right now, but I don't want to wipe that out just yet because there's no way for normal users to see this new validation. Test Plan: Tried to set "phabricator.base-uri" to crazy nonsense, was harshly rebuffed. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4316
2013-01-02 03:22:48 +01:00
'PhabricatorCoreConfigOptions' => 'applications/config/option/PhabricatorCoreConfigOptions.php',
Countdown revamp Summary: countdown_timer table named to countdown. datepoint and related stuff renamed to epoch. Countdowns now have phids. Various UI items changed from timer to countdown. Test Plan: Did run storage upgrade and added some countdowns. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2624 Differential Revision: https://secure.phabricator.com/D5812
2013-05-04 00:49:29 +02:00
'PhabricatorCountdown' => 'applications/countdown/storage/PhabricatorCountdown.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorCountdownApplication' => 'applications/countdown/application/PhabricatorCountdownApplication.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorCountdownController' => 'applications/countdown/controller/PhabricatorCountdownController.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorCountdownCountdownPHIDType' => 'applications/countdown/phid/PhabricatorCountdownCountdownPHIDType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorCountdownDAO' => 'applications/countdown/storage/PhabricatorCountdownDAO.php',
Moderize Countdown Summary: [DRAFT] Ref T8895. Makes a reasonable attempt at: - Project Support - Timeline / History - Better Search - Better ObjectItemLists Test Plan: Needs better testing (I'm sleepy) Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: eadler, epriestley, Korvin Maniphest Tasks: T8895 Differential Revision: https://secure.phabricator.com/D13660
2015-07-22 22:35:34 +02:00
'PhabricatorCountdownDefaultEditCapability' => 'applications/countdown/capability/PhabricatorCountdownDefaultEditCapability.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'PhabricatorCountdownDefaultViewCapability' => 'applications/countdown/capability/PhabricatorCountdownDefaultViewCapability.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorCountdownDeleteController' => 'applications/countdown/controller/PhabricatorCountdownDeleteController.php',
'PhabricatorCountdownEditController' => 'applications/countdown/controller/PhabricatorCountdownEditController.php',
Convert Countdown to EditEngine Summary: Fixes T10684. Fixes T10520. This primarily implements a date/epoch field, and then does a bunch of standard plumbing. Test Plan: - Created countdowns. - Edited countdowns. - Used HTTP prefilling. - Created a countdown ending on "Christmas Morning", etc. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10520, T10684 Differential Revision: https://secure.phabricator.com/D15655
2016-04-07 20:06:26 +02:00
'PhabricatorCountdownEditEngine' => 'applications/countdown/editor/PhabricatorCountdownEditEngine.php',
Moderize Countdown Summary: [DRAFT] Ref T8895. Makes a reasonable attempt at: - Project Support - Timeline / History - Better Search - Better ObjectItemLists Test Plan: Needs better testing (I'm sleepy) Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: eadler, epriestley, Korvin Maniphest Tasks: T8895 Differential Revision: https://secure.phabricator.com/D13660
2015-07-22 22:35:34 +02:00
'PhabricatorCountdownEditor' => 'applications/countdown/editor/PhabricatorCountdownEditor.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorCountdownListController' => 'applications/countdown/controller/PhabricatorCountdownListController.php',
Add mailKeys to Countdown Summary: Adds mailkeys and reply handler support Test Plan: Edit Countdown, New Countdown, no errors. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13713
2015-07-26 00:47:07 +02:00
'PhabricatorCountdownMailReceiver' => 'applications/countdown/mail/PhabricatorCountdownMailReceiver.php',
Use application PHIDs in countdown Summary: Ref T2715. Swap countdown to application PHIDs. Test Plan: Used `phid.lookup`; `phid.query`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6532
2013-07-22 23:42:25 +02:00
'PhabricatorCountdownQuery' => 'applications/countdown/query/PhabricatorCountdownQuery.php',
Pre-prepare for hovercards Summary: D5120 and followups refactor and generalize object references in Remarkup -- notably, they move remarkup rules from a central location to the implementing applications. Preserve blame by doing moves/renames only first. This change moves application remarkup rules into those applications, and renames the ones D5120 modifies. Test Plan: Typed some preview text into a textarea, got a valid Remarkup render. Reviewers: vrana, chad Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5123
2013-02-26 23:57:41 +01:00
'PhabricatorCountdownRemarkupRule' => 'applications/countdown/remarkup/PhabricatorCountdownRemarkupRule.php',
Moderize Countdown Summary: [DRAFT] Ref T8895. Makes a reasonable attempt at: - Project Support - Timeline / History - Better Search - Better ObjectItemLists Test Plan: Needs better testing (I'm sleepy) Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: eadler, epriestley, Korvin Maniphest Tasks: T8895 Differential Revision: https://secure.phabricator.com/D13660
2015-07-22 22:35:34 +02:00
'PhabricatorCountdownReplyHandler' => 'applications/countdown/mail/PhabricatorCountdownReplyHandler.php',
'PhabricatorCountdownSchemaSpec' => 'applications/countdown/storage/PhabricatorCountdownSchemaSpec.php',
Modernize Countdown somewhat Summary: Far from perfect, but better? Test Plan: {F51153} {F51154} {F51155} Reviewers: btrahan, chad Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6533
2013-07-23 15:16:19 +02:00
'PhabricatorCountdownSearchEngine' => 'applications/countdown/query/PhabricatorCountdownSearchEngine.php',
Moderize Countdown Summary: [DRAFT] Ref T8895. Makes a reasonable attempt at: - Project Support - Timeline / History - Better Search - Better ObjectItemLists Test Plan: Needs better testing (I'm sleepy) Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: eadler, epriestley, Korvin Maniphest Tasks: T8895 Differential Revision: https://secure.phabricator.com/D13660
2015-07-22 22:35:34 +02:00
'PhabricatorCountdownTransaction' => 'applications/countdown/storage/PhabricatorCountdownTransaction.php',
Add Comments to Countdown Summary: 3, 2, 1, Liftoff! (Adds basic commenting to countdown) Test Plan: asdf asdf asdf Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T8895 Differential Revision: https://secure.phabricator.com/D13707
2015-07-25 00:40:55 +02:00
'PhabricatorCountdownTransactionComment' => 'applications/countdown/storage/PhabricatorCountdownTransactionComment.php',
Moderize Countdown Summary: [DRAFT] Ref T8895. Makes a reasonable attempt at: - Project Support - Timeline / History - Better Search - Better ObjectItemLists Test Plan: Needs better testing (I'm sleepy) Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: eadler, epriestley, Korvin Maniphest Tasks: T8895 Differential Revision: https://secure.phabricator.com/D13660
2015-07-22 22:35:34 +02:00
'PhabricatorCountdownTransactionQuery' => 'applications/countdown/query/PhabricatorCountdownTransactionQuery.php',
Modernize Countdown somewhat Summary: Far from perfect, but better? Test Plan: {F51153} {F51154} {F51155} Reviewers: btrahan, chad Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6533
2013-07-23 15:16:19 +02:00
'PhabricatorCountdownView' => 'applications/countdown/view/PhabricatorCountdownView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorCountdownViewController' => 'applications/countdown/controller/PhabricatorCountdownViewController.php',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorCredentialsUsedByObjectEdgeType' => 'applications/passphrase/edge/PhabricatorCredentialsUsedByObjectEdgeType.php',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorCursorPagedPolicyAwareQuery' => 'infrastructure/query/policy/PhabricatorCursorPagedPolicyAwareQuery.php',
Begin generalizing custom fields Summary: Ref T1703. We have currently have two custom field implementations (Maniphest, Differential) and are about to add a third (User, see D6122). I'd like to generalize custom fields before doing a third implementation, so we don't back ourselves into the ApplicationTransactions corner we have with Maniphest/Differential/Audit. For the most part, the existing custom fields work well and can be directly generalized. There are three specific things I want to improve, though: - Integration with ApplicationSearch: Custom fields aren't indexable. ApplicationSearch is now online and seems stable and good. D5278 provides a template for a backend which can integrate with ApplicationSearch, and ApplicationSearch solves many of the other UI problems implied by exposing custom fields into search (principally, giant pages full of query fields). Generally, I want to provide stronger builtin integration between custom fields and ApplicationSearch. - Integration with ApplicationTransactions: Likewise, custom fields should support more native integrations with ApplicationTransactions, which are also online and seem stable and well designed. - Selection and sorting: Selecting and sorting custom fields is a huge mess right now. I want to move this into config now that we have the UI to support it, and move away from requiring users to subclass a ton of stuff just to add a field. For ApplicationSearch, I've adopted and generalized D5278. For ApplicationTransactions, I haven't made any specific affordances yet. For selection and sorting, I've partially implemented config-based selection and sorting. It will work like this: - We add a new configuration value, like `differential.fields`. In the UI, this is a draggable list of supported fields. Fields can be reordered, and most fields can be disabled. - We load every avialable field to populate this list. New fields will appear at the bottom. - There are two downsides to this approach: - If we add fields in the upstream at a later date, they will appear at the end of the list if an install has customized list order or disabled fields, even if we insert them elsewhere in the upstream. - If we reorder fields in the upstream, the reordering will not be reflected in install which have customized the order/availability. - I think these are both acceptable costs. We only incur them if an admin edits this config, which implies they'll know how to fix it if they want to. - We can fix both of these problems with a straightforward configuration migration if we want to bother. - There are numerous upsides to this approach: - We can delete a bunch of code and replace it with simple configuration. - In general, we don't need the "selector" classes anymore. - Users can enable available-but-disabled fields with one click. - Users can add fields by putting their implementations in `src/extensions/` with zero subclassing or libphutil stuff. - Generally, it's super easy for users to understand. This doesn't actually do anything yet and will probably see some adjustments before anything starts running it. Test Plan: Static checks only, this code isn't reachable yet. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6147
2013-06-06 23:52:40 +02:00
'PhabricatorCustomField' => 'infrastructure/customfield/field/PhabricatorCustomField.php',
Further simplify PhabricatorCustomFieldInterface Summary: Ref T1703. Ref T3718. This introduces `PhabricatorCustomFieldAttachment`, which is just a fancy `array()`. The goal here is to simplify `PhabricatorCustomFieldInterface` as much as possible. In particular, it can now use common infrastructure (`assertAttached()`) and is more difficult to get wrong. Test Plan: Edited custom fields on profile. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1703, T3718 Differential Revision: https://secure.phabricator.com/D6752
2013-08-14 18:53:59 +02:00
'PhabricatorCustomFieldAttachment' => 'infrastructure/customfield/field/PhabricatorCustomFieldAttachment.php',
Allow configuration to have custom UI types Summary: Ref T1703. This sets the stage for (but does not yet implement) custom UI types for config. In particular, a draggable list for custom fields. I might make all the builtin types go through this at some point too, but don't really want to bother for the moment. It would be very slightly cleaner but woudn't get us much of anything. Test Plan: UI now renders via custom code, although that code does nothing (produces an unadorned text field): {F45693} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6154
2013-06-07 21:36:18 +02:00
'PhabricatorCustomFieldConfigOptionType' => 'infrastructure/customfield/config/PhabricatorCustomFieldConfigOptionType.php',
Begin generalizing custom fields Summary: Ref T1703. We have currently have two custom field implementations (Maniphest, Differential) and are about to add a third (User, see D6122). I'd like to generalize custom fields before doing a third implementation, so we don't back ourselves into the ApplicationTransactions corner we have with Maniphest/Differential/Audit. For the most part, the existing custom fields work well and can be directly generalized. There are three specific things I want to improve, though: - Integration with ApplicationSearch: Custom fields aren't indexable. ApplicationSearch is now online and seems stable and good. D5278 provides a template for a backend which can integrate with ApplicationSearch, and ApplicationSearch solves many of the other UI problems implied by exposing custom fields into search (principally, giant pages full of query fields). Generally, I want to provide stronger builtin integration between custom fields and ApplicationSearch. - Integration with ApplicationTransactions: Likewise, custom fields should support more native integrations with ApplicationTransactions, which are also online and seem stable and well designed. - Selection and sorting: Selecting and sorting custom fields is a huge mess right now. I want to move this into config now that we have the UI to support it, and move away from requiring users to subclass a ton of stuff just to add a field. For ApplicationSearch, I've adopted and generalized D5278. For ApplicationTransactions, I haven't made any specific affordances yet. For selection and sorting, I've partially implemented config-based selection and sorting. It will work like this: - We add a new configuration value, like `differential.fields`. In the UI, this is a draggable list of supported fields. Fields can be reordered, and most fields can be disabled. - We load every avialable field to populate this list. New fields will appear at the bottom. - There are two downsides to this approach: - If we add fields in the upstream at a later date, they will appear at the end of the list if an install has customized list order or disabled fields, even if we insert them elsewhere in the upstream. - If we reorder fields in the upstream, the reordering will not be reflected in install which have customized the order/availability. - I think these are both acceptable costs. We only incur them if an admin edits this config, which implies they'll know how to fix it if they want to. - We can fix both of these problems with a straightforward configuration migration if we want to bother. - There are numerous upsides to this approach: - We can delete a bunch of code and replace it with simple configuration. - In general, we don't need the "selector" classes anymore. - Users can enable available-but-disabled fields with one click. - Users can add fields by putting their implementations in `src/extensions/` with zero subclassing or libphutil stuff. - Generally, it's super easy for users to understand. This doesn't actually do anything yet and will probably see some adjustments before anything starts running it. Test Plan: Static checks only, this code isn't reachable yet. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6147
2013-06-06 23:52:40 +02:00
'PhabricatorCustomFieldDataNotAvailableException' => 'infrastructure/customfield/exception/PhabricatorCustomFieldDataNotAvailableException.php',
Add "owners.search" Conduit API endpoint, with CustomField support Summary: Ref T9964. Adds a new-style "owners.search" endpoint, and an extension for customfields. Puts enough indirection in place to give us nice, consistent "custom.key" user-facing keys instead of "std:custom:owners:na0shf9a8dfdsafl" junk. Test Plan: - Searched Owners via API. - Searched by ID. - Ordered by custom fields. - Reviewed API docs. - Used normal search with ordering. - Viewed custom field values in search results. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14758
2015-12-13 01:25:51 +01:00
'PhabricatorCustomFieldEditEngineExtension' => 'infrastructure/customfield/engineextension/PhabricatorCustomFieldEditEngineExtension.php',
Partially support CustomFields in EditEngine Summary: Ref T9132. This isn't perfect, but doesn't break any existing functionality. This stuff works: - Editing values. - Reordering fields. - All builtin field tyepes. This stuff may not work yet: - Assigning custom field defaults. - Some conduit stuff. - Fully custom fields? - Locking/hiding fields? Didn't actually test this one. I'll keep chipping away at that stuff. In some cases, it may be easier to convert all the CustomField apps first, although Differential might be a fair bit of work. Test Plan: Created a bunch of custom fields of every avialable type and edited them. {F1008789} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14617
2015-11-29 19:47:16 +01:00
'PhabricatorCustomFieldEditField' => 'infrastructure/customfield/editor/PhabricatorCustomFieldEditField.php',
'PhabricatorCustomFieldEditType' => 'infrastructure/customfield/editor/PhabricatorCustomFieldEditType.php',
Modularize fulltext indexing of Projects, Subscriptions and Custom Fields Summary: Ref T9979. This is going to become `FulltextEngine`, but pave the way for that by pulling extensions out of it. Test Plan: {F1036624} - Used `bin/search index Txxx`, saw projects, subscribers and custom fields rebuild in the index. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14835
2015-12-21 15:31:31 +01:00
'PhabricatorCustomFieldFulltextEngineExtension' => 'infrastructure/customfield/engineextension/PhabricatorCustomFieldFulltextEngineExtension.php',
Make Herald custom field integration modular Summary: Ref T8726. The existing implementation is largely made redundant by the newer modular implementation. Test Plan: Created a custom field rule, set custom field to various values until it matched, saw effect and proper transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13497
2015-07-06 22:15:58 +02:00
'PhabricatorCustomFieldHeraldField' => 'infrastructure/customfield/herald/PhabricatorCustomFieldHeraldField.php',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'PhabricatorCustomFieldHeraldFieldGroup' => 'infrastructure/customfield/herald/PhabricatorCustomFieldHeraldFieldGroup.php',
Begin generalizing custom fields Summary: Ref T1703. We have currently have two custom field implementations (Maniphest, Differential) and are about to add a third (User, see D6122). I'd like to generalize custom fields before doing a third implementation, so we don't back ourselves into the ApplicationTransactions corner we have with Maniphest/Differential/Audit. For the most part, the existing custom fields work well and can be directly generalized. There are three specific things I want to improve, though: - Integration with ApplicationSearch: Custom fields aren't indexable. ApplicationSearch is now online and seems stable and good. D5278 provides a template for a backend which can integrate with ApplicationSearch, and ApplicationSearch solves many of the other UI problems implied by exposing custom fields into search (principally, giant pages full of query fields). Generally, I want to provide stronger builtin integration between custom fields and ApplicationSearch. - Integration with ApplicationTransactions: Likewise, custom fields should support more native integrations with ApplicationTransactions, which are also online and seem stable and well designed. - Selection and sorting: Selecting and sorting custom fields is a huge mess right now. I want to move this into config now that we have the UI to support it, and move away from requiring users to subclass a ton of stuff just to add a field. For ApplicationSearch, I've adopted and generalized D5278. For ApplicationTransactions, I haven't made any specific affordances yet. For selection and sorting, I've partially implemented config-based selection and sorting. It will work like this: - We add a new configuration value, like `differential.fields`. In the UI, this is a draggable list of supported fields. Fields can be reordered, and most fields can be disabled. - We load every avialable field to populate this list. New fields will appear at the bottom. - There are two downsides to this approach: - If we add fields in the upstream at a later date, they will appear at the end of the list if an install has customized list order or disabled fields, even if we insert them elsewhere in the upstream. - If we reorder fields in the upstream, the reordering will not be reflected in install which have customized the order/availability. - I think these are both acceptable costs. We only incur them if an admin edits this config, which implies they'll know how to fix it if they want to. - We can fix both of these problems with a straightforward configuration migration if we want to bother. - There are numerous upsides to this approach: - We can delete a bunch of code and replace it with simple configuration. - In general, we don't need the "selector" classes anymore. - Users can enable available-but-disabled fields with one click. - Users can add fields by putting their implementations in `src/extensions/` with zero subclassing or libphutil stuff. - Generally, it's super easy for users to understand. This doesn't actually do anything yet and will probably see some adjustments before anything starts running it. Test Plan: Static checks only, this code isn't reachable yet. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6147
2013-06-06 23:52:40 +02:00
'PhabricatorCustomFieldImplementationIncompleteException' => 'infrastructure/customfield/exception/PhabricatorCustomFieldImplementationIncompleteException.php',
'PhabricatorCustomFieldIndexStorage' => 'infrastructure/customfield/storage/PhabricatorCustomFieldIndexStorage.php',
Flesh out ApplicationTransactions/CustomField integration Summary: None of this code is reachable yet. See discussion in D6147. Ref T1703. Provide tighter integration between ApplicationTransactions and CustomField. Basically, I'm just trying to get all the shared stuff into the base implementation. Test Plan: Code not reachable. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6149
2013-06-06 23:53:07 +02:00
'PhabricatorCustomFieldInterface' => 'infrastructure/customfield/interface/PhabricatorCustomFieldInterface.php',
Support configuration-driven custom fields Summary: Ref T1702. Ref T3718. There are a couple of things going on here: **PhabricatorCustomFieldList**: I added `PhabricatorCustomFieldList`, which is just a convenience class for dealing with lists of fields. Often, current field code does something like this inline in a Controller: foreach ($fields as $field) { // do some junk } Often, that junk has some slightly subtle implications. Move all of it to `$list->doSomeJunk()` methods (like `appendFieldsToForm()`, `loadFieldsFromStorage()`) to reduce code duplication and prevent errors. This additionally moves an existing list-convenience method there, out of `PhabricatorPropertyListView`. **PhabricatorUserConfiguredCustomFieldStorage**: Adds `PhabricatorUserConfiguredCustomFieldStorage` for storing custom field data (like "ICQ Handle", "Phone Number", "Desk", "Favorite Flower", etc). **Configuration-Driven Custom Fields**: Previously, I was thinking about doing these with interfaces, but as I thought about it more I started to dislike that approach. Instead, I built proxies into `PhabricatorCustomField`. Basically, this means that fields (like a custom, configuration-driven "Favorite Flower" field) can just use some other Field to actually provide their implementation (like a "standard" field which knows how to render text areas). The previous approach would have involed subclasssing the "standard" field and implementing an interface, but that would mean that every application would have at least two "base" fields and generally just seemed bleh as I worked through it. The cost of this approach is that we need a bunch of `proxy` junk in the base class, but that's a one-time cost and I think it simplifies all the implementations and makes them a lot less magical (e.g., all of the custom fields now extend the right base field classes). **Fixed Some Bugs**: Some of this code hadn't really been run yet and had minor bugs. Test Plan: {F54240} {F54241} {F54242} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1702, T1703, T3718 Differential Revision: https://secure.phabricator.com/D6749
2013-08-14 17:10:16 +02:00
'PhabricatorCustomFieldList' => 'infrastructure/customfield/field/PhabricatorCustomFieldList.php',
Modularize parser for "Closes task X as Y" Summary: Ref T3886. Ref T3872. Ref T1812. We have several parsers which look for textual references to other objects, like: Closes Tx. Depends on Dy. Reverts Dz. Currently, these are pretty hard coded, don't get all the edge cases right, and don't generalize well. They're also implemented in the middle of Differential's field code. So I want to: - Share more code so that, e.g., "Tx, Ty" always works (only some rules support it right now); - fix bugs in the parser, like T3872; - make this a modular, extensible process which runs against custom fields, not a builtin part of fields; - make the internals more flexible to accommodate custom stuff like T1812. This implements the "Verbs optional-noun Object, Optional Other Objects optional-as-something." grammar in a general way so subclasses can just plug in their keywords. Runtime code doesn't touch this yet. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3872, T1812, T3886 Differential Revision: https://secure.phabricator.com/D8261
2014-02-18 00:53:47 +01:00
'PhabricatorCustomFieldMonogramParser' => 'infrastructure/customfield/parser/PhabricatorCustomFieldMonogramParser.php',
Flesh out ApplicationTransactions/CustomField integration Summary: None of this code is reachable yet. See discussion in D6147. Ref T1703. Provide tighter integration between ApplicationTransactions and CustomField. Basically, I'm just trying to get all the shared stuff into the base implementation. Test Plan: Code not reachable. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6149
2013-06-06 23:53:07 +02:00
'PhabricatorCustomFieldNotAttachedException' => 'infrastructure/customfield/exception/PhabricatorCustomFieldNotAttachedException.php',
Support configuration-driven custom fields Summary: Ref T1702. Ref T3718. There are a couple of things going on here: **PhabricatorCustomFieldList**: I added `PhabricatorCustomFieldList`, which is just a convenience class for dealing with lists of fields. Often, current field code does something like this inline in a Controller: foreach ($fields as $field) { // do some junk } Often, that junk has some slightly subtle implications. Move all of it to `$list->doSomeJunk()` methods (like `appendFieldsToForm()`, `loadFieldsFromStorage()`) to reduce code duplication and prevent errors. This additionally moves an existing list-convenience method there, out of `PhabricatorPropertyListView`. **PhabricatorUserConfiguredCustomFieldStorage**: Adds `PhabricatorUserConfiguredCustomFieldStorage` for storing custom field data (like "ICQ Handle", "Phone Number", "Desk", "Favorite Flower", etc). **Configuration-Driven Custom Fields**: Previously, I was thinking about doing these with interfaces, but as I thought about it more I started to dislike that approach. Instead, I built proxies into `PhabricatorCustomField`. Basically, this means that fields (like a custom, configuration-driven "Favorite Flower" field) can just use some other Field to actually provide their implementation (like a "standard" field which knows how to render text areas). The previous approach would have involed subclasssing the "standard" field and implementing an interface, but that would mean that every application would have at least two "base" fields and generally just seemed bleh as I worked through it. The cost of this approach is that we need a bunch of `proxy` junk in the base class, but that's a one-time cost and I think it simplifies all the implementations and makes them a lot less magical (e.g., all of the custom fields now extend the right base field classes). **Fixed Some Bugs**: Some of this code hadn't really been run yet and had minor bugs. Test Plan: {F54240} {F54241} {F54242} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1702, T1703, T3718 Differential Revision: https://secure.phabricator.com/D6749
2013-08-14 17:10:16 +02:00
'PhabricatorCustomFieldNotProxyException' => 'infrastructure/customfield/exception/PhabricatorCustomFieldNotProxyException.php',
Begin generalizing custom fields Summary: Ref T1703. We have currently have two custom field implementations (Maniphest, Differential) and are about to add a third (User, see D6122). I'd like to generalize custom fields before doing a third implementation, so we don't back ourselves into the ApplicationTransactions corner we have with Maniphest/Differential/Audit. For the most part, the existing custom fields work well and can be directly generalized. There are three specific things I want to improve, though: - Integration with ApplicationSearch: Custom fields aren't indexable. ApplicationSearch is now online and seems stable and good. D5278 provides a template for a backend which can integrate with ApplicationSearch, and ApplicationSearch solves many of the other UI problems implied by exposing custom fields into search (principally, giant pages full of query fields). Generally, I want to provide stronger builtin integration between custom fields and ApplicationSearch. - Integration with ApplicationTransactions: Likewise, custom fields should support more native integrations with ApplicationTransactions, which are also online and seem stable and well designed. - Selection and sorting: Selecting and sorting custom fields is a huge mess right now. I want to move this into config now that we have the UI to support it, and move away from requiring users to subclass a ton of stuff just to add a field. For ApplicationSearch, I've adopted and generalized D5278. For ApplicationTransactions, I haven't made any specific affordances yet. For selection and sorting, I've partially implemented config-based selection and sorting. It will work like this: - We add a new configuration value, like `differential.fields`. In the UI, this is a draggable list of supported fields. Fields can be reordered, and most fields can be disabled. - We load every avialable field to populate this list. New fields will appear at the bottom. - There are two downsides to this approach: - If we add fields in the upstream at a later date, they will appear at the end of the list if an install has customized list order or disabled fields, even if we insert them elsewhere in the upstream. - If we reorder fields in the upstream, the reordering will not be reflected in install which have customized the order/availability. - I think these are both acceptable costs. We only incur them if an admin edits this config, which implies they'll know how to fix it if they want to. - We can fix both of these problems with a straightforward configuration migration if we want to bother. - There are numerous upsides to this approach: - We can delete a bunch of code and replace it with simple configuration. - In general, we don't need the "selector" classes anymore. - Users can enable available-but-disabled fields with one click. - Users can add fields by putting their implementations in `src/extensions/` with zero subclassing or libphutil stuff. - Generally, it's super easy for users to understand. This doesn't actually do anything yet and will probably see some adjustments before anything starts running it. Test Plan: Static checks only, this code isn't reachable yet. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6147
2013-06-06 23:52:40 +02:00
'PhabricatorCustomFieldNumericIndexStorage' => 'infrastructure/customfield/storage/PhabricatorCustomFieldNumericIndexStorage.php',
Add "owners.search" Conduit API endpoint, with CustomField support Summary: Ref T9964. Adds a new-style "owners.search" endpoint, and an extension for customfields. Puts enough indirection in place to give us nice, consistent "custom.key" user-facing keys instead of "std:custom:owners:na0shf9a8dfdsafl" junk. Test Plan: - Searched Owners via API. - Searched by ID. - Ordered by custom fields. - Reviewed API docs. - Used normal search with ordering. - Viewed custom field values in search results. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14758
2015-12-13 01:25:51 +01:00
'PhabricatorCustomFieldSearchEngineExtension' => 'infrastructure/customfield/engineextension/PhabricatorCustomFieldSearchEngineExtension.php',
Begin generalizing custom fields Summary: Ref T1703. We have currently have two custom field implementations (Maniphest, Differential) and are about to add a third (User, see D6122). I'd like to generalize custom fields before doing a third implementation, so we don't back ourselves into the ApplicationTransactions corner we have with Maniphest/Differential/Audit. For the most part, the existing custom fields work well and can be directly generalized. There are three specific things I want to improve, though: - Integration with ApplicationSearch: Custom fields aren't indexable. ApplicationSearch is now online and seems stable and good. D5278 provides a template for a backend which can integrate with ApplicationSearch, and ApplicationSearch solves many of the other UI problems implied by exposing custom fields into search (principally, giant pages full of query fields). Generally, I want to provide stronger builtin integration between custom fields and ApplicationSearch. - Integration with ApplicationTransactions: Likewise, custom fields should support more native integrations with ApplicationTransactions, which are also online and seem stable and well designed. - Selection and sorting: Selecting and sorting custom fields is a huge mess right now. I want to move this into config now that we have the UI to support it, and move away from requiring users to subclass a ton of stuff just to add a field. For ApplicationSearch, I've adopted and generalized D5278. For ApplicationTransactions, I haven't made any specific affordances yet. For selection and sorting, I've partially implemented config-based selection and sorting. It will work like this: - We add a new configuration value, like `differential.fields`. In the UI, this is a draggable list of supported fields. Fields can be reordered, and most fields can be disabled. - We load every avialable field to populate this list. New fields will appear at the bottom. - There are two downsides to this approach: - If we add fields in the upstream at a later date, they will appear at the end of the list if an install has customized list order or disabled fields, even if we insert them elsewhere in the upstream. - If we reorder fields in the upstream, the reordering will not be reflected in install which have customized the order/availability. - I think these are both acceptable costs. We only incur them if an admin edits this config, which implies they'll know how to fix it if they want to. - We can fix both of these problems with a straightforward configuration migration if we want to bother. - There are numerous upsides to this approach: - We can delete a bunch of code and replace it with simple configuration. - In general, we don't need the "selector" classes anymore. - Users can enable available-but-disabled fields with one click. - Users can add fields by putting their implementations in `src/extensions/` with zero subclassing or libphutil stuff. - Generally, it's super easy for users to understand. This doesn't actually do anything yet and will probably see some adjustments before anything starts running it. Test Plan: Static checks only, this code isn't reachable yet. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6147
2013-06-06 23:52:40 +02:00
'PhabricatorCustomFieldStorage' => 'infrastructure/customfield/storage/PhabricatorCustomFieldStorage.php',
'PhabricatorCustomFieldStringIndexStorage' => 'infrastructure/customfield/storage/PhabricatorCustomFieldStringIndexStorage.php',
UI - add ability to customize header logo Summary: Fixes T7165. Let users specify a file phid in config, and then use that file via an inline style tag. Also, cache the URI so that we don't have to query the file on every page load. Test Plan: {F319050} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7165 Differential Revision: https://secure.phabricator.com/D11886
2015-02-25 21:00:36 +01:00
'PhabricatorCustomHeaderConfigType' => 'applications/config/custom/PhabricatorCustomHeaderConfigType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorDaemon' => 'infrastructure/daemon/PhabricatorDaemon.php',
Improve daemon console for daemons on multiple hosts Summary: Ref T10756. This: - Fixes T7307. This UI is now admin-only. - Makes the main "running daemons" table more useful for multi-host setups (show where daemons are running). - Removes logs from the web UI: these are sometimes vaguely sensitive and shouldn't be visible. The UI tells you how to get them with `bin/phd log`. - Minor modernization. Test Plan: - As a non-admin, viewed daemons (access error) and bulk jobs (worked great). - Browsed bulk job pages. - Ran a bulk job. - Viewed daemon console. - Viewed task detail / daemon detail / daemon list pages. {F1220516} Reviewers: chad Reviewed By: chad Maniphest Tasks: T7307, T10756 Differential Revision: https://secure.phabricator.com/D15724
2016-04-15 21:00:34 +02:00
'PhabricatorDaemonBulkJobController' => 'applications/daemon/controller/PhabricatorDaemonBulkJobController.php',
Execute Maniphest batch edits in the background with a web UI progress bar Summary: Ref T8637. This does nothing interesting, just has empty scaffolding for a bulk job queue. Basic idea is that when you do something like a batch edit in Maniphest, we: - Create a BulkJob with all the details. - Queue a worker to start the job. - Send you to a progress bar page for the job. In the background: - The "start job" worker creates a ton of Task objects, then queues worker tasks to do the work. In the foreground: - Fancy ajax animates the progress bar and it goes wooosh. In general: - Big jobs actually work. - Jobs get logged. - You can monitor jobs. - Terrible junk like T8637 should be much harder to write and much easier to catch and diagnose. Test Plan: No interesting code/beahavior yet. Clean `storage adjust`. {F526411} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8637 Differential Revision: https://secure.phabricator.com/D13392
2015-06-23 22:36:16 +02:00
'PhabricatorDaemonBulkJobListController' => 'applications/daemon/controller/PhabricatorDaemonBulkJobListController.php',
'PhabricatorDaemonBulkJobMonitorController' => 'applications/daemon/controller/PhabricatorDaemonBulkJobMonitorController.php',
'PhabricatorDaemonBulkJobViewController' => 'applications/daemon/controller/PhabricatorDaemonBulkJobViewController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorDaemonConsoleController' => 'applications/daemon/controller/PhabricatorDaemonConsoleController.php',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorDaemonContentSource' => 'infrastructure/daemon/contentsource/PhabricatorDaemonContentSource.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorDaemonController' => 'applications/daemon/controller/PhabricatorDaemonController.php',
Use a real Query class to load daemon information Summary: Ref T3557. This stuff does a bunch of nonsense in the View right now. Instead, do it in a real Query class. Fixes a long-standing bug which prevented "all daemons" from showing more than 3 days' worth of data. Test Plan: Viewed `/daemon/`, viewed "All Daemons". Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3557 Differential Revision: https://secure.phabricator.com/D6544
2013-07-23 21:11:34 +02:00
'PhabricatorDaemonDAO' => 'applications/daemon/storage/PhabricatorDaemonDAO.php',
Use events rather than Conduit to report daemon status in Phabricator Summary: Ref T1670. Use events and direct database writes instead of Conduit. Deprecate the Conduit methods. Test Plan: Ran daemons, used the console to review daemon event logs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1670 Differential Revision: https://secure.phabricator.com/D6536
2013-07-23 21:10:02 +02:00
'PhabricatorDaemonEventListener' => 'applications/daemon/event/PhabricatorDaemonEventListener.php',
Use a real Query class to load daemon information Summary: Ref T3557. This stuff does a bunch of nonsense in the View right now. Instead, do it in a real Query class. Fixes a long-standing bug which prevented "all daemons" from showing more than 3 days' worth of data. Test Plan: Viewed `/daemon/`, viewed "All Daemons". Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3557 Differential Revision: https://secure.phabricator.com/D6544
2013-07-23 21:11:34 +02:00
'PhabricatorDaemonLog' => 'applications/daemon/storage/PhabricatorDaemonLog.php',
'PhabricatorDaemonLogEvent' => 'applications/daemon/storage/PhabricatorDaemonLogEvent.php',
Garbage collect daemon logs Summary: We already have GC for daemon log events, but not for daemon logs themselves. Collect old daemon logs which aren't still running. Test Plan: Ran `phd debug garbage`, observed old logs get cleaned up. Started some daemons, re-ran garbage, made sure they stuck around. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9610
2014-06-18 00:33:08 +02:00
'PhabricatorDaemonLogEventGarbageCollector' => 'applications/daemon/garbagecollector/PhabricatorDaemonLogEventGarbageCollector.php',
Allow long daemon log messages to be expanded Summary: Ref T3557. We summarize long messages, but don't let you see the entire message. This is occasionally inconvenient, and I'm planning to add more prefix junk to some messages for T2569. Provide a link you can click to see the full message. This isn't javascripted because a ton of these can make the page ridiculously enormous and it seems unlikely you'd care much about all of them. Test Plan: {F51261} {F51262} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T3557 Differential Revision: https://secure.phabricator.com/D6546
2013-07-23 21:30:58 +02:00
'PhabricatorDaemonLogEventViewController' => 'applications/daemon/controller/PhabricatorDaemonLogEventViewController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorDaemonLogEventsView' => 'applications/daemon/view/PhabricatorDaemonLogEventsView.php',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorDaemonLogGarbageCollector' => 'applications/daemon/garbagecollector/PhabricatorDaemonLogGarbageCollector.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorDaemonLogListController' => 'applications/daemon/controller/PhabricatorDaemonLogListController.php',
'PhabricatorDaemonLogListView' => 'applications/daemon/view/PhabricatorDaemonLogListView.php',
Mostly modernize daemon detail views Summary: Ref T3557. The major goals here are: - Modernize use of UI elements. - Present daemon status with more clarity. Particularly, the "Waiting" status is called out and explained in detail. Test Plan: {F51247} {F51248} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3557 Differential Revision: https://secure.phabricator.com/D6541
2013-07-23 21:10:41 +02:00
'PhabricatorDaemonLogQuery' => 'applications/daemon/query/PhabricatorDaemonLogQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorDaemonLogViewController' => 'applications/daemon/controller/PhabricatorDaemonLogViewController.php',
Modernize architecture of `phd` Summary: Ref T1670. Mostly, use PhutilArgumentParser. This breaks up the mismash of functional stuff and PhabriatorDaemonControl into proper argumentparser Workflows. There are no functional changes, except that I removed the "pingConduit()" call prior to starting daemons, because I intend to remove all Conduit integration. Test Plan: - Ran `phd list`. - Ran `phd status` (running daemons). - Ran `phd status` (no running daemons). - Ran `phd stop <pid>` (dead task). - Ran `phd stop <pid>` (live task). - Ran `phd stop zebra` (invalid PID). - Ran `phd stop 1` (bad PID). - Ran `phd stop`. - Ran `phd debug zebra` (no match). - Ran `phd debug e` (ambiguous). - Ran `phd debug task`. - Ran `phd launch task`. - Ran `phd launch 0 task` (invalid arg). - Ran `phd launch 2 task`. - Ran `phd help`. - Ran `phd help list`. - Ran `phd start`. - Ran `phd restart`. - Looked at Repositories (daemon running). - Looked at Repositories (daemon not running). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1670 Differential Revision: https://secure.phabricator.com/D6490
2013-07-19 00:28:56 +02:00
'PhabricatorDaemonManagementDebugWorkflow' => 'applications/daemon/management/PhabricatorDaemonManagementDebugWorkflow.php',
'PhabricatorDaemonManagementLaunchWorkflow' => 'applications/daemon/management/PhabricatorDaemonManagementLaunchWorkflow.php',
'PhabricatorDaemonManagementListWorkflow' => 'applications/daemon/management/PhabricatorDaemonManagementListWorkflow.php',
Add `bin/phd log <id>` to dump all logs to the CLI Summary: Ref T3557. Make it easier to access full daemon logs from the CLI. Test Plan: {F51265} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3557 Differential Revision: https://secure.phabricator.com/D6547
2013-07-23 21:48:45 +02:00
'PhabricatorDaemonManagementLogWorkflow' => 'applications/daemon/management/PhabricatorDaemonManagementLogWorkflow.php',
Add `phd reload` to send SIGHUP to overseers Summary: Ref T7384. This just sends SIGHUP to specified overseers in a nice package. Test Plan: See D11898. Reviewers: hach-que, btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T7384 Differential Revision: https://secure.phabricator.com/D11899
2015-02-27 20:38:42 +01:00
'PhabricatorDaemonManagementReloadWorkflow' => 'applications/daemon/management/PhabricatorDaemonManagementReloadWorkflow.php',
Modernize architecture of `phd` Summary: Ref T1670. Mostly, use PhutilArgumentParser. This breaks up the mismash of functional stuff and PhabriatorDaemonControl into proper argumentparser Workflows. There are no functional changes, except that I removed the "pingConduit()" call prior to starting daemons, because I intend to remove all Conduit integration. Test Plan: - Ran `phd list`. - Ran `phd status` (running daemons). - Ran `phd status` (no running daemons). - Ran `phd stop <pid>` (dead task). - Ran `phd stop <pid>` (live task). - Ran `phd stop zebra` (invalid PID). - Ran `phd stop 1` (bad PID). - Ran `phd stop`. - Ran `phd debug zebra` (no match). - Ran `phd debug e` (ambiguous). - Ran `phd debug task`. - Ran `phd launch task`. - Ran `phd launch 0 task` (invalid arg). - Ran `phd launch 2 task`. - Ran `phd help`. - Ran `phd help list`. - Ran `phd start`. - Ran `phd restart`. - Looked at Repositories (daemon running). - Looked at Repositories (daemon not running). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1670 Differential Revision: https://secure.phabricator.com/D6490
2013-07-19 00:28:56 +02:00
'PhabricatorDaemonManagementRestartWorkflow' => 'applications/daemon/management/PhabricatorDaemonManagementRestartWorkflow.php',
'PhabricatorDaemonManagementStartWorkflow' => 'applications/daemon/management/PhabricatorDaemonManagementStartWorkflow.php',
'PhabricatorDaemonManagementStatusWorkflow' => 'applications/daemon/management/PhabricatorDaemonManagementStatusWorkflow.php',
'PhabricatorDaemonManagementStopWorkflow' => 'applications/daemon/management/PhabricatorDaemonManagementStopWorkflow.php',
'PhabricatorDaemonManagementWorkflow' => 'applications/daemon/management/PhabricatorDaemonManagementWorkflow.php',
Add a daemon overseer module to restart daemons when config changes Summary: Fixes T7053. Depends on D14452. Test Plan: Created a custom daemon which dumps out the config hash (by querying `PhabricatorEnv::calculateEnvironmentHash()`). Ran this daemon with `./bin/phd debug PhabricatorDebugDaemon` and saw the config hash update within 30 seconds. {P1886} Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Maniphest Tasks: T7053 Differential Revision: https://secure.phabricator.com/D14458
2015-11-10 22:34:34 +01:00
'PhabricatorDaemonOverseerModule' => 'infrastructure/daemon/overseer/PhabricatorDaemonOverseerModule.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorDaemonReference' => 'infrastructure/daemon/control/PhabricatorDaemonReference.php',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorDaemonTaskGarbageCollector' => 'applications/daemon/garbagecollector/PhabricatorDaemonTaskGarbageCollector.php',
Separate daemon task table rendering into a standalone class Summary: Ref T5402, T6238. Pull this out into a class so the Instances app can embed task views. Test Plan: Loaded `/daemon/` and examined the content in the tables. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T6238, T5402 Differential Revision: https://secure.phabricator.com/D11090
2014-12-30 19:00:06 +01:00
'PhabricatorDaemonTasksTableView' => 'applications/daemon/view/PhabricatorDaemonTasksTableView.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorDaemonsApplication' => 'applications/daemon/application/PhabricatorDaemonsApplication.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorDaemonsSetupCheck' => 'applications/config/check/PhabricatorDaemonsSetupCheck.php',
Add a "daily routine" trigger clock for backups, etc. Summary: Ref T6881. Before implementing subscriptions, I'm going to vet triggers by using them to do backups. Each instance will get a daily trigger for backups, and that should give us a smaller-scale test to catch issues and limitations, with more opportunities for something to go wrong since it fires more often. Test Plan: Added unit tests. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11427
2015-01-20 01:54:23 +01:00
'PhabricatorDailyRoutineTriggerClock' => 'infrastructure/daemon/workers/clock/PhabricatorDailyRoutineTriggerClock.php',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboard' => 'applications/dashboard/storage/PhabricatorDashboard.php',
Allow panels to appear on dashboards Summary: Ref T3583. Adds edges, query relationships, etc. Lots of debugging/temporary UI. My general intent here is to use edges to track where panels appear, and then put additional data on the dashboard itself to control layout, positioning, etc. Dashboards don't actually render yet so this is still pretty boring. Test Plan: {F149175} {F149176} {F149177} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8916
2014-04-30 23:28:55 +02:00
'PhabricatorDashboardAddPanelController' => 'applications/dashboard/controller/PhabricatorDashboardAddPanelController.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorDashboardApplication' => 'applications/dashboard/application/PhabricatorDashboardApplication.php',
Add DashboardArchiveController Summary: So Fancy, Much JavaScript. Ref T9414 Test Plan: Archive a Dashboard, Activate a Dashboard, Edit a Dashboard Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9414 Differential Revision: https://secure.phabricator.com/D14725
2015-12-09 21:17:03 +01:00
'PhabricatorDashboardArchiveController' => 'applications/dashboard/controller/PhabricatorDashboardArchiveController.php',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardController' => 'applications/dashboard/controller/PhabricatorDashboardController.php',
Allow entire dashboards to be copied Summary: Further improve UX for dealing with policy rules on dashboards: - When in the "Manage" view of a dashboard you can not edit: - Don't show the panel management controls. - Show a notice that the board isn't editable, recommending you make a copy instead. - Add a "Copy Dashboard" action to create a copy which you //can// edit. Test Plan: Copied some dashboards. See screenshots. Reviewers: chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9508
2014-06-13 06:49:19 +02:00
'PhabricatorDashboardCopyController' => 'applications/dashboard/controller/PhabricatorDashboardCopyController.php',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardDAO' => 'applications/dashboard/storage/PhabricatorDashboardDAO.php',
Modernize Dashboard edges Summary: Modernize Dashboard edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Attached a panel to a dashboard, observed the expected comment in the transaction view (both ways). Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11114
2015-01-02 00:11:59 +01:00
'PhabricatorDashboardDashboardHasPanelEdgeType' => 'applications/dashboard/edge/PhabricatorDashboardDashboardHasPanelEdgeType.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorDashboardDashboardPHIDType' => 'applications/dashboard/phid/PhabricatorDashboardDashboardPHIDType.php',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardEditController' => 'applications/dashboard/controller/PhabricatorDashboardEditController.php',
Dashboards - add ability to install dashboard as home Summary: See title. Adds PhabricatorDashboardInstall data object which scopes installs to objectPHID + applicationClass. This is because we already have a collision for user home pages and user profiles. Assume only one dashboard per objectPHID + applicationClass though at the database level. Fixes T5076. Test Plan: From dashboard view, installed a dashboard - success! Went back to dashboard view and uninstalled it! Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5076 Differential Revision: https://secure.phabricator.com/D9206
2014-05-20 01:09:31 +02:00
'PhabricatorDashboardInstall' => 'applications/dashboard/storage/PhabricatorDashboardInstall.php',
'PhabricatorDashboardInstallController' => 'applications/dashboard/controller/PhabricatorDashboardInstallController.php',
Dashboards - add layout mode to dashboards Summary: This gets us the ability to specify a "layout mode" and which column a panel should appear in at panel add time. Changing the layout mode from a multi column view to a single column view or vice versa will reset all panels to the left most column. You can also drag and drop where columns appear via the "arrange" mode. We also have a new dashboard create flow. Create dashboard -> arrange mode. (As opposed to view mode.) This could all possibly use massaging. Fixes T4996. Test Plan: made a dashboard with panels in multiple columns. verified correct widths for various layout modes re-arranged collumns like whoa. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4996 Differential Revision: https://secure.phabricator.com/D9031
2014-05-16 04:12:40 +02:00
'PhabricatorDashboardLayoutConfig' => 'applications/dashboard/layoutconfig/PhabricatorDashboardLayoutConfig.php',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardListController' => 'applications/dashboard/controller/PhabricatorDashboardListController.php',
Make the default view of dashboards be just the dashboard Summary: Fixes T4985, add manage page, change view page to show only panels. Arguably, PhabricatorDashboardArrangeController is no longer necessary. Also, still trying to figure out if I updated all flows that involve "arrange/{id}". Probably missed some. Also not sure of the Manage Dashboard icon. Please advise. Test Plan: Create dashboard, add panels, "view/{id}" should show just panels, Manage Dashboard should show timeline and edit links. Reviewers: #blessed_reviewers, epriestley, chad Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4985 Differential Revision: https://secure.phabricator.com/D9258
2014-05-22 19:59:46 +02:00
'PhabricatorDashboardManageController' => 'applications/dashboard/controller/PhabricatorDashboardManageController.php',
Dashboards - add layout mode to dashboards Summary: This gets us the ability to specify a "layout mode" and which column a panel should appear in at panel add time. Changing the layout mode from a multi column view to a single column view or vice versa will reset all panels to the left most column. You can also drag and drop where columns appear via the "arrange" mode. We also have a new dashboard create flow. Create dashboard -> arrange mode. (As opposed to view mode.) This could all possibly use massaging. Fixes T4996. Test Plan: made a dashboard with panels in multiple columns. verified correct widths for various layout modes re-arranged collumns like whoa. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4996 Differential Revision: https://secure.phabricator.com/D9031
2014-05-16 04:12:40 +02:00
'PhabricatorDashboardMovePanelController' => 'applications/dashboard/controller/PhabricatorDashboardMovePanelController.php',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardPanel' => 'applications/dashboard/storage/PhabricatorDashboardPanel.php',
Allow dashboard panels to be archived Summary: Ref T5471. Adds an archived state for panels. Archived panels don't show up in the default query view or in the "Add Existing Panel" workflow. Test Plan: - Archived a panel. - Activated a panel. - Viewed / searched for archived/active panels. - Popped "Add Existing Panel" dropdown and saw it omit archived panels. Reviewers: chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T5471 Differential Revision: https://secure.phabricator.com/D9779
2014-07-02 02:50:28 +02:00
'PhabricatorDashboardPanelArchiveController' => 'applications/dashboard/controller/PhabricatorDashboardPanelArchiveController.php',
Let dashboard panel types use customfield to manage editing Summary: Ref T3583. Use the same approach Harbormaster does to give panels cheap forms. Test Plan: {F149218} {F149219} {F149220} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8919
2014-04-30 23:29:41 +02:00
'PhabricatorDashboardPanelCoreCustomField' => 'applications/dashboard/customfield/PhabricatorDashboardPanelCoreCustomField.php',
'PhabricatorDashboardPanelCustomField' => 'applications/dashboard/customfield/PhabricatorDashboardPanelCustomField.php',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardPanelEditController' => 'applications/dashboard/controller/PhabricatorDashboardPanelEditController.php',
Modernize Dashboard edges Summary: Modernize Dashboard edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Attached a panel to a dashboard, observed the expected comment in the transaction view (both ways). Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11114
2015-01-02 00:11:59 +01:00
'PhabricatorDashboardPanelHasDashboardEdgeType' => 'applications/dashboard/edge/PhabricatorDashboardPanelHasDashboardEdgeType.php',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardPanelListController' => 'applications/dashboard/controller/PhabricatorDashboardPanelListController.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorDashboardPanelPHIDType' => 'applications/dashboard/phid/PhabricatorDashboardPanelPHIDType.php',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardPanelQuery' => 'applications/dashboard/query/PhabricatorDashboardPanelQuery.php',
Let dashboard panels render in a very basic way Summary: Ref T3583. This implements very primitive panel rendering on the panel detail page, and an ajaxable standalone view. Test Plan: {F149135} {F149136} {F149137} {F149138} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8913
2014-04-30 23:28:37 +02:00
'PhabricatorDashboardPanelRenderController' => 'applications/dashboard/controller/PhabricatorDashboardPanelRenderController.php',
'PhabricatorDashboardPanelRenderingEngine' => 'applications/dashboard/engine/PhabricatorDashboardPanelRenderingEngine.php',
Allow users to select QueryPanel search engines from a list Summary: Ref T4986. Instead of requiring users to know the name of an application search engine class, let them select from a list. Test Plan: Created a new panel. {F165468} Reviewers: chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9500
2014-06-12 22:22:20 +02:00
'PhabricatorDashboardPanelSearchApplicationCustomField' => 'applications/dashboard/customfield/PhabricatorDashboardPanelSearchApplicationCustomField.php',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardPanelSearchEngine' => 'applications/dashboard/query/PhabricatorDashboardPanelSearchEngine.php',
Make query panels editable by normal humans Summary: Ref T4986. Instead of requiring you to know engine class names and copy/paste URLs, provide select dropdowns that use SCARY JAVASCRIPT to do magical things. I think this is mostly reasonable, the only issue is that it's hard to create a panel out of a completely ad-hoc query (you'd have to save it, then create a panel out of the saved query, then remove the saved query). Once we develop T5307 we can do a better job of this. Test Plan: See screenshots. Reviewers: chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9572
2014-06-16 21:27:12 +02:00
'PhabricatorDashboardPanelSearchQueryCustomField' => 'applications/dashboard/customfield/PhabricatorDashboardPanelSearchQueryCustomField.php',
Make Dashboard tab panels editable by humans Summary: Fixes T5335. This is not pretty, but should reasonably let normal humans create tab panels. Test Plan: See screenshot. Reviewers: chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T5335 Differential Revision: https://secure.phabricator.com/D9600
2014-06-18 00:32:55 +02:00
'PhabricatorDashboardPanelTabsCustomField' => 'applications/dashboard/customfield/PhabricatorDashboardPanelTabsCustomField.php',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardPanelTransaction' => 'applications/dashboard/storage/PhabricatorDashboardPanelTransaction.php',
'PhabricatorDashboardPanelTransactionEditor' => 'applications/dashboard/editor/PhabricatorDashboardPanelTransactionEditor.php',
'PhabricatorDashboardPanelTransactionQuery' => 'applications/dashboard/query/PhabricatorDashboardPanelTransactionQuery.php',
Add dashboard panel types Summary: Ref T3583. These will be the primary class carrying panel implementations. Test Plan: {F149125} {F149126} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8912
2014-04-30 23:28:20 +02:00
'PhabricatorDashboardPanelType' => 'applications/dashboard/paneltype/PhabricatorDashboardPanelType.php',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardPanelViewController' => 'applications/dashboard/controller/PhabricatorDashboardPanelViewController.php',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardQuery' => 'applications/dashboard/query/PhabricatorDashboardQuery.php',
Rename `PhabricatorDashboardPanelType` subclasses for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11182
2015-01-04 20:32:07 +01:00
'PhabricatorDashboardQueryPanelType' => 'applications/dashboard/paneltype/PhabricatorDashboardQueryPanelType.php',
Embed dashboard panels in comments Summary: Fixes T4983, Panel prefix 'W' should be recognized as a shortcut to a dashboard panel Test Plan: Open any comment input, type '{W1}', or other existing panel, preview should embed that panel. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T4983 Differential Revision: https://secure.phabricator.com/D9215
2014-05-20 19:53:27 +02:00
'PhabricatorDashboardRemarkupRule' => 'applications/dashboard/remarkup/PhabricatorDashboardRemarkupRule.php',
Dashboards - add remove functionality Summary: To get there, upgrade "headerless" to "headerMode". Add a new removepanel controller. Fixes T5084. Test Plan: removed some panels to much success Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5078, T5084 Differential Revision: https://secure.phabricator.com/D9156
2014-05-19 23:04:26 +02:00
'PhabricatorDashboardRemovePanelController' => 'applications/dashboard/controller/PhabricatorDashboardRemovePanelController.php',
Give dashboards basic rendering and Ajax support Summary: Ref T3583. Let dashboards "render", sorta. Test Plan: {F149187} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8917
2014-04-30 23:29:14 +02:00
'PhabricatorDashboardRenderingEngine' => 'applications/dashboard/engine/PhabricatorDashboardRenderingEngine.php',
Generate expected schemata for Dashboards and Conpherence Summary: Ref T1191. - Add edge schemata generation. - Hit a couple of mostly-minor issues (T6128, T6129, T6130). Test Plan: Viewed schema in web UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10518
2014-09-18 20:15:38 +02:00
'PhabricatorDashboardSchemaSpec' => 'applications/dashboard/storage/PhabricatorDashboardSchemaSpec.php',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardSearchEngine' => 'applications/dashboard/query/PhabricatorDashboardSearchEngine.php',
Rename `PhabricatorDashboardPanelType` subclasses for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11182
2015-01-04 20:32:07 +01:00
'PhabricatorDashboardTabsPanelType' => 'applications/dashboard/paneltype/PhabricatorDashboardTabsPanelType.php',
'PhabricatorDashboardTextPanelType' => 'applications/dashboard/paneltype/PhabricatorDashboardTextPanelType.php',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardTransaction' => 'applications/dashboard/storage/PhabricatorDashboardTransaction.php',
'PhabricatorDashboardTransactionEditor' => 'applications/dashboard/editor/PhabricatorDashboardTransactionEditor.php',
'PhabricatorDashboardTransactionQuery' => 'applications/dashboard/query/PhabricatorDashboardTransactionQuery.php',
Dashboards - add ability to install dashboard as home Summary: See title. Adds PhabricatorDashboardInstall data object which scopes installs to objectPHID + applicationClass. This is because we already have a collision for user home pages and user profiles. Assume only one dashboard per objectPHID + applicationClass though at the database level. Fixes T5076. Test Plan: From dashboard view, installed a dashboard - success! Went back to dashboard view and uninstalled it! Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5076 Differential Revision: https://secure.phabricator.com/D9206
2014-05-20 01:09:31 +02:00
'PhabricatorDashboardUninstallController' => 'applications/dashboard/controller/PhabricatorDashboardUninstallController.php',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardViewController' => 'applications/dashboard/controller/PhabricatorDashboardViewController.php',
Restructure cache checks to improve modularity Summary: Ref T5501. This code was headed down a bad road; dump an indirection layer between rendering and data gatehring. In particular, this will make it much easier to lift these issues into setup warnings eventually. Test Plan: Viewed cache status page. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5501 Differential Revision: https://secure.phabricator.com/D12315
2015-04-07 23:38:03 +02:00
'PhabricatorDataCacheSpec' => 'applications/cache/spec/PhabricatorDataCacheSpec.php',
Use application PHIDs in Releeph, plus more Summary: Ref T2715. Ref T3551. Ref T603. This does a few things, but they're all sort of small: - We commonly use a `getX()` / `attachX()` pattern, but have very similar code in the `getX()` method every time. Provide a convenience method to make this pattern easier to write. - We use `willFilterPage()` in many queries, but it currently is called with zero or more results. This means we have a lot of "if no results, return nothing" boilerplate. Make it call only for one or more results. - Implement `PhabricatorPolicyInterface` on `ReleephBranch`. A branch has the same policy as its project. - Implement `ReleephBranchQuery`. - Move the branch PHID type to application PHID infrastructure. Test Plan: Browsed Releeph. Used `phid.query` to query branch PHIDs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2715, T3551 Differential Revision: https://secure.phabricator.com/D6512
2013-07-21 18:27:00 +02:00
'PhabricatorDataNotAttachedException' => 'infrastructure/storage/lisk/PhabricatorDataNotAttachedException.php',
Automatically sever databases after prolonged unreachability Summary: Ref T4571. When a database goes down briefly, we fall back to replicas. However, this fallback is slow (not good for users) and keeps sending a lot of traffic to the master (might be bad if the root cause is load-related). Keep track of recent connections and fully degrade into "severed" mode if we see a sequence of failures over a reasonable period of time. In this mode, we send much less traffic to the master (faster for users; less load for the database). We do send a little bit of traffic still, and if the master recovers we'll recover back into normal mode seeing several connections in a row succeed. This is similar to what most load balancers do when pulling web servers in and out of pools. For now, the specific numbers are: - We do at most one health check every 3 seconds. - If 5 checks in a row fail or succeed, we sever or un-sever the database (so it takes about 15 seconds to switch modes). - If the database is currently marked unhealthy, we reduce timeouts and retries when connecting to it. Test Plan: - Configured a bad `master`. - Browsed around for a bit, initially saw "unrechable master" errors. - After about 15 seconds, saw "major interruption" errors instead. - Fixed the config for `master`. - Browsed around for a while longer. - After about 15 seconds, things recovered. - Used "Cluster Databases" console to keep an eye on health checks: it now shows how many recent health checks were good: {F1213397} Reviewers: chad Reviewed By: chad Maniphest Tasks: T4571 Differential Revision: https://secure.phabricator.com/D15677
2016-04-10 23:18:09 +02:00
'PhabricatorDatabaseHealthRecord' => 'infrastructure/cluster/PhabricatorDatabaseHealthRecord.php',
Add a "Database Cluster Status" console in Config Summary: Ref T4571. The configuration option still doesn't do anything, but add a status panel for basic setup monitoring. Test Plan: Here's what a good version looks like: {F1212291} Also faked most of the errors it can detect and got helpful diagnostic messages like this: {F1212292} Reviewers: chad Reviewed By: chad Maniphest Tasks: T4571 Differential Revision: https://secure.phabricator.com/D15667
2016-04-10 00:21:29 +02:00
'PhabricatorDatabaseRef' => 'infrastructure/cluster/PhabricatorDatabaseRef.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorDatabaseSetupCheck' => 'applications/config/check/PhabricatorDatabaseSetupCheck.php',
Implement a basic version of ApplicationEditor in Paste Summary: Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste. This mostly looks and works like ApplicationSearch, and is heavily modeled on it. Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else. This has no functional changes, except: - I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it. - Subscribers are now editable. - Form field order is a little goofy (this will be fixed in a future diff). - Subscribers and projects are now race-resistant. The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits. Test Plan: - Created pastes. - Created pastes via API. - Edited pastes. - Edited every field. - Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4768, T9132 Differential Revision: https://secure.phabricator.com/D14390
2015-11-03 03:58:32 +01:00
'PhabricatorDatasourceEditField' => 'applications/transactions/editfield/PhabricatorDatasourceEditField.php',
Make "Assign / Claim" stacked action work properly in Maniphest Summary: Ref T9132. This is kind of a mess because the tokenizer rewrite left rendering tokenizers in Javascript a little rough. This causes bugs like icons not showing up on tokens in the "Policy" dialog, which there's a task for somewhere I think. I think I've fixed it enough that the beahavior is now correct (i.e., icons show up properly), but some of the code is a bit iffy. I'll eventually clean this up properly, but it's fairly well contained for now. Test Plan: - Reassigned a task. - Put a task up for grabs. - No reassign on closed tasks. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14669
2015-12-04 18:30:53 +01:00
'PhabricatorDatasourceEditType' => 'applications/transactions/edittype/PhabricatorDatasourceEditType.php',
Split up settings into "Date and Time Settings" and everything else. Summary: Ref T8176, Split up settings into "Date and Time Settings" and everything else. Test Plan: Open /settings, Account Settings should now have two tabs: "Account" and "Date and Time" Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T8176 Differential Revision: https://secure.phabricator.com/D12881
2015-05-17 02:21:37 +02:00
'PhabricatorDateTimeSettingsPanel' => 'applications/settings/panel/PhabricatorDateTimeSettingsPanel.php',
Add a robots.txt file to disallow /diffusion/ Summary: Fixes T4610. Open to suggestions, etc., if there's anything I'm missing. Also: - Moves these "system" endpoints into a real application. - Makes `isUnlisted()` work a little more consistently. Test Plan: Accessed `/robots.txt`, `/status/` and `/debug/`. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4610 Differential Revision: https://secure.phabricator.com/D8532
2014-03-14 19:53:17 +01:00
'PhabricatorDebugController' => 'applications/system/controller/PhabricatorDebugController.php',
Modularize Aphront exception handling Summary: Ref T1806. Ref T7173. Depends on D14047. Currently, all exception handling is in this big messy clump in `AphrontDefaultApplicationConfiguration`. Split it out into modular classes. This will let a future change add new classes in the Phacility cluster which intercept particular exceptions we care about and replaces the default, generic responses with more useful, tailored responses. Test Plan: {F777391} - Hit a Conduit error (made a method throw). - Hit an Ajax error (made comment preview throw). - Hit a high security error (tried to edit TOTP). - Hit a rate limiting error (added a bunch of email addresses). - Hit a policy error (tried to look at something with no permission). - Hit an arbitrary exception (made a randomc ontroller throw). Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14049
2015-09-03 19:04:42 +02:00
'PhabricatorDefaultRequestExceptionHandler' => 'aphront/handler/PhabricatorDefaultRequestExceptionHandler.php',
Generate syntax highlighting CSS from a reusable map Summary: Ref T9790. This prepares the syntax color rules to be reused in mail. This goes about halfway toward T5701 by sort-of supporting different styles but not really. Test Plan: - Ran `bin/celerity syntax` to regenerate syntax map. - Viewed some highlighted code, didn't see any differences. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9790 Differential Revision: https://secure.phabricator.com/D15846
2016-05-05 03:24:59 +02:00
'PhabricatorDefaultSyntaxStyle' => 'infrastructure/syntax/PhabricatorDefaultSyntaxStyle.php',
Desktop Notification support Summary: Fixes T4139. Adds a "Desktop Notifications" panel to settings. For now, we start with "Send Desktop Notifications Too" functionality. We can try to be fancy later and only send desktop notifications if the web app doesn't have focus, etc. Test Plan: Made some comments as a test user on a task and got purdy desktop notifications using Chrome. Then did it again with Firefox. Played around with permissions form with Chrome and got helpful information about what was up. Played around with Firefox and got similar results, except canceling the dialogue didn't invoke my handler code somehow. Oh Firefox! Reviewers: epriestley Reviewed By: epriestley Subscribers: rbalik, tycho.tatitscheff, joshuaspence, epriestley, Korvin Maniphest Tasks: T4139 Differential Revision: https://secure.phabricator.com/D13219
2015-06-22 22:11:37 +02:00
'PhabricatorDesktopNotificationsSettingsPanel' => 'applications/settings/panel/PhabricatorDesktopNotificationsSettingsPanel.php',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorDestructibleInterface' => 'applications/system/interface/PhabricatorDestructibleInterface.php',
Implement bin/remove, for structured destruction of objects Summary: Ref T4749. Ref T3265. Ref T4909. Several goals here: - Move user destruction to the CLI to limit the power of rogue admins. - Start consolidating all "destroy named object" scripts into a single UI, to make it easier to know how to destroy things. - Structure object destruction so we can do a better and more automatic job of cleaning up transactions, edges, search indexes, etc. - Log when we destroy objects so there's a record if data goes missing. Test Plan: Used `bin/remove destroy` to destroy several users. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3265, T4749, T4909 Differential Revision: https://secure.phabricator.com/D8940
2014-05-02 03:23:31 +02:00
'PhabricatorDestructionEngine' => 'applications/system/engine/PhabricatorDestructionEngine.php',
Prepare DestructionEngine to be modularized Summary: Ref T9979. The general shape of "engine" code feels pretty good, and I plan to move indexing to be more in line with other modern engines, with the ultimate goal of supporting subprojects (T10010) and several intermediate goals. Before moving indexing, clean up Destruction, since some of the new indexes will need destruction hooks and destruction currently has a lot of `instanceof` stuff that should be easy to fix by applying more modern approaches. Test Plan: - Used `bin/remove destroy` to destory an Almanac device. - Verified that properties for the device were destroyed. - Viewed module panel in UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14831
2015-12-20 16:44:03 +01:00
'PhabricatorDestructionEngineExtension' => 'applications/system/engine/PhabricatorDestructionEngineExtension.php',
'PhabricatorDestructionEngineExtensionModule' => 'applications/system/engine/PhabricatorDestructionEngineExtensionModule.php',
Add "Developer" and "Access Log" config option groups, some types Summary: - Add a "developer" option group. - Add an "access log" option group. - Render the types "bool", "int" and "string" in a more tailored way. - Add a config check for dead config. Right now this serves as a "TODO" list of things that need to be migrated. Test Plan: Looked at config options, setup issues. Edited bool, int, string options. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4308
2013-01-01 23:09:17 +01:00
'PhabricatorDeveloperConfigOptions' => 'applications/config/option/PhabricatorDeveloperConfigOptions.php',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorDeveloperPreferencesSettingsPanel' => 'applications/settings/panel/PhabricatorDeveloperPreferencesSettingsPanel.php',
Extend TransactionCommentQuery for Differential Summary: Ref T2009. Ref T1460. Replace hard-coded garbage with a real Query-layer query. Test Plan: Submitted inline comments in Differential. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2009, T1460 Differential Revision: https://secure.phabricator.com/D12027
2015-03-09 20:40:29 +01:00
'PhabricatorDiffInlineCommentQuery' => 'infrastructure/diff/query/PhabricatorDiffInlineCommentQuery.php',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorDiffPreferencesSettingsPanel' => 'applications/settings/panel/PhabricatorDiffPreferencesSettingsPanel.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorDifferenceEngine' => 'infrastructure/diff/PhabricatorDifferenceEngine.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorDifferentialApplication' => 'applications/differential/application/PhabricatorDifferentialApplication.php',
Move commit attachment to a separate CLI command Summary: Ref T9319. See D14967. As before, this is making a deeply-buried, complex operation easier to test by providing a CLI command. This adds `bin/differential attach-commit rXnnnn Dnnnn` to pretend that `rXnnnn` was just committed and matched `Dnnnn`. Test Plan: - Ran `bin/differential attach-commit X Y` for several different values, saw updates in the UI. - Faked the message parser to make sure stuff still worked there. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9319 Differential Revision: https://secure.phabricator.com/D14968
2016-01-08 13:59:31 +01:00
'PhabricatorDifferentialAttachCommitWorkflow' => 'applications/differential/management/PhabricatorDifferentialAttachCommitWorkflow.php',
Begin moving Phabricator configuration into PHP Summary: Ref T2255. Ref T2221. Lay the groundwork to move configuration into PHP, so we can show descriptions in the web UI, do typechecking, disable application options when an application is uninstalled, etc. Test Plan: {F28421} {F28420} {F28422} Reviewers: codeblock, btrahan, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221, T2255 Differential Revision: https://secure.phabricator.com/D4306
2012-12-31 00:36:06 +01:00
'PhabricatorDifferentialConfigOptions' => 'applications/differential/config/PhabricatorDifferentialConfigOptions.php',
Move diff extraction from commits to a separate test with a CLI command Summary: Ref T9319. When we discover a commit, we sometimes update the corresponding revision with a "this is the actual committed change" diff and send out a link to the changes between review and commit. This is currently very difficult to test, because it only happens the first time and you have to either go set up a bunch of objects or add a bunch of special casing to the parser to hit the workflow. I'm making some changes to how it pulls file content. To make those changes easier to test, first start extracting this stuff so the code can be run with `bin/differential extract ...` instead of needing to do a bunch of more complicated setup steps. Test Plan: - Ran `bin/differential extract ...` to extract diffs from commits. - Forced my way through the daemon workflow by faking out a bunch of flags, got a clean extract + attach + update. After this patch, this should rarely be necessary. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9319 Differential Revision: https://secure.phabricator.com/D14967
2016-01-08 13:35:17 +01:00
'PhabricatorDifferentialExtractWorkflow' => 'applications/differential/management/PhabricatorDifferentialExtractWorkflow.php',
'PhabricatorDifferentialManagementWorkflow' => 'applications/differential/management/PhabricatorDifferentialManagementWorkflow.php',
xDiffs and Revisions Generating Summary: Ref T2903 Test Plan: Revisions and Diffs are visually being generated Reviewers: epriestley, xask.linus Reviewed By: epriestley CC: AnhNhan, aran, Korvin Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5835
2013-05-06 23:11:26 +02:00
'PhabricatorDifferentialRevisionTestDataGenerator' => 'applications/differential/lipsum/PhabricatorDifferentialRevisionTestDataGenerator.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorDiffusionApplication' => 'applications/diffusion/application/PhabricatorDiffusionApplication.php',
Diffusion / MetaMTA options Summary: Implement Diffusion MetaMTA options. Also make the fake '{{config.option}}' rule work, and use Remarkup to render summaries as well as descriptions. Test Plan: Looked at Diffusion rules, edited some, looked at setup issues, verified '{{config.option}}' linked to the right option. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4466
2013-01-16 18:08:13 +01:00
'PhabricatorDiffusionConfigOptions' => 'applications/diffusion/config/PhabricatorDiffusionConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorDisabledUserController' => 'applications/auth/controller/PhabricatorDisabledUserController.php',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorDisplayPreferencesSettingsPanel' => 'applications/settings/panel/PhabricatorDisplayPreferencesSettingsPanel.php',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorDisqusAuthProvider' => 'applications/auth/provider/PhabricatorDisqusAuthProvider.php',
Add a visual divider element to profile menus Summary: Ref T10054. Test Plan: {F1061529} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15024
2016-01-14 23:34:21 +01:00
'PhabricatorDividerProfilePanel' => 'applications/search/profilepanel/PhabricatorDividerProfilePanel.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorDivinerApplication' => 'applications/diviner/application/PhabricatorDivinerApplication.php',
'PhabricatorDoorkeeperApplication' => 'applications/doorkeeper/application/PhabricatorDoorkeeperApplication.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorDraft' => 'applications/draft/storage/PhabricatorDraft.php',
'PhabricatorDraftDAO' => 'applications/draft/storage/PhabricatorDraftDAO.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorDrydockApplication' => 'applications/drydock/application/PhabricatorDrydockApplication.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorEdgeConfig' => 'infrastructure/edges/constants/PhabricatorEdgeConfig.php',
'PhabricatorEdgeConstants' => 'infrastructure/edges/constants/PhabricatorEdgeConstants.php',
Allow edges to be configured to prevent cycles Summary: Certain types of things we should be storing in edges (notably, Task X depends on Task Y) should always be acyclic. Allow `PhabricatorEdgeEditor` to enforce this, since we can't correctly enforce it outside of the editor without being vulnerable to races. Each edge type can be marked acyclic. If an edge type is acyclic, we perform additional steps when writing new edges of that type: - We acquire a global lock on the edge type before performing any reads or writes. This ensures we can't produce a cycle as a result of a race where two edits add edges which independently do not produce a cycle, but do produce a cycle when combined. - After performing writes but before committing transactions, we load the edge graph for each acyclic type and verify that it is, in fact, acyclic. If we detect cycles, we abort the edit. - When we're done, we release the edge type locks. This is a relatively high-complexity change, but gives us a simple way to flag an edge type as acyclic in a robust way. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D2940
2012-07-09 19:39:38 +02:00
'PhabricatorEdgeCycleException' => 'infrastructure/edges/exception/PhabricatorEdgeCycleException.php',
Roughly generate transaction-oriented API methods from EditEngines Summary: Ref T5873. Ref T9132. This is really rough and feels pretty flimsy at the edges (missing validation, generality, modularity, clean error handling, etc) but gets us most of the way toward generating plausible "whatever.edit" Conduit API methods from EditEngines. These methods are full-power methods which can do everything the edit form can, automatically support the same range of operations, and update when new fields are added. Test Plan: - Used new `paste.edit` to create a new Paste. - Used new `paste.edit` to update an existing paste. - Applied a variety of different transactions. - Hit a reasonable set of errors. {F941144} {F941145} {F941146} {F941147} Reviewers: chad Reviewed By: chad Maniphest Tasks: T5873, T9132 Differential Revision: https://secure.phabricator.com/D14393
2015-11-03 17:45:00 +01:00
'PhabricatorEdgeEditType' => 'applications/transactions/edittype/PhabricatorEdgeEditType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorEdgeEditor' => 'infrastructure/edges/editor/PhabricatorEdgeEditor.php',
Allow edges to be configured to prevent cycles Summary: Certain types of things we should be storing in edges (notably, Task X depends on Task Y) should always be acyclic. Allow `PhabricatorEdgeEditor` to enforce this, since we can't correctly enforce it outside of the editor without being vulnerable to races. Each edge type can be marked acyclic. If an edge type is acyclic, we perform additional steps when writing new edges of that type: - We acquire a global lock on the edge type before performing any reads or writes. This ensures we can't produce a cycle as a result of a race where two edits add edges which independently do not produce a cycle, but do produce a cycle when combined. - After performing writes but before committing transactions, we load the edge graph for each acyclic type and verify that it is, in fact, acyclic. If we detect cycles, we abort the edit. - When we're done, we release the edge type locks. This is a relatively high-complexity change, but gives us a simple way to flag an edge type as acyclic in a robust way. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D2940
2012-07-09 19:39:38 +02:00
'PhabricatorEdgeGraph' => 'infrastructure/edges/util/PhabricatorEdgeGraph.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorEdgeQuery' => 'infrastructure/edges/query/PhabricatorEdgeQuery.php',
Allow edges to be configured to prevent cycles Summary: Certain types of things we should be storing in edges (notably, Task X depends on Task Y) should always be acyclic. Allow `PhabricatorEdgeEditor` to enforce this, since we can't correctly enforce it outside of the editor without being vulnerable to races. Each edge type can be marked acyclic. If an edge type is acyclic, we perform additional steps when writing new edges of that type: - We acquire a global lock on the edge type before performing any reads or writes. This ensures we can't produce a cycle as a result of a race where two edits add edges which independently do not produce a cycle, but do produce a cycle when combined. - After performing writes but before committing transactions, we load the edge graph for each acyclic type and verify that it is, in fact, acyclic. If we detect cycles, we abort the edit. - When we're done, we release the edge type locks. This is a relatively high-complexity change, but gives us a simple way to flag an edge type as acyclic in a robust way. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D2940
2012-07-09 19:39:38 +02:00
'PhabricatorEdgeTestCase' => 'infrastructure/edges/__tests__/PhabricatorEdgeTestCase.php',
Make edge types modular Summary: Ref T5245. I want to add a new capability to edge types, which is a good opportunity to move away from `PhabricatorEdgeConfig`, which isn't modular. This is basically the same as the modularization of PHID types, which has worked well. Add `PhabricatorEdgeType` and provide an adaption layer for the existing code. This has no runtime changes, except the fixed edge constant. Test Plan: Ran `var_dump(PhabricatorEdgeType::getAllTypes())` and got reasonable looking output. Reviewers: chad, btrahan, joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5245 Differential Revision: https://secure.phabricator.com/D9837
2014-07-18 00:40:37 +02:00
'PhabricatorEdgeType' => 'infrastructure/edges/type/PhabricatorEdgeType.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorEdgeTypeTestCase' => 'infrastructure/edges/type/__tests__/PhabricatorEdgeTypeTestCase.php',
Fully modularize DestructionEngine Summary: Ref T9979. Convert all DestructionEngine behaviors to extensions. Test Plan: {F1033244} Destroyed an object, verifying: - Herald transcripts were destroyed; - edges were destroyed; - flags were destroyed; - tokens were destroyed; - transactions were destroyed; - worker tasks were cancelled. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14832
2015-12-20 17:11:59 +01:00
'PhabricatorEdgesDestructionEngineExtension' => 'infrastructure/edges/engineextension/PhabricatorEdgesDestructionEngineExtension.php',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorEditEngine' => 'applications/transactions/editengine/PhabricatorEditEngine.php',
'PhabricatorEditEngineAPIMethod' => 'applications/transactions/editengine/PhabricatorEditEngineAPIMethod.php',
Implement a rough optgroup-based "Move on Workboard" stacked action Summary: Ref T6027. Try this out and see how it feels? Clear issues: - This definitely shouldn't be at the top. - You should probably be able to select it multiple times? - Some of the "which columns show up" rules might need adjustment? - Diamond marker maybe not great? Not sure I love this but it doesn't feel //terrible//... Test Plan: {F1207891} Reviewers: chad Reviewed By: chad Maniphest Tasks: T6027 Differential Revision: https://secure.phabricator.com/D15638
2016-04-06 14:59:09 +02:00
'PhabricatorEditEngineColumnsCommentAction' => 'applications/transactions/commentaction/PhabricatorEditEngineColumnsCommentAction.php',
Provide "Change Projects" and "Change Subscribers" (instead of "Add ...") in comment actions Summary: Ref T9908. Fixes T6205. This is largely some refactoring to improve the code. The new structure is: - Each EditField has zero or one "submit" (normal edit form) controls. - Each EditField has zero or one "comment" (stacked actions) controls. - If we want more than one in the future, we'd just add two fields. - Each EditField can have multiple EditTypes which provide Conduit transactions. - EditTypes are now lower-level and less involved on the Submit/Comment pathways. Test Plan: - Added and removed projects and subscribers. - Changed task statuses. - In two windows: added some subscribers in one, removed different ones in the other. The changes did not conflict. - Applied changes via Conduit. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6205, T9908 Differential Revision: https://secure.phabricator.com/D14789
2015-12-15 15:57:32 +01:00
'PhabricatorEditEngineCommentAction' => 'applications/transactions/commentaction/PhabricatorEditEngineCommentAction.php',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorEditEngineConfiguration' => 'applications/transactions/storage/PhabricatorEditEngineConfiguration.php',
Allow EditEngine configurations to be disabled and marked as "Default" Summary: Ref T9132. Let configurations be enabled/disabled. This doesn't do much right now. Let configurations be marked as default entries in the application "Create" menu. This makes them show up in the application in a dropdown, so you can replace the default form and/or provide several forms. In Maniphest, we'll do this to provide a menu something like this: - New Bug Report - New Feature Request - ADVANCED TASK CREATION!!11~ (only available for Community members) Test Plan: {F1005679} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14584
2015-11-19 23:16:44 +01:00
'PhabricatorEditEngineConfigurationDefaultCreateController' => 'applications/transactions/controller/PhabricatorEditEngineConfigurationDefaultCreateController.php',
Allow EditEngine forms to have defaults assigned Summary: Ref T9132. Allow form configurations to include defaults (like default projects, spaces, policies, etc). Test Plan: Defaulted "Language" to "Rainbow", plus other adjustments: {F975746} {F975747} {F975748} {F975749} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14508
2015-11-18 19:38:12 +01:00
'PhabricatorEditEngineConfigurationDefaultsController' => 'applications/transactions/controller/PhabricatorEditEngineConfigurationDefaultsController.php',
Allow EditEngine configurations to be disabled and marked as "Default" Summary: Ref T9132. Let configurations be enabled/disabled. This doesn't do much right now. Let configurations be marked as default entries in the application "Create" menu. This makes them show up in the application in a dropdown, so you can replace the default form and/or provide several forms. In Maniphest, we'll do this to provide a menu something like this: - New Bug Report - New Feature Request - ADVANCED TASK CREATION!!11~ (only available for Community members) Test Plan: {F1005679} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14584
2015-11-19 23:16:44 +01:00
'PhabricatorEditEngineConfigurationDisableController' => 'applications/transactions/controller/PhabricatorEditEngineConfigurationDisableController.php',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorEditEngineConfigurationEditController' => 'applications/transactions/controller/PhabricatorEditEngineConfigurationEditController.php',
'PhabricatorEditEngineConfigurationEditEngine' => 'applications/transactions/editor/PhabricatorEditEngineConfigurationEditEngine.php',
'PhabricatorEditEngineConfigurationEditor' => 'applications/transactions/editor/PhabricatorEditEngineConfigurationEditor.php',
Allow EditEngine forms to be marked as "edit" forms Summary: Ref T9132. Ref T9908. This attempts to move us forward on answering this question: > Which form gets used when a user clicks "Edit Task"? One answer is "the same form that was used to create the task". There are several problems with that: - The form might not exist anymore. - The user might not have permission to see it. - Some of the fields might be hidden, essentially preventing them from being edited. - We have to store the value somewhere and old tasks won't have a value. - Any instructions on the form probably don't apply to edits. One answer is "force the default, full form". That's not as problematic, but it means we have no ability to create limited access users who see fewer fields. The answer in this diff is: - Forms can be marked as "edit forms". - We take the user to the first edit form they have permission to see, from a master list. This allows you to create several forms like: - Advanced Edit Form (say, all fields -- visible to administrators). - Basic Edit Form (say, no policies -- visible to trusted users). - Noob Edit Form (say, no policies, priorities, or status -- visible to everyone). Then you can give everyone access to "noob", some people access to "basic", and a few people access to "advanced". This might only be part of the answer. In particular, you can still //use// any edit form you can see, so we could do these things in the future: - Give you an option to switch to a different form if you want. - Save the form the task was created with, and use that form by default. If we do pursue those, we can fall back to this behavior if there's a problem with them (e.g., original form doesn't exist or wasn't recorded). There's also no "reorder" UI yet, that'll be coming in the next diff. I'm also going to try to probably make the "create" and "edit" stuff a little more consistent / less weird in a bit. Test Plan: Marked various forms as edit forms or not edit forms, made edits, hit permissions errors, etc. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132, T9908 Differential Revision: https://secure.phabricator.com/D14702
2015-12-08 02:11:35 +01:00
'PhabricatorEditEngineConfigurationIsEditController' => 'applications/transactions/controller/PhabricatorEditEngineConfigurationIsEditController.php',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorEditEngineConfigurationListController' => 'applications/transactions/controller/PhabricatorEditEngineConfigurationListController.php',
Allow EditEngine form fields to be locked and hidden Summary: Ref T9132. Allows fields to be locked (shown, but not modifiable) and hidden (not shown). In both cases, default values are still respected. This lets you do things like create a form that generates objects with specific projects, policies, etc. Test Plan: - Set defaults. - Locked and hid a bunch of fields. - Created new objects using the resulting form. {F975801} {F975802} {F975803} {F975804} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14509
2015-11-18 19:50:09 +01:00
'PhabricatorEditEngineConfigurationLockController' => 'applications/transactions/controller/PhabricatorEditEngineConfigurationLockController.php',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorEditEngineConfigurationPHIDType' => 'applications/transactions/phid/PhabricatorEditEngineConfigurationPHIDType.php',
'PhabricatorEditEngineConfigurationQuery' => 'applications/transactions/query/PhabricatorEditEngineConfigurationQuery.php',
Allow form configurations to retitle and reorder forms and add preambles Summary: Ref T9132. This just makes edited forms do //something//, albeit not anything very useful yet. You can now edit a form and: - Retitle it; - add a preamble (instructions on top of the form); and - reorder the form's fields. Test Plan: {F974632} {F974633} {F974634} {F974635} {F974636} Reviewers: chad Reviewed By: chad Subscribers: hach-que Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14503
2015-11-17 18:33:06 +01:00
'PhabricatorEditEngineConfigurationReorderController' => 'applications/transactions/controller/PhabricatorEditEngineConfigurationReorderController.php',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorEditEngineConfigurationSaveController' => 'applications/transactions/controller/PhabricatorEditEngineConfigurationSaveController.php',
'PhabricatorEditEngineConfigurationSearchEngine' => 'applications/transactions/query/PhabricatorEditEngineConfigurationSearchEngine.php',
Allow EditEngine create and edit forms to be reordered Summary: Ref T9132. Ref T9908. Puts reordering UI in place: - For create forms, this just lets you pick a UI display order other than alphabetical. Seems nice to have. - For edit forms, this lets you create a hierarchy of advanced-to-basic forms and give them different visibility policies, if you want. Test Plan: {F1017842} - Verified that "Edit Thing" now takes me to the highest-ranked edit form. - Verified that create menu and quick create menu reflect application order. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132, T9908 Differential Revision: https://secure.phabricator.com/D14704
2015-12-08 15:14:47 +01:00
'PhabricatorEditEngineConfigurationSortController' => 'applications/transactions/controller/PhabricatorEditEngineConfigurationSortController.php',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorEditEngineConfigurationTransaction' => 'applications/transactions/storage/PhabricatorEditEngineConfigurationTransaction.php',
'PhabricatorEditEngineConfigurationTransactionQuery' => 'applications/transactions/query/PhabricatorEditEngineConfigurationTransactionQuery.php',
'PhabricatorEditEngineConfigurationViewController' => 'applications/transactions/controller/PhabricatorEditEngineConfigurationViewController.php',
'PhabricatorEditEngineController' => 'applications/transactions/controller/PhabricatorEditEngineController.php',
Fully modularize DestructionEngine Summary: Ref T9979. Convert all DestructionEngine behaviors to extensions. Test Plan: {F1033244} Destroyed an object, verifying: - Herald transcripts were destroyed; - edges were destroyed; - flags were destroyed; - tokens were destroyed; - transactions were destroyed; - worker tasks were cancelled. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14832
2015-12-20 17:11:59 +01:00
'PhabricatorEditEngineExtension' => 'applications/transactions/engineextension/PhabricatorEditEngineExtension.php',
'PhabricatorEditEngineExtensionModule' => 'applications/transactions/engineextension/PhabricatorEditEngineExtensionModule.php',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorEditEngineListController' => 'applications/transactions/controller/PhabricatorEditEngineListController.php',
Support enabling a formal points field in Maniphest Summary: Ref T4427. - New config option for labels, enabling, etc., but no UI/niceness yet. - When enabled, add a field. - Allow nonnegative values, including fractional values. - EditEngine is nice and Conduit / actions basically just work with a tiny bit of extra support code. Test Plan: - Edited points via "Edit". - Edited points via Conduit. - Edited points via stacked actions. - Tried to set "zebra" points. - Tried to set -1 points. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4427 Differential Revision: https://secure.phabricator.com/D15220
2016-02-09 00:24:52 +01:00
'PhabricatorEditEnginePointsCommentAction' => 'applications/transactions/commentaction/PhabricatorEditEnginePointsCommentAction.php',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorEditEngineQuery' => 'applications/transactions/query/PhabricatorEditEngineQuery.php',
'PhabricatorEditEngineSearchEngine' => 'applications/transactions/query/PhabricatorEditEngineSearchEngine.php',
Provide "Change Projects" and "Change Subscribers" (instead of "Add ...") in comment actions Summary: Ref T9908. Fixes T6205. This is largely some refactoring to improve the code. The new structure is: - Each EditField has zero or one "submit" (normal edit form) controls. - Each EditField has zero or one "comment" (stacked actions) controls. - If we want more than one in the future, we'd just add two fields. - Each EditField can have multiple EditTypes which provide Conduit transactions. - EditTypes are now lower-level and less involved on the Submit/Comment pathways. Test Plan: - Added and removed projects and subscribers. - Changed task statuses. - In two windows: added some subscribers in one, removed different ones in the other. The changes did not conflict. - Applied changes via Conduit. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6205, T9908 Differential Revision: https://secure.phabricator.com/D14789
2015-12-15 15:57:32 +01:00
'PhabricatorEditEngineSelectCommentAction' => 'applications/transactions/commentaction/PhabricatorEditEngineSelectCommentAction.php',
'PhabricatorEditEngineTokenizerCommentAction' => 'applications/transactions/commentaction/PhabricatorEditEngineTokenizerCommentAction.php',
Implement a basic version of ApplicationEditor in Paste Summary: Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste. This mostly looks and works like ApplicationSearch, and is heavily modeled on it. Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else. This has no functional changes, except: - I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it. - Subscribers are now editable. - Form field order is a little goofy (this will be fixed in a future diff). - Subscribers and projects are now race-resistant. The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits. Test Plan: - Created pastes. - Created pastes via API. - Edited pastes. - Edited every field. - Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4768, T9132 Differential Revision: https://secure.phabricator.com/D14390
2015-11-03 03:58:32 +01:00
'PhabricatorEditField' => 'applications/transactions/editfield/PhabricatorEditField.php',
Split Repository EditEngine form into smaller pages Summary: Ref T10748. This allows an EditEngine form to be broken up into pages. This is less powerful than `PHUIPagedFormView`, because the pages are not sequential / stateful. Each form saves immediately once it's submitted, and can not take you to a new form or back/forward in a series of forms. For example, you can't create a workflow where the user fills out 5 pages of information before we create an object, like the current repository workflow does. However, the only place we've ever wanted to do this is repositories and it's fairly bad there, so I feel reasonably confident we aren't going to miss this in the future. (We do "choose a type of service/repository/rule -> fill out one page of info" fairly often, but can do this without the full-power paging stuff.) Test Plan: - Created a repository usin the new Manage UI, filling out only a handful of fields. - Edited a repository using the new Manage UI. - All forms are now EditEngine forms offering paged views of the big huge underlying form: {F1254371} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15832
2016-05-02 14:35:05 +02:00
'PhabricatorEditPage' => 'applications/transactions/editengine/PhabricatorEditPage.php',
Roughly generate transaction-oriented API methods from EditEngines Summary: Ref T5873. Ref T9132. This is really rough and feels pretty flimsy at the edges (missing validation, generality, modularity, clean error handling, etc) but gets us most of the way toward generating plausible "whatever.edit" Conduit API methods from EditEngines. These methods are full-power methods which can do everything the edit form can, automatically support the same range of operations, and update when new fields are added. Test Plan: - Used new `paste.edit` to create a new Paste. - Used new `paste.edit` to update an existing paste. - Applied a variety of different transactions. - Hit a reasonable set of errors. {F941144} {F941145} {F941146} {F941147} Reviewers: chad Reviewed By: chad Maniphest Tasks: T5873, T9132 Differential Revision: https://secure.phabricator.com/D14393
2015-11-03 17:45:00 +01:00
'PhabricatorEditType' => 'applications/transactions/edittype/PhabricatorEditType.php',
If users are on the email to Phabricator, do not send them the Phabricator reply. Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email. Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected. Reviewers: epriestley, vrana Reviewed By: vrana CC: aran, Korvin, vrana Maniphest Tasks: T1676 Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 19:18:23 +02:00
'PhabricatorEditor' => 'infrastructure/PhabricatorEditor.php',
Rename "SearchEngine" to "FulltextStorageEngine" Summary: Ref T9979. I picked this name long before the advent of modern "Engine" architecture and it ended up being pretty confusing. Rename "SearchEngine" (currently: mysql or elasticsearch, used to store and query fulltext indexes) to "FulltextStorageEngine" to make it more clear what it does and disambituate it from ApplicationSearch, which also has a bunch of stuff called "SearchEngine", "SearchEngineExtension", etc. Test Plan: Grepped for `phabricatorsearchengine`. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14843
2015-12-21 19:25:28 +01:00
'PhabricatorElasticFulltextStorageEngine' => 'applications/search/fulltextstorage/PhabricatorElasticFulltextStorageEngine.php',
Modernize search engine selection Summary: Remove the `PhabricatorDefaultSearchEngineSelector` class. This is quite similar to D12053. Test Plan: Went to `/view/PhabricatorSearchApplication/` and saw the storage engine configuration. Set `search.elastic.host` and saw the highlighted storage engine change. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D12670
2015-05-19 22:59:58 +02:00
'PhabricatorElasticSearchSetupCheck' => 'applications/config/check/PhabricatorElasticSearchSetupCheck.php',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorEmailAddressesSettingsPanel' => 'applications/settings/panel/PhabricatorEmailAddressesSettingsPanel.php',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorEmailContentSource' => 'applications/metamta/contentsource/PhabricatorEmailContentSource.php',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorEmailFormatSettingsPanel' => 'applications/settings/panel/PhabricatorEmailFormatSettingsPanel.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorEmailLoginController' => 'applications/auth/controller/PhabricatorEmailLoginController.php',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorEmailPreferencesSettingsPanel' => 'applications/settings/panel/PhabricatorEmailPreferencesSettingsPanel.php',
Modernize email verification page Summary: Fixes T3517. Moves the email verification page out of People and into Auth. Makes it look less awful. Test Plan: {F49636} {F49637} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3517 Differential Revision: https://secure.phabricator.com/D6425
2013-07-11 03:53:09 +02:00
'PhabricatorEmailVerificationController' => 'applications/auth/controller/PhabricatorEmailVerificationController.php',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhabricatorEmbedFileRemarkupRule' => 'applications/files/markup/PhabricatorEmbedFileRemarkupRule.php',
Support `:emoji:` in Remarkup Summary: Ref T1191. This actually works without T1191, but makes emoji use on the desktop easier. Test Plan: {F210416} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10605
2014-09-29 17:31:00 +02:00
'PhabricatorEmojiRemarkupRule' => 'applications/macro/markup/PhabricatorEmojiRemarkupRule.php',
Introduce PhabricatorEmptyQueryException Summary: It's dumb to execute a query which we know will return an empty result. Test Plan: Looked at comment preview with "11", didn't see "1 = 0" in DarkConsole. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5177
2013-03-01 20:28:02 +01:00
'PhabricatorEmptyQueryException' => 'infrastructure/query/PhabricatorEmptyQueryException.php',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorEnv' => 'infrastructure/env/PhabricatorEnv.php',
'PhabricatorEnvTestCase' => 'infrastructure/env/__tests__/PhabricatorEnvTestCase.php',
Convert Countdown to EditEngine Summary: Fixes T10684. Fixes T10520. This primarily implements a date/epoch field, and then does a bunch of standard plumbing. Test Plan: - Created countdowns. - Edited countdowns. - Used HTTP prefilling. - Created a countdown ending on "Christmas Morning", etc. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10520, T10684 Differential Revision: https://secure.phabricator.com/D15655
2016-04-07 20:06:26 +02:00
'PhabricatorEpochEditField' => 'applications/transactions/editfield/PhabricatorEpochEditField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorEvent' => 'infrastructure/events/PhabricatorEvent.php',
'PhabricatorEventEngine' => 'infrastructure/events/PhabricatorEventEngine.php',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'PhabricatorEventListener' => 'infrastructure/events/PhabricatorEventListener.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorEventType' => 'infrastructure/events/constant/PhabricatorEventType.php',
Add an example event listener, improve documentation, and add a commit discovery event Summary: Improve documentation around Phabricator events. Test Plan: Generated and read documentation. Ran test script. Reviewers: btrahan, jungejason Reviewed By: jungejason CC: aran Maniphest Tasks: T1092 Differential Revision: https://secure.phabricator.com/D2917
2012-07-04 01:46:27 +02:00
'PhabricatorExampleEventListener' => 'infrastructure/events/PhabricatorExampleEventListener.php',
Allow diffusion.filecontentquery to load data for arbitrarily large files Summary: Fixes T10186. After D14970, `diffusion.filecontentquery` puts the content in a file and returns the file PHID. However, it does this in a way that doesn't go through the chunking engine, so it will fail for files larger than the chunk threshold (generally, 8MB). Instead, stream the file from the underlying command directly into chunked storage. Test Plan: - Made a commit including a really big file: https://github.com/epriestley/poems/commit/4dcd4c492b31d82f0fec6f447cf3719b9cc079e0 - Used `diffusion.filecontentquery` to load file content. - Parsed/imported commit locally. - Used `diffusion.filecontentquery` to load content for smaller files (README, etc). Reviewers: chad Reviewed By: chad Maniphest Tasks: T10186 Differential Revision: https://secure.phabricator.com/D15072
2016-01-21 13:25:38 +01:00
'PhabricatorExecFutureFileUploadSource' => 'applications/files/uploadsource/PhabricatorExecFutureFileUploadSource.php',
Add support for "Extended Policies" Summary: Ref T7703. See that task and inline for a bunch of discussion. Briefly, when we run implicit policy rules ("to see a revision, you must also be able to see its repository") at query time, they don't apply to other viewers we might check later. We do this very rarely, but when we do we're often doing it for a bunch of different viewers (for example, in Herald) so I don't want to just reload the object a million times. Test Plan: - Added and executed unit tests. - Wrote a "flag everything" Herald rule, as in the original report in T7703, and no longer got "Unknown Object" flags on revisions. - Rigged up a lot of cases in the web UI and couldn't find any inconsistencies, although this case is normally very hard to hit. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7703 Differential Revision: https://secure.phabricator.com/D13104
2015-05-11 23:23:35 +02:00
'PhabricatorExtendedPolicyInterface' => 'applications/policy/interface/PhabricatorExtendedPolicyInterface.php',
Add the "Extending Phabricator" config group. Summary: Refs T2255 and takes care of the "EXTENDING PHABRICATOR" group thereof. Test Plan: Looked at each of the new options. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4325
2013-01-03 00:52:30 +01:00
'PhabricatorExtendingPhabricatorConfigOptions' => 'applications/config/option/PhabricatorExtendingPhabricatorConfigOptions.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorExtensionsSetupCheck' => 'applications/config/check/PhabricatorExtensionsSetupCheck.php',
Created PhabricatorExternalAccount Class and Sql patch to create an external_account table. Summary: Created PhabricatorExternalAccount class with only data members. Will discuss with you regarding the necessary functions to be implemented in this class. Sql Patch to create a new table for external_accounts. Will I have to write unit tests the new storage object? Sending you this diff so that you can comment on this to further improve :). Test Plan: {F40977} Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T1536, T1205 Differential Revision: https://secure.phabricator.com/D5724
2013-04-19 20:40:13 +02:00
'PhabricatorExternalAccount' => 'applications/people/storage/PhabricatorExternalAccount.php',
Clean up image loading for ExternalAccounts Summary: Ref T1536. This gets the single queries out of the View and builds a propery Query class for ExternalAccount. Test Plan: Linked/unlinked accounts, logged out, logged in. Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6212
2013-06-17 21:14:00 +02:00
'PhabricatorExternalAccountQuery' => 'applications/auth/query/PhabricatorExternalAccountQuery.php',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorExternalAccountsSettingsPanel' => 'applications/settings/panel/PhabricatorExternalAccountsSettingsPanel.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorExtraConfigSetupCheck' => 'applications/config/check/PhabricatorExtraConfigSetupCheck.php',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorFacebookAuthProvider' => 'applications/auth/provider/PhabricatorFacebookAuthProvider.php',
Add aggregated facts to the Facts application Summary: Some facts are aggregations of other facts. For example, we may compute how many times each macro is used in each object as a "raw fact": Dnnn uses macro "psyduck" 6 times. But we want to present this data in aggregate form, e.g. "order macros by popularity". We can do this at runtime and it probably won't be too awful a query, but we can also aggregate it cheaply: Macro "psyduck" is used 3920 times across all objects. ...and then do a query like "select macros ordered by usage". "Aggregate" facts support facts like this. The aggregate facts I've implemented are: - Count of all objects. - Count of objects of type X. - Last time facts were updated. These clearly fit the "aggregate" facts template well. I'm not 100% sure macros do. We can use this table to answer a question like "What are the most popular macros, ordered by use?" We can also use it to answer a question like "What are the most popular macros in the last 6 months?", if we build a specific fact for that. But we can't use it to answer a question like "What are the most popular macros between times X and Y?". Maybe that's important; maybe not. This seems like a good fit for at least some types of facts. I'll de-magic the keys a bit in the next diff. Test Plan: Ran the engines and got some aggregated facts about other facts. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3089
2012-07-27 22:46:01 +02:00
'PhabricatorFactAggregate' => 'applications/fact/storage/PhabricatorFactAggregate.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorFactApplication' => 'applications/fact/application/PhabricatorFactApplication.php',
Allow Fact app to draw charts Summary: For any count fact, allow a chart to be drawn. INCREDIBLY POWERFUL DATA ANALYSIS PLATFORM. Test Plan: Drew a chart of object counts. Drew the Maniphest burn chart. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3099
2012-07-30 19:44:08 +02:00
'PhabricatorFactChartController' => 'applications/fact/controller/PhabricatorFactChartController.php',
Add aggregated facts to the Facts application Summary: Some facts are aggregations of other facts. For example, we may compute how many times each macro is used in each object as a "raw fact": Dnnn uses macro "psyduck" 6 times. But we want to present this data in aggregate form, e.g. "order macros by popularity". We can do this at runtime and it probably won't be too awful a query, but we can also aggregate it cheaply: Macro "psyduck" is used 3920 times across all objects. ...and then do a query like "select macros ordered by usage". "Aggregate" facts support facts like this. The aggregate facts I've implemented are: - Count of all objects. - Count of objects of type X. - Last time facts were updated. These clearly fit the "aggregate" facts template well. I'm not 100% sure macros do. We can use this table to answer a question like "What are the most popular macros, ordered by use?" We can also use it to answer a question like "What are the most popular macros in the last 6 months?", if we build a specific fact for that. But we can't use it to answer a question like "What are the most popular macros between times X and Y?". Maybe that's important; maybe not. This seems like a good fit for at least some types of facts. I'll de-magic the keys a bit in the next diff. Test Plan: Ran the engines and got some aggregated facts about other facts. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3089
2012-07-27 22:46:01 +02:00
'PhabricatorFactController' => 'applications/fact/controller/PhabricatorFactController.php',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactCountEngine' => 'applications/fact/engine/PhabricatorFactCountEngine.php',
Add FactCursors and application fact datasources Summary: - Add PhabricatorApplication. This is a general class that I have grand designs for, but used here to allow applications to provide objects for analysis by the facts appliction. - Add FactCursors, to keep track of where iterators are. - Make the daemon do something sort of useful. - Add `bin/fact cursors` for showing and managing objects and cursors. - Add some options to `bin/fact analyze`. Test Plan: - `bin/fact cursors`, `bin/fact cursors --reset DifferentialRevision`, `bin/fact cursors --reset X` - `bin/fact analyze`, `bin/fact analyze --all`, `bin/fact analyze --iterator DifferentialRevision --skip-aggregates` - `bin/phd debug fact` Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3098
2012-07-30 19:43:49 +02:00
'PhabricatorFactCursor' => 'applications/fact/storage/PhabricatorFactCursor.php',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactDAO' => 'applications/fact/storage/PhabricatorFactDAO.php',
'PhabricatorFactDaemon' => 'applications/fact/daemon/PhabricatorFactDaemon.php',
'PhabricatorFactEngine' => 'applications/fact/engine/PhabricatorFactEngine.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorFactEngineTestCase' => 'applications/fact/engine/__tests__/PhabricatorFactEngineTestCase.php',
Add aggregated facts to the Facts application Summary: Some facts are aggregations of other facts. For example, we may compute how many times each macro is used in each object as a "raw fact": Dnnn uses macro "psyduck" 6 times. But we want to present this data in aggregate form, e.g. "order macros by popularity". We can do this at runtime and it probably won't be too awful a query, but we can also aggregate it cheaply: Macro "psyduck" is used 3920 times across all objects. ...and then do a query like "select macros ordered by usage". "Aggregate" facts support facts like this. The aggregate facts I've implemented are: - Count of all objects. - Count of objects of type X. - Last time facts were updated. These clearly fit the "aggregate" facts template well. I'm not 100% sure macros do. We can use this table to answer a question like "What are the most popular macros, ordered by use?" We can also use it to answer a question like "What are the most popular macros in the last 6 months?", if we build a specific fact for that. But we can't use it to answer a question like "What are the most popular macros between times X and Y?". Maybe that's important; maybe not. This seems like a good fit for at least some types of facts. I'll de-magic the keys a bit in the next diff. Test Plan: Ran the engines and got some aggregated facts about other facts. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3089
2012-07-27 22:46:01 +02:00
'PhabricatorFactHomeController' => 'applications/fact/controller/PhabricatorFactHomeController.php',
'PhabricatorFactLastUpdatedEngine' => 'applications/fact/engine/PhabricatorFactLastUpdatedEngine.php',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactManagementAnalyzeWorkflow' => 'applications/fact/management/PhabricatorFactManagementAnalyzeWorkflow.php',
Add FactCursors and application fact datasources Summary: - Add PhabricatorApplication. This is a general class that I have grand designs for, but used here to allow applications to provide objects for analysis by the facts appliction. - Add FactCursors, to keep track of where iterators are. - Make the daemon do something sort of useful. - Add `bin/fact cursors` for showing and managing objects and cursors. - Add some options to `bin/fact analyze`. Test Plan: - `bin/fact cursors`, `bin/fact cursors --reset DifferentialRevision`, `bin/fact cursors --reset X` - `bin/fact analyze`, `bin/fact analyze --all`, `bin/fact analyze --iterator DifferentialRevision --skip-aggregates` - `bin/phd debug fact` Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3098
2012-07-30 19:43:49 +02:00
'PhabricatorFactManagementCursorsWorkflow' => 'applications/fact/management/PhabricatorFactManagementCursorsWorkflow.php',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactManagementDestroyWorkflow' => 'applications/fact/management/PhabricatorFactManagementDestroyWorkflow.php',
'PhabricatorFactManagementListWorkflow' => 'applications/fact/management/PhabricatorFactManagementListWorkflow.php',
'PhabricatorFactManagementStatusWorkflow' => 'applications/fact/management/PhabricatorFactManagementStatusWorkflow.php',
'PhabricatorFactManagementWorkflow' => 'applications/fact/management/PhabricatorFactManagementWorkflow.php',
'PhabricatorFactRaw' => 'applications/fact/storage/PhabricatorFactRaw.php',
Add PhabricatorFactSpec, for naming and formatting facts Summary: Not totally sure about this but I think it's okay? Test Plan: Loaded /fact/, got a more readable page. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3090
2012-07-28 02:29:44 +02:00
'PhabricatorFactSimpleSpec' => 'applications/fact/spec/PhabricatorFactSimpleSpec.php',
'PhabricatorFactSpec' => 'applications/fact/spec/PhabricatorFactSpec.php',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactUpdateIterator' => 'applications/fact/extract/PhabricatorFactUpdateIterator.php',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorFaxContentSource' => 'infrastructure/contentsource/PhabricatorFaxContentSource.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorFeedApplication' => 'applications/feed/application/PhabricatorFeedApplication.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFeedBuilder' => 'applications/feed/builder/PhabricatorFeedBuilder.php',
Feed options. Test Plan: Looked at them. Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4434
2013-01-15 02:49:32 +01:00
'PhabricatorFeedConfigOptions' => 'applications/feed/config/PhabricatorFeedConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFeedController' => 'applications/feed/controller/PhabricatorFeedController.php',
'PhabricatorFeedDAO' => 'applications/feed/storage/PhabricatorFeedDAO.php',
Add a feed detail/permalink page for feed stories Summary: Ref T2852. Asana has one bug which I'm having a little trouble figuring out. I want to get more information to debug it, but I'll need them to run `bin/feed republish <story_id>` to get that data. Right now, it's incredibly hard to figure out the story ID for feed stories. So mostly this is to make that easier (click permalink; pull it out of the URL), but it also adds a little functionality and cleans the code up a bit. The page itself could be prettier and maybe some day we'll add comments or whatever, but it seems reasonably functionalish. Test Plan: {F49962} - Also loaded many pages of feed history to check that nothing broke. Reviewers: btrahan, chad Reviewed By: chad CC: chad, aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6440
2013-07-13 02:04:02 +02:00
'PhabricatorFeedDetailController' => 'applications/feed/controller/PhabricatorFeedDetailController.php',
Use ApplicationSearch in Feed Summary: Ref T2625. This doesn't do anything fancy, but gives feed a little more flexibility. Test Plan: Viewed `/feed/`. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6681
2013-08-05 23:10:41 +02:00
'PhabricatorFeedListController' => 'applications/feed/controller/PhabricatorFeedListController.php',
Push feed publishing deeper into the task queue Summary: Ref T2852. I want to model Asana integration as a response to feed events. Currently, we queue one feed event for each HTTP hook. Instead, always queue one feed event and then have it queue any necessary followup events (now, http hooks; soon, asana). Add a script to make it easy to reproducibly fire feed event publishing. Test Plan: Republished a feed event and verified it hit configured HTTP hooks correctly. $ ./bin/feed republish 5765774156541908292 --trace >>> [2] <connect> phabricator2_feed <<< [2] <connect> 1,660 us >>> [3] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [3] <query> 595 us >>> [4] <connect> phabricator2_differential <<< [4] <connect> 760 us >>> [5] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [5] <query> 478 us >>> [6] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [6] <query> 449 us >>> [7] <connect> phabricator2_user <<< [7] <connect> 1,062 us >>> [8] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [8] <query> 540 us >>> [9] <connect> phabricator2_file <<< [9] <connect> 951 us >>> [10] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [10] <query> 498 us >>> [11] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [11] <query> 507 us Republishing story... >>> [12] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [12] <query> 685 us >>> [13] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [13] <query> 489 us >>> [14] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [14] <query> 512 us >>> [15] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [15] <query> 601 us >>> [16] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [16] <query> 405 us >>> [17] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [17] <query> 551 us >>> [18] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [18] <query> 507 us >>> [19] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [19] <query> 428 us >>> [20] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [20] <query> 419 us >>> [21] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [21] <query> 591 us >>> [22] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [22] <query> 406 us >>> [23] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [23] <query> 593 us >>> [24] <http> http://127.0.0.1/derp/ <<< [24] <http> 746,157 us [2013-06-24 20:23:26] EXCEPTION: (HTTPFutureResponseStatusHTTP) [HTTP/500] Internal Server Error Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6291
2013-06-26 01:29:47 +02:00
'PhabricatorFeedManagementRepublishWorkflow' => 'applications/feed/management/PhabricatorFeedManagementRepublishWorkflow.php',
'PhabricatorFeedManagementWorkflow' => 'applications/feed/management/PhabricatorFeedManagementWorkflow.php',
Use ApplicationSearch in Feed Summary: Ref T2625. This doesn't do anything fancy, but gives feed a little more flexibility. Test Plan: Viewed `/feed/`. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6681
2013-08-05 23:10:41 +02:00
'PhabricatorFeedQuery' => 'applications/feed/query/PhabricatorFeedQuery.php',
'PhabricatorFeedSearchEngine' => 'applications/feed/query/PhabricatorFeedSearchEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFeedStory' => 'applications/feed/story/PhabricatorFeedStory.php',
'PhabricatorFeedStoryData' => 'applications/feed/storage/PhabricatorFeedStoryData.php',
Adds base notification application Summary: First diff in a series of diffs to add notifications to Phabricator. This is the notification application ONLY. This commit does not include the changes to other applications that makes them add notifications. As such, no notifications will be generated beyond the initial database import. Test Plan: This is part of the notifications architecture which has been running on http://theoryphabricator.com for the past several months. Reviewers: epriestley, btrahan, ddfisher Reviewed By: epriestley CC: allenjohnashton, keebuhm, aran, Korvin, jungejason, nh Maniphest Tasks: T974 Differential Revision: https://secure.phabricator.com/D2571
2012-06-08 15:31:30 +02:00
'PhabricatorFeedStoryNotification' => 'applications/notification/storage/PhabricatorFeedStoryNotification.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFeedStoryPublisher' => 'applications/feed/PhabricatorFeedStoryPublisher.php',
'PhabricatorFeedStoryReference' => 'applications/feed/storage/PhabricatorFeedStoryReference.php',
'PhabricatorFile' => 'applications/files/storage/PhabricatorFile.php',
Viewerize ArcBundle file loading callbacks Summary: Ref T603. Clean these up and move them to a single place. Test Plan: - Downloaded a raw diff. - Enabled "attach diffs", created a revision, got an email with a diff. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7179
2013-09-30 21:21:33 +02:00
'PhabricatorFileBundleLoader' => 'applications/files/query/PhabricatorFileBundleLoader.php',
Add a chunking storage engine for files Summary: Ref T7149. This isn't complete and isn't active yet, but does basically work. I'll shore it up in the next few diffs. The new workflow goes like this: > Client, file.allocate(): I'd like to upload a file with length L, metadata M, and hash H. Then the server returns `upload` (a boolean) and `filePHID` (a PHID). These mean: | upload | filePHID | means | |---|---|---| | false | false | Server can't accept file. | false | true | File data already known, file created from hash. | true | false | Just upload normally. | true | true | Query chunks to start or resume a chunked upload. All but the last case are uninteresting and work like exising uploads with `file.uploadhash` (which we can eventually deprecate). In the last case: > Client, file.querychunks(): Give me a list of chunks that I should upload. This returns all the chunks for the file. Chunks have a start byte, an end byte, and a "complete" flag to indicate that the server already has the data. Then, the client fills in chunks by sending them: > Client, file.uploadchunk(): Here is the data for one chunk. This stuff doesn't work yet or has some caveats: - I haven't tested resume much. - Files need an "isPartial()" flag for partial uploads, and the UI needs to respect it. - The JS client needs to become chunk-aware. - Chunk size is set crazy low to make testing easier. - Some debugging flags that I'll remove soon-ish. - Downloading works, but still streams the whole file into memory. - This storage engine is disabled by default (hardcoded as a unit test engine) because it's still sketchy. - Need some code to remove the "isParital" flag when the last chunk is uploaded. - Maybe do checksumming on chunks. Test Plan: - Hacked up `arc upload` (see next diff) to be chunk-aware and uploaded a readme in 18 32-byte chunks. Then downloaded it. Got the same file back that I uploaded. - File UI now shows some basic chunk info for chunked files: {F336434} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12060
2015-03-13 19:30:02 +01:00
'PhabricatorFileChunk' => 'applications/files/storage/PhabricatorFileChunk.php',
Stream chunks when sending chunked files Summary: Ref T7149. Return a real iterator from the Chunk engine, which processes chunks sequentially. Test Plan: This is a bit hard to read, but shows the underlying chunks being accessed one at a time and only some being accessed when requesting a range of a file: ``` $ ./bin/files cat F878 --trace --begin 100 --end 256 ... >>> [10] <query> SELECT * FROM `file_storageblob` WHERE `id` = 85 <<< [10] <query> 240 us better software. Phabricat>>> [11] <query> SELECT * FROM `file_storageblob` WHERE `id` = 84 <<< [11] <query> 205 us or includes applications for: >>> [12] <query> SELECT * FROM `file_storageblob` WHERE `id` = 83 <<< [12] <query> 226 us - reviewing and auditing source>>> [13] <query> SELECT * FROM `file_storageblob` WHERE `id` = 82 <<< [13] <query> 203 us code; - hosting and browsing >>> [14] <query> SELECT * FROM `file_storageblob` WHERE `id` = 81 <<< [14] <query> 231 us repositories; - tracking bugs; ``` Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12073
2015-03-14 16:29:30 +01:00
'PhabricatorFileChunkIterator' => 'applications/files/engine/PhabricatorFileChunkIterator.php',
Add a chunking storage engine for files Summary: Ref T7149. This isn't complete and isn't active yet, but does basically work. I'll shore it up in the next few diffs. The new workflow goes like this: > Client, file.allocate(): I'd like to upload a file with length L, metadata M, and hash H. Then the server returns `upload` (a boolean) and `filePHID` (a PHID). These mean: | upload | filePHID | means | |---|---|---| | false | false | Server can't accept file. | false | true | File data already known, file created from hash. | true | false | Just upload normally. | true | true | Query chunks to start or resume a chunked upload. All but the last case are uninteresting and work like exising uploads with `file.uploadhash` (which we can eventually deprecate). In the last case: > Client, file.querychunks(): Give me a list of chunks that I should upload. This returns all the chunks for the file. Chunks have a start byte, an end byte, and a "complete" flag to indicate that the server already has the data. Then, the client fills in chunks by sending them: > Client, file.uploadchunk(): Here is the data for one chunk. This stuff doesn't work yet or has some caveats: - I haven't tested resume much. - Files need an "isPartial()" flag for partial uploads, and the UI needs to respect it. - The JS client needs to become chunk-aware. - Chunk size is set crazy low to make testing easier. - Some debugging flags that I'll remove soon-ish. - Downloading works, but still streams the whole file into memory. - This storage engine is disabled by default (hardcoded as a unit test engine) because it's still sketchy. - Need some code to remove the "isParital" flag when the last chunk is uploaded. - Maybe do checksumming on chunks. Test Plan: - Hacked up `arc upload` (see next diff) to be chunk-aware and uploaded a readme in 18 32-byte chunks. Then downloaded it. Got the same file back that I uploaded. - File UI now shows some basic chunk info for chunked files: {F336434} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12060
2015-03-13 19:30:02 +01:00
'PhabricatorFileChunkQuery' => 'applications/files/query/PhabricatorFileChunkQuery.php',
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
'PhabricatorFileCommentController' => 'applications/files/controller/PhabricatorFileCommentController.php',
Add an icon+background selector for project images Summary: Makes it easy to choose distinctive icons for projects. Test Plan: {F71018} {F71020} {F71019} {F71021} Reviewers: btrahan, chad Reviewed By: chad CC: chad, aran Differential Revision: https://secure.phabricator.com/D7333
2013-10-17 18:32:34 +02:00
'PhabricatorFileComposeController' => 'applications/files/controller/PhabricatorFileComposeController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFileController' => 'applications/files/controller/PhabricatorFileController.php',
'PhabricatorFileDAO' => 'applications/files/storage/PhabricatorFileDAO.php',
'PhabricatorFileDataController' => 'applications/files/controller/PhabricatorFileDataController.php',
'PhabricatorFileDeleteController' => 'applications/files/controller/PhabricatorFileDeleteController.php',
'PhabricatorFileDropUploadController' => 'applications/files/controller/PhabricatorFileDropUploadController.php',
Allow users to set view policies on files explicitly Summary: Ref T4589. Allow users to adjust visibility settings on files explicitly. This makes it easier to understand and manage upcoming changes in T4589. Test Plan: Changed the view policy for a file several times. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4589 Differential Revision: https://secure.phabricator.com/D10129
2014-08-02 23:45:50 +02:00
'PhabricatorFileEditController' => 'applications/files/controller/PhabricatorFileEditController.php',
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
'PhabricatorFileEditor' => 'applications/files/editor/PhabricatorFileEditor.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorFileFilePHIDType' => 'applications/files/phid/PhabricatorFileFilePHIDType.php',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorFileHasObjectEdgeType' => 'applications/files/edge/PhabricatorFileHasObjectEdgeType.php',
Provide a "PHUIFormIconSetControl" Summary: Ref T9992. This is a step on the path to getting EditEngine working in Badges, Projects and Calendar. This doesn't add a new `EditField` for icons yet, just standardizes the old stuff. New stuff is more general and I saved 150 lines of code. I put the endpoint in Files because the similar "choose a profile picture" endpoint will definitely go there, and this endpoint might eventually feature, like, "draw your own icon~~" or something. Test Plan: - Created events, projects and badges with custom icons. - Edited events, projects and badges, changing their icons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9992 Differential Revision: https://secure.phabricator.com/D14799
2015-12-16 16:53:13 +01:00
'PhabricatorFileIconSetSelectController' => 'applications/files/controller/PhabricatorFileIconSetSelectController.php',
Move "Macros" to a first-class application Summary: This is mostly to unblock D3547. - Move "Macros" to a first-class application called "Macros". - After D3547, this application will also house "Memes" (macros with text on them). - This will also make them easier to find; the top navigational query I field is "where are image macros?" nowadays, since it's not intuitive they're part of files. - This makes some of the UI mobile-aware but doesn't set the `device` flag yet, since there are still some missing pieces. - I'll separate storage out and continue modernizing the UI as we unblock and integrate D3547. Test Plan: Created, edited and deleted macros. Viewed files. Reviewers: btrahan, vrana, teisenbe Reviewed By: vrana CC: aran Maniphest Tasks: T175 Differential Revision: https://secure.phabricator.com/D3572
2012-10-01 23:04:03 +02:00
'PhabricatorFileImageMacro' => 'applications/macro/storage/PhabricatorFileImageMacro.php',
Modularize file transforms and provide a "transforms" UI Summary: Ref T7707. Available transforms are currently relatively hard-coded and don't really have any support UI. Modularize them so we can build some support UI. This doesn't actually //use// any of the new stuff yet: I want to make a clean cutover once I fix the aspect ratio stuff so I can pick up a cachekey/URI change as a side effect. Test Plan: {F400524} Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T7707 Differential Revision: https://secure.phabricator.com/D12808
2015-05-12 15:16:18 +02:00
'PhabricatorFileImageTransform' => 'applications/files/transform/PhabricatorFileImageTransform.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFileInfoController' => 'applications/files/controller/PhabricatorFileInfoController.php',
Introduce lightbox view for images Summary: images attached to maniphest tasks and mentioned in remarkup anywhere now invoke a lightbox control that lets the user page through all the images. lightbox includes a download button, next / prev buttons, and if we're not at the tippy toppy of hte page an "X" or close button. we also respond to left, right, and esc for navigating. next time we should get non-images working in here...! Test Plan: played with maniphest - looks good made comments with images. looks good. made sure multiple image comments worked. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad Maniphest Tasks: T1896 Differential Revision: https://secure.phabricator.com/D3705
2012-10-23 04:06:56 +02:00
'PhabricatorFileLinkView' => 'view/layout/PhabricatorFileLinkView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFileListController' => 'applications/files/controller/PhabricatorFileListController.php',
Add PhabricatorFileQuery Summary: This doesn't do anything useful yet but Pholio needs to access Files and I wanted to get the groundwork in place for eventual policy-awareness. Test Plan: Will use in Pholio. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3829
2012-10-31 17:57:46 +01:00
'PhabricatorFileQuery' => 'applications/files/query/PhabricatorFileQuery.php',
Add expected schemata for Fund, Files, Flags and Legalpad Summary: Ref T1191. Nothing too exciting in these. Test Plan: Saw more blue in UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10521
2014-09-19 14:44:40 +02:00
'PhabricatorFileSchemaSpec' => 'applications/files/storage/PhabricatorFileSchemaSpec.php',
Implement ApplicationSearch in Files Summary: Ref T2625. Ref T1163. A couple of small generalization nudges, but this is almost entirely straightforward. Test Plan: Executed various File queries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1163, T2625 Differential Revision: https://secure.phabricator.com/D6091
2013-05-31 19:51:05 +02:00
'PhabricatorFileSearchEngine' => 'applications/files/query/PhabricatorFileSearchEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFileStorageBlob' => 'applications/files/storage/PhabricatorFileStorageBlob.php',
'PhabricatorFileStorageConfigurationException' => 'applications/files/exception/PhabricatorFileStorageConfigurationException.php',
'PhabricatorFileStorageEngine' => 'applications/files/engine/PhabricatorFileStorageEngine.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorFileStorageEngineTestCase' => 'applications/files/engine/__tests__/PhabricatorFileStorageEngineTestCase.php',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorFileTemporaryGarbageCollector' => 'applications/files/garbagecollector/PhabricatorFileTemporaryGarbageCollector.php',
Make file storage more testable Summary: Fixes T2474. Adds a storage dummy storage engine for unit tests, and adds a couple of simple tests for basic file storage. Test Plan: Ran `arc unit` to execute unit tests. Reviewers: kwadwon Reviewed By: kwadwon CC: aran Maniphest Tasks: T2474 Differential Revision: https://secure.phabricator.com/D4777
2013-02-06 22:37:42 +01:00
'PhabricatorFileTestCase' => 'applications/files/storage/__tests__/PhabricatorFileTestCase.php',
Files Generating Summary: Ref T2903 Test Plan: Files are being generating, albeit temporary. Reviewers: epriestley, AnhNhan Reviewed By: AnhNhan CC: aran, Korvin, AnhNhan, chad Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5801
2013-05-06 19:30:24 +02:00
'PhabricatorFileTestDataGenerator' => 'applications/files/lipsum/PhabricatorFileTestDataGenerator.php',
Modularize file transforms and provide a "transforms" UI Summary: Ref T7707. Available transforms are currently relatively hard-coded and don't really have any support UI. Modularize them so we can build some support UI. This doesn't actually //use// any of the new stuff yet: I want to make a clean cutover once I fix the aspect ratio stuff so I can pick up a cachekey/URI change as a side effect. Test Plan: {F400524} Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T7707 Differential Revision: https://secure.phabricator.com/D12808
2015-05-12 15:16:18 +02:00
'PhabricatorFileThumbnailTransform' => 'applications/files/transform/PhabricatorFileThumbnailTransform.php',
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
'PhabricatorFileTransaction' => 'applications/files/storage/PhabricatorFileTransaction.php',
'PhabricatorFileTransactionComment' => 'applications/files/storage/PhabricatorFileTransactionComment.php',
'PhabricatorFileTransactionQuery' => 'applications/files/query/PhabricatorFileTransactionQuery.php',
Modularize file transforms and provide a "transforms" UI Summary: Ref T7707. Available transforms are currently relatively hard-coded and don't really have any support UI. Modularize them so we can build some support UI. This doesn't actually //use// any of the new stuff yet: I want to make a clean cutover once I fix the aspect ratio stuff so I can pick up a cachekey/URI change as a side effect. Test Plan: {F400524} Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T7707 Differential Revision: https://secure.phabricator.com/D12808
2015-05-12 15:16:18 +02:00
'PhabricatorFileTransform' => 'applications/files/transform/PhabricatorFileTransform.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFileTransformController' => 'applications/files/controller/PhabricatorFileTransformController.php',
Modularize file transforms and provide a "transforms" UI Summary: Ref T7707. Available transforms are currently relatively hard-coded and don't really have any support UI. Modularize them so we can build some support UI. This doesn't actually //use// any of the new stuff yet: I want to make a clean cutover once I fix the aspect ratio stuff so I can pick up a cachekey/URI change as a side effect. Test Plan: {F400524} Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T7707 Differential Revision: https://secure.phabricator.com/D12808
2015-05-12 15:16:18 +02:00
'PhabricatorFileTransformListController' => 'applications/files/controller/PhabricatorFileTransformListController.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorFileTransformTestCase' => 'applications/files/transform/__tests__/PhabricatorFileTransformTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFileUploadController' => 'applications/files/controller/PhabricatorFileUploadController.php',
Move Maniphest attached files section into textbox. Summary: Add a button to the Remarkup area that explains how to attach an image and remove the separate upload field. Test Plan: Check that the dialog pops up correctly and that dropping images onto the Remarkup area works. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T879 Differential Revision: https://secure.phabricator.com/D6049
2013-05-26 22:45:24 +02:00
'PhabricatorFileUploadDialogController' => 'applications/files/controller/PhabricatorFileUploadDialogController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFileUploadException' => 'applications/files/exception/PhabricatorFileUploadException.php',
Allow diffusion.filecontentquery to load data for arbitrarily large files Summary: Fixes T10186. After D14970, `diffusion.filecontentquery` puts the content in a file and returns the file PHID. However, it does this in a way that doesn't go through the chunking engine, so it will fail for files larger than the chunk threshold (generally, 8MB). Instead, stream the file from the underlying command directly into chunked storage. Test Plan: - Made a commit including a really big file: https://github.com/epriestley/poems/commit/4dcd4c492b31d82f0fec6f447cf3719b9cc079e0 - Used `diffusion.filecontentquery` to load file content. - Parsed/imported commit locally. - Used `diffusion.filecontentquery` to load content for smaller files (README, etc). Reviewers: chad Reviewed By: chad Maniphest Tasks: T10186 Differential Revision: https://secure.phabricator.com/D15072
2016-01-21 13:25:38 +01:00
'PhabricatorFileUploadSource' => 'applications/files/uploadsource/PhabricatorFileUploadSource.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorFileinfoSetupCheck' => 'applications/config/check/PhabricatorFileinfoSetupCheck.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorFilesApplication' => 'applications/files/application/PhabricatorFilesApplication.php',
Modernize file storage engine selection Summary: Fixes T5843. File storage engines use a very old "selector" mechanism which makes them difficult to extend. This mechanism predates widespread use of `PhutilSymbolLoader` to discover available implementations at runtime. Runtime discovery has generally proven more flexible and easier to use than explicit selection (although it sometimes needs more UI to support it in cases where order or enabled/disabled flags can not be directly determined). Use a modern runtime discovery mechanism instead of an explicit selector. This might break any installs which subclassed the `Selector`, but I believe almost no such installs exist, and they'll receive a meaningful exception upon upgrading (any custom engines will no longer implement all of the required methods). Looking forward, this modernizes infrastructure to prepare for new "virtual" chunked-storage engines, with the eventual goal of supporting very large file uploads and data import into the Phacility cluster. This uses D12051 to add UI to make it easier to understand the state of storage engines. Test Plan: Used new UI panel to assess storage engines: {F336270} - Uploaded a small file, saw it go to MySQL engine. - Uploaded a larger file, saw it go to S3 engine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5843 Differential Revision: https://secure.phabricator.com/D12053
2015-03-12 21:28:53 +01:00
'PhabricatorFilesApplicationStorageEnginePanel' => 'applications/files/applicationpanel/PhabricatorFilesApplicationStorageEnginePanel.php',
Update project profile image composer for new IconSet code Summary: Fixes T6856. Fixes T10164. - Make the profile image composer code use the underlying icon name instead of the top-level icon key, so it works instead of 404'ing. - Change the button to show a preview of the profile icon instead of the text "Use Icon and Color". - When creating a new non-milestone project, automatically set the profile image to the icon + color image. Test Plan: - Created several new projects, saw appropriate default icons. - Edited projects, saw icon previews. - Clicked icon buttons to set icons. - Poked around other applications which use builtins (Pholio, user profiles) to look for anything I broke, but everything seemed fine. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6856, T10164 Differential Revision: https://secure.phabricator.com/D15050
2016-01-18 21:58:19 +01:00
'PhabricatorFilesBuiltinFile' => 'applications/files/builtin/PhabricatorFilesBuiltinFile.php',
'PhabricatorFilesComposeIconBuiltinFile' => 'applications/files/builtin/PhabricatorFilesComposeIconBuiltinFile.php',
First go at Files settings. Summary: Based on @epriestley's https://secure.phabricator.com/differential/diff/9186/ plus others that seemed like they belong here. Test Plan: Saw the new settings show up in the web interface. Reviewers: epriestley, btrahan, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4425
2013-01-14 02:01:00 +01:00
'PhabricatorFilesConfigOptions' => 'applications/files/config/PhabricatorFilesConfigOptions.php',
Add `bin/files cat` to print a file to stdout Summary: Ref T7149. This makes debugging some of this stuff a bit easier by removing the HTTP part in the middle. Particularly, I anticipate having this stream data chunk-by-chunk in the near future. Test Plan: Ran `files cat F23`, got output. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12062
2015-03-13 19:30:13 +01:00
'PhabricatorFilesManagementCatWorkflow' => 'applications/files/management/PhabricatorFilesManagementCatWorkflow.php',
Add `bin/files compact` for sharing file data storage Summary: Fixes T5912. When we write files, we attempt to share storage if two files have the same content. In some cases, we may not share storage. Examples include: - Files migrated with `bin/files migrate` (it's simpler not to try to dedupe them). - Old files, from before storage was sharable (the mechanism did not exist). - Files broken by the bug fixed in T5912. Add a script to compact files by pointing files with the same content hash at the same file contnet. In the particular case of files broken by the bug in T5912, we know the hash of the file's content and will only point them at a file that we can load the data for, so this fixes them. Compaction is not hugely useful in general, but this script isn't too complex and the ability to fix damage from the bug in T5912 is desirable. We could remove this capability eventually. Test Plan: - Ran `files compact --all --dry-run` and sanity checked a bunch of the duplicates for actually being duplicates. - Migrated individual files with `files compact Fnnn --trace` and verified the storage compacted and all files survived the process. - Verified unused storage was correctly destroyed after removing the last reference to it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5912 Differential Revision: https://secure.phabricator.com/D10327
2014-08-21 20:47:59 +02:00
'PhabricatorFilesManagementCompactWorkflow' => 'applications/files/management/PhabricatorFilesManagementCompactWorkflow.php',
Add a script to migrate files between storage engines Summary: Quora requested this (moving to S3) but it's also clearly a good idea. Test Plan: Ran with various valid/invalid options to test options. Error/sanity checking seemed OK. Migrated individual local files. Migrated all my local files back and forth between engines several times. Uploaded some new files. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran Maniphest Tasks: T1950 Differential Revision: https://secure.phabricator.com/D3808
2012-10-25 20:36:38 +02:00
'PhabricatorFilesManagementEnginesWorkflow' => 'applications/files/management/PhabricatorFilesManagementEnginesWorkflow.php',
'PhabricatorFilesManagementMigrateWorkflow' => 'applications/files/management/PhabricatorFilesManagementMigrateWorkflow.php',
Add a `bin/files purge` workflow Summary: We can lose file data through various means; one reasonable way is if files get deleted from disk with 'local-disk' storage. If data goes missing, Ref T3265. Also, reduce some code duplication. Test Plan: Ran `bin/files purge`, `bin/files migrate`, `bin/files rebuild` with various args. Deleted a file with "local-disk" storage, ran `bin/files purge`, made sure it got picked up. Reviewers: dctrwatson, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3265 Differential Revision: https://secure.phabricator.com/D6068
2013-05-29 15:28:57 +02:00
'PhabricatorFilesManagementPurgeWorkflow' => 'applications/files/management/PhabricatorFilesManagementPurgeWorkflow.php',
Rename `bin/files metadata` to `bin/files rebuild` and let it rebuild MIME information Summary: See <https://github.com/facebook/phabricator/issues/320>. Files can end up with a bad MIME type, and we don't update it when uploading another copy of the file since obviously the new copy has the same data and thus the same MIME type. - Rename `bin/files metadata` to `bin/files rebuild` to make it a more consistent verb. - Let it rebuild MIME types so users who hit issues like this can run `bin/files rebuild --all --rebuild-mime` to straighten things out. Test Plan: Ran `bin/files` in various modes, examined output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5951
2013-05-17 19:00:31 +02:00
'PhabricatorFilesManagementRebuildWorkflow' => 'applications/files/management/PhabricatorFilesManagementRebuildWorkflow.php',
Add a script to migrate files between storage engines Summary: Quora requested this (moving to S3) but it's also clearly a good idea. Test Plan: Ran with various valid/invalid options to test options. Error/sanity checking seemed OK. Migrated individual local files. Migrated all my local files back and forth between engines several times. Uploaded some new files. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran Maniphest Tasks: T1950 Differential Revision: https://secure.phabricator.com/D3808
2012-10-25 20:36:38 +02:00
'PhabricatorFilesManagementWorkflow' => 'applications/files/management/PhabricatorFilesManagementWorkflow.php',
Update project profile image composer for new IconSet code Summary: Fixes T6856. Fixes T10164. - Make the profile image composer code use the underlying icon name instead of the top-level icon key, so it works instead of 404'ing. - Change the button to show a preview of the profile icon instead of the text "Use Icon and Color". - When creating a new non-milestone project, automatically set the profile image to the icon + color image. Test Plan: - Created several new projects, saw appropriate default icons. - Edited projects, saw icon previews. - Clicked icon buttons to set icons. - Poked around other applications which use builtins (Pholio, user profiles) to look for anything I broke, but everything seemed fine. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6856, T10164 Differential Revision: https://secure.phabricator.com/D15050
2016-01-18 21:58:19 +01:00
'PhabricatorFilesOnDiskBuiltinFile' => 'applications/files/builtin/PhabricatorFilesOnDiskBuiltinFile.php',
Rate limit outbound requests in Macros Summary: Ref T6755. Although we do not return response bodies, it is possible to perform crude portscanning if you can execute a DNS rebinding attack (which, for now, remains theoretical). Limit users to 60 requests / hour to make it less feasible. This would require ~30 years to portscan all ports on a `/32` netblock. Users who can guess that services may exist can confirm their existence more quickly than this, but if the attacker already had a very small set of candidate services it seems unlikely that portscanning would be of much use in executing the attack. This protection should eventually be applied to T4190, too (that task also has other considerations). Test Plan: Set rate limit very low, hit rate limit. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6755 Differential Revision: https://secure.phabricator.com/D12168
2015-03-26 19:11:52 +01:00
'PhabricatorFilesOutboundRequestAction' => 'applications/files/action/PhabricatorFilesOutboundRequestAction.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFlag' => 'applications/flag/storage/PhabricatorFlag.php',
Modularize Herald "flag" action, plus update transcripts Summary: Ref T8726. This modularizes "Mark with flag", plus rebuilds transcripts in a more modern/flexible way. The big transcript stuff is: - Transcripts are now translatable. - Transcripts can now show multiple outputs from a single action. For example, an action like "add A, B, C to subscribers" can now say "added A; B is invalid; C was already subscribed". Test Plan: {F637784} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: joshuaspence, eadler, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13649
2015-07-18 14:54:26 +02:00
'PhabricatorFlagAddFlagHeraldAction' => 'applications/flag/herald/PhabricatorFlagAddFlagHeraldAction.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFlagColor' => 'applications/flag/constants/PhabricatorFlagColor.php',
'PhabricatorFlagConstants' => 'applications/flag/constants/PhabricatorFlagConstants.php',
'PhabricatorFlagController' => 'applications/flag/controller/PhabricatorFlagController.php',
'PhabricatorFlagDAO' => 'applications/flag/storage/PhabricatorFlagDAO.php',
'PhabricatorFlagDeleteController' => 'applications/flag/controller/PhabricatorFlagDeleteController.php',
Fully modularize DestructionEngine Summary: Ref T9979. Convert all DestructionEngine behaviors to extensions. Test Plan: {F1033244} Destroyed an object, verifying: - Herald transcripts were destroyed; - edges were destroyed; - flags were destroyed; - tokens were destroyed; - transactions were destroyed; - worker tasks were cancelled. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14832
2015-12-20 17:11:59 +01:00
'PhabricatorFlagDestructionEngineExtension' => 'applications/flag/engineextension/PhabricatorFlagDestructionEngineExtension.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFlagEditController' => 'applications/flag/controller/PhabricatorFlagEditController.php',
'PhabricatorFlagListController' => 'applications/flag/controller/PhabricatorFlagListController.php',
'PhabricatorFlagQuery' => 'applications/flag/query/PhabricatorFlagQuery.php',
Implement ApplicationSearch in Flags Summary: Ref T1809. Provide ApplicationSearch to Flags and allow the user to select flags by color. @chad might have some design feedback on my control. Test Plan: {F54131} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D6747
2013-08-14 01:27:26 +02:00
'PhabricatorFlagSearchEngine' => 'applications/flag/query/PhabricatorFlagSearchEngine.php',
'PhabricatorFlagSelectControl' => 'applications/flag/view/PhabricatorFlagSelectControl.php',
Add filter by object ability to flag query Summary: See title. Fixes T1809. Test Plan: verified each type that has flaggable interface still can be flagged verified that new custom query filter works Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D7392
2013-10-25 21:52:00 +02:00
'PhabricatorFlaggableInterface' => 'applications/flag/interface/PhabricatorFlaggableInterface.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorFlagsApplication' => 'applications/flag/application/PhabricatorFlagsApplication.php',
Allow pastes to be flagged Summary: This does a few things: - Allows you to flag pastes. This is straightforward. - Allows Applications to register event listeners. - Makes object action lists emit a 'didrenderactions' event, so other applications can add more actions. The Flags application injects its action in this way. This should generally make it much easier to add actions to objects when we add new applications, with less code duplication and better modularity. We have a really hacky version of this in Differential that I want to get rid of in lieu of this more general approach. I'm going to make object lists do the same thing, so any application can jump in and add stuff. Test Plan: Flagged and unflagged pastes. Viewed home page, differential, flags list. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3377
2012-08-24 22:19:47 +02:00
'PhabricatorFlagsUIEventListener' => 'applications/flag/events/PhabricatorFlagsUIEventListener.php',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorFulltextEngine' => 'applications/search/index/PhabricatorFulltextEngine.php',
Modularize fulltext indexing of Projects, Subscriptions and Custom Fields Summary: Ref T9979. This is going to become `FulltextEngine`, but pave the way for that by pulling extensions out of it. Test Plan: {F1036624} - Used `bin/search index Txxx`, saw projects, subscribers and custom fields rebuild in the index. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14835
2015-12-21 15:31:31 +01:00
'PhabricatorFulltextEngineExtension' => 'applications/search/index/PhabricatorFulltextEngineExtension.php',
'PhabricatorFulltextEngineExtensionModule' => 'applications/search/index/PhabricatorFulltextEngineExtensionModule.php',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorFulltextIndexEngineExtension' => 'applications/search/engineextension/PhabricatorFulltextIndexEngineExtension.php',
'PhabricatorFulltextInterface' => 'applications/search/interface/PhabricatorFulltextInterface.php',
Rename "SearchEngine" to "FulltextStorageEngine" Summary: Ref T9979. I picked this name long before the advent of modern "Engine" architecture and it ended up being pretty confusing. Rename "SearchEngine" (currently: mysql or elasticsearch, used to store and query fulltext indexes) to "FulltextStorageEngine" to make it more clear what it does and disambituate it from ApplicationSearch, which also has a bunch of stuff called "SearchEngine", "SearchEngineExtension", etc. Test Plan: Grepped for `phabricatorsearchengine`. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14843
2015-12-21 19:25:28 +01:00
'PhabricatorFulltextStorageEngine' => 'applications/search/fulltextstorage/PhabricatorFulltextStorageEngine.php',
Scaffolding for Fund Summary: Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet. You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc). Only notable decisions: - Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative. - I think that's it? Test Plan: - Created an initiative. - Edited an initiative. - Changed application policy defaults. - Searched for initiatives. - Subscribed to an initiative. - Opened/closed an initiative. - Used `I123` and `{I123}` in remarkup. - Destroyed an initiative. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
'PhabricatorFundApplication' => 'applications/fund/application/PhabricatorFundApplication.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorGDSetupCheck' => 'applications/config/check/PhabricatorGDSetupCheck.php',
Modularize the Garbage Collector Summary: The GC is a big block of hard-coded application GCs right now. Among other things, this means third parties can't tap into the infrastructure. Modularize it into `GarbageCollector` classes. This implements only one to prove the new stuff works; I'll followup with the rest in the next diff or few depending on how much mess I run into. Test Plan: Used `bin/phd debug garbage` to run the collector in debug mode, observed reasonable output and behavior. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7970
2014-01-15 19:02:24 +01:00
'PhabricatorGarbageCollector' => 'infrastructure/daemon/garbagecollector/PhabricatorGarbageCollector.php',
Provide `bin/garbage` for interacting with garbage collection Summary: Fixes T9494. This: - Removes all the random GC.x.y.z config. - Puts it all in one place that's locked and which you use `bin/garbage set-policy ...` to adjust. - Makes every TTL-based GC configurable. - Simplifies the code in the actual GCs. Test Plan: - Ran `bin/garbage collect` to collect some garbage, until it stopped collecting. - Ran `bin/garbage set-policy ...` to shorten policy. Saw change in web UI. Ran `bin/garbage collect` again and saw it collect more garbage. - Set policy to indefinite and saw it not collect garabge. - Set policy to default and saw it reflected in web UI / `collect`. - Ran `bin/phd debug trigger` and saw all GCs fire with reasonable looking queries. - Read new docs. {F857928} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9494 Differential Revision: https://secure.phabricator.com/D14219
2015-10-02 18:17:24 +02:00
'PhabricatorGarbageCollectorManagementCollectWorkflow' => 'infrastructure/daemon/garbagecollector/management/PhabricatorGarbageCollectorManagementCollectWorkflow.php',
'PhabricatorGarbageCollectorManagementSetPolicyWorkflow' => 'infrastructure/daemon/garbagecollector/management/PhabricatorGarbageCollectorManagementSetPolicyWorkflow.php',
'PhabricatorGarbageCollectorManagementWorkflow' => 'infrastructure/daemon/garbagecollector/management/PhabricatorGarbageCollectorManagementWorkflow.php',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorGestureUIExample' => 'applications/uiexample/examples/PhabricatorGestureUIExample.php',
Use subprocess output streaming to improve performance of Git commit discovery Summary: Improve performance of large discovery tasks in Git by using subprocess streaming, like we do for Mercurial. Basically, we save the cost of running many `git log` commands by running one big `git log` command but only parsing as much of it as we need to. This is pretty complicated, but we more or less need it for mercurial (which has ~100ms of 'hg' overhead instead of ~5ms of 'git' overhead) so we're already committed to most of the complexity costs. The git implementation is much simpler than the hg implementation because we don't need to handle all the weird parent rules (git gives us to them easily). Test Plan: Before, `discover --repair` on Phabricator took 35s: real 0m35.324s user 0m13.364s sys 0m21.088s Now 7s: real 0m7.236s user 0m2.436s sys 0m3.444s Note that most of the time is spent inserting rows after discover, the actual speedup of the git discovery part is much larger (subjectively, it runs in less than a second now, from ~28 seconds before). Also ran discover/pull on single new commits in normal cases to verify that nothing broke in the common case. Reviewers: jungejason, nh, vrana Reviewed By: vrana CC: aran Maniphest Tasks: T1401 Differential Revision: https://secure.phabricator.com/D2851
2012-06-26 00:21:48 +02:00
'PhabricatorGitGraphStream' => 'applications/repository/daemon/PhabricatorGitGraphStream.php',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorGitHubAuthProvider' => 'applications/auth/provider/PhabricatorGitHubAuthProvider.php',
Implement a MySQL-backed global lock Summary: Implementation is a little crazy but this seems to work as advertised. Test Plan: Acquired locks with "lock.php". Verified they held as long as the process reamined open and released properly on kill -9, ^C, etc. Reviewers: nh, jungejason, vrana, btrahan, Girish, edward Reviewed By: btrahan CC: aran Maniphest Tasks: T1400 Differential Revision: https://secure.phabricator.com/D2864
2012-06-27 22:59:12 +02:00
'PhabricatorGlobalLock' => 'infrastructure/util/PhabricatorGlobalLock.php',
Modernize file uploads Summary: Modernizes file uploads. In particular: - Adds a mobile menu, with an "Upload File" item. - Adds crumbs to the list view, detail view and upload view. - Adds "Upload File" action to crumbs. - Moves upload file to a separate page. - Removes the combined upload file + recent files page. - Makes upload file use a normal file control by default (works on mobile). - Home page, file list and file upload page are now global drop targets which accept files dropped anywhere on them. Dragging a file into the window shows a mask and an instructional message. - User education on this is a little weak but I think that's a big can of worms? - Fixes a bug where dropping multiple files into a Remarkup text area produced bad results (resolves T2190). T879 is related, although it's specifically about Maniphest. I've declined to make global drop targets yet there because there are multiple drop targets on the page with different meanings. That UI needs updating in general. @chad, do we have an "upload" icon (counterpart to "download")? Test Plan: Uploaded files in Maniphest, Differential, Files, and from Home. Dragged and dropped multiple files into Differential. Used crumbs, mobile. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2190 Differential Revision: https://secure.phabricator.com/D4200
2012-12-17 01:34:01 +01:00
'PhabricatorGlobalUploadTargetView' => 'applications/files/view/PhabricatorGlobalUploadTargetView.php',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorGoogleAuthProvider' => 'applications/auth/provider/PhabricatorGoogleAuthProvider.php',
Modularize complex HTTP parameter types Summary: Ref T9132. We have several places in the code that sometimes need to parse complex types. For example, we accept all of these in ApplicationSearch and now in ApplicationEditor: > /?subscribers=cat,dog > /?subscribers=PHID-USER-1111 > /?subscribers[]=cat&subscribers[]=PHID-USER-2222 ..etc. The logic to parse this stuff isn't too complex, but it isn't trivial either. Right now it lives in some odd places. Notably, `PhabricatorApplicationSearchEngine` has some weird helper methods for this stuff. Rather than give `EditEngine` the same set of weird helper methods, pull all this stuff out into "HTTPParameterTypes". Future diffs will add "Projects" and "Users" types where all the custom parsing/lookup logic can live. Then eventually the Search stuff can reuse these. Generally, this just breaks the code up into smaller pieces that have more specific responsibilities. Test Plan: {F944142} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14402
2015-11-04 14:05:10 +01:00
'PhabricatorHTTPParameterTypeTableView' => 'applications/config/view/PhabricatorHTTPParameterTypeTableView.php',
Improve handle semantics with HandlePool / HandleList Summary: Ref T7689, which discusses some of the motivation here. Briefly, these methods are awkward: - Controller->loadHandles() - Controller->loadViewerHandles() - Controller->renderHandlesForPHIDs() This moves us toward better semantics, less awkwardness, and a more reasonable attack on T7688 which won't double-fetch a bunch of data. Test Plan: - Added unit tests. - Converted one controller to the new stuff. - Viewed countdown lists, saw handles render. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7689 Differential Revision: https://secure.phabricator.com/D12202
2015-03-30 03:22:27 +02:00
'PhabricatorHandleList' => 'applications/phid/handle/pool/PhabricatorHandleList.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorHandleObjectSelectorDataView' => 'applications/phid/handle/view/PhabricatorHandleObjectSelectorDataView.php',
Improve handle semantics with HandlePool / HandleList Summary: Ref T7689, which discusses some of the motivation here. Briefly, these methods are awkward: - Controller->loadHandles() - Controller->loadViewerHandles() - Controller->renderHandlesForPHIDs() This moves us toward better semantics, less awkwardness, and a more reasonable attack on T7688 which won't double-fetch a bunch of data. Test Plan: - Added unit tests. - Converted one controller to the new stuff. - Viewed countdown lists, saw handles render. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7689 Differential Revision: https://secure.phabricator.com/D12202
2015-03-30 03:22:27 +02:00
'PhabricatorHandlePool' => 'applications/phid/handle/pool/PhabricatorHandlePool.php',
'PhabricatorHandlePoolTestCase' => 'applications/phid/handle/pool/__tests__/PhabricatorHandlePoolTestCase.php',
Proide application-based handle loads; load Slowvote handles from the application Summary: Ref T2715. This is pretty straightforward, I think. Notes: - Long term, I want to replace `PhabricatorObjectHandleData` with `PhabricatorObjectQuery` and `PhabricatorHandleQuery`. The former's name is a relic of old Facebook stuff and unusual now that everything else uses normal queries. - I simplified the amount of work applications need to do in order to populate handles. The should just need to set names and URIs in most cases. Test Plan: Used `phid.lookup` and `phid.query` to load slowvote handles. Browsed around to load other handles. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6508
2013-07-21 16:03:10 +02:00
'PhabricatorHandleQuery' => 'applications/phid/query/PhabricatorHandleQuery.php',
Remarkup rule for rendering PHIDs as handles Summary: adds the `{{PHID....}}` rule. Should mostly be useful in UI code that refers to Objects. It doesn't add any mention links/transactions. Test Plan: Comment with this, see email (plain + html) and comment box. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15488
2016-03-17 21:24:03 +01:00
'PhabricatorHandleRemarkupRule' => 'applications/phid/remarkup/PhabricatorHandleRemarkupRule.php',
Make "Create Subtask" work properly in EditEngine Summary: Ref T9908. This fixes "Create Subtask" so it works with the new stuff. Mostly straightforward. Test Plan: Created some subtasks. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9908 Differential Revision: https://secure.phabricator.com/D14706
2015-12-08 16:54:01 +01:00
'PhabricatorHandlesEditField' => 'applications/transactions/editfield/PhabricatorHandlesEditField.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorHarbormasterApplication' => 'applications/harbormaster/application/PhabricatorHarbormasterApplication.php',
Implemented support for build logs Summary: Depends on D7519. This implements support for build logs in Harbormaster. This includes support for appending to a log from the "Run Remote Command" build step. It also adds the ability to cancel builds. Currently the build view page doesn't update the logs live; I'm sure this can be achieved with Javelin, but I don't have enough experience with Javelin to actually make it poll from updates to content in the background. {F79151} {F79153} {F79150} {F79152} Test Plan: Tested this by setting up SSH on a Windows machine and using a Remote Command configured with: ``` C:\Windows\system32\cmd.exe /C cd C:\Build && mkdir Build_${timestamp} && cd Build_${timestamp} && git clone --recursive https://github.com/hach-que/Tychaia.git && cd Tychaia && Protobuild.exe && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Tychaia.Windows.sln ``` and observed the output of the build stream from the Windows machine into Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7521
2013-11-09 03:09:03 +01:00
'PhabricatorHarbormasterConfigOptions' => 'applications/harbormaster/config/PhabricatorHarbormasterConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorHash' => 'infrastructure/util/PhabricatorHash.php',
Add PhabricatorHash::digestForIndex() Summary: Does this seem reasonable? It's a bit more compact than digest() (6 bits / byte instead of 4 bits / byte) and 72 bits of entropy @ 12 bytes instead of 128 bits of entropy @ 32 bytes. I feel like it's important to preserve the printability, though, and this seemed like a fairly good balance of concerns. Test Plan: unit tests Reviewers: vrana Reviewed By: vrana CC: aran, yemao932 Differential Revision: https://secure.phabricator.com/D4253
2012-12-21 14:43:33 +01:00
'PhabricatorHashTestCase' => 'infrastructure/util/__tests__/PhabricatorHashTestCase.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorHelpApplication' => 'applications/help/application/PhabricatorHelpApplication.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorHelpController' => 'applications/help/controller/PhabricatorHelpController.php',
Allow applications to have multiple "help" menu items Summary: Ref T7199. Convert the single help menu item into a dropdown and allow applications to list multiple items there. When an application has mail command objects, link them in the menu. Test Plan: {F355925} {F355926} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12244
2015-04-01 17:13:12 +02:00
'PhabricatorHelpDocumentationController' => 'applications/help/controller/PhabricatorHelpDocumentationController.php',
Whitelist allowed editor protocols Summary: This is the other half of D8548. Specifically, the attack here was to set your own editor link to `javascript\n:...` and then you could XSS yourself. This isn't a hugely damaging attack, but we can be more certain by adding a whitelist here. We already whitelist linkable protocols in remarkup (`uri.allowed-protocols`) in general. Test Plan: Tried to set and use valid/invalid editor URIs. {F130883} {F130884} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8551
2014-03-17 21:00:37 +01:00
'PhabricatorHelpEditorProtocolController' => 'applications/help/controller/PhabricatorHelpEditorProtocolController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorHelpKeyboardShortcutController' => 'applications/help/controller/PhabricatorHelpKeyboardShortcutController.php',
Begin modularizing main menu items Summary: Ref T10077. Ref T8918. The way the main menu is built is not very modular and fairly hacky. It assumes menus are provided by applications, but this isn't exactly true. Notably, the "Quick Create" menu is not per-application. The current method of building this menu is very inefficient (see T10077). Particularly, we have to build it //twice// because we need to build it once to render the item and then again to render the dropdown options. Start cleaning this up. This diff doesn't actually have any behavioral changes, since I can't swap the menu over until we get rid of all the other items and I haven't extended this to Notifications/Conpherence yet so it doesn't actually fix T8918. Test Plan: Viewed menus while logged in, logged out, in different applications, in desktop/mobile. Nothing appeared different. Reviewers: chad Reviewed By: chad Maniphest Tasks: T8918, T10077 Differential Revision: https://secure.phabricator.com/D14922
2016-01-01 13:26:36 +01:00
'PhabricatorHelpMainMenuBarExtension' => 'applications/help/extension/PhabricatorHelpMainMenuBarExtension.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorHeraldApplication' => 'applications/herald/application/PhabricatorHeraldApplication.php',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorHeraldContentSource' => 'applications/herald/contentsource/PhabricatorHeraldContentSource.php',
Modularize Aphront exception handling Summary: Ref T1806. Ref T7173. Depends on D14047. Currently, all exception handling is in this big messy clump in `AphrontDefaultApplicationConfiguration`. Split it out into modular classes. This will let a future change add new classes in the Phacility cluster which intercept particular exceptions we care about and replaces the default, generic responses with more useful, tailored responses. Test Plan: {F777391} - Hit a Conduit error (made a method throw). - Hit an Ajax error (made comment preview throw). - Hit a high security error (tried to edit TOTP). - Hit a rate limiting error (added a bunch of email addresses). - Hit a policy error (tried to look at something with no permission). - Hit an arbitrary exception (made a randomc ontroller throw). Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14049
2015-09-03 19:04:42 +02:00
'PhabricatorHighSecurityRequestExceptionHandler' => 'aphront/handler/PhabricatorHighSecurityRequestExceptionHandler.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorHomeApplication' => 'applications/home/application/PhabricatorHomeApplication.php',
Make "Home" a formal application Summary: Ref T3979. Currently, the home page lives in an old application called "directory" and is informally defined. Make it a real application called "Home", with a formal definition. It isn't launchable and can't be uninstalled. Test Plan: Loaded home, saw exact same stuff. Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T3979 Differential Revision: https://secure.phabricator.com/D8074
2014-01-26 21:26:13 +01:00
'PhabricatorHomeController' => 'applications/home/controller/PhabricatorHomeController.php',
'PhabricatorHomeMainController' => 'applications/home/controller/PhabricatorHomeMainController.php',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorHomePreferencesSettingsPanel' => 'applications/settings/panel/PhabricatorHomePreferencesSettingsPanel.php',
Add very basic "quick create" menu Summary: Ref T3623. This is like a pre-v0, in that it doesn't have a dropdown yet. Clicking the button takes you to a page which can serve as a right click / mobile / edit target in the long run, but is obviously not great for desktop use. I'll add the dropdown in the next iteration. Test Plan: {F105631} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T3623 Differential Revision: https://secure.phabricator.com/D8088
2014-01-29 05:18:01 +01:00
'PhabricatorHomeQuickCreateController' => 'applications/home/controller/PhabricatorHomeQuickCreateController.php',
Modernize Hovercard implementation Summary: Ref T8980. Move away from events to EngineExtensions. This also simplifies hovercards a bit: - Removes tasks from revision cards. - Removes blockers/blocked from task cards. - Removes "Send Message" from user cards. These mostly felt cluttery to me. Open to arguments to retain them. I think we can make better use of the space, though (e.g., flags, projects + board columns). Test Plan: - Viewed people, task, revision, commit and project hovercards. {F1043256} {F1043257} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8980 Differential Revision: https://secure.phabricator.com/D14878
2015-12-24 20:20:18 +01:00
'PhabricatorHovercardEngineExtension' => 'applications/search/engineextension/PhabricatorHovercardEngineExtension.php',
'PhabricatorHovercardEngineExtensionModule' => 'applications/search/engineextension/PhabricatorHovercardEngineExtensionModule.php',
Add a `bin/hunks` script to manage migrations of hunk data Summary: Ref T4045. Ref T5179. While we'll eventually need to force a migration, we can let installs (particularly large installs) do an online migration for now. This moves hunks to the new storage format one at a time. (Note that nothing writes to the new store yet, so this is the only way to populate it.) WARNING: Installs, don't run this yet! It won't compress the data. Wait until it can also do compression. Test Plan: Added a `break;` after migrating one row and moved a few rows over. Spot checked them in the database and viewed the affected diffs. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4045, T5179 Differential Revision: https://secure.phabricator.com/D9291
2014-05-25 18:54:12 +02:00
'PhabricatorHunksManagementMigrateWorkflow' => 'applications/differential/management/PhabricatorHunksManagementMigrateWorkflow.php',
'PhabricatorHunksManagementWorkflow' => 'applications/differential/management/PhabricatorHunksManagementWorkflow.php',
Clean up "ids" and "phids" handling in SearchEngines Summary: Ref T9964. I added several hacks to get these working. Clean them up and pull this into a proper extension. The behavior in the web UI is: - they work in all applications; but - they only show up in the UI if a value is specified. So if you visit `/view/?ids=1,2` you get the field, but normally it's not present. We could refine this later. I'm going to add documentation about how to prefill these forms regardless, which should make this discoverable by reading the documentation. There's one teensey weensey hack: in the API, I push these fields to the top of the table. That one feels OK, since it's purely a convenience/display adjustment. Test Plan: Queried by IDs, reviewed docs. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14769
2015-12-13 19:11:40 +01:00
'PhabricatorIDsSearchEngineExtension' => 'applications/search/engineextension/PhabricatorIDsSearchEngineExtension.php',
'PhabricatorIDsSearchField' => 'applications/search/field/PhabricatorIDsSearchField.php',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorIRCProtocolAdapter' => 'infrastructure/daemon/bot/adapter/PhabricatorIRCProtocolAdapter.php',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhabricatorIconRemarkupRule' => 'applications/macro/markup/PhabricatorIconRemarkupRule.php',
Provide a "PHUIFormIconSetControl" Summary: Ref T9992. This is a step on the path to getting EditEngine working in Badges, Projects and Calendar. This doesn't add a new `EditField` for icons yet, just standardizes the old stuff. New stuff is more general and I saved 150 lines of code. I put the endpoint in Files because the similar "choose a profile picture" endpoint will definitely go there, and this endpoint might eventually feature, like, "draw your own icon~~" or something. Test Plan: - Created events, projects and badges with custom icons. - Edited events, projects and badges, changing their icons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9992 Differential Revision: https://secure.phabricator.com/D14799
2015-12-16 16:53:13 +01:00
'PhabricatorIconSet' => 'applications/files/iconset/PhabricatorIconSet.php',
Convert projects to EditEngine Summary: Ref T10010. This is pretty straightforward with a couple of very minor new behaviors, like the icon selector edit field. Test Plan: - Created projects. - Edited projects. - Saw "Create Project" in quick create menu. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14896
2015-12-27 15:45:53 +01:00
'PhabricatorIconSetEditField' => 'applications/transactions/editfield/PhabricatorIconSetEditField.php',
Provide a "PHUIFormIconSetControl" Summary: Ref T9992. This is a step on the path to getting EditEngine working in Badges, Projects and Calendar. This doesn't add a new `EditField` for icons yet, just standardizes the old stuff. New stuff is more general and I saved 150 lines of code. I put the endpoint in Files because the similar "choose a profile picture" endpoint will definitely go there, and this endpoint might eventually feature, like, "draw your own icon~~" or something. Test Plan: - Created events, projects and badges with custom icons. - Edited events, projects and badges, changing their icons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9992 Differential Revision: https://secure.phabricator.com/D14799
2015-12-16 16:53:13 +01:00
'PhabricatorIconSetIcon' => 'applications/files/iconset/PhabricatorIconSetIcon.php',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhabricatorImageMacroRemarkupRule' => 'applications/macro/markup/PhabricatorImageMacroRemarkupRule.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorImageTransformer' => 'applications/files/PhabricatorImageTransformer.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorImagemagickSetupCheck' => 'applications/config/check/PhabricatorImagemagickSetupCheck.php',
Begin improving modularity of IndexEngine, add locks Summary: Ref T9890. Ref T9979. Several adjacent goals: - The `SearchEngine` vs `ApplicationSearchEngine` thing is really confusing. There are also a bunch of confusing class names and class relationships within the fulltext indexing. I want to rename these classes to be more standard (`IndexEngine`, `IndexEngineExtension`, etc). Rename `SearchIndexer` to `IndexEngine`. A future change will rename `SearchEngine`. - Add the index locks described in T9890. - Structure things a little more normally so future diffs can do the "EngineExtension" thing more cleanly. Test Plan: Indexing: - Renamed a task to have a unique word in the title. - Ran `bin/search index Txxx`. - Searched for unique word. - Found task. Locking: - Added a `sleep(10)` after the `lock()` call. - Ran `bin/search index Txxx` in two windows. - Saw first one lock, sleep 10 seconds, index. - Saw second one give up temporarily after failing to grab the lock. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9890, T9979 Differential Revision: https://secure.phabricator.com/D14834
2015-12-20 17:54:29 +01:00
'PhabricatorIndexEngine' => 'applications/search/index/PhabricatorIndexEngine.php',
Lift Conpherence indexing up out of the Fulltext index Summary: Ref T9979. There are currently some hacks around Conpherence indexing: it does not really use the fulltext index, but its own specialized index. However, it's kind of hacked up so it can get reindexed by the normal indexing pipeline. Lift it up into IndexEngine, instead of FulltextEngine. Specifically, the new stuff is going to look like this: - IndexEngine: Rebuild all indexes. - ConpherenceIndexExtension: Rebuild thread indexes. - ProjectMemberIndexExtension: Rebuild project membership views. - NgramIndexExtension: Rebuild ngram indexes. - FulltextIndexExtension / FulltextEngine: Rebuild fulltext indexes, a special type of index. - FulltextCommentExtension: Rebuild comment fulltext indexes. - FulltextProjectExtension: Rebuild project fulltext indexes. - etc. Most of this is at least sort-of-in-place as of this diff, although some of the part in the middle is still pretty rough. Test Plan: - Made a unique comment in a Conpherence thread. - Used `bin/search index --force` to rebuild the index. - Searched for the comment. - Found the thread. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14841
2015-12-21 15:07:41 +01:00
'PhabricatorIndexEngineExtension' => 'applications/search/index/PhabricatorIndexEngineExtension.php',
'PhabricatorIndexEngineExtensionModule' => 'applications/search/index/PhabricatorIndexEngineExtensionModule.php',
Move infrastructure tests up one directory. Summary: Sometimes, the `PhabricatorInfrastructureTestCase` //would// fail, but we don't run it with `arc unit` because of the directory structure. See D9556 for an example. Test Plan: This is essentially the same as D9557. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D9559
2014-06-15 21:52:11 +02:00
'PhabricatorInfrastructureTestCase' => '__tests__/PhabricatorInfrastructureTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorInlineCommentController' => 'infrastructure/diff/PhabricatorInlineCommentController.php',
'PhabricatorInlineCommentInterface' => 'infrastructure/diff/interface/PhabricatorInlineCommentInterface.php',
Make inline comment preview work in Diffusion Summary: created a PhabricatorInlineCommentPreviewController so controllers in Diffusion and Differential respectively just have to handle the URI mapping and data loading like good little controllers. Test Plan: left inline comments on commits, deleted inline commits, submitted inline comments -- all worked well did the same on some diffs Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1176 Differential Revision: https://secure.phabricator.com/D3034
2012-07-23 20:01:28 +02:00
'PhabricatorInlineCommentPreviewController' => 'infrastructure/diff/PhabricatorInlineCommentPreviewController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorInlineSummaryView' => 'infrastructure/diff/view/PhabricatorInlineSummaryView.php',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorInstructionsEditField' => 'applications/transactions/editfield/PhabricatorInstructionsEditField.php',
Write a very basic string extractor Summary: Ref T1139. This has some issues and glitches, but is a reasonable initial attempt that gets some of the big pieces in. We have about 5,200 strings in Phabricator. Test Plan: {F108261} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D8138
2014-02-05 20:02:41 +01:00
'PhabricatorInternationalizationManagementExtractWorkflow' => 'infrastructure/internationalization/management/PhabricatorInternationalizationManagementExtractWorkflow.php',
'PhabricatorInternationalizationManagementWorkflow' => 'infrastructure/internationalization/management/PhabricatorInternationalizationManagementWorkflow.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorInvalidConfigSetupCheck' => 'applications/config/check/PhabricatorInvalidConfigSetupCheck.php',
Make password hashing modular Summary: Ref T4443. Make hashing algorithms pluggable and extensible so we can deal with the attendant complexities more easily. This moves "Iterated MD5" to a modular implementation, and adds a tiny bit of hack-glue so we don't need to migrate the DB in this patch. I'll migrate in the next patch, then add bcrypt. Test Plan: - Verified that the same stuff gets stored in the DB (i.e., no functional changes): - Logged into an old password account. - Changed password. - Registered a new account. - Changed password. - Switched back to master. - Logged in / out, changed password. - Switched back, logged in. - Ran unit tests (they aren't super extensive, but cover some of the basics). Reviewers: btrahan Reviewed By: btrahan CC: aran, kofalt Maniphest Tasks: T4443 Differential Revision: https://secure.phabricator.com/D8268
2014-02-18 18:31:30 +01:00
'PhabricatorIteratedMD5PasswordHasher' => 'infrastructure/util/password/PhabricatorIteratedMD5PasswordHasher.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorIteratedMD5PasswordHasherTestCase' => 'infrastructure/util/password/__tests__/PhabricatorIteratedMD5PasswordHasherTestCase.php',
Support pushing data into Git LFS Summary: Ref T7789. Ref T10604. This implements the `upload` action, which streams file data into Files. This makes Git LFS actually work, at least roughly. Test Plan: - Tracked files in an LFS repository. - Pushed LFS data (`git lfs track '*.png'; git add something.png; git commit -m ...; git push`). - Pulled LFS data (`git checkout master^; rm -rf .git/lfs; git checkout master; open something.png`). - Verified LFS refs show up in the gitlfsref table. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7789, T10604 Differential Revision: https://secure.phabricator.com/D15492
2016-03-18 14:22:37 +01:00
'PhabricatorIteratorFileUploadSource' => 'applications/files/uploadsource/PhabricatorIteratorFileUploadSource.php',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorJIRAAuthProvider' => 'applications/auth/provider/PhabricatorJIRAAuthProvider.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorJavelinLinter' => 'infrastructure/lint/linter/PhabricatorJavelinLinter.php',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorJiraIssueHasObjectEdgeType' => 'applications/doorkeeper/edge/PhabricatorJiraIssueHasObjectEdgeType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorJumpNavHandler' => 'applications/search/engine/PhabricatorJumpNavHandler.php',
Implement a more compact, general database-backed key-value cache Summary: See discussion in D4204. Facebook currently has a 314MB remarkup cache with a 55MB index, which is slow to access. Under the theory that this is an index size/quality problem (the current index is on a potentially-384-byte field, with many keys sharing prefixes), provide a more general index with fancy new features: - It implements PhutilKeyValueCache, so it can be a component in cache stacks and supports TTL. - It has a 12-byte hash-based key. - It automatically compresses large blocks of data (most of what we store is highly-compressible HTML). Test Plan: - Basics: - Loaded /paste/, saw caches generate and save. - Reloaded /paste/, saw the page hit cache. - GC: - Ran GC daemon, saw nothing. - Set maximum lifetime to 1 second, ran GC daemon, saw it collect the entire cache. - Deflate: - Selected row formats from the database, saw a mixture of 'raw' and 'deflate' storage. - Used profiler to verify that 'deflate' is fast (12 calls @ 220us on my paste list). - Ran unit tests Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D4259
2012-12-21 23:17:56 +01:00
'PhabricatorKeyValueDatabaseCache' => 'applications/cache/PhabricatorKeyValueDatabaseCache.php',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorLDAPAuthProvider' => 'applications/auth/provider/PhabricatorLDAPAuthProvider.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorLegalpadApplication' => 'applications/legalpad/application/PhabricatorLegalpadApplication.php',
Legalpad V0.2 - add mail integration Summary: Supports !unsubscribe and commenting on replies. Subscribers get mailed something reasonable. Fixes T3480. Sneaks in /LX/ support. In the near future I want to have that /LX/ be a clean "signature" page sans all the edit actions and other fluff... Will resolve this as part of T3481. Test Plan: used the metamta console to add comments and unsubscribe. added a phlog() inside mail code to verify mail bodies looked okay. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3480 Differential Revision: https://secure.phabricator.com/D6369
2013-07-04 01:37:05 +02:00
'PhabricatorLegalpadConfigOptions' => 'applications/legalpad/config/PhabricatorLegalpadConfigOptions.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorLegalpadDocumentPHIDType' => 'applications/legalpad/phid/PhabricatorLegalpadDocumentPHIDType.php',
Move some files around Summary: Move some `PhabricatorPolicyRule` implementations to a subdirectory of the parent application. Test Plan: N/A Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14478
2015-11-16 20:26:13 +01:00
'PhabricatorLegalpadSignaturePolicyRule' => 'applications/legalpad/policyrule/PhabricatorLegalpadSignaturePolicyRule.php',
Use `PhutilLibraryTestCase` Summary: Depends on D11231. Test Plan: `arc unit` Reviewers: btrahan, #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11233
2015-01-06 21:38:08 +01:00
'PhabricatorLibraryTestCase' => '__tests__/PhabricatorLibraryTestCase.php',
Begin modularizing profile panel/link construction Summary: Ref T10054. This has no product impact, but prepares us for customizable side nav on "profiles" (today, projects; probably users some day; and maybe other stuff down the road). Test Plan: Clicked all links on a profile, everything was exactly the same as before. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15007
2016-01-12 19:27:39 +01:00
'PhabricatorLinkProfilePanel' => 'applications/search/profilepanel/PhabricatorLinkProfilePanel.php',
Add a basic random image generator Summary: Adds an abstract base class for random image generation. Implements a concrete subclass for generating Mondrian-like images. Test Plan: {F40759} {F40760} {F40761} {F40762} {F40763} Reviewers: DeedyDas, AnhNhan Reviewed By: AnhNhan CC: chad, aran Differential Revision: https://secure.phabricator.com/D5705
2013-04-16 17:19:45 +02:00
'PhabricatorLipsumArtist' => 'applications/lipsum/image/PhabricatorLipsumArtist.php',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorLipsumContentSource' => 'infrastructure/contentsource/PhabricatorLipsumContentSource.php',
First Diff of Test Data Generator Summary: Progress to fix T2903 Test Plan: Ran './bin/lipsum help' and 'generate' workflows. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5672
2013-04-12 23:07:15 +02:00
'PhabricatorLipsumGenerateWorkflow' => 'applications/lipsum/management/PhabricatorLipsumGenerateWorkflow.php',
'PhabricatorLipsumManagementWorkflow' => 'applications/lipsum/management/PhabricatorLipsumManagementWorkflow.php',
Add a basic random image generator Summary: Adds an abstract base class for random image generation. Implements a concrete subclass for generating Mondrian-like images. Test Plan: {F40759} {F40760} {F40761} {F40762} {F40763} Reviewers: DeedyDas, AnhNhan Reviewed By: AnhNhan CC: chad, aran Differential Revision: https://secure.phabricator.com/D5705
2013-04-16 17:19:45 +02:00
'PhabricatorLipsumMondrianArtist' => 'applications/lipsum/image/PhabricatorLipsumMondrianArtist.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'PhabricatorLiskDAO' => 'infrastructure/storage/lisk/PhabricatorLiskDAO.php',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorLiskFulltextEngineExtension' => 'applications/search/engineextension/PhabricatorLiskFulltextEngineExtension.php',
Implement a rough initial version of ApplicationSearch-driven Conduit read endpoints Summary: Ref T9964. See that task for some context and discussion. Ref T7715, which has the bigger picture here. Basically, I want Conduit read endpoints to be full-power, ApplicationSearch-driven endpoints, so that applications can: - Write one EditEngine and get web + conduit writes for free. - Write one SearchEngine and get web + conduit reads for free. I previously made some steps toward this, but this puts more of the structure in place. Test Plan: Viewed API console endpoint and read 20 pages of docs: {F1021961} Made various calls: with query keys, constraints, pagination, and limits. Viewed new {nav Config > Modules} page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7715, T9964 Differential Revision: https://secure.phabricator.com/D14743
2015-12-11 17:45:56 +01:00
'PhabricatorLiskSearchEngineExtension' => 'applications/search/engineextension/PhabricatorLiskSearchEngineExtension.php',
Make Currency a more formal type Summary: Ref T2787. Phortune currently stores a bunch of stuff as `...inUSDCents`. This ends up being pretty cumbersome and I worry it will create a huge headache down the road (and possibly not that far off if we do Coinbase/Bitcoin soon). Even now, it's more of a pain than I figured it would be. Instead: - Provide an application-level serialization mechanism. - Provide currency serialization. - Store currency in an abstract way (currently, as "1.23 USD") that can handle currencies in the future. - Change all `...inUSDCents` to `..asCurrency`. - This generally simplifies all the application code. - Also remove some columns which don't make sense or don't make sense anymore. Notably, `Product` is going to get more abstract and mostly be provided by applications. Test Plan: - Created a new product. - Purchased a product. - Backed an initiative. - Ran unit tests. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10633
2014-10-06 19:26:48 +02:00
'PhabricatorLiskSerializer' => 'infrastructure/storage/lisk/PhabricatorLiskSerializer.php',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorListFilterUIExample' => 'applications/uiexample/examples/PhabricatorListFilterUIExample.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorLocalDiskFileStorageEngine' => 'applications/files/engine/PhabricatorLocalDiskFileStorageEngine.php',
'PhabricatorLocalTimeTestCase' => 'view/__tests__/PhabricatorLocalTimeTestCase.php',
Send mail to targets in the user's translation Summary: Ref T6367. Test Plan: - Added and executed unit tests. - Sent mail to A (en_US) and B (en_A*). - Got one mail in English and one mail in ENGLISH. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6367 Differential Revision: https://secure.phabricator.com/D13142
2015-06-03 19:49:27 +02:00
'PhabricatorLocaleScopeGuard' => 'infrastructure/internationalization/scope/PhabricatorLocaleScopeGuard.php',
'PhabricatorLocaleScopeGuardTestCase' => 'infrastructure/internationalization/scope/__tests__/PhabricatorLocaleScopeGuardTestCase.php',
Implement clock/trigger infrastructure for scheduling actions Summary: Ref T6881. Hopefully, this is the hard part. This adds a new daemon (the "trigger" daemon) which processes triggers, schedules them, and then executes them at the scheduled time. The design is a little complicated, but has these goals: - High resistance to race conditions: only the application writes to the trigger table; only the daemon writes to the event table. We won't lose events if someone saves a meeting at the same time as we're sending a reminder out for it. - Execution guarantees: scheduled events are guaranteed to execute exactly once. - Support for arbitrarily large queues: the daemon will make progress even if there are millions of triggers in queue. The cost to update the queue is proportional to the number of changes in it; the cost to process the queue is proportional to the number of events to execute. - Relatively good observability: you can monitor the state of the trigger queue reasonably well from the web UI. - Modular Infrastructure: this is a very low-level construct that Calendar, Phortune, etc., should be able to build on top of. It doesn't have this stuff yet: - Not very robust to bad actions: a misbehaving trigger can stop the queue fairly easily. This is OK for now since we aren't planning to make it part of any other applications for a while. We do still get execute-exaclty-once, but it might not happen for a long time (until someone goes and fixes the queue), when we could theoretically continue executing other events. - Doesn't start automatically: normal users don't need to run this thing yet so I'm not starting it by default. - Not super well tested: I've vetted the basics but haven't run real workloads through this yet. - No sophisticated tooling: I added some basic stuff but it's missing some pieces we'll have to build sooner or later, e.g. `bin/trigger cancel` or whatever. - Intentionally not realtime: This design puts execution guarantees far above realtime concerns, and will not give you precise event execution at 1-second resolution. I think this is the correct goal to pursue architecturally, and certainly correct for subscriptions and meeting reminders. Events which execute after they have become irrelevant can simply decline to do anything (like a meeting reminder which executes after the meeting is over). In general, the expectation for applications is: - When creating an object (like a calendar event) that needs to trigger a scheduled action, write a trigger (and save the PHID if you plan to update it later). - The daemon will process the event and schedule the action efficiently, in a race-free way. - If you want to move the action, update the trigger and the daemon will take care of it. - Your action will eventually dump a task into the task queue, and the task daemons will actually perform it. Test Plan: Using a test script like this: ``` <?php require_once 'scripts/__init_script__.php'; $trigger = id(new PhabricatorWorkerTrigger()) ->setAction( new PhabricatorLogTriggerAction( array( 'message' => 'test', ))) ->setClock( new PhabricatorMetronomicTriggerClock( array( 'period' => 33, ))) ->save(); var_dump($trigger); ``` ...I queued triggers and ran the daemon: - Verified triggers fire; - verified triggers reschedule; - verified trigger events show up in the web UI; - tried different periods; - added some triggers while the daemon was running; - examined `phd debug` output for anything suspicious. It seems to work in trivial use case, at least. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11419
2015-01-16 21:13:31 +01:00
'PhabricatorLogTriggerAction' => 'infrastructure/daemon/workers/action/PhabricatorLogTriggerAction.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorLogoutController' => 'applications/auth/controller/PhabricatorLogoutController.php',
Rename `PhabricatorPolicyRule` subclasses for consistency Summary: Ref T5655. Fixes T6849. This is another take on D11131, which was missing the DB migration and was reverted in rP7c4de0f6be77ddaea593e1f41ae27211ec179a55. Test Plan: Ran `./bin/storage upgrade` and verified that the classes were renamed in the `phabricator_policy.policy` table. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6849, T5655 Differential Revision: https://secure.phabricator.com/D11166
2015-01-03 13:48:19 +01:00
'PhabricatorLunarPhasePolicyRule' => 'applications/policy/rule/PhabricatorLunarPhasePolicyRule.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorMacroApplication' => 'applications/macro/application/PhabricatorMacroApplication.php',
Allow macros to have associated audio and audio behaviors Summary: Ref T3887. Implements storage and editors, but not the actual audio part. Test Plan: Edited audio, audio behaviors of macros. Transactions and email looked good. Hit error cases. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3887 Differential Revision: https://secure.phabricator.com/D7159
2013-09-28 01:01:37 +02:00
'PhabricatorMacroAudioController' => 'applications/macro/controller/PhabricatorMacroAudioController.php',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorMacroCommentController' => 'applications/macro/controller/PhabricatorMacroCommentController.php',
MetaMTA: Owners, Pholio, Macro Summary: Port MetaMTA options for Owners, Pholio and Macro. At some point I'd like to get rid of all these options (provide one "reply domain", and not allow overrides of reply handlers -- use events instead) but that's a battle we can fight later. Test Plan: Looked at options, looked at setup issues, edited something. Reviewers: codeblock, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4469
2013-01-16 19:52:30 +01:00
'PhabricatorMacroConfigOptions' => 'applications/macro/config/PhabricatorMacroConfigOptions.php',
Move "Macros" to a first-class application Summary: This is mostly to unblock D3547. - Move "Macros" to a first-class application called "Macros". - After D3547, this application will also house "Memes" (macros with text on them). - This will also make them easier to find; the top navigational query I field is "where are image macros?" nowadays, since it's not intuitive they're part of files. - This makes some of the UI mobile-aware but doesn't set the `device` flag yet, since there are still some missing pieces. - I'll separate storage out and continue modernizing the UI as we unblock and integrate D3547. Test Plan: Created, edited and deleted macros. Viewed files. Reviewers: btrahan, vrana, teisenbe Reviewed By: vrana CC: aran Maniphest Tasks: T175 Differential Revision: https://secure.phabricator.com/D3572
2012-10-01 23:04:03 +02:00
'PhabricatorMacroController' => 'applications/macro/controller/PhabricatorMacroController.php',
Modernize "macro" typeahead datasource Summary: Ref T4420. Make this modern. Test Plan: - Used typeahead in remarkup comment area to select macro "derpdog". Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9875
2014-07-11 01:18:15 +02:00
'PhabricatorMacroDatasource' => 'applications/macro/typeahead/PhabricatorMacroDatasource.php',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorMacroDisableController' => 'applications/macro/controller/PhabricatorMacroDisableController.php',
Move "Macros" to a first-class application Summary: This is mostly to unblock D3547. - Move "Macros" to a first-class application called "Macros". - After D3547, this application will also house "Memes" (macros with text on them). - This will also make them easier to find; the top navigational query I field is "where are image macros?" nowadays, since it's not intuitive they're part of files. - This makes some of the UI mobile-aware but doesn't set the `device` flag yet, since there are still some missing pieces. - I'll separate storage out and continue modernizing the UI as we unblock and integrate D3547. Test Plan: Created, edited and deleted macros. Viewed files. Reviewers: btrahan, vrana, teisenbe Reviewed By: vrana CC: aran Maniphest Tasks: T175 Differential Revision: https://secure.phabricator.com/D3572
2012-10-01 23:04:03 +02:00
'PhabricatorMacroEditController' => 'applications/macro/controller/PhabricatorMacroEditController.php',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorMacroEditor' => 'applications/macro/editor/PhabricatorMacroEditor.php',
Move "Macros" to a first-class application Summary: This is mostly to unblock D3547. - Move "Macros" to a first-class application called "Macros". - After D3547, this application will also house "Memes" (macros with text on them). - This will also make them easier to find; the top navigational query I field is "where are image macros?" nowadays, since it's not intuitive they're part of files. - This makes some of the UI mobile-aware but doesn't set the `device` flag yet, since there are still some missing pieces. - I'll separate storage out and continue modernizing the UI as we unblock and integrate D3547. Test Plan: Created, edited and deleted macros. Viewed files. Reviewers: btrahan, vrana, teisenbe Reviewed By: vrana CC: aran Maniphest Tasks: T175 Differential Revision: https://secure.phabricator.com/D3572
2012-10-01 23:04:03 +02:00
'PhabricatorMacroListController' => 'applications/macro/controller/PhabricatorMacroListController.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorMacroMacroPHIDType' => 'applications/macro/phid/PhabricatorMacroMacroPHIDType.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorMacroMailReceiver' => 'applications/macro/mail/PhabricatorMacroMailReceiver.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'PhabricatorMacroManageCapability' => 'applications/macro/capability/PhabricatorMacroManageCapability.php',
Made Meme Generator Summary: Fixed T2353 Test Plan: Checked whether same text generated the same URL Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2353 Differential Revision: https://secure.phabricator.com/D4551
2013-01-20 03:43:35 +01:00
'PhabricatorMacroMemeController' => 'applications/macro/controller/PhabricatorMacroMemeController.php',
Create a basic meme dialog Summary: Simple dialog for creating memes. We can add more features (typeahead, selection thumbs, preview) later. Test Plan: {F29815} Reviewers: DeedyDas, chad Reviewed By: chad CC: aran Maniphest Tasks: T2353 Differential Revision: https://secure.phabricator.com/D4557
2013-01-22 03:46:04 +01:00
'PhabricatorMacroMemeDialogController' => 'applications/macro/controller/PhabricatorMacroMemeDialogController.php',
Adding some filters and queries to Macro application Summary: Fixes T2778 Introduces `PhabricatorMacroQuery`, which should consolidate all queries regarding macros Adds `PolicyInterface` to `PhabricatorImageMacro`, as else the query would fail (we should consider adding it to the ApplicationTransaction instead, if that was ever planned) Adds `Active Macros` filter, making it the default Adds `My Macros` filter. You may ask why it overwrites `$authors`. Well, I did not want the page jump to the conclusion that it is a search result. It //is// one more or less, but the filter would jump to `seach` instead of `my`. If you want `My Macros` removed, tell me. It is useful only to heavy-macro-uploaders-and-users though. Five or six people in `http://secure.phabricator.(org|com)`, and an estimated dozen and a half at bigger installs. Test Plan: created multiple macros from multiple authors, disabled them at will. browsed around, verified that Macros only appeared in the right filters and that nothing else broke. Reviewers: epriestley, chad, btrahan CC: aran, Korvin Maniphest Tasks: T2778 Differential Revision: https://secure.phabricator.com/D5409
2013-03-22 17:46:21 +01:00
'PhabricatorMacroQuery' => 'applications/macro/query/PhabricatorMacroQuery.php',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorMacroReplyHandler' => 'applications/macro/mail/PhabricatorMacroReplyHandler.php',
Implement generalized application search in Macros Summary: Ref T2625. Works out the last kinks of generalization and gives Macros the more powerful new query engine. Overall, this feels pretty good to me. Test Plan: Executed, saved and edited a bunch of Macro queries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6078
2013-05-30 23:09:37 +02:00
'PhabricatorMacroSearchEngine' => 'applications/macro/query/PhabricatorMacroSearchEngine.php',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorMacroTransaction' => 'applications/macro/storage/PhabricatorMacroTransaction.php',
'PhabricatorMacroTransactionComment' => 'applications/macro/storage/PhabricatorMacroTransactionComment.php',
'PhabricatorMacroTransactionQuery' => 'applications/macro/query/PhabricatorMacroTransactionQuery.php',
'PhabricatorMacroViewController' => 'applications/macro/controller/PhabricatorMacroViewController.php',
Add basic support for Herald outbound rules Summary: Ref T5791. This is still very basic (no global actions, no support for matching headers/bodies/recipients/etc) but gets the core in. Test Plan: {F715209} {F715211} Reviewers: chad Reviewed By: chad Maniphest Tasks: T5791 Differential Revision: https://secure.phabricator.com/D13897
2015-08-15 19:54:33 +02:00
'PhabricatorMailEmailHeraldField' => 'applications/metamta/herald/PhabricatorMailEmailHeraldField.php',
'PhabricatorMailEmailHeraldFieldGroup' => 'applications/metamta/herald/PhabricatorMailEmailHeraldFieldGroup.php',
'PhabricatorMailEmailSubjectHeraldField' => 'applications/metamta/herald/PhabricatorMailEmailSubjectHeraldField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMailImplementationAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationAdapter.php',
'PhabricatorMailImplementationAmazonSESAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationAmazonSESAdapter.php',
Mailgun receive support Summary: As you've suggested, I took the SendGrid code and massaged it until it played nice with Mailgun. btw - unless I'm missing something, it appears that the SendGrid receiver lets you spoof emails (it performs no validation on the data received). Test Plan: Opened a task with Mailgun. Felt great. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4326 Differential Revision: https://secure.phabricator.com/D7989
2014-01-21 19:36:33 +01:00
'PhabricatorMailImplementationMailgunAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationMailgunAdapter.php',
Support SMTP as the mailer. Summary: Support SMTP as the mailer and user could turn on SMTP authentication if needed. Import PHPMailer as PHPMailerLite doesn't support SMTP. Make class PhabricatorMailImplementationPHPMailerAdapter final. Test Plan: N/A Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2139 Differential Revision: https://secure.phabricator.com/D4063
2012-12-09 11:36:40 +01:00
'PhabricatorMailImplementationPHPMailerAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationPHPMailerAdapter.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMailImplementationPHPMailerLiteAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationPHPMailerLiteAdapter.php',
'PhabricatorMailImplementationSendGridAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationSendGridAdapter.php',
'PhabricatorMailImplementationTestAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationTestAdapter.php',
Move the inbound mail list to the CLI Summary: Same as D6419. See D6413. Test Plan: 13 epriestley D6 Re: [local/Differential] [Request, 83 lines] D6: aabd 14 epriestley D6 Re: [local/Differential] [Request, 83 lines] D6: aabd 15 - - Re: [local/Diffusion] [Commit] rGTEST8fc313c77729: derp 16 - - Re: [local/Diffusion] [Commit] rGTEST8fc313c77729: derp 17 - - Re: [local/Diffusion] [Commit] rGTEST8fc313c77729: derp 18 - - Re: [local/Diffusion] [Commit] rGTEST8fc313c77729: derp 19 - - Re: [local/Diffusion] [Commit] rGTEST8fc313c77729: derp 20 - - (No subject.) 21 epriestley D22 (No subject.) 22 epriestley D12 (No subject.) Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6420
2013-07-11 00:18:37 +02:00
'PhabricatorMailManagementListInboundWorkflow' => 'applications/metamta/management/PhabricatorMailManagementListInboundWorkflow.php',
Move outbound mail lists to CLI and enhance details Summary: Finish off moving all this stuff to the CLI. Ref T3306. Test Plan: PROPERTIES ID: 6483 Status: void Retry Count: 0 Next Retry: 1373494457 Related PHID: PHID-DREV-5bnb33yeuhuaulyc3exg Message: Message has no valid recipients: all To/Cc are disabled, invalid, or configured not to receive this mail. PARAMETERS from: PHID-USER-lqiz3yd7wmk64ejugvov is-html: parent-message-id: null thread-id: differential-rev-PHID-DREV-5bnb33yeuhuaulyc3exg-req is-first-message: null is-bulk: 1 mailtags: ["differential-comment"] cc: ["PHID-USER-cluwcdowc35gmperlkbi"] subject: D22: quack quack subject-prefix: [Differential] vary-subject-prefix: [Commented On] worker-task: 936546 HEADERS Thread-Topic: D22: quack quack X-Herald-Rules: none X-Differential-Author: <PHID-USER-lqiz3yd7wmk64ejugvov> X-Differential-CC: <PHID-USER-ly3pvrtdkw7lbgs72jvr> X-Differential-CC: <PHID-USER-cluwcdowc35gmperlkbi> X-Differential-CC: <PHID-MLST-wkxaantg3q6pgdkty5pt> X-Differential-CC: <PHID-USER-aeabc4ipqbifny3rw4ok> X-Differential-CC: <PHID-USER-zqxtb3oi4pouwxnxlv3f> X-Differential-CC: <PHID-USER-cknqtm2dzw7twnwyiaye> X-Differential-CCs: <PHID-USER-ly3pvrtdkw7lbgs72jvr>, <PHID-USER-cluwcdowc35gmperlkbi>, <PHID-MLST-wkxaantg3q6pgdkty5pt>, <PHID-USER-aeabc4ipqbifny3rw4ok>, <PHID-USER-zqxtb3oi4pouwxnxlv3f>, <PHID-USER-cknqtm2dzw7twnwyiaye> X-Differential-Explicit-CC: <PHID-USER-ly3pvrtdkw7lbgs72jvr> X-Differential-Explicit-CC: <PHID-USER-cluwcdowc35gmperlkbi> X-Differential-Explicit-CC: <PHID-MLST-wkxaantg3q6pgdkty5pt> X-Differential-Explicit-CC: <PHID-USER-aeabc4ipqbifny3rw4ok> X-Differential-Explicit-CC: <PHID-USER-zqxtb3oi4pouwxnxlv3f> X-Differential-Explicit-CC: <PHID-USER-cknqtm2dzw7twnwyiaye> X-Differential-Explicit-CCs: <PHID-USER-ly3pvrtdkw7lbgs72jvr>, <PHID-USER-cluwcdowc35gmperlkbi>, <PHID-MLST-wkxaantg3q6pgdkty5pt>, <PHID-USER-aeabc4ipqbifny3rw4ok>, <PHID-USER-zqxtb3oi4pouwxnxlv3f>, <PHID-USER-cknqtm2dzw7twnwyiaye> X-Phabricator-To: <PHID-USER-lqiz3yd7wmk64ejugvov> X-Phabricator-Cc: <PHID-USER-ly3pvrtdkw7lbgs72jvr> X-Phabricator-Cc: <PHID-USER-cluwcdowc35gmperlkbi> X-Phabricator-Cc: <PHID-MLST-wkxaantg3q6pgdkty5pt> X-Phabricator-Cc: <PHID-USER-aeabc4ipqbifny3rw4ok> X-Phabricator-Cc: <PHID-USER-zqxtb3oi4pouwxnxlv3f> X-Phabricator-Cc: <PHID-USER-cknqtm2dzw7twnwyiaye> RECIPIENTS ! dog (dog) - This user is disabled; disabled users do not receive mail. BODY epriestley has commented on the revision "quack quack". zxcbzxcb REVISION DETAIL http://local.aphront.com:8080/D22 To: epriestley Cc: Unknown User, dog, list, duck, epriestley992, asana Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3306 Differential Revision: https://secure.phabricator.com/D6423
2013-07-11 03:52:22 +02:00
'PhabricatorMailManagementListOutboundWorkflow' => 'applications/metamta/management/PhabricatorMailManagementListOutboundWorkflow.php',
Move mail "Receive Test" from web UI to CLI Summary: Ref T3306. Moves this from the web to the CLI, which is a tiny bit clunkier but way better as far as policies go and more repeatable for development. See discussion in D6413. Test Plan: Ran `bin/mail receive-test`, verified mail was received. Used and abused various options. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3306 Differential Revision: https://secure.phabricator.com/D6417
2013-07-11 00:13:24 +02:00
'PhabricatorMailManagementReceiveTestWorkflow' => 'applications/metamta/management/PhabricatorMailManagementReceiveTestWorkflow.php',
Introduce basic `bin/mail` with a `resend` workflow Summary: Fixes T2458. Ref T2843. @tido's email from T2843 has exhausted its retries and failed, but we want to try it again with the patch from D5464 to capture the actual error. This sort of thing has come up a few times in debugging, too. Also fixed some stuff that came up while debugging this. Test Plan: - Ran command with no args. - Ran resend with no args. - Ran resend with bad IDs. - Ran resend with already-queued messages, got "already queued" error. - Ran resend with already-sent message, got requeue. Reviewers: btrahan, tido Reviewed By: tido CC: aran Maniphest Tasks: T2458, T2843 Differential Revision: https://secure.phabricator.com/D5493
2013-03-30 23:53:49 +01:00
'PhabricatorMailManagementResendWorkflow' => 'applications/metamta/management/PhabricatorMailManagementResendWorkflow.php',
Move "send test" to bin/mail Summary: Like D6417. See D6413. Test Plan: >>> orbital ~/devtools/phabricator $ echo "hello" | ./bin/mail send-test --to dog --cc duck --from epriestley --subject 'hey there' --attach README --tag blip --tag bloop Reading message body from stdin... Mail sent! You can view details by running this command: phabricator/ $ ./bin/mail show-outbound --id 6480 >>> orbital ~/devtools/phabricator $ ./bin/mail show-outbound --id 6480 PROPERTIES ID: 6480 Status: sent Retry Count: 0 Next Retry: 1373493443 Related PHID: Message: PARAMETERS to: ["PHID-USER-cluwcdowc35gmperlkbi"] cc: ["PHID-USER-aeabc4ipqbifny3rw4ok"] subject: hey there is-html: is-bulk: mailtags: ["blip","bloop"] from: PHID-USER-lqiz3yd7wmk64ejugvov worker-task: 936543 BODY hello Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6419
2013-07-11 00:18:24 +02:00
'PhabricatorMailManagementSendTestWorkflow' => 'applications/metamta/management/PhabricatorMailManagementSendTestWorkflow.php',
Provide some diagnostic tools for examining inbound and outbound mail Summary: We can't show this stuff on the web UI because it has password reset links and private reply-to addresses, but we can provide easier CLI tools than "root around in the database". Land a rough version of `bin/mail show-inbound` and `bin/mail show-outbound`. Test Plan: Used both commands to examine mail from the CLI. Reviewers: btrahan Reviewed By: btrahan CC: tido, euresti, aran Differential Revision: https://secure.phabricator.com/D5963
2013-05-20 19:13:42 +02:00
'PhabricatorMailManagementShowInboundWorkflow' => 'applications/metamta/management/PhabricatorMailManagementShowInboundWorkflow.php',
'PhabricatorMailManagementShowOutboundWorkflow' => 'applications/metamta/management/PhabricatorMailManagementShowOutboundWorkflow.php',
Add a rough `bin/mail volume` command for showing mail volume Summary: Ref T7013. This might help us understand the problem better. Test Plan: ``` $ ./bin/mail volume +==============+============+ | User | Unfiltered | +==============+============+ | admin | 136 | | dog | 31 | | epriestley | 24 | | ducksey | 18 | | saurus | 8 | | example-list | 7 | | squeakybirdo | 3 | | nnn | 3 | | facebooker | 2 | +==============+============+ Mail sent in the last 30 days. "Unfiltered" is raw volume before preferences were applied. ``` Reviewers: chad Reviewed By: chad Maniphest Tasks: T7013 Differential Revision: https://secure.phabricator.com/D13813
2015-08-06 20:32:17 +02:00
'PhabricatorMailManagementVolumeWorkflow' => 'applications/metamta/management/PhabricatorMailManagementVolumeWorkflow.php',
Introduce basic `bin/mail` with a `resend` workflow Summary: Fixes T2458. Ref T2843. @tido's email from T2843 has exhausted its retries and failed, but we want to try it again with the patch from D5464 to capture the actual error. This sort of thing has come up a few times in debugging, too. Also fixed some stuff that came up while debugging this. Test Plan: - Ran command with no args. - Ran resend with no args. - Ran resend with bad IDs. - Ran resend with already-queued messages, got "already queued" error. - Ran resend with already-sent message, got requeue. Reviewers: btrahan, tido Reviewed By: tido CC: aran Maniphest Tasks: T2458, T2843 Differential Revision: https://secure.phabricator.com/D5493
2013-03-30 23:53:49 +01:00
'PhabricatorMailManagementWorkflow' => 'applications/metamta/management/PhabricatorMailManagementWorkflow.php',
Add basic support for Herald outbound rules Summary: Ref T5791. This is still very basic (no global actions, no support for matching headers/bodies/recipients/etc) but gets the core in. Test Plan: {F715209} {F715211} Reviewers: chad Reviewed By: chad Maniphest Tasks: T5791 Differential Revision: https://secure.phabricator.com/D13897
2015-08-15 19:54:33 +02:00
'PhabricatorMailOutboundMailHeraldAdapter' => 'applications/metamta/herald/PhabricatorMailOutboundMailHeraldAdapter.php',
'PhabricatorMailOutboundRoutingHeraldAction' => 'applications/metamta/herald/PhabricatorMailOutboundRoutingHeraldAction.php',
'PhabricatorMailOutboundRoutingSelfEmailHeraldAction' => 'applications/metamta/herald/PhabricatorMailOutboundRoutingSelfEmailHeraldAction.php',
'PhabricatorMailOutboundRoutingSelfNotificationHeraldAction' => 'applications/metamta/herald/PhabricatorMailOutboundRoutingSelfNotificationHeraldAction.php',
Consolidate outbound mail status in a new class Summary: Ref T5791. This collects outbound mail status in one place and makes the list view a little spiffier. Test Plan: Looked at list and detail views. Grepped for changed classes/constants. Reviewers: chad Reviewed By: chad Maniphest Tasks: T5791 Differential Revision: https://secure.phabricator.com/D13884
2015-08-14 13:31:42 +02:00
'PhabricatorMailOutboundStatus' => 'applications/metamta/constants/PhabricatorMailOutboundStatus.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorMailReceiver' => 'applications/metamta/receiver/PhabricatorMailReceiver.php',
Add unit tests to cover PhabricatorMailReceiver::matchAddresses() Summary: Ref T3183. We should accept addresses like `"New Bug" <bugs@example.com>` to match `bugs@example.com`. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3183 Differential Revision: https://secure.phabricator.com/D5923
2013-05-15 00:04:17 +02:00
'PhabricatorMailReceiverTestCase' => 'applications/metamta/receiver/__tests__/PhabricatorMailReceiverTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMailReplyHandler' => 'applications/metamta/replyhandler/PhabricatorMailReplyHandler.php',
Add basic support for Herald outbound rules Summary: Ref T5791. This is still very basic (no global actions, no support for matching headers/bodies/recipients/etc) but gets the core in. Test Plan: {F715209} {F715211} Reviewers: chad Reviewed By: chad Maniphest Tasks: T5791 Differential Revision: https://secure.phabricator.com/D13897
2015-08-15 19:54:33 +02:00
'PhabricatorMailRoutingRule' => 'applications/metamta/constants/PhabricatorMailRoutingRule.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorMailSetupCheck' => 'applications/config/check/PhabricatorMailSetupCheck.php',
Build separate mail for each recipient, honoring recipient access levels Summary: Ref T6367. Removes `multiplexMail()`! We can't pass a single body into a function which splits it anymore: we need to split recipients first, then build bodies for each recipient list. This lets us build separate bodies for each recipient's individual translation/access levels. The new logic does this: - First, split recipients into groups called "targets". - Each target corresponds to one actual mail we're going to build. - Each target has a viewer (whose translation / access levels will be used to generate the mail). - Each target has a to/cc list (the users who we'll ultimately send the mail to). - For each target, build a custom mail body based on the viewer's access levels and settings (language prefs not actually implemented). - Then, deliver the mail. Test Plan: - Read new config help. Then did a bunch of testing, primarily with `bin/mail list-outbound` and `bin/mail show-outbound` (to review generated mail), `bin/phd debug taskmaster` (to run daemons freely) and `bin/worker execute --id <id>` (to repeatedly test a specific piece of code after identifying an issue). With `one-mail-per-recipient` on (default): - Sent mail to multiple users. - Verified mail showed up in `mail list-outbound`. - Examined mail with `mail show-outbound`. - Added a project that a subscriber could not see. - Verified it was not present in `X-Phabricator-Projects`. - Verified it was rendered as "Restricted Project" for the non-permissioned viewer. - Added a subscriber, then changed the object policy so they could not see it and sent mail. - Verified I received mail but the other user did not. - Enabled public replies and verified mail generated with public addresses. - Disabld public replies and verified mail generated with private addresses. With `one-mail-per-recipient` off: - Verified that one mail is sent to all recipients. - Verified users who can not see the object are still filtered. - Verified that partially-visible projects are completely visible in the mail (this violates policies, as documented, as the best available compromise). - Enabled public replies and verified the mail generated with "Reply To". Reviewers: btrahan Reviewed By: btrahan Subscribers: carlsverre, epriestley Maniphest Tasks: T6367 Differential Revision: https://secure.phabricator.com/D13131
2015-06-02 23:29:30 +02:00
'PhabricatorMailTarget' => 'applications/metamta/replyhandler/PhabricatorMailTarget.php',
Mailgun receive support Summary: As you've suggested, I took the SendGrid code and massaged it until it played nice with Mailgun. btw - unless I'm missing something, it appears that the SendGrid receiver lets you spoof emails (it performs no validation on the data received). Test Plan: Opened a task with Mailgun. Felt great. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4326 Differential Revision: https://secure.phabricator.com/D7989
2014-01-21 19:36:33 +01:00
'PhabricatorMailgunConfigOptions' => 'applications/config/option/PhabricatorMailgunConfigOptions.php',
Begin modularizing main menu items Summary: Ref T10077. Ref T8918. The way the main menu is built is not very modular and fairly hacky. It assumes menus are provided by applications, but this isn't exactly true. Notably, the "Quick Create" menu is not per-application. The current method of building this menu is very inefficient (see T10077). Particularly, we have to build it //twice// because we need to build it once to render the item and then again to render the dropdown options. Start cleaning this up. This diff doesn't actually have any behavioral changes, since I can't swap the menu over until we get rid of all the other items and I haven't extended this to Notifications/Conpherence yet so it doesn't actually fix T8918. Test Plan: Viewed menus while logged in, logged out, in different applications, in desktop/mobile. Nothing appeared different. Reviewers: chad Reviewed By: chad Maniphest Tasks: T8918, T10077 Differential Revision: https://secure.phabricator.com/D14922
2016-01-01 13:26:36 +01:00
'PhabricatorMainMenuBarExtension' => 'view/page/menu/PhabricatorMainMenuBarExtension.php',
Switch to new menubar Summary: - Looks better (can probably still use some tweaks), especially search. - Moves logout from weird footer location to main menu. - Reactive: on tablets and phones, the menu adjusts to remain useful. - Fixed position on desktops for future side nav changes. - Adds an icon header thing that's currently hard-coded but will be application-driven soon. Test Plan: Used menu on desktop, tablet, phone, logged in / logged out, toggled darkconsole. Will add some screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3105
2012-07-31 01:09:14 +02:00
'PhabricatorMainMenuSearchView' => 'view/page/menu/PhabricatorMainMenuSearchView.php',
'PhabricatorMainMenuView' => 'view/page/menu/PhabricatorMainMenuView.php',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorManagementWorkflow' => 'infrastructure/management/PhabricatorManagementWorkflow.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorManiphestApplication' => 'applications/maniphest/application/PhabricatorManiphestApplication.php',
Port Maniphest options. Test Plan: Viewed the new options. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4401
2013-01-11 19:24:35 +01:00
'PhabricatorManiphestConfigOptions' => 'applications/maniphest/config/PhabricatorManiphestConfigOptions.php',
Fixed Task Generation Summary: Ref T2903 Test Plan: Successfully generated tasks with authors and owners. Reviewers: epriestley, AnhNhan Reviewed By: epriestley CC: aran, Korvin, AnhNhan, chad Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5704
2013-04-25 03:17:30 +02:00
'PhabricatorManiphestTaskTestDataGenerator' => 'applications/maniphest/lipsum/PhabricatorManiphestTaskTestDataGenerator.php',
Add a generic multistep Markup cache Summary: The immediate issue this addresses is T1366, adding a rendering cache to Phriction. For wiki pages with code blocks especially, rerendering them each time is expensive. The broader issue is that out markup caches aren't very good right now. They have three major problems: **Problem 1: the data is stored in the wrong place.** We currently store remarkup caches on objects. This means we're always loading it and passing it around even when we don't need it, can't genericize cache management code (e.g., have one simple script to drop/GC caches), need to update authoritative rows to clear caches, and can't genericize rendering code since each object is different. To solve this, I created a dedicated cache database that I plan to move all markup caches to use. **Problem 2: time-variant rules break when cached.** Some rules like `**bold**` are time-invariant and always produce the same output, but some rules like `{Tnnn}` and `@username` are variant and may render differently (because a task was closed or a user is on vacation). Currently, we cache the raw output, so these time-variant rules get locked at whatever values they had when they were first rendered. This is the main reason Phriction doesn't have a cache right now -- I wanted `{Tnnn}` rules to reflect open/closed tasks. To solve this, I split markup into a "preprocessing" phase (which does all the parsing and evaluates all time-invariant rules) and a "postprocessing" phase (which evaluates time-variant rules only). The preprocessing phase is most of the expense (and, notably, includes syntax highlighting) so this is nearly as good as caching the final output. I did most of the work here in D737 / D738, but we never moved to use it in Phabricator -- we currently just do the two operations serially in all cases. This diff splits them apart and caches the output of preprocessing only, so we benefit from caching but also get accurate time-variant rendering. **Problem 3: cache access isn't batched/pipelined optimally.** When we're rendering a list of markup blocks, we should be able to batch datafetching better than we do. D738 helped with this (fetching is batched within a single hunk of markup) and this improves batching on cache access. We could still do better here, but this is at least a step forward. Also fixes a bug with generating a link in the Phriction history interface ($uri gets clobbered). I'm using PHP serialization instead of JSON serialization because Remarkup does some stuff with non-ascii characters that might not survive JSON. Test Plan: - Created a Phriction document and verified that previews don't go to cache (no rows appear in the cache table). - Verified that published documents come out of cache. - Verified that caches generate/regenerate correctly, time-variant rules render properly and old documents hit the right caches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1366 Differential Revision: https://secure.phabricator.com/D2945
2012-07-10 00:20:56 +02:00
'PhabricatorMarkupCache' => 'applications/cache/storage/PhabricatorMarkupCache.php',
Minor, move all remarkup code to src/infrastructure/markup/
2012-07-02 19:44:37 +02:00
'PhabricatorMarkupEngine' => 'infrastructure/markup/PhabricatorMarkupEngine.php',
Add a generic multistep Markup cache Summary: The immediate issue this addresses is T1366, adding a rendering cache to Phriction. For wiki pages with code blocks especially, rerendering them each time is expensive. The broader issue is that out markup caches aren't very good right now. They have three major problems: **Problem 1: the data is stored in the wrong place.** We currently store remarkup caches on objects. This means we're always loading it and passing it around even when we don't need it, can't genericize cache management code (e.g., have one simple script to drop/GC caches), need to update authoritative rows to clear caches, and can't genericize rendering code since each object is different. To solve this, I created a dedicated cache database that I plan to move all markup caches to use. **Problem 2: time-variant rules break when cached.** Some rules like `**bold**` are time-invariant and always produce the same output, but some rules like `{Tnnn}` and `@username` are variant and may render differently (because a task was closed or a user is on vacation). Currently, we cache the raw output, so these time-variant rules get locked at whatever values they had when they were first rendered. This is the main reason Phriction doesn't have a cache right now -- I wanted `{Tnnn}` rules to reflect open/closed tasks. To solve this, I split markup into a "preprocessing" phase (which does all the parsing and evaluates all time-invariant rules) and a "postprocessing" phase (which evaluates time-variant rules only). The preprocessing phase is most of the expense (and, notably, includes syntax highlighting) so this is nearly as good as caching the final output. I did most of the work here in D737 / D738, but we never moved to use it in Phabricator -- we currently just do the two operations serially in all cases. This diff splits them apart and caches the output of preprocessing only, so we benefit from caching but also get accurate time-variant rendering. **Problem 3: cache access isn't batched/pipelined optimally.** When we're rendering a list of markup blocks, we should be able to batch datafetching better than we do. D738 helped with this (fetching is batched within a single hunk of markup) and this improves batching on cache access. We could still do better here, but this is at least a step forward. Also fixes a bug with generating a link in the Phriction history interface ($uri gets clobbered). I'm using PHP serialization instead of JSON serialization because Remarkup does some stuff with non-ascii characters that might not survive JSON. Test Plan: - Created a Phriction document and verified that previews don't go to cache (no rows appear in the cache table). - Verified that published documents come out of cache. - Verified that caches generate/regenerate correctly, time-variant rules render properly and old documents hit the right caches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1366 Differential Revision: https://secure.phabricator.com/D2945
2012-07-10 00:20:56 +02:00
'PhabricatorMarkupInterface' => 'infrastructure/markup/PhabricatorMarkupInterface.php',
Provide a concrete class for one-off remarkup blocks Summary: I want to use some of these for instructional text in Diffusion. Provide a concrete class to make one-offs cacheable and switch Releeph to use it. Test Plan: {F44175} Reviewers: btrahan, chad, edward Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6032
2013-05-24 21:37:53 +02:00
'PhabricatorMarkupOneOff' => 'infrastructure/markup/PhabricatorMarkupOneOff.php',
Partially generalize Remarkup previews and add support to Differential Summary: Ref T3671. A lot of applications have pretty ad-hoc preview code. Clean it up a bit and add Summary preview to Differential. After ApplicationTransactions we might want to try to serialize the whole form and show a preview of all the transactions, but this seems not very useful in most cases (I'd guess that Remarkup previews are 99% of the value) and tricky to get right (e.g., adding images which don't exist yet to Pholio mocks). I think I can add this in a few other places, too. Test Plan: Edited Maniphest Tasks and Differential Revisions, mashed some buttons. Verified previews rendered correctly. Grepped for removed CSS classes (no hits). {F52907} Reviewers: btrahan, Firehed Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T3671 Differential Revision: https://secure.phabricator.com/D6673
2013-08-05 19:46:39 +02:00
'PhabricatorMarkupPreviewController' => 'infrastructure/markup/PhabricatorMarkupPreviewController.php',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhabricatorMemeRemarkupRule' => 'applications/macro/markup/PhabricatorMemeRemarkupRule.php',
'PhabricatorMentionRemarkupRule' => 'applications/people/markup/PhabricatorMentionRemarkupRule.php',
Transactions - add infrastructure for "mentions" Summary: Fixes T4036. Now if you say something on diff X like "This reminds me of Tx and Dy and commitHashFoo and Px." each of those objects gets a little visible transaction that the mention occurred. No feed, email, or notifications. Test Plan: made a comment like above and verified transactions. also submitted a diff that "Fixes Tx" and Tx did not get the transaction as expected. Reviewers: epriestley Reviewed By: epriestley Subscribers: joshuaspence, epriestley, Korvin Maniphest Tasks: T4036 Differential Revision: https://secure.phabricator.com/D10451
2014-09-09 23:21:13 +02:00
'PhabricatorMentionableInterface' => 'applications/transactions/interface/PhabricatorMentionableInterface.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMercurialGraphStream' => 'applications/repository/daemon/PhabricatorMercurialGraphStream.php',
Show why recipients were excluded from mail Summary: Ref T3306. This interface has a hard time balancing security/policy issues and I'm not sure what the best way forward is. Some possibilities: # We just let you see everything from the web UI. - This makes debugging easier. - Anyone who can see this stuff can trivially take over any user's account with five seconds of work and no technical expertise (reset their password from the web UI, then go read the email and click the link). # We let you see everything, but only for messages you were a recipient of or author of. - This makes it much more difficult to debug issues with mailing lists. - But maybe we could just say mailing list recipients are "public", or define some other ruleset. - Generally this gets privacy and ease of use right. # We could move the whole thing to the CLI. - Makes the UI/UX way worse. # We could strike an awkward balance between concerns, as we do now. - We expose //who// sent and received messages, but not the content of the messages. This doesn't feel great. I'm inclined to probably go with (2) and figure something out for mailing lists? Anyway, irrespective of that this should generally make things more clear, and improves the code a lot if nothing else. Test Plan: {F49546} - Looked at a bunch of mail. - Sent mail from different apps. - Checked that recipients seem correct. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3306 Differential Revision: https://secure.phabricator.com/D6413
2013-07-11 00:17:38 +02:00
'PhabricatorMetaMTAActor' => 'applications/metamta/query/PhabricatorMetaMTAActor.php',
'PhabricatorMetaMTAActorQuery' => 'applications/metamta/query/PhabricatorMetaMTAActorQuery.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorMetaMTAApplication' => 'applications/metamta/application/PhabricatorMetaMTAApplication.php',
MetaMTA - add (basic) application emails and deploy to Maniphest Summary: Ref T5952, T3404. This lays the basic plumbing for how this will work, all the way to deploying on Maniphest. Aside from what is mentioned on T5952, I think page(s) on editing application emails could use a little more helpful text about what's going on, similar to how the config page that's getting deprecated works. Test Plan: ran migration and noted my create email address migrated successfully. used bin/mail to make a task. added another email and used bin/mail to make a task. deleted an email. edited an email. invoked various error states and they all looked good. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T3404, T5952 Differential Revision: https://secure.phabricator.com/D11418
2015-01-20 01:07:26 +01:00
'PhabricatorMetaMTAApplicationEmail' => 'applications/metamta/storage/PhabricatorMetaMTAApplicationEmail.php',
Application Emails - add datasource so we can have a typeahead Summary: Ref T5039. This will be necessary for Herald integration so users can make rules like "if app email is one of x, y, or z add projects foo, bar, and metallica." I think its best to do an actual typeahead here -- users select full email addresses -- rather than support prefix, suffix, etc stuff on the email address. I think the latter approach would yield lots of confusion, as well as prevent us from (more) easily providing diagnostic tools about what happened when and why. Test Plan: hacked a maniphest tokenizer to use this new datasource and it worked Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5039 Differential Revision: https://secure.phabricator.com/D11546
2015-01-28 23:35:42 +01:00
'PhabricatorMetaMTAApplicationEmailDatasource' => 'applications/metamta/typeahead/PhabricatorMetaMTAApplicationEmailDatasource.php',
Use ApplicationTransactions in ApplicationEmail Summary: Ref T8498. I want to add Spaces to these, and the logic for getting Spaces right is a bit tricky, so swap these to ApplicationTransactions. One new piece of tech: made it easier for Editors to raise DuplicateKeyException as a normal ValidationException, so callers don't have to handle this case specially. One behavioral change: we no longer require these addresses to be at the `auth.email-domains` domains -- I think this wasn't quite right in the general case. It's OK to require users to have `@mycompany.com` addresses but add `@phabricator.mycompany-infrastructure.com` addresses here if you want. Test Plan: - Tried to create a duplicate email. - Tried to create an empty email. - Tried to create an invalid email. - Created a new email. - Deleted an email. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8498 Differential Revision: https://secure.phabricator.com/D13246
2015-06-11 19:15:49 +02:00
'PhabricatorMetaMTAApplicationEmailEditor' => 'applications/metamta/editor/PhabricatorMetaMTAApplicationEmailEditor.php',
Modularize Application Email Herald field Summary: Ref T8726. There's no interface we can check for this, so the adapter needs to opt in. Also fix a spelling mistake. Test Plan: Created rules with "Application Email" fields. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13499
2015-07-06 22:16:26 +02:00
'PhabricatorMetaMTAApplicationEmailHeraldField' => 'applications/metamta/herald/PhabricatorMetaMTAApplicationEmailHeraldField.php',
MetaMTA - add (basic) application emails and deploy to Maniphest Summary: Ref T5952, T3404. This lays the basic plumbing for how this will work, all the way to deploying on Maniphest. Aside from what is mentioned on T5952, I think page(s) on editing application emails could use a little more helpful text about what's going on, similar to how the config page that's getting deprecated works. Test Plan: ran migration and noted my create email address migrated successfully. used bin/mail to make a task. added another email and used bin/mail to make a task. deleted an email. edited an email. invoked various error states and they all looked good. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T3404, T5952 Differential Revision: https://secure.phabricator.com/D11418
2015-01-20 01:07:26 +01:00
'PhabricatorMetaMTAApplicationEmailPHIDType' => 'applications/phid/PhabricatorMetaMTAApplicationEmailPHIDType.php',
Modularize application configuration panels Summary: Ref T7149. This is a few steps away, but: - Generally, I'd like to reduce the amount of "Config" configuration we have. - One good way to do this is to move it into UIs in Application configuration. We did this with email recently. - I think this was a great change and I'd like to keep moving in this direction. - T7149 touches configuration related to file storage engines. Although I'm not planning to fully move configuration into applications yet, it would be easier to debug and test if I could drop a read-only panel there to show engines. - So, modularize the config stuff so I can add a new panel without hard-coding it. Test Plan: - Added, edited, and deleted application emails. - Viewed non-email application detail pages. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12051
2015-03-12 21:28:37 +01:00
'PhabricatorMetaMTAApplicationEmailPanel' => 'applications/metamta/applicationpanel/PhabricatorMetaMTAApplicationEmailPanel.php',
MetaMTA - add (basic) application emails and deploy to Maniphest Summary: Ref T5952, T3404. This lays the basic plumbing for how this will work, all the way to deploying on Maniphest. Aside from what is mentioned on T5952, I think page(s) on editing application emails could use a little more helpful text about what's going on, similar to how the config page that's getting deprecated works. Test Plan: ran migration and noted my create email address migrated successfully. used bin/mail to make a task. added another email and used bin/mail to make a task. deleted an email. edited an email. invoked various error states and they all looked good. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T3404, T5952 Differential Revision: https://secure.phabricator.com/D11418
2015-01-20 01:07:26 +01:00
'PhabricatorMetaMTAApplicationEmailQuery' => 'applications/metamta/query/PhabricatorMetaMTAApplicationEmailQuery.php',
Use ApplicationTransactions in ApplicationEmail Summary: Ref T8498. I want to add Spaces to these, and the logic for getting Spaces right is a bit tricky, so swap these to ApplicationTransactions. One new piece of tech: made it easier for Editors to raise DuplicateKeyException as a normal ValidationException, so callers don't have to handle this case specially. One behavioral change: we no longer require these addresses to be at the `auth.email-domains` domains -- I think this wasn't quite right in the general case. It's OK to require users to have `@mycompany.com` addresses but add `@phabricator.mycompany-infrastructure.com` addresses here if you want. Test Plan: - Tried to create a duplicate email. - Tried to create an empty email. - Tried to create an invalid email. - Created a new email. - Deleted an email. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8498 Differential Revision: https://secure.phabricator.com/D13246
2015-06-11 19:15:49 +02:00
'PhabricatorMetaMTAApplicationEmailTransaction' => 'applications/metamta/storage/PhabricatorMetaMTAApplicationEmailTransaction.php',
'PhabricatorMetaMTAApplicationEmailTransactionQuery' => 'applications/metamta/query/PhabricatorMetaMTAApplicationEmailTransactionQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMetaMTAAttachment' => 'applications/metamta/storage/PhabricatorMetaMTAAttachment.php',
Implement all remaining config options Summary: Resolves T2255. Test Plan: Looked at mail options. Saw no remaining "Setup Issues". Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4477
2013-01-17 00:06:39 +01:00
'PhabricatorMetaMTAConfigOptions' => 'applications/config/option/PhabricatorMetaMTAConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMetaMTAController' => 'applications/metamta/controller/PhabricatorMetaMTAController.php',
'PhabricatorMetaMTADAO' => 'applications/metamta/storage/PhabricatorMetaMTADAO.php',
Add another pattern to quoted email body stripping Summary: Ref T3217. @hlau has an email client which quotes text with: ________________________________________ From: ... Add a regular expression to correctly detect this as quoted body text. Test Plan: Add unit test; executed unit test. Reviewers: btrahan, chad Reviewed By: chad CC: hlau, aran Maniphest Tasks: T3217 Differential Revision: https://secure.phabricator.com/D5986
2013-05-21 00:52:54 +02:00
'PhabricatorMetaMTAEmailBodyParser' => 'applications/metamta/parser/PhabricatorMetaMTAEmailBodyParser.php',
'PhabricatorMetaMTAEmailBodyParserTestCase' => 'applications/metamta/parser/__tests__/PhabricatorMetaMTAEmailBodyParserTestCase.php',
Modularize "Send an Email" Herald actions Summary: Ref T8726. No surprises. Test Plan: Created rules using both action variants, applied upgrade, saw rules still work correctly. {F658842} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13701
2015-07-24 17:19:47 +02:00
'PhabricatorMetaMTAEmailHeraldAction' => 'applications/metamta/herald/PhabricatorMetaMTAEmailHeraldAction.php',
'PhabricatorMetaMTAEmailOthersHeraldAction' => 'applications/metamta/herald/PhabricatorMetaMTAEmailOthersHeraldAction.php',
'PhabricatorMetaMTAEmailSelfHeraldAction' => 'applications/metamta/herald/PhabricatorMetaMTAEmailSelfHeraldAction.php',
When we fail to process mail, tell the user about it Summary: Ref T4371. Ref T4699. Fixes T3994. Currently, we're very conservative about sending errors back to users. A concern I had about this was that mistakes could lead to email loops, massive amounts of email spam, etc. Because of this, I was pretty hesitant about replying to email with more email when I wrote this stuff. However, this was a long time ago. We now have Message-ID deduplication, "X-Phabricator-Sent-This-Mail", generally better mail infrastructure, and rate limiting. Together, these mechanisms should reasonably prevent anything crazy (primarily, infinite email loops) from happening. Thus: - When we hit any processing error after receiving a mail, try to send the author a reply with details about what went wrong. These are limited to 6 per hour per address. - Rewrite most of the errors to be more detailed and informative. - Rewrite most of the errors in a user-facing voice ("You sent this mail..." instead of "This mail was sent.."). - Remove the redundant, less sophisticated code which does something similar in Differential. Test Plan: - Using `scripts/mail/mail_receiver.php`, artificially received a pile of mail. - Hit a bunch of different errors. - Saw reasonable error mail get sent to me. - Saw other reasonable error mail get rate limited. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3994, T4371, T4699 Differential Revision: https://secure.phabricator.com/D8692
2014-04-04 03:43:18 +02:00
'PhabricatorMetaMTAErrorMailAction' => 'applications/metamta/action/PhabricatorMetaMTAErrorMailAction.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMetaMTAMail' => 'applications/metamta/storage/PhabricatorMetaMTAMail.php',
Centralize rendering of application mail bodies Summary: This is a minor quality-of-life improvement to prevent D2968 from being as nasty as it is. Test Plan: Ran unit tests; generated Differential, Maniphest and Diffusion emails and verified the bodies looked sensible. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran Maniphest Tasks: T931 Differential Revision: https://secure.phabricator.com/D2986
2012-07-17 04:01:43 +02:00
'PhabricatorMetaMTAMailBody' => 'applications/metamta/view/PhabricatorMetaMTAMailBody.php',
'PhabricatorMetaMTAMailBodyTestCase' => 'applications/metamta/view/__tests__/PhabricatorMetaMTAMailBodyTestCase.php',
MetaMTA - more progress towards a mail application Summary: Ref T5791. This diff does a few things... - Adds code to write recipients to edges on save - Makes Query performance for policy filtering okay-ish - Adds a Search Engine for PhabricatorMetaMTAMail - Adds "working" List Controller - Inbox and Outbox both work - Adds stub View Controller Test Plan: ran `./bin/storage upgrade` and saw my inbox and outbox start getting data. played with application and saw new entries in inbox and outbox Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5791 Differential Revision: https://secure.phabricator.com/D13397
2015-06-23 20:37:14 +02:00
'PhabricatorMetaMTAMailHasRecipientEdgeType' => 'applications/metamta/edge/PhabricatorMetaMTAMailHasRecipientEdgeType.php',
'PhabricatorMetaMTAMailListController' => 'applications/metamta/controller/PhabricatorMetaMTAMailListController.php',
MetaMTA - lay some ground work for having an application Summary: Ref T5791. This does a few bits there. Namely: - Adds PHID column to PhabricatorMetaMTAMail - Implements a PhabricatorMetaMTAMailPHIDType - Script to backpopulate them. - Makes PhabricatorMetaMTAMail implement PolicyInterface. - View policy is NOONE and the author and recipients have automatic view capabilities - No edit capability. - Adds a PhabricatorMetaMTAMailQuery for PhabricatorMetaMTAMail. Test Plan: ran `./bin/storage upgrade` successfully. commented on a maniphest task and verifed the metamta mail object in the database was created successfully with a shiny new phid Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5791 Differential Revision: https://secure.phabricator.com/D13394
2015-06-22 22:46:26 +02:00
'PhabricatorMetaMTAMailPHIDType' => 'applications/metamta/phid/PhabricatorMetaMTAMailPHIDType.php',
'PhabricatorMetaMTAMailQuery' => 'applications/metamta/query/PhabricatorMetaMTAMailQuery.php',
MetaMTA - more progress towards a mail application Summary: Ref T5791. This diff does a few things... - Adds code to write recipients to edges on save - Makes Query performance for policy filtering okay-ish - Adds a Search Engine for PhabricatorMetaMTAMail - Adds "working" List Controller - Inbox and Outbox both work - Adds stub View Controller Test Plan: ran `./bin/storage upgrade` and saw my inbox and outbox start getting data. played with application and saw new entries in inbox and outbox Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5791 Differential Revision: https://secure.phabricator.com/D13397
2015-06-23 20:37:14 +02:00
'PhabricatorMetaMTAMailSearchEngine' => 'applications/metamta/query/PhabricatorMetaMTAMailSearchEngine.php',
HTML emails Summary: Added support for side-by-side HTML and plaintext email building. We can control if the HTML stuff is sent by by a new config, metamta.html-emails Test Plan: Been running this in our deployment for a few months now. ====Well behaved clients==== - Gmail - Mail.app ====Bad clients==== - [[ http://airmailapp.com/ | Airmail ]]. They confuse Gmail too, though. ====Need testing==== - Outlook (Windows + Mac) Reviewers: chad, #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: webframp, taoqiping, chad, epriestley, Korvin Maniphest Tasks: T992 Differential Revision: https://secure.phabricator.com/D9375
2014-08-15 17:04:10 +02:00
'PhabricatorMetaMTAMailSection' => 'applications/metamta/view/PhabricatorMetaMTAMailSection.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMetaMTAMailTestCase' => 'applications/metamta/storage/__tests__/PhabricatorMetaMTAMailTestCase.php',
MetaMTA - more progress towards a mail application Summary: Ref T5791. This diff does a few things... - Adds code to write recipients to edges on save - Makes Query performance for policy filtering okay-ish - Adds a Search Engine for PhabricatorMetaMTAMail - Adds "working" List Controller - Inbox and Outbox both work - Adds stub View Controller Test Plan: ran `./bin/storage upgrade` and saw my inbox and outbox start getting data. played with application and saw new entries in inbox and outbox Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5791 Differential Revision: https://secure.phabricator.com/D13397
2015-06-23 20:37:14 +02:00
'PhabricatorMetaMTAMailViewController' => 'applications/metamta/controller/PhabricatorMetaMTAMailViewController.php',
Modernize "mailable" typeahead datasources Summary: Ref T4420. Modernize the mailing list datasource, then build a composite "mailable" datasource. Test Plan: - Edited "subscribers" field in Differential revision edit. - Edited "subscribers" field in Differential search. - Edited "add subscribers" field in differential revision view. - Edited "add ccs" field in Diffusion commit view. - Edited "add emails to CC" in a Herald rule. - Edited "add ccs" in maniphest bulk editor. - Edited "add ccs" in maniphest task detail view. - Edited "CC" on maniphest edit view. - Edited "subscribers" on maniphest task earch view. - Edited "CC" on pholio mock edit. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9886
2014-07-18 00:44:29 +02:00
'PhabricatorMetaMTAMailableDatasource' => 'applications/metamta/typeahead/PhabricatorMetaMTAMailableDatasource.php',
Add a "mailable" function datasource Summary: Ref T4100. Add a function datasource for filtering mailable objects (e.g., subscribers). Test Plan: Searched for objects with "Current Viewer", "Members: Dog Project", etc., as a subscriber in global search. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12524
2015-04-23 12:34:33 +02:00
'PhabricatorMetaMTAMailableFunctionDatasource' => 'applications/metamta/typeahead/PhabricatorMetaMTAMailableFunctionDatasource.php',
Mailgun receive support Summary: As you've suggested, I took the SendGrid code and massaged it until it played nice with Mailgun. btw - unless I'm missing something, it appears that the SendGrid receiver lets you spoof emails (it performs no validation on the data received). Test Plan: Opened a task with Mailgun. Felt great. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4326 Differential Revision: https://secure.phabricator.com/D7989
2014-01-21 19:36:33 +01:00
'PhabricatorMetaMTAMailgunReceiveController' => 'applications/metamta/controller/PhabricatorMetaMTAMailgunReceiveController.php',
Expand aggregate email recipients prior to multiplexing Summary: Ref T4361. Before we figure out which To/CC are addressable, try to expand To/CC. Specifically, the supported expansion right now is project PHIDs expanding to all their members. Because of the way multiplexing works, we have to do this in two places: explicitly in `multiplexMail()`, and when sending mail that wasn't multiplexed. This is messy; eventually we can get rid of it (after ApplicationTransactions are everywhere). This has some rough edges, but should basically give us what we need to make stuff like projects mailable. Particularly, it deals with most issues in D7436: - I got around the resolution/multiplexing issue by resolving aggregate mailables separately from mailable actors. - We get to keep the Project PHID as a To/CC/Reviewer/Whatever until the last second. - Users won't get two emails for being a CC and also a member of a CC'd project. - We can degrade to the list stuff this way if we want, by having the project aggregate yield a single list PHID. Test Plan: Added a comment to a revision with a project reviewer, got mail to all the project's members. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4361 Differential Revision: https://secure.phabricator.com/D8117
2014-02-01 23:35:55 +01:00
'PhabricatorMetaMTAMemberQuery' => 'applications/metamta/query/PhabricatorMetaMTAMemberQuery.php',
Allow MetaMTA adapters to indicate that a mail is permanently undeliverable Summary: Currently, adapters can only fail mail temporarily. Allow them to indicate a permanent failure by throwing a special exception. Test Plan: Added and ran unit tests. Reviewers: wez, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6847
2013-08-30 17:21:50 +02:00
'PhabricatorMetaMTAPermanentFailureException' => 'applications/metamta/exception/PhabricatorMetaMTAPermanentFailureException.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMetaMTAReceivedMail' => 'applications/metamta/storage/PhabricatorMetaMTAReceivedMail.php',
Begin improving the soundness of received mail Summary: We/I broke a couple of things here recently (see D5911) and are doing some work here in general (see D5912, etc.). Generally, this code is pretty oldschool and not especially well architected for modern application-oriented Phabricator. It hardcodes a lot of stuff which should be applications' responsibilites. Take the first steps toward making it more solid to reduce the risk here. In particular: - Factor out the "self mail" and "duplicate mail" checks and add unit tests. - Make Message-ID hash handling automatic. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5915
2013-05-14 01:32:19 +02:00
'PhabricatorMetaMTAReceivedMailProcessingException' => 'applications/metamta/exception/PhabricatorMetaMTAReceivedMailProcessingException.php',
'PhabricatorMetaMTAReceivedMailTestCase' => 'applications/metamta/storage/__tests__/PhabricatorMetaMTAReceivedMailTestCase.php',
Generate expected schemata for MetaMTA, Nuance, MetaData, OAuthServer Summary: Ref T1191. Handful of minor things here (T6150, T6149, T6148, T6147, T6146) but nothing very noteworthy. Test Plan: Viewed web UI, saw fewer errors. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10527
2014-09-24 22:50:00 +02:00
'PhabricatorMetaMTASchemaSpec' => 'applications/metamta/storage/PhabricatorMetaMTASchemaSpec.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMetaMTASendGridReceiveController' => 'applications/metamta/controller/PhabricatorMetaMTASendGridReceiveController.php',
'PhabricatorMetaMTAWorker' => 'applications/metamta/PhabricatorMetaMTAWorker.php',
Implement clock/trigger infrastructure for scheduling actions Summary: Ref T6881. Hopefully, this is the hard part. This adds a new daemon (the "trigger" daemon) which processes triggers, schedules them, and then executes them at the scheduled time. The design is a little complicated, but has these goals: - High resistance to race conditions: only the application writes to the trigger table; only the daemon writes to the event table. We won't lose events if someone saves a meeting at the same time as we're sending a reminder out for it. - Execution guarantees: scheduled events are guaranteed to execute exactly once. - Support for arbitrarily large queues: the daemon will make progress even if there are millions of triggers in queue. The cost to update the queue is proportional to the number of changes in it; the cost to process the queue is proportional to the number of events to execute. - Relatively good observability: you can monitor the state of the trigger queue reasonably well from the web UI. - Modular Infrastructure: this is a very low-level construct that Calendar, Phortune, etc., should be able to build on top of. It doesn't have this stuff yet: - Not very robust to bad actions: a misbehaving trigger can stop the queue fairly easily. This is OK for now since we aren't planning to make it part of any other applications for a while. We do still get execute-exaclty-once, but it might not happen for a long time (until someone goes and fixes the queue), when we could theoretically continue executing other events. - Doesn't start automatically: normal users don't need to run this thing yet so I'm not starting it by default. - Not super well tested: I've vetted the basics but haven't run real workloads through this yet. - No sophisticated tooling: I added some basic stuff but it's missing some pieces we'll have to build sooner or later, e.g. `bin/trigger cancel` or whatever. - Intentionally not realtime: This design puts execution guarantees far above realtime concerns, and will not give you precise event execution at 1-second resolution. I think this is the correct goal to pursue architecturally, and certainly correct for subscriptions and meeting reminders. Events which execute after they have become irrelevant can simply decline to do anything (like a meeting reminder which executes after the meeting is over). In general, the expectation for applications is: - When creating an object (like a calendar event) that needs to trigger a scheduled action, write a trigger (and save the PHID if you plan to update it later). - The daemon will process the event and schedule the action efficiently, in a race-free way. - If you want to move the action, update the trigger and the daemon will take care of it. - Your action will eventually dump a task into the task queue, and the task daemons will actually perform it. Test Plan: Using a test script like this: ``` <?php require_once 'scripts/__init_script__.php'; $trigger = id(new PhabricatorWorkerTrigger()) ->setAction( new PhabricatorLogTriggerAction( array( 'message' => 'test', ))) ->setClock( new PhabricatorMetronomicTriggerClock( array( 'period' => 33, ))) ->save(); var_dump($trigger); ``` ...I queued triggers and ran the daemon: - Verified triggers fire; - verified triggers reschedule; - verified trigger events show up in the web UI; - tried different periods; - added some triggers while the daemon was running; - examined `phd debug` output for anything suspicious. It seems to work in trivial use case, at least. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11419
2015-01-16 21:13:31 +01:00
'PhabricatorMetronomicTriggerClock' => 'infrastructure/daemon/workers/clock/PhabricatorMetronomicTriggerClock.php',
Add a motivational profile menu panel Summary: Motivate your employees with inspirational quotes. A new quote every day! Test Plan: So inspirational. Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15026
2016-01-15 00:29:21 +01:00
'PhabricatorMotivatorProfilePanel' => 'applications/search/profilepanel/PhabricatorMotivatorProfilePanel.php',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorMultiColumnUIExample' => 'applications/uiexample/examples/PhabricatorMultiColumnUIExample.php',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorMultiFactorSettingsPanel' => 'applications/settings/panel/PhabricatorMultiFactorSettingsPanel.php',
Skeleton for "Multimeter", a performance sampling application Summary: Ref T6930. This application collects and displays performance samples -- roughly, things Phabricator spent some kind of resource on. It will collect samples on different types of resources and events: - Wall time (queries, service calls, pages) - Bytes In / Bytes Out (requests) - Implicit requests to CSS/JS (static resources) I've started with the simplest case (static resources), since this can be used in an immediate, straghtforward way to improve packaging (look at which individual files have the most requests recently). There's no aggregation yet and a lot of the data isn't collected properly. Future diffs will add more dimension data (controllers, users), more event and resource types (queries, service calls, wall time), and more display options (aggregation, sorting). Test Plan: {F389344} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6930 Differential Revision: https://secure.phabricator.com/D12623
2015-05-01 22:19:43 +02:00
'PhabricatorMultimeterApplication' => 'applications/multimeter/application/PhabricatorMultimeterApplication.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMustVerifyEmailController' => 'applications/auth/controller/PhabricatorMustVerifyEmailController.php',
Port MySQL settings to PHP Summary: - Ports MySQL settings to PHP. - Removes "mysql.retries" -- this existed only because Magic Numbers Are Bad, but there is no concievable reason it should ever be set to anything other than 3. - Introduced "Hidden" config, which isn't visible from the web (for SaaS, we'll just mark anything with secret keys as "hidden"). - Introduced "Masked" config, which will be masked in darkconsole once that gets updated. - "Hidden" implies "Masked" and "Locked". - Moved "storage.default-namespace" here -- it probably makes more sense than core; this was my bad in T2255. - Put cancel button back for hidden/locked config. - Introduce 'class' config type. Test Plan: Viewed MySQL options. None are editable. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4326
2013-01-03 15:01:14 +01:00
'PhabricatorMySQLConfigOptions' => 'applications/config/option/PhabricatorMySQLConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMySQLFileStorageEngine' => 'applications/files/engine/PhabricatorMySQLFileStorageEngine.php',
Rename "SearchEngine" to "FulltextStorageEngine" Summary: Ref T9979. I picked this name long before the advent of modern "Engine" architecture and it ended up being pretty confusing. Rename "SearchEngine" (currently: mysql or elasticsearch, used to store and query fulltext indexes) to "FulltextStorageEngine" to make it more clear what it does and disambituate it from ApplicationSearch, which also has a bunch of stuff called "SearchEngine", "SearchEngineExtension", etc. Test Plan: Grepped for `phabricatorsearchengine`. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14843
2015-12-21 19:25:28 +01:00
'PhabricatorMySQLFulltextStorageEngine' => 'applications/search/fulltextstorage/PhabricatorMySQLFulltextStorageEngine.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorMySQLSetupCheck' => 'applications/config/check/PhabricatorMySQLSetupCheck.php',
Add ability to name saved queries. Summary: Can name saved queries. Test Plan: Try naming some saved queries using the form. Reviewers: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D5878 Conflicts: src/infrastructure/storage/patch/PhabricatorBuiltinPatchList.php
2013-05-10 22:43:59 +02:00
'PhabricatorNamedQuery' => 'applications/search/storage/PhabricatorNamedQuery.php',
Introduce PhabricatorNamedQueryQuery Summary: Adds a first-class Query object for querying NamedQueries. xzibit would be proud. Test Plan: Updated query edit interface to use this query, verified it works correctly. Reviewers: btrahan, blc Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6051
2013-05-27 22:40:43 +02:00
'PhabricatorNamedQueryQuery' => 'applications/search/query/PhabricatorNamedQueryQuery.php',
Add a remarkup element for a navigation sequence Summary: Fixes T4769. This is silly and just scratches an itch, but do a better job with navigation sequences. Test Plan: {F195082} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T4769 Differential Revision: https://secure.phabricator.com/D10353
2014-08-26 21:14:28 +02:00
'PhabricatorNavigationRemarkupRule' => 'infrastructure/markup/rule/PhabricatorNavigationRemarkupRule.php',
Implement clock/trigger infrastructure for scheduling actions Summary: Ref T6881. Hopefully, this is the hard part. This adds a new daemon (the "trigger" daemon) which processes triggers, schedules them, and then executes them at the scheduled time. The design is a little complicated, but has these goals: - High resistance to race conditions: only the application writes to the trigger table; only the daemon writes to the event table. We won't lose events if someone saves a meeting at the same time as we're sending a reminder out for it. - Execution guarantees: scheduled events are guaranteed to execute exactly once. - Support for arbitrarily large queues: the daemon will make progress even if there are millions of triggers in queue. The cost to update the queue is proportional to the number of changes in it; the cost to process the queue is proportional to the number of events to execute. - Relatively good observability: you can monitor the state of the trigger queue reasonably well from the web UI. - Modular Infrastructure: this is a very low-level construct that Calendar, Phortune, etc., should be able to build on top of. It doesn't have this stuff yet: - Not very robust to bad actions: a misbehaving trigger can stop the queue fairly easily. This is OK for now since we aren't planning to make it part of any other applications for a while. We do still get execute-exaclty-once, but it might not happen for a long time (until someone goes and fixes the queue), when we could theoretically continue executing other events. - Doesn't start automatically: normal users don't need to run this thing yet so I'm not starting it by default. - Not super well tested: I've vetted the basics but haven't run real workloads through this yet. - No sophisticated tooling: I added some basic stuff but it's missing some pieces we'll have to build sooner or later, e.g. `bin/trigger cancel` or whatever. - Intentionally not realtime: This design puts execution guarantees far above realtime concerns, and will not give you precise event execution at 1-second resolution. I think this is the correct goal to pursue architecturally, and certainly correct for subscriptions and meeting reminders. Events which execute after they have become irrelevant can simply decline to do anything (like a meeting reminder which executes after the meeting is over). In general, the expectation for applications is: - When creating an object (like a calendar event) that needs to trigger a scheduled action, write a trigger (and save the PHID if you plan to update it later). - The daemon will process the event and schedule the action efficiently, in a race-free way. - If you want to move the action, update the trigger and the daemon will take care of it. - Your action will eventually dump a task into the task queue, and the task daemons will actually perform it. Test Plan: Using a test script like this: ``` <?php require_once 'scripts/__init_script__.php'; $trigger = id(new PhabricatorWorkerTrigger()) ->setAction( new PhabricatorLogTriggerAction( array( 'message' => 'test', ))) ->setClock( new PhabricatorMetronomicTriggerClock( array( 'period' => 33, ))) ->save(); var_dump($trigger); ``` ...I queued triggers and ran the daemon: - Verified triggers fire; - verified triggers reschedule; - verified trigger events show up in the web UI; - tried different periods; - added some triggers while the daemon was running; - examined `phd debug` output for anything suspicious. It seems to work in trivial use case, at least. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11419
2015-01-16 21:13:31 +01:00
'PhabricatorNeverTriggerClock' => 'infrastructure/daemon/workers/clock/PhabricatorNeverTriggerClock.php',
Implement basic ngram search for Owners Package names Summary: Ref T9979. This uses ngrams (specifically, trigrams) to build a reasonably efficient index for substring matching. Specifically, for a package like "Example", with ID 123, we store rows like this: ``` < ex, 123> <exa, 123> <xam, 123> <amp, 123> <mpl, 123> <ple, 123> <le , 123> ``` When the user searches for `exam`, we join this table for packages with tokens `exa` and `xam`. MySQL can do this a lot more efficiently than it can process a `LIKE "%exam%"` query against a huge table. When the user searches for a one-letter or two-letter string, we only search the beginnings of words. This is probably what they want, the only thing we can do quickly, and a reasonable/expected behavior for typeaheads. Test Plan: - Ran storage upgrades and search indexer. - Searched for stuff with "name contains". - Used typehaead and got sensible results. - Searched for `aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz` and saw only 16 joins. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14846
2015-12-21 21:22:07 +01:00
'PhabricatorNgramsIndexEngineExtension' => 'applications/search/engineextension/PhabricatorNgramsIndexEngineExtension.php',
'PhabricatorNgramsInterface' => 'applications/search/interface/PhabricatorNgramsInterface.php',
Move files in notification one level up. Summary: Moved the files in notification one level up to match the rest of code base. And ran arc liberate. Test Plan: Made sure __phutil_library_map__ points to the right files. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: allenjohnashton, aran, Korvin Differential Revision: https://secure.phabricator.com/D2688
2012-06-08 22:00:07 +02:00
'PhabricatorNotificationBuilder' => 'applications/notification/builder/PhabricatorNotificationBuilder.php',
Add a "Mark All Read" button for notifications Summary: Adds a button to mark everything as read. Test Plan: Clicked button. Reviewers: btrahan, jungejason, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T974 Differential Revision: https://secure.phabricator.com/D2812
2012-06-20 22:51:19 +02:00
'PhabricatorNotificationClearController' => 'applications/notification/controller/PhabricatorNotificationClearController.php',
Version the Aphlict notification server and prompt users to upgrade if they're out of date Summary: Ref T4324. Add some version information to the server status output, and setup checks to test for an unreachable or out-of-date server. Test Plan: - With server down, hit reasonable setup check. - With server up and at a bad version, hit reasonable setup check. - Viewed `/notification/status/`. - The CSS thing fixes this: {F114445} Reviewers: btrahan, chad Reviewed By: chad CC: chad, aran Maniphest Tasks: T4324 Differential Revision: https://secure.phabricator.com/D8251
2014-02-18 00:59:39 +01:00
'PhabricatorNotificationClient' => 'applications/notification/client/PhabricatorNotificationClient.php',
Move notification configuration into PHP Summary: Bring notification settings to PHP. Test Plan: Viewed notification settings in /config/. Reviewers: codeblock, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4337
2013-01-03 18:29:19 +01:00
'PhabricatorNotificationConfigOptions' => 'applications/config/option/PhabricatorNotificationConfigOptions.php',
Move files in notification one level up. Summary: Moved the files in notification one level up to match the rest of code base. And ran arc liberate. Test Plan: Made sure __phutil_library_map__ points to the right files. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: allenjohnashton, aran, Korvin Differential Revision: https://secure.phabricator.com/D2688
2012-06-08 22:00:07 +02:00
'PhabricatorNotificationController' => 'applications/notification/controller/PhabricatorNotificationController.php',
Fully modularize DestructionEngine Summary: Ref T9979. Convert all DestructionEngine behaviors to extensions. Test Plan: {F1033244} Destroyed an object, verifying: - Herald transcripts were destroyed; - edges were destroyed; - flags were destroyed; - tokens were destroyed; - transactions were destroyed; - worker tasks were cancelled. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14832
2015-12-20 17:11:59 +01:00
'PhabricatorNotificationDestructionEngineExtension' => 'applications/notification/engineextension/PhabricatorNotificationDestructionEngineExtension.php',
Make Notifications Realtime Summary: Adds the node.js Aphlict server, the flash Aphlict client, and some supporting javascript. Built on top of - and requires - D2703 (which is still in progress). Will likely work with no modification on top of the final version, though. The node server is currently run with sudo node support/aphlict/server/aphlict_server.js Test Plan: tested locally Reviewers: epriestley Reviewed By: epriestley CC: allenjohnashton, keebuhm, aran, Korvin Differential Revision: https://secure.phabricator.com/D2704
2012-06-12 02:49:32 +02:00
'PhabricatorNotificationIndividualController' => 'applications/notification/controller/PhabricatorNotificationIndividualController.php',
Add a list of all notifications Summary: Add a "View All Notifications" link and page. Test Plan: Viewed all notifications Reviewers: jungejason, vrana Reviewed By: jungejason CC: aran Maniphest Tasks: T974 Differential Revision: https://secure.phabricator.com/D2780
2012-06-18 23:07:38 +02:00
'PhabricatorNotificationListController' => 'applications/notification/controller/PhabricatorNotificationListController.php',
Adds the UI dropdown panel Summary: Add a dropdown to display notificaitons. Right now there is nothing real time about it, but we do update the panel when the user clicks. This panel is only displayed if the install has notifications enabled and you have them enabled in your preferences (not using them by default). Test Plan: Turn off notifications for user1, left them on for user2. Did things from user1 and from user2 on task both were cc'd on. user2 recieved all notifications, user1 recieved nothing. Made new user, made sure everything was switched off by default. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: keebuhm, ddfisher, aran, Korvin Differential Revision: https://secure.phabricator.com/D2703
2012-06-11 18:37:06 +02:00
'PhabricatorNotificationPanelController' => 'applications/notification/controller/PhabricatorNotificationPanelController.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorNotificationQuery' => 'applications/notification/query/PhabricatorNotificationQuery.php',
Move notifications to ApplicationSearch Summary: Ref T5891. This just modernizes infrastructure. Test Plan: Viewed "All" and "Unread" notifications. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T5891 Differential Revision: https://secure.phabricator.com/D10281
2014-08-16 20:14:32 +02:00
'PhabricatorNotificationSearchEngine' => 'applications/notification/query/PhabricatorNotificationSearchEngine.php',
Complete modernization of Aphlict configuration Summary: Fixes T10697. This finishes bringing the rest of the config up to cluster power levels. Phabricator is now given an arbitrarily long list of notification servers. Each Aphlict server is given an arbitrarily long list of ports to run services on. Users are free to make them meet in the middle by proxying whatever they want to whatever else they want. This should also accommodate clustering fairly easily in the future. Also rewrote the status UI and changed a million other things. :boar: Test Plan: {F1217864} {F1217865} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10697 Differential Revision: https://secure.phabricator.com/D15703
2016-04-13 21:07:48 +02:00
'PhabricatorNotificationServerRef' => 'applications/notification/client/PhabricatorNotificationServerRef.php',
'PhabricatorNotificationServersConfigOptionType' => 'applications/notification/config/PhabricatorNotificationServersConfigOptionType.php',
Show Aphlict connection status in notification menu Summary: Fixes T5373. Ref T5281. Several changes: - The `marshallExceptions` thing is useful if JS throws an exception when invoked from Flash, so set it. The resulting exceptions are a little odd (not escaped correctly, e.g.) but way better than nothing. - Put connection status in the notification menu. - When the connection fails, try to provide contextual help where we can. Test Plan: {F169493} Reviewers: chad, joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5281, T5373 Differential Revision: https://secure.phabricator.com/D9700
2014-06-24 01:26:16 +02:00
'PhabricatorNotificationStatusView' => 'applications/notification/view/PhabricatorNotificationStatusView.php',
Add a "Send Test Notification" button to make testing the server easier Summary: Ref T4324. Currently, it's a bit of a pain to send yourself notifications, and often involves multiple browsers. Instead, add a button to send them. Test Plan: {F114495} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4324 Differential Revision: https://secure.phabricator.com/D8255
2014-02-18 01:00:33 +01:00
'PhabricatorNotificationTestController' => 'applications/notification/controller/PhabricatorNotificationTestController.php',
Desktop Notification support Summary: Fixes T4139. Adds a "Desktop Notifications" panel to settings. For now, we start with "Send Desktop Notifications Too" functionality. We can try to be fancy later and only send desktop notifications if the web app doesn't have focus, etc. Test Plan: Made some comments as a test user on a task and got purdy desktop notifications using Chrome. Then did it again with Firefox. Played around with permissions form with Chrome and got helpful information about what was up. Played around with Firefox and got similar results, except canceling the dialogue didn't invoke my handler code somehow. Oh Firefox! Reviewers: epriestley Reviewed By: epriestley Subscribers: rbalik, tycho.tatitscheff, joshuaspence, epriestley, Korvin Maniphest Tasks: T4139 Differential Revision: https://secure.phabricator.com/D13219
2015-06-22 22:11:37 +02:00
'PhabricatorNotificationTestFeedStory' => 'applications/notification/feed/PhabricatorNotificationTestFeedStory.php',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorNotificationUIExample' => 'applications/uiexample/examples/PhabricatorNotificationUIExample.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorNotificationsApplication' => 'applications/notification/application/PhabricatorNotificationsApplication.php',
'PhabricatorNuanceApplication' => 'applications/nuance/application/PhabricatorNuanceApplication.php',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorOAuth1AuthProvider' => 'applications/auth/provider/PhabricatorOAuth1AuthProvider.php',
Convert OAuth1 handshake tokens to new modular temporary tokens Summary: Ref T10603. Swap these over and give them nice UI strings. Test Plan: - Refreshed a Twitter OAuth link. - Unlinked and re-linked a Twitter account. - Viewed the new type in {nav Config > Temporary Tokens}. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10603 Differential Revision: https://secure.phabricator.com/D15480
2016-03-16 14:36:04 +01:00
'PhabricatorOAuth1SecretTemporaryTokenType' => 'applications/auth/provider/PhabricatorOAuth1SecretTemporaryTokenType.php',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorOAuth2AuthProvider' => 'applications/auth/provider/PhabricatorOAuth2AuthProvider.php',
'PhabricatorOAuthAuthProvider' => 'applications/auth/provider/PhabricatorOAuthAuthProvider.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOAuthClientAuthorization' => 'applications/oauthserver/storage/PhabricatorOAuthClientAuthorization.php',
'PhabricatorOAuthClientAuthorizationQuery' => 'applications/oauthserver/query/PhabricatorOAuthClientAuthorizationQuery.php',
Don't explicitly name abstract base classes Summary: Ref T5655. It is superfluous to include "base" in the name of an abstract base class. Furthermore, it is not done consistently within the code base. Test Plan: Ran `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9989
2014-07-21 16:05:17 +02:00
'PhabricatorOAuthClientController' => 'applications/oauthserver/controller/client/PhabricatorOAuthClientController.php',
Allow OAuth applications to be disabled instead of destroyed Summary: Ref T7303. This interaction is very oldschool; modernize it to enable/disable instead of "nuke from orbit". Test Plan: - Enabled applications. - Disabled applications. - Viewed applications in list view. - Generated new tokens. - Tried to use a token from a disabled application (got rebuffed). - Tried to use a token from an enabled application (worked fine). Reviewers: chad Reviewed By: chad Maniphest Tasks: T7303 Differential Revision: https://secure.phabricator.com/D15620
2016-04-05 18:40:22 +02:00
'PhabricatorOAuthClientDisableController' => 'applications/oauthserver/controller/client/PhabricatorOAuthClientDisableController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOAuthClientEditController' => 'applications/oauthserver/controller/client/PhabricatorOAuthClientEditController.php',
'PhabricatorOAuthClientListController' => 'applications/oauthserver/controller/client/PhabricatorOAuthClientListController.php',
OAuthServer - hide client secret behind a "View Secret" action Summary: ...also adds policies on who can view and who can edit an action. Fixes T6949. Test Plan: viewed a secret through the new UI and it worked Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6949 Differential Revision: https://secure.phabricator.com/D11401
2015-01-15 02:27:45 +01:00
'PhabricatorOAuthClientSecretController' => 'applications/oauthserver/controller/client/PhabricatorOAuthClientSecretController.php',
Modernize some OAuth Server code Summary: Ref T7303. This inches toward properly-behaved cluster logout. - Use IDs instead of PHIDs in URIs. - Slightly more modern code. - Fix some crumb stuff. Test Plan: Created, edited, viewed, deleted, showed secret for, authorized, test-auth'd an application. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7303 Differential Revision: https://secure.phabricator.com/D15592
2016-04-03 16:25:33 +02:00
'PhabricatorOAuthClientTestController' => 'applications/oauthserver/controller/client/PhabricatorOAuthClientTestController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOAuthClientViewController' => 'applications/oauthserver/controller/client/PhabricatorOAuthClientViewController.php',
'PhabricatorOAuthResponse' => 'applications/oauthserver/PhabricatorOAuthResponse.php',
'PhabricatorOAuthServer' => 'applications/oauthserver/PhabricatorOAuthServer.php',
'PhabricatorOAuthServerAccessToken' => 'applications/oauthserver/storage/PhabricatorOAuthServerAccessToken.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorOAuthServerApplication' => 'applications/oauthserver/application/PhabricatorOAuthServerApplication.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOAuthServerAuthController' => 'applications/oauthserver/controller/PhabricatorOAuthServerAuthController.php',
'PhabricatorOAuthServerAuthorizationCode' => 'applications/oauthserver/storage/PhabricatorOAuthServerAuthorizationCode.php',
Make OAuth client authorizations a Settings panel Summary: This modernizes and simplifies OAuth client authorizations a bit, moving them to a settings panel similar to the "Sessions" panel. Test Plan: - Viewed authorizations. - Revoked an authorization. - Created a test authorization. {F131196} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8561
2014-03-18 21:28:19 +01:00
'PhabricatorOAuthServerAuthorizationsSettingsPanel' => 'applications/oauthserver/panel/PhabricatorOAuthServerAuthorizationsSettingsPanel.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOAuthServerClient' => 'applications/oauthserver/storage/PhabricatorOAuthServerClient.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorOAuthServerClientAuthorizationPHIDType' => 'applications/oauthserver/phid/PhabricatorOAuthServerClientAuthorizationPHIDType.php',
'PhabricatorOAuthServerClientPHIDType' => 'applications/oauthserver/phid/PhabricatorOAuthServerClientPHIDType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOAuthServerClientQuery' => 'applications/oauthserver/query/PhabricatorOAuthServerClientQuery.php',
Use ApplicationSearch in OAuthServer Summary: Update the infrastructure and UI of the client list. Test Plan: {F131570} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8563
2014-03-18 21:31:04 +01:00
'PhabricatorOAuthServerClientSearchEngine' => 'applications/oauthserver/query/PhabricatorOAuthServerClientSearchEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOAuthServerController' => 'applications/oauthserver/controller/PhabricatorOAuthServerController.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'PhabricatorOAuthServerCreateClientsCapability' => 'applications/oauthserver/capability/PhabricatorOAuthServerCreateClientsCapability.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOAuthServerDAO' => 'applications/oauthserver/storage/PhabricatorOAuthServerDAO.php',
Convert OAuthServer to Transactions + EditEngine Summary: Ref T7303. This application is currently stone-age tech (no transactions, hard "delete" action). Bring it up to modern specs. Test Plan: - Created and edited an OAuth application. - Viewed transaction record. - Tried to create something with no name, invalid redirect URI, etc. Was gently rebuffed with detailed explanatory errors. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7303 Differential Revision: https://secure.phabricator.com/D15609
2016-04-04 18:27:42 +02:00
'PhabricatorOAuthServerEditEngine' => 'applications/oauthserver/editor/PhabricatorOAuthServerEditEngine.php',
'PhabricatorOAuthServerEditor' => 'applications/oauthserver/editor/PhabricatorOAuthServerEditor.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOAuthServerScope' => 'applications/oauthserver/PhabricatorOAuthServerScope.php',
'PhabricatorOAuthServerTestCase' => 'applications/oauthserver/__tests__/PhabricatorOAuthServerTestCase.php',
'PhabricatorOAuthServerTokenController' => 'applications/oauthserver/controller/PhabricatorOAuthServerTokenController.php',
Convert OAuthServer to Transactions + EditEngine Summary: Ref T7303. This application is currently stone-age tech (no transactions, hard "delete" action). Bring it up to modern specs. Test Plan: - Created and edited an OAuth application. - Viewed transaction record. - Tried to create something with no name, invalid redirect URI, etc. Was gently rebuffed with detailed explanatory errors. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7303 Differential Revision: https://secure.phabricator.com/D15609
2016-04-04 18:27:42 +02:00
'PhabricatorOAuthServerTransaction' => 'applications/oauthserver/storage/PhabricatorOAuthServerTransaction.php',
'PhabricatorOAuthServerTransactionQuery' => 'applications/oauthserver/query/PhabricatorOAuthServerTransactionQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorObjectHandle' => 'applications/phid/PhabricatorObjectHandle.php',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorObjectHasAsanaSubtaskEdgeType' => 'applications/doorkeeper/edge/PhabricatorObjectHasAsanaSubtaskEdgeType.php',
'PhabricatorObjectHasAsanaTaskEdgeType' => 'applications/doorkeeper/edge/PhabricatorObjectHasAsanaTaskEdgeType.php',
'PhabricatorObjectHasContributorEdgeType' => 'applications/transactions/edges/PhabricatorObjectHasContributorEdgeType.php',
'PhabricatorObjectHasFileEdgeType' => 'applications/transactions/edges/PhabricatorObjectHasFileEdgeType.php',
'PhabricatorObjectHasJiraIssueEdgeType' => 'applications/doorkeeper/edge/PhabricatorObjectHasJiraIssueEdgeType.php',
'PhabricatorObjectHasSubscriberEdgeType' => 'applications/transactions/edges/PhabricatorObjectHasSubscriberEdgeType.php',
'PhabricatorObjectHasUnsubscriberEdgeType' => 'applications/transactions/edges/PhabricatorObjectHasUnsubscriberEdgeType.php',
'PhabricatorObjectHasWatcherEdgeType' => 'applications/transactions/edges/PhabricatorObjectHasWatcherEdgeType.php',
Extract textual object list parsing from Differential Summary: Ref T2222. Currently, Differential has a fairly hairy piece of logic to parse object lists, like `Reviewers: alincoln, htaft`. Extract, generalize, and cover this. - Some of the logic can be simplified with modern ObjectQuery stuff. - Make `@username` the formal monogram for users. - Make `list@domain.com` the formal monogram for mailing lists. - Add test coverage. Test Plan: - Ran unit tests. - Called `differential.parsecommitmessage` with a bunch of real-world inputs and got sensible results. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8445
2014-03-08 02:44:44 +01:00
'PhabricatorObjectListQuery' => 'applications/phid/query/PhabricatorObjectListQuery.php',
'PhabricatorObjectListQueryTestCase' => 'applications/phid/query/__tests__/PhabricatorObjectListQueryTestCase.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorObjectMailReceiver' => 'applications/metamta/receiver/PhabricatorObjectMailReceiver.php',
Move sender validation into MailReceiver classes Summary: Ref T1205. Finally able to delete a big chunk of this nastiness. Make MailReceivers responsible for validating senders. For object creation receivers (bugs, conpherences) this just means that users must not be disabled. For other receivers the senders must be able to see the objects, have the right hashes, etc., according to policy. Test Plan: Added a bunch of test cases (everything except policy). Verified behavior via the Receive test console. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5943
2013-05-17 12:49:29 +02:00
'PhabricatorObjectMailReceiverTestCase' => 'applications/metamta/receiver/__tests__/PhabricatorObjectMailReceiverTestCase.php',
Rename classes for consistency Summary: These classes are named differently from other `PhabricatorEdgeType` subclasses. Rename them for consistency. Test Plan: I would expect the linter to complain if I missed anything. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11112
2015-01-01 05:40:26 +01:00
'PhabricatorObjectMentionedByObjectEdgeType' => 'applications/transactions/edges/PhabricatorObjectMentionedByObjectEdgeType.php',
'PhabricatorObjectMentionsObjectEdgeType' => 'applications/transactions/edges/PhabricatorObjectMentionsObjectEdgeType.php',
Provide basic infrastructure for moving PHIDs, Handles and Object Names to applications Summary: See discussion in T2715. Currently, PHIDs are all hard coded in the PHID application. In the long run, we need to move them out into actual applications. A specific immediate issue is Releeph, which uses a very very old and very broken mechanism to inject PHIDs in a way that only sort of works. Moving forward, every PHID type will be provided by a `PhabricatorPHIDType` subclass, which will manage loading it, etc. This also moves toward cleaning up the "load objects by name" (where "name" means something like `D12`) code, which is an //enormous// mess and spread across at least 4-5 callsites. Test Plan: Used `phid.lookup` and `phid.query` to load Slowvotes. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6502
2013-07-21 15:34:21 +02:00
'PhabricatorObjectQuery' => 'applications/phid/query/PhabricatorObjectQuery.php',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhabricatorObjectRemarkupRule' => 'infrastructure/markup/rule/PhabricatorObjectRemarkupRule.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorObjectSelectorDialog' => 'view/control/PhabricatorObjectSelectorDialog.php',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorObjectUsesCredentialsEdgeType' => 'applications/transactions/edges/PhabricatorObjectUsesCredentialsEdgeType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOffsetPagedQuery' => 'infrastructure/query/PhabricatorOffsetPagedQuery.php',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorOldWorldContentSource' => 'infrastructure/contentsource/PhabricatorOldWorldContentSource.php',
Implement "trigger clocks" for scheduling events Summary: Ref T6881. This will probably make more sense in a couple of diffs, but this is a class that implements scheduling/recurrence rules. Two rules are provided: - Trigger an event at a specific time (e.g., a meeting reminder notification). - Trigger an event on the Nth day of every month (e.g., a subscription bill). At some point, we'll presumably add a rule for T2896 (maybe using the "RRULE" spec) so you can do stuff like "the second to last thursday of every month", etc., but we don't need that for now. (The "Nth day of every month, or move it back if no such day exists" rule doesn't seem to be expressible with the "RRULE" format, so implementing that wouldn't give us a superset of this. I think this rule is correct and desirable for this purpose, though.) Test Plan: Added and executed unit tests. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11403
2015-01-16 00:57:45 +01:00
'PhabricatorOneTimeTriggerClock' => 'infrastructure/daemon/workers/clock/PhabricatorOneTimeTriggerClock.php',
Restructure cache checks to improve modularity Summary: Ref T5501. This code was headed down a bad road; dump an indirection layer between rendering and data gatehring. In particular, this will make it much easier to lift these issues into setup warnings eventually. Test Plan: Viewed cache status page. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5501 Differential Revision: https://secure.phabricator.com/D12315
2015-04-07 23:38:03 +02:00
'PhabricatorOpcodeCacheSpec' => 'applications/cache/spec/PhabricatorOpcodeCacheSpec.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOwnerPathQuery' => 'applications/owners/query/PhabricatorOwnerPathQuery.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorOwnersApplication' => 'applications/owners/application/PhabricatorOwnersApplication.php',
Add PhabricatorOwnersArchiveController Summary: Ability to Archive and Activate Packages from the view page. Ref T9414 Test Plan: New Package, Edit Package, Archive Package, Activate Package Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9414 Differential Revision: https://secure.phabricator.com/D14728
2015-12-09 22:41:31 +01:00
'PhabricatorOwnersArchiveController' => 'applications/owners/controller/PhabricatorOwnersArchiveController.php',
MetaMTA: Owners, Pholio, Macro Summary: Port MetaMTA options for Owners, Pholio and Macro. At some point I'd like to get rid of all these options (provide one "reply domain", and not allow overrides of reply handlers -- use events instead) but that's a battle we can fight later. Test Plan: Looked at options, looked at setup issues, edited something. Reviewers: codeblock, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4469
2013-01-16 19:52:30 +01:00
'PhabricatorOwnersConfigOptions' => 'applications/owners/config/PhabricatorOwnersConfigOptions.php',
Add CustomField support to Owners Summary: Fixes T9351. This is straightforward since this application is now relatively modern and doesn't have any bizarre craziness. Test Plan: {F787981} {F787982} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9351 Differential Revision: https://secure.phabricator.com/D14093
2015-09-10 22:32:31 +02:00
'PhabricatorOwnersConfiguredCustomField' => 'applications/owners/customfield/PhabricatorOwnersConfiguredCustomField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOwnersController' => 'applications/owners/controller/PhabricatorOwnersController.php',
Add CustomField support to Owners Summary: Fixes T9351. This is straightforward since this application is now relatively modern and doesn't have any bizarre craziness. Test Plan: {F787981} {F787982} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9351 Differential Revision: https://secure.phabricator.com/D14093
2015-09-10 22:32:31 +02:00
'PhabricatorOwnersCustomField' => 'applications/owners/customfield/PhabricatorOwnersCustomField.php',
'PhabricatorOwnersCustomFieldNumericIndex' => 'applications/owners/storage/PhabricatorOwnersCustomFieldNumericIndex.php',
'PhabricatorOwnersCustomFieldStorage' => 'applications/owners/storage/PhabricatorOwnersCustomFieldStorage.php',
'PhabricatorOwnersCustomFieldStringIndex' => 'applications/owners/storage/PhabricatorOwnersCustomFieldStringIndex.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOwnersDAO' => 'applications/owners/storage/PhabricatorOwnersDAO.php',
Give Owners real view and edit policies Summary: Fixes T10360. In modern code, most of the meat is automatic. Test Plan: - Edited view policy and edit policy from web UI. - Viewed package, saw policy badge in header. - Tried to edit a package as a user without permission, got appropriate disabled states and errors. - Changed policies via Conduit. - Tried to view a package as a user without permission. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10360 Differential Revision: https://secure.phabricator.com/D15275
2016-02-15 20:37:13 +01:00
'PhabricatorOwnersDefaultEditCapability' => 'applications/owners/capability/PhabricatorOwnersDefaultEditCapability.php',
'PhabricatorOwnersDefaultViewCapability' => 'applications/owners/capability/PhabricatorOwnersDefaultViewCapability.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOwnersDetailController' => 'applications/owners/controller/PhabricatorOwnersDetailController.php',
'PhabricatorOwnersEditController' => 'applications/owners/controller/PhabricatorOwnersEditController.php',
'PhabricatorOwnersListController' => 'applications/owners/controller/PhabricatorOwnersListController.php',
'PhabricatorOwnersOwner' => 'applications/owners/storage/PhabricatorOwnersOwner.php',
'PhabricatorOwnersPackage' => 'applications/owners/storage/PhabricatorOwnersPackage.php',
Modernize "owners" datasource Summary: Ref T4420. Update owners. Test Plan: - Used typeahead from Herald. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9880
2014-07-11 01:21:21 +02:00
'PhabricatorOwnersPackageDatasource' => 'applications/owners/typeahead/PhabricatorOwnersPackageDatasource.php',
Move Owners to EditEngine Summary: Ref T9132. Paste is in fairly good shape so Owners is up next. Reasoning: - One install wants API access for it. - It's a simple application for getting CustomFields working with EditEngine. This only does the EditEngine part, so CustomFields are no longer editable until I make that work. That will be up next, and I'll hold this until that's ready. Test Plan: - Created and edited packages via web UI. - Created and edited package editing forms via web UI. - Created and edited packages via Conduit. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14598
2015-11-29 18:33:36 +01:00
'PhabricatorOwnersPackageEditEngine' => 'applications/owners/editor/PhabricatorOwnersPackageEditEngine.php',
Implement basic ngram search for Owners Package names Summary: Ref T9979. This uses ngrams (specifically, trigrams) to build a reasonably efficient index for substring matching. Specifically, for a package like "Example", with ID 123, we store rows like this: ``` < ex, 123> <exa, 123> <xam, 123> <amp, 123> <mpl, 123> <ple, 123> <le , 123> ``` When the user searches for `exam`, we join this table for packages with tokens `exa` and `xam`. MySQL can do this a lot more efficiently than it can process a `LIKE "%exam%"` query against a huge table. When the user searches for a one-letter or two-letter string, we only search the beginnings of words. This is probably what they want, the only thing we can do quickly, and a reasonable/expected behavior for typeaheads. Test Plan: - Ran storage upgrades and search indexer. - Searched for stuff with "name contains". - Used typehaead and got sensible results. - Searched for `aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz` and saw only 16 joins. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14846
2015-12-21 21:22:07 +01:00
'PhabricatorOwnersPackageFulltextEngine' => 'applications/owners/query/PhabricatorOwnersPackageFulltextEngine.php',
Modernize Audit search engine Summary: Fixes T9279. Modernizes the SearchEngine and Query classes. User-facing changes: - Added order by commit date, default to order by commit date with newest commits first. - Added explicit "Needs Audit by". - Added new `packages(...)` typeahead function. - Picked up automatic subscribers, projects, and order fields. This changes behavior a little bit: we previously attempted to exclude, e.g., commits which a package you own needs to audit, but which you have resigned from. This is difficult in general and I think it needs a more comprehensive solution. This shouldn't impact users much, anyway. Test Plan: {F767628} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9279 Differential Revision: https://secure.phabricator.com/D14013
2015-08-31 19:17:54 +02:00
'PhabricatorOwnersPackageFunctionDatasource' => 'applications/owners/typeahead/PhabricatorOwnersPackageFunctionDatasource.php',
Implement basic ngram search for Owners Package names Summary: Ref T9979. This uses ngrams (specifically, trigrams) to build a reasonably efficient index for substring matching. Specifically, for a package like "Example", with ID 123, we store rows like this: ``` < ex, 123> <exa, 123> <xam, 123> <amp, 123> <mpl, 123> <ple, 123> <le , 123> ``` When the user searches for `exam`, we join this table for packages with tokens `exa` and `xam`. MySQL can do this a lot more efficiently than it can process a `LIKE "%exam%"` query against a huge table. When the user searches for a one-letter or two-letter string, we only search the beginnings of words. This is probably what they want, the only thing we can do quickly, and a reasonable/expected behavior for typeaheads. Test Plan: - Ran storage upgrades and search indexer. - Searched for stuff with "name contains". - Used typehaead and got sensible results. - Searched for `aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz` and saw only 16 joins. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14846
2015-12-21 21:22:07 +01:00
'PhabricatorOwnersPackageNameNgrams' => 'applications/owners/storage/PhabricatorOwnersPackageNameNgrams.php',
Modernize Audit search engine Summary: Fixes T9279. Modernizes the SearchEngine and Query classes. User-facing changes: - Added order by commit date, default to order by commit date with newest commits first. - Added explicit "Needs Audit by". - Added new `packages(...)` typeahead function. - Picked up automatic subscribers, projects, and order fields. This changes behavior a little bit: we previously attempted to exclude, e.g., commits which a package you own needs to audit, but which you have resigned from. This is difficult in general and I think it needs a more comprehensive solution. This shouldn't impact users much, anyway. Test Plan: {F767628} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9279 Differential Revision: https://secure.phabricator.com/D14013
2015-08-31 19:17:54 +02:00
'PhabricatorOwnersPackageOwnerDatasource' => 'applications/owners/typeahead/PhabricatorOwnersPackageOwnerDatasource.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorOwnersPackagePHIDType' => 'applications/owners/phid/PhabricatorOwnersPackagePHIDType.php',
Add PhabricatorOwnersPackageQuery Summary: This is a step toward unearthing Project queries enough that I can make them policy-aware. Right now, some ProjectQuery callsites do not have reasonable access to the viewer. In particular, Owners packages need to issue Project queries because we allow projects to own packages and resolve project members inside of some package queries. Currently, we have a very unmodern approach to querying packages, with a large number of one-off static load methods: PhabricatorOwnersPackage::loadAffectedPackages() PhabricatorOwnersPackage::loadOwningPackages() PhabricatorOwnersPackage::loadPackagesForPaths() PhabricatorOwnersOwner::loadAllForPackages() PhabricatorOwnersOwner::loadAffiliatedUserPHIDs() PhabricatorOwnersOwner::loadAffiliatedPackages() ConduitAPI_owners_query_Method::queryAll() ConduitAPI_owners_query_Method::queryByOwner() ConduitAPI_owners_query_Method::queryByAffiliatedUser() ConduitAPI_owners_query_Method::queryByPath() We should replace `PhabricatorOwnersOwner` with an Edge and move all of these calls to a Query class. I'm going to try to do as little of this work as I can for now since I'm much more interested in getting a functional policy implementation into other applications, but ProjectQuery needs to be policy-aware before I can do that and I need to dig some at least some of the callsites out enough that I can get a viewer in there without making the code worse than it is. This adds a PhabricatorOwnersPackageQuery class and removes one callsite of one of those static methods. I also intend to dissolve the two separate concepts of an "owner" (direct owner) and an "affiliated user" (indirect owner via project membership) since I think we're always fine with "affiliated users" owners. Test Plan: Loaded home page / audit tool, which use the modified path. Ran queries manually via script. Made sure results included directly owned packages and packages owned through project membership. Reviewers: vrana, btrahan, meitros Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3193
2012-08-08 21:25:11 +02:00
'PhabricatorOwnersPackageQuery' => 'applications/owners/query/PhabricatorOwnersPackageQuery.php',
Use ApplicationSearch in Owners Summary: Ref T8320. Modernize search and major interfaces. This slightly regresses some list view and search features; I'll probably restore some later (once the Query has proper `needX(...)` methods) and drop the rest. Test Plan: Browsed, edited, deleted, and created packages. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8320 Differential Revision: https://secure.phabricator.com/D13024
2015-05-27 19:29:01 +02:00
'PhabricatorOwnersPackageSearchEngine' => 'applications/owners/query/PhabricatorOwnersPackageSearchEngine.php',
Allow excluding paths from package Summary: Resolves T2149. Test Plan: $ bin/storage upgrade # /owners/ - saw + # /owners/package/1/ - saw + # /owners/edit/1/ - added exclude paths, saw correct e-mail # /rPabc123 - included paths are still highlighted and excluded not # /owners/view/search/?path=/included/ - found # /owners/view/search/?path=/excluded/ - not found # owners.query - path: /included/ # owners.query - path: /excluded/ # new unit test PhabricatorOwnersPackage::loadAffectedPackages( $repository, array('/excluded/b.php')); PhabricatorOwnersPackage::loadAffectedPackages( $repository, array('/included/a.php')); Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2149 Differential Revision: https://secure.phabricator.com/D4102
2012-12-07 02:23:56 +01:00
'PhabricatorOwnersPackageTestCase' => 'applications/owners/storage/__tests__/PhabricatorOwnersPackageTestCase.php',
Use ApplicationTransactions for all non-path edits to Owners packages Summary: Ref T8320. Test Plan: {F437431} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8320 Differential Revision: https://secure.phabricator.com/D13028
2015-05-27 19:30:08 +02:00
'PhabricatorOwnersPackageTransaction' => 'applications/owners/storage/PhabricatorOwnersPackageTransaction.php',
'PhabricatorOwnersPackageTransactionEditor' => 'applications/owners/editor/PhabricatorOwnersPackageTransactionEditor.php',
'PhabricatorOwnersPackageTransactionQuery' => 'applications/owners/query/PhabricatorOwnersPackageTransactionQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOwnersPath' => 'applications/owners/storage/PhabricatorOwnersPath.php',
Separate editing of package data and paths in Owners Summary: Ref T8320. There's currently one enormous form; split it into a general information form (name, description, owners) and a paths form. I think this is a little more manageable from both a UX point of view and from an "I have to convert this to use ApplicationTransactions" point of view. Test Plan: - Edited paths. - Edited non-path information. - Created new packages. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8320 Differential Revision: https://secure.phabricator.com/D13026
2015-05-27 19:29:50 +02:00
'PhabricatorOwnersPathsController' => 'applications/owners/controller/PhabricatorOwnersPathsController.php',
Give "owners.search" a "paths" attachment and a default "owners" value Summary: Ref T9964. - Add a "paths" attachment for fetching paths. - Always load owners. We will need this to do policy checks in the future, anyway, and this data is not large, is very useful, and is reasonable to load unconditionally. Test Plan: - Queried packages via API. - Edited packages (paths, owners). - Created a package. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14775
2015-12-14 15:11:03 +01:00
'PhabricatorOwnersPathsSearchEngineAttachment' => 'applications/owners/engineextension/PhabricatorOwnersPathsSearchEngineAttachment.php',
Fix file PHID extraction in Owners and Differential Summary: Ref T9787. To fix this, I want to change how file PHIDs are extracted slightly: specifically, I'm going to extract them later in the editing process. Before doing this, clean up a couple of bad implementations: - Owners extracts its description as a file PHID. This is an error. - Extract the description as a remarkup block instead. - Add an edge table so stuff like file attachment works properly. - Differential has a no-op extract method. This is presumably just a copy/paste issue from long ago. Test Plan: - Edited a revision in Differential. - Dropped a file into the description of an Owners package. - Before change: this did not attach the file. - After change: the file now attaches properly and shows up as "Attached" in the file details. Reviewers: chad, joshuaspence Reviewed By: joshuaspence Subscribers: joshuaspence Maniphest Tasks: T9787 Differential Revision: https://secure.phabricator.com/D14493
2015-11-16 18:53:01 +01:00
'PhabricatorOwnersSchemaSpec' => 'applications/owners/storage/PhabricatorOwnersSchemaSpec.php',
Move some PhabricatorSearchField subclasses Summary: Move some `PhabricatorSearchField` subclasses to be adjacent to the application to which they belong. This seems generally better to me than lumping them all together in the `src/applications/search/field/` directory. I was also wondering if it makes sense to rename these subclasses as `PhabricatorXSearchField` rather than `PhabricatorSearchXField` (as per T5655), but wasn't really sure if these objects are meant to be search-fields, or just fields belonging to the #search application. Test Plan: N/A. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13374
2015-07-06 14:52:04 +02:00
'PhabricatorOwnersSearchField' => 'applications/owners/searchfield/PhabricatorOwnersSearchField.php',
PHD Options. Test Plan: Looked at the options render properly. Reviewers: epriestley, btrahan, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4367
2013-01-09 15:05:34 +01:00
'PhabricatorPHDConfigOptions' => 'applications/config/option/PhabricatorPHDConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPHID' => 'applications/phid/storage/PhabricatorPHID.php',
'PhabricatorPHIDConstants' => 'applications/phid/PhabricatorPHIDConstants.php',
Work around a bug in PHP 5.3-ish with abstract methods in interfaces Summary: @chad is hitting an issue described in P961, which I think is this bug in PHP: https://bugs.php.net/bug.php?id=43200 Work around it by defining a "PHIDInterface" and having both "Flaggable" and "Policy" extend it, so that there is only one `getPHID()` declaration. Test Plan: shrug~ Reviewers: chad, btrahan Reviewed By: chad CC: chad, aran Differential Revision: https://secure.phabricator.com/D7408
2013-10-26 00:58:17 +02:00
'PhabricatorPHIDInterface' => 'applications/phid/interface/PhabricatorPHIDInterface.php',
Improve code structure of PHID fields in EditEngine Summary: Ref T9132. I had some hacks in place for dealing with Edge/Subscribers stuff. Clean that up so it's structured a little better. Test Plan: - Edited subscribers and projects. - Verified things still show up in Conduit. - Made concurrent edits (added a project in one window, removed it in another window, got a clean result with a correct merge of the two edits). Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14601
2015-11-29 22:24:47 +01:00
'PhabricatorPHIDListEditField' => 'applications/transactions/editfield/PhabricatorPHIDListEditField.php',
Make "Assign / Claim" stacked action work properly in Maniphest Summary: Ref T9132. This is kind of a mess because the tokenizer rewrite left rendering tokenizers in Javascript a little rough. This causes bugs like icons not showing up on tokens in the "Policy" dialog, which there's a task for somewhere I think. I think I've fixed it enough that the beahavior is now correct (i.e., icons show up properly), but some of the code is a bit iffy. I'll eventually clean this up properly, but it's fairly well contained for now. Test Plan: - Reassigned a task. - Put a task up for grabs. - No reassign on closed tasks. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14669
2015-12-04 18:30:53 +01:00
'PhabricatorPHIDListEditType' => 'applications/transactions/edittype/PhabricatorPHIDListEditType.php',
Provide formal Users/Projects/Mailable fields for EditEngine Summary: Ref T9132. This allows you to prefill EditEngine forms with stuff like `?subscribers=epriestley`, and we'll figure out what you mean. Test Plan: - Did `/?subscribers=...` with various values (good, bad, mis-capitalized). - Did `/?projects=...` with various values (good, bad, mis-capitalized). - Reviewed documentation. - Reviewed {nav Config > HTTP Parameter Types}. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14404
2015-11-04 19:20:38 +01:00
'PhabricatorPHIDResolver' => 'applications/phid/resolver/PhabricatorPHIDResolver.php',
Provide basic infrastructure for moving PHIDs, Handles and Object Names to applications Summary: See discussion in T2715. Currently, PHIDs are all hard coded in the PHID application. In the long run, we need to move them out into actual applications. A specific immediate issue is Releeph, which uses a very very old and very broken mechanism to inject PHIDs in a way that only sort of works. Moving forward, every PHID type will be provided by a `PhabricatorPHIDType` subclass, which will manage loading it, etc. This also moves toward cleaning up the "load objects by name" (where "name" means something like `D12`) code, which is an //enormous// mess and spread across at least 4-5 callsites. Test Plan: Used `phid.lookup` and `phid.query` to load Slowvotes. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6502
2013-07-21 15:34:21 +02:00
'PhabricatorPHIDType' => 'applications/phid/type/PhabricatorPHIDType.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorPHIDTypeTestCase' => 'applications/phid/type/__tests__/PhabricatorPHIDTypeTestCase.php',
Clean up "ids" and "phids" handling in SearchEngines Summary: Ref T9964. I added several hacks to get these working. Clean them up and pull this into a proper extension. The behavior in the web UI is: - they work in all applications; but - they only show up in the UI if a value is specified. So if you visit `/view/?ids=1,2` you get the field, but normally it's not present. We could refine this later. I'm going to add documentation about how to prefill these forms regardless, which should make this discoverable by reading the documentation. There's one teensey weensey hack: in the API, I push these fields to the top of the table. That one feels OK, since it's purely a convenience/display adjustment. Test Plan: Queried by IDs, reviewed docs. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14769
2015-12-13 19:11:40 +01:00
'PhabricatorPHIDsSearchField' => 'applications/search/field/PhabricatorPHIDsSearchField.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPHPASTApplication' => 'applications/phpast/application/PhabricatorPHPASTApplication.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorPHPConfigSetupCheck' => 'applications/config/check/PhabricatorPHPConfigSetupCheck.php',
Bring PHPMailer config into the new config UI Summary: Port PHPMailer options. Also: - Don't show values on config lists if they're masked (this is mostly for passwords, to prevent them from being idly/accidentally disclosed). - Don't show "default" icon -- just show an icon if the value has been customized. This makes it easier to pick out custom values. Test Plan: Looked at / edited mailer values. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4441
2013-01-15 21:03:44 +01:00
'PhabricatorPHPMailerConfigOptions' => 'applications/config/option/PhabricatorPHPMailerConfigOptions.php',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorPagedFormUIExample' => 'applications/uiexample/examples/PhabricatorPagedFormUIExample.php',
Fix a file name to match the PHP class name Summary: This was misnamed in D11177. Test Plan: `arc lint` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11193
2015-01-04 20:38:59 +01:00
'PhabricatorPagerUIExample' => 'applications/uiexample/examples/PhabricatorPagerUIExample.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPassphraseApplication' => 'applications/passphrase/application/PhabricatorPassphraseApplication.php',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorPasswordAuthProvider' => 'applications/auth/provider/PhabricatorPasswordAuthProvider.php',
Make password hashing modular Summary: Ref T4443. Make hashing algorithms pluggable and extensible so we can deal with the attendant complexities more easily. This moves "Iterated MD5" to a modular implementation, and adds a tiny bit of hack-glue so we don't need to migrate the DB in this patch. I'll migrate in the next patch, then add bcrypt. Test Plan: - Verified that the same stuff gets stored in the DB (i.e., no functional changes): - Logged into an old password account. - Changed password. - Registered a new account. - Changed password. - Switched back to master. - Logged in / out, changed password. - Switched back, logged in. - Ran unit tests (they aren't super extensive, but cover some of the basics). Reviewers: btrahan Reviewed By: btrahan CC: aran, kofalt Maniphest Tasks: T4443 Differential Revision: https://secure.phabricator.com/D8268
2014-02-18 18:31:30 +01:00
'PhabricatorPasswordHasher' => 'infrastructure/util/password/PhabricatorPasswordHasher.php',
'PhabricatorPasswordHasherTestCase' => 'infrastructure/util/password/__tests__/PhabricatorPasswordHasherTestCase.php',
'PhabricatorPasswordHasherUnavailableException' => 'infrastructure/util/password/PhabricatorPasswordHasherUnavailableException.php',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorPasswordSettingsPanel' => 'applications/settings/panel/PhabricatorPasswordSettingsPanel.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPaste' => 'applications/paste/storage/PhabricatorPaste.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPasteApplication' => 'applications/paste/application/PhabricatorPasteApplication.php',
Add PasteArchiveController Summary: Makes this more consistent. Also clean up spacing. Ref T9414 Test Plan: Archive/Activate Paste, Edit Paste Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9414 Differential Revision: https://secure.phabricator.com/D14724
2015-12-09 20:50:19 +01:00
'PhabricatorPasteArchiveController' => 'applications/paste/controller/PhabricatorPasteArchiveController.php',
Add some create mail handlers for paste and files Summary: Fixes T1144. Though actually I think T1144 wanted some handy way to email from the command-line / arc, this is cooler. :D Test Plan: set conf properly and then ./bin/mail receive-test --as btrahan --to pasties@phabricator.dev | README --> it worked...! couldn't test files as easily but verified exception thrown when I tried to test. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1144 Differential Revision: https://secure.phabricator.com/D6622
2013-07-30 22:26:55 +02:00
'PhabricatorPasteConfigOptions' => 'applications/paste/config/PhabricatorPasteConfigOptions.php',
Add a "content" attachment for Pastes for Conduit API Summary: Ref T9964. Builds on D14772. Allows callers to get the raw content of pastes as an attachment. Test Plan: - Read docs. - Executed attachment query. - Saw raw paste content. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14774
2015-12-14 15:01:04 +01:00
'PhabricatorPasteContentSearchEngineAttachment' => 'applications/paste/engineextension/PhabricatorPasteContentSearchEngineAttachment.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPasteController' => 'applications/paste/controller/PhabricatorPasteController.php',
'PhabricatorPasteDAO' => 'applications/paste/storage/PhabricatorPasteDAO.php',
Split paste create/edit and list views Summary: We have this hybrid "create / last few pastes" landing screen right now but I ~never use the list at the bottom and it makes the controller kind of complicated. I want to let you edit pastes too, and this generally simplifies things. Also makes the textarea monospaced and cleans up the fork logic a bit. Test Plan: Created, forked pastes. Viewed paste lists. Viewed pastes. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1690 Differential Revision: https://secure.phabricator.com/D3375
2012-08-24 22:19:14 +02:00
'PhabricatorPasteEditController' => 'applications/paste/controller/PhabricatorPasteEditController.php',
Implement a basic version of ApplicationEditor in Paste Summary: Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste. This mostly looks and works like ApplicationSearch, and is heavily modeled on it. Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else. This has no functional changes, except: - I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it. - Subscribers are now editable. - Form field order is a little goofy (this will be fixed in a future diff). - Subscribers and projects are now race-resistant. The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits. Test Plan: - Created pastes. - Created pastes via API. - Edited pastes. - Edited every field. - Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4768, T9132 Differential Revision: https://secure.phabricator.com/D14390
2015-11-03 03:58:32 +01:00
'PhabricatorPasteEditEngine' => 'applications/paste/editor/PhabricatorPasteEditEngine.php',
Paste - add transactions Summary: Ref T3650. This adds a create transaction, transactions for metadata (title, langauge, view policy), and comments. Editor is used on all create /edit paths. Test Plan: made some pastes via web and email - yay. edited pastes - yay. verified txns showed up on pastes and in feed correctly. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3516, T3650 Differential Revision: https://secure.phabricator.com/D6645
2013-08-02 21:56:58 +02:00
'PhabricatorPasteEditor' => 'applications/paste/editor/PhabricatorPasteEditor.php',
Improve lispum generation of pastes Summary: Fixes T8482, or something. I can't actually repro that but I think it should be fixed either here or earlier Test Plan: ``` $ ./bin/lipsum generate paste GENERATORS Selected generators: Pastes. WARNING This command generates synthetic test data, including user accounts. It is intended for use in development environments so you can test features more easily. There is no easy way to delete this data or undo the effects of this command. If you run it in a production environment, it will pollute your data with large amounts of meaningless garbage that you can not get rid of. Are you sure you want to generate piles of garbage? [y/N] y LIPSUM Generating synthetic test objects forever. Use ^C to stop when satisfied. Generated "Paste": P223 forgotten_memory_disks_backup.java Generated "Paste": P224 backup_disk_tables_and_administrate_backup_memory_account.java Generated "Paste": P225 sync_backup_disk_and_undo_memory.php Generated "Paste": P226 administrate_memory_shard_helper.php Generated "Paste": P227 cancel_disk_users Generated "Paste": P228 backups_pro.txt Generated "Paste": P229 undo_host.txt Generated "Paste": P230 accelerate_database_accounts.java Generated "Paste": P231 entomb_accounts.java Generated "Paste": P232 legendary_legendary_shards_helper.java Generated "Paste": P233 compact_backup_and_user_and_purge_memory Generated "Paste": P234 account_script_script_backup_helper_helper.java Generated "Paste": P235 purge_disk.php Generated "Paste": P236 forgotten_elder_account.txt Generated "Paste": P237 ancient_ancient_disks.txt Generated "Paste": P238 disk_user.php ``` Reviewers: chad Reviewed By: chad Maniphest Tasks: T8482 Differential Revision: https://secure.phabricator.com/D14883
2015-12-25 15:20:25 +01:00
'PhabricatorPasteFilenameContextFreeGrammar' => 'applications/paste/lipsum/PhabricatorPasteFilenameContextFreeGrammar.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPasteListController' => 'applications/paste/controller/PhabricatorPasteListController.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorPastePastePHIDType' => 'applications/paste/phid/PhabricatorPastePastePHIDType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPasteQuery' => 'applications/paste/query/PhabricatorPasteQuery.php',
Provide a stable URI for getting raw paste content Summary: Fixes T9312. This is a bit fluff, but does simplify the view controller slightly and seems reasonable/useful in general. Test Plan: Clicked "View Raw File" on a paste, got redirected to the raw file via a stable URI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9312 Differential Revision: https://secure.phabricator.com/D14167
2015-09-25 19:45:01 +02:00
'PhabricatorPasteRawController' => 'applications/paste/controller/PhabricatorPasteRawController.php',
Pre-prepare for hovercards Summary: D5120 and followups refactor and generalize object references in Remarkup -- notably, they move remarkup rules from a central location to the implementing applications. Preserve blame by doing moves/renames only first. This change moves application remarkup rules into those applications, and renames the ones D5120 modifies. Test Plan: Typed some preview text into a textarea, got a valid Remarkup render. Reviewers: vrana, chad Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5123
2013-02-26 23:57:41 +01:00
'PhabricatorPasteRemarkupRule' => 'applications/paste/remarkup/PhabricatorPasteRemarkupRule.php',
Generate expected scheamta for Passphrase, Paste, Phlux, Phame Summary: Ref T1191. Nothing notable in these. Test Plan: Viewed web UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10528
2014-09-24 22:50:57 +02:00
'PhabricatorPasteSchemaSpec' => 'applications/paste/storage/PhabricatorPasteSchemaSpec.php',
Move paste search to generic search. Summary: Begin implementing generic application search and refactoring paste search. Test Plan: See if the paste search still works. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5621
2013-04-14 15:53:20 +02:00
'PhabricatorPasteSearchEngine' => 'applications/paste/query/PhabricatorPasteSearchEngine.php',
Truncate long source lines in Paste search result list snippets Summary: An attempt to resolve T9600. - `PhabricatorPasteQuery` builds truncated snippet when requested using `needSnippet()`. - `PhabricatorPasteSearchEngine` uses Paste snippet istead of content. - `PhabricatorSourceCodeView` accepts truncated source and type instead of line limit. Test Plan: Generated some content for Paste application and also added huge JSON oneliner. Checked Paste application pages in browser. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T9600 Differential Revision: https://secure.phabricator.com/D14313
2015-10-20 21:07:04 +02:00
'PhabricatorPasteSnippet' => 'applications/paste/snippet/PhabricatorPasteSnippet.php',
Completed Paste Generation Summary: Ref T2903 Test Plan: Pastes being generated with all types of parents, view policies, code, etc. Reviewers: epriestley, AnhNhan Reviewed By: epriestley CC: AnhNhan, aran, Korvin Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5707
2013-04-29 21:10:53 +02:00
'PhabricatorPasteTestDataGenerator' => 'applications/paste/lipsum/PhabricatorPasteTestDataGenerator.php',
Paste - add transactions Summary: Ref T3650. This adds a create transaction, transactions for metadata (title, langauge, view policy), and comments. Editor is used on all create /edit paths. Test Plan: made some pastes via web and email - yay. edited pastes - yay. verified txns showed up on pastes and in feed correctly. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3516, T3650 Differential Revision: https://secure.phabricator.com/D6645
2013-08-02 21:56:58 +02:00
'PhabricatorPasteTransaction' => 'applications/paste/storage/PhabricatorPasteTransaction.php',
'PhabricatorPasteTransactionComment' => 'applications/paste/storage/PhabricatorPasteTransactionComment.php',
'PhabricatorPasteTransactionQuery' => 'applications/paste/query/PhabricatorPasteTransactionQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPasteViewController' => 'applications/paste/controller/PhabricatorPasteViewController.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorPathSetupCheck' => 'applications/config/check/PhabricatorPathSetupCheck.php',
Add an anyone() typeahead function for matching any document owner Summary: Fixes T5733. Test Plan: Ran search and Maniphest queries. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5733 Differential Revision: https://secure.phabricator.com/D12535
2015-04-24 00:44:27 +02:00
'PhabricatorPeopleAnyOwnerDatasource' => 'applications/people/typeahead/PhabricatorPeopleAnyOwnerDatasource.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPeopleApplication' => 'applications/people/application/PhabricatorPeopleApplication.php',
Implement most of the administrative UI for approval queues Summary: Nothing fancy here, just: - UI to show users needing approval. - "Approve" and "Disable" actions. - Send "Approved" email on approve. - "Approve" edit + log operations. - "Wait for Approval" state for users who need approval. There's still no natural way for users to end up not-approved -- you have to write directly to the database. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7573
2013-11-13 20:24:18 +01:00
'PhabricatorPeopleApproveController' => 'applications/people/controller/PhabricatorPeopleApproveController.php',
Calendar upgrades Summary: Does a handful of things to make Calendar significantly more useful - Enabled overlapping events - Profile has a 'week view' of the user - Profile has a 'month view' of the users - Multiple users on a calendar are color coded - Browse view slightly more useful This stops short of implementing the new 'home' view on Calendar, mostly this is a big step though to make that happen next. Test Plan: Make lots of events on diffent users. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T2897, T4375 Differential Revision: https://secure.phabricator.com/D8317
2014-02-24 19:04:23 +01:00
'PhabricatorPeopleCalendarController' => 'applications/people/controller/PhabricatorPeopleCalendarController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPeopleController' => 'applications/people/controller/PhabricatorPeopleController.php',
Make user creation process simpler Summary: Fixes T4065. This divides user creation into separate "Standard User" and "Script/Bot" workflows which show only relevant fields and provide guidance. This fixes the verification mess associated with script/bot users by verifying their email addresses automatically. Test Plan: - Created a standard user. - Created a script/bot. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8674
2014-04-02 21:06:27 +02:00
'PhabricatorPeopleCreateController' => 'applications/people/controller/PhabricatorPeopleCreateController.php',
Modernize "users" typeahead datasource Summary: Ref T4420. Modernize users. Test Plan: - Edited "Commit Authors" on Audit search. - Edited "Created By" on calendar search. - Edited "invited" on calendar search. - Edited "To" on "New conpherence message". - Edited user on "Add user to conpherence thread". - Edited "Authors" on countdown search. - Edited "Author" on differential search. - Edited "Responsible users" on differential search. - Edited "Owner" on Diffusion lint search. - Edited "include users" on Feed search. - Edited "Authors" on file search. - Edited "Authors" on Herald rule search. - Edited a couple of user-selecting Herald fields on rules. - Edited "user" on legalpad signature exemption. - Edited "creator" on legalpad search. - Edited "contributors" on legalpad search. - Edited "signers" on legalpad signature search. - Edited "Authors" on macro search. - Edited "Reassign/claim" on task detail. - Edited "assigned to" on task edit. - Edited "assigned to", "users projects", "authors" on task search. - Edited "creators" on oauthserver. - Edited "authors" on paste search. - Edited "actors" and "users" on activity log search. - Edited "authors" on pholio search. - Edited "users" on phrequent search. - Edited "authors", "answered by" on Ponder search. - Edited "add members" on project membership editor. - Edited "members" on project search. - Edited "pushers" on releeph product edit. - Edited "requestors" on releeph request search. - Edited "pushers" on diffusion push log. - Edited "authors", "owners", "subscribers" on global search. - Edited "authors" on slowvote search. - Edited users in custom policy. - Grepped for "common/authors", no hits. - Grepped for "common/users", no (relevant) hits. - Grepped for "common/accounts", no (relevant) hits. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9885
2014-07-18 00:44:18 +02:00
'PhabricatorPeopleDatasource' => 'applications/people/typeahead/PhabricatorPeopleDatasource.php',
Move "Delete User" action to user profiles Summary: Ref T4065. The existence of two separate edit workflows for users is broadly confusing to administrators. I want to unify user administration and improve administration of system agent accounts. Particularly, I plan to: - Give administrators limited access to profile editing of system agents (e.g., change profile picture). - Give administrators limited access to Settings for system agents. - Broadly, move all the weird old special editing into standard editing. Test Plan: - Hit all the errors (delete self, no username, wrong username). - Deleted a user. - Visited page as a non-admin, got 403'd. - Viewed old edit UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8662
2014-04-02 21:05:07 +02:00
'PhabricatorPeopleDeleteController' => 'applications/people/controller/PhabricatorPeopleDeleteController.php',
Convert user profiles to Profile Panels Summary: Ref T10054. Primary goal is to be able to remove IconNav from the codebase. I've made these non-editable so users can't customize them yet. We //might// want administrators to customize these globally instead? In any case, we avoid a bunch of product questions by just locking these down for now. Test Plan: {F1061348} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15020
2016-01-14 15:47:06 +01:00
'PhabricatorPeopleDetailsProfilePanel' => 'applications/people/profilepanel/PhabricatorPeopleDetailsProfilePanel.php',
Implement most of the administrative UI for approval queues Summary: Nothing fancy here, just: - UI to show users needing approval. - "Approve" and "Disable" actions. - Send "Approved" email on approve. - "Approve" edit + log operations. - "Wait for Approval" state for users who need approval. There's still no natural way for users to end up not-approved -- you have to write directly to the database. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7573
2013-11-13 20:24:18 +01:00
'PhabricatorPeopleDisableController' => 'applications/people/controller/PhabricatorPeopleDisableController.php',
Put Disable/Admin flags on profiles Summary: Ref T4065. Moves the "disable / enable" and "make / unmake administrator" actions to profiles. Test Plan: Disabled and enabled users, and made and unmade administrators. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8666
2014-04-02 21:05:49 +02:00
'PhabricatorPeopleEmpowerController' => 'applications/people/controller/PhabricatorPeopleEmpowerController.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorPeopleExternalPHIDType' => 'applications/people/phid/PhabricatorPeopleExternalPHIDType.php',
Allow users to have profile icons Summary: Ref T10054. This primarily improves aesthetics and consistency for member/wathcher lists in projects. Test Plan: {F1068873} {F1068874} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15103
2016-01-24 14:43:57 +01:00
'PhabricatorPeopleIconSet' => 'applications/people/icon/PhabricatorPeopleIconSet.php',
Add administrative invite interfaces Summary: Ref T7152. This implements the administrative UI for the upstream email invite workflow. Pieces of this will be reused in Instances to implement the instance invite workflow, although some of it is probably going to be a bit copy/pastey. This doesn't actually create or send invites yet, and they still can't be carried through registration. Test Plan: {F290970} {F290971} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11733
2015-02-11 15:05:53 +01:00
'PhabricatorPeopleInviteController' => 'applications/people/controller/PhabricatorPeopleInviteController.php',
'PhabricatorPeopleInviteListController' => 'applications/people/controller/PhabricatorPeopleInviteListController.php',
'PhabricatorPeopleInviteSendController' => 'applications/people/controller/PhabricatorPeopleInviteSendController.php',
Added ldap import controller
2012-07-04 04:10:38 +02:00
'PhabricatorPeopleLdapController' => 'applications/people/controller/PhabricatorPeopleLdapController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPeopleListController' => 'applications/people/controller/PhabricatorPeopleListController.php',
Modernize user activity logs (ApplicationSearch, policies) Summary: Ref T4398. Ref T4842. I want to let users review their own account activity, partly as a general security measure and partly to make some of the multi-factor stuff easier to build and debug. To support this, implement modern policies and application search. I also removed the "old" and "new" columns from this output, since they had limited utility and revealed email addresses to administrators for some actions. We don't let administrators access email addresses from other UIs, and the value of doing so here seems very small. Test Plan: Used interface to issue a bunch of queries against user logs, got reasonable/expected results. Reviewers: btrahan Reviewed By: btrahan Subscribers: keir, epriestley Maniphest Tasks: T4842, T4398 Differential Revision: https://secure.phabricator.com/D8856
2014-04-28 02:31:35 +02:00
'PhabricatorPeopleLogQuery' => 'applications/people/query/PhabricatorPeopleLogQuery.php',
'PhabricatorPeopleLogSearchEngine' => 'applications/people/query/PhabricatorPeopleLogSearchEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPeopleLogsController' => 'applications/people/controller/PhabricatorPeopleLogsController.php',
Begin modularizing main menu items Summary: Ref T10077. Ref T8918. The way the main menu is built is not very modular and fairly hacky. It assumes menus are provided by applications, but this isn't exactly true. Notably, the "Quick Create" menu is not per-application. The current method of building this menu is very inefficient (see T10077). Particularly, we have to build it //twice// because we need to build it once to render the item and then again to render the dropdown options. Start cleaning this up. This diff doesn't actually have any behavioral changes, since I can't swap the menu over until we get rid of all the other items and I haven't extended this to Notifications/Conpherence yet so it doesn't actually fix T8918. Test Plan: Viewed menus while logged in, logged out, in different applications, in desktop/mobile. Nothing appeared different. Reviewers: chad Reviewed By: chad Maniphest Tasks: T8918, T10077 Differential Revision: https://secure.phabricator.com/D14922
2016-01-01 13:26:36 +01:00
'PhabricatorPeopleMainMenuBarExtension' => 'applications/people/extension/PhabricatorPeopleMainMenuBarExtension.php',
Move user editing/management actions to a separate "Manage" item, like projects Summary: This improves consistency (by making this UI more similar to the projects UI) and gives us more flexibility the next time we update user profiles. Test Plan: {F1068889} Took all the actions (probably?) to check that all the redirects were updated. Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15104
2016-01-24 16:07:17 +01:00
'PhabricatorPeopleManageProfilePanel' => 'applications/people/profilepanel/PhabricatorPeopleManageProfilePanel.php',
Make user creation process simpler Summary: Fixes T4065. This divides user creation into separate "Standard User" and "Script/Bot" workflows which show only relevant fields and provide guidance. This fixes the verification mess associated with script/bot users by verifying their email addresses automatically. Test Plan: - Created a standard user. - Created a script/bot. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8674
2014-04-02 21:06:27 +02:00
'PhabricatorPeopleNewController' => 'applications/people/controller/PhabricatorPeopleNewController.php',
Refine global search UI for tokenizer functions Summary: Ref T4100. - Removes the "with unowned" checkbox in favor of the "no owners" function. - Support functions in "Authors" and "Owners". Test Plan: - Ran various global search and Maniphest queries. {F379931} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12523
2015-04-23 12:07:24 +02:00
'PhabricatorPeopleNoOwnerDatasource' => 'applications/people/typeahead/PhabricatorPeopleNoOwnerDatasource.php',
'PhabricatorPeopleOwnerDatasource' => 'applications/people/typeahead/PhabricatorPeopleOwnerDatasource.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPeopleProfileController' => 'applications/people/controller/PhabricatorPeopleProfileController.php',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
'PhabricatorPeopleProfileEditController' => 'applications/people/controller/PhabricatorPeopleProfileEditController.php',
Move user editing/management actions to a separate "Manage" item, like projects Summary: This improves consistency (by making this UI more similar to the projects UI) and gives us more flexibility the next time we update user profiles. Test Plan: {F1068889} Took all the actions (probably?) to check that all the redirects were updated. Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15104
2016-01-24 16:07:17 +01:00
'PhabricatorPeopleProfileManageController' => 'applications/people/controller/PhabricatorPeopleProfileManageController.php',
Convert user profiles to Profile Panels Summary: Ref T10054. Primary goal is to be able to remove IconNav from the codebase. I've made these non-editable so users can't customize them yet. We //might// want administrators to customize these globally instead? In any case, we avoid a bunch of product questions by just locking these down for now. Test Plan: {F1061348} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15020
2016-01-14 15:47:06 +01:00
'PhabricatorPeopleProfilePanelEngine' => 'applications/people/engine/PhabricatorPeopleProfilePanelEngine.php',
Improve UI for selecting profile pictures Summary: Ref T1703. Move profile pictures to a separate, dedicated interface. Instead of the 35 controls we currently provide, just show all the possible images we can find and then let the user upload an additional one if they want. Possible improvements to this interface: - Write an edge so we can show old profile pictures too. - The cropping/scaling got a bit buggy at some point, fix that. - Refresh OAuth sources which we're capable of refreshing before showing images (more work than I really want to deal with). - We could show little inset icons for the image source ("f" for Facebook, etc.) instead of just the tooltips. Test Plan: Chose images, uploaded new images, hit various error cases. {F49344} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2919, T1703 Differential Revision: https://secure.phabricator.com/D6398
2013-07-10 01:23:54 +02:00
'PhabricatorPeopleProfilePictureController' => 'applications/people/controller/PhabricatorPeopleProfilePictureController.php',
Convert user profiles to Profile Panels Summary: Ref T10054. Primary goal is to be able to remove IconNav from the codebase. I've made these non-editable so users can't customize them yet. We //might// want administrators to customize these globally instead? In any case, we avoid a bunch of product questions by just locking these down for now. Test Plan: {F1061348} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15020
2016-01-14 15:47:06 +01:00
'PhabricatorPeopleProfileViewController' => 'applications/people/controller/PhabricatorPeopleProfileViewController.php',
Implement ApplicationSearch in People Summary: Ref T2625. Fixes T2812. Implement ApplicationSearch in People. {F44788} Test Plan: Made People queries. Used Conduit. Used `@mentions`. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2625, T2812 Differential Revision: https://secure.phabricator.com/D6092
2013-05-31 19:51:20 +02:00
'PhabricatorPeopleQuery' => 'applications/people/query/PhabricatorPeopleQuery.php',
Move "Change Username" from weird edit panel to standard object action Summary: Ref T4065. Make this work in a more standard way which administrators have a reasonable shot at finding and using. See D8662 for discussion. Test Plan: Changed a user's username. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8663
2014-04-02 21:05:19 +02:00
'PhabricatorPeopleRenameController' => 'applications/people/controller/PhabricatorPeopleRenameController.php',
Implement ApplicationSearch in People Summary: Ref T2625. Fixes T2812. Implement ApplicationSearch in People. {F44788} Test Plan: Made People queries. Used Conduit. Used `@mentions`. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2625, T2812 Differential Revision: https://secure.phabricator.com/D6092
2013-05-31 19:51:20 +02:00
'PhabricatorPeopleSearchEngine' => 'applications/people/query/PhabricatorPeopleSearchEngine.php',
Successfully Generated People Summary: Ref T2903 Test Plan: Added new person whose profile was visible afterwards. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan, btrahan Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5682
2013-04-15 04:09:20 +02:00
'PhabricatorPeopleTestDataGenerator' => 'applications/people/lipsum/PhabricatorPeopleTestDataGenerator.php',
Implement PhabricatorApplicationTransactionInterface on PhabricatorUser Summary: Right now, "Publish" workers for user profile edits (title / blub) can get gummed up in the daemons. Implement the interfaces and provide a Query so they can go through. Test Plan: - Made a profile "Title" edit. - Used `bin/worker execute --id <id>` to see task fail. - Applied patch. - Saw task work. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D13213
2015-06-08 22:35:57 +02:00
'PhabricatorPeopleTransactionQuery' => 'applications/people/query/PhabricatorPeopleTransactionQuery.php',
Rename TypehaeadUserParameterizedDatasource to PeopleUserFunctionDatasource Summary: Ref T4100. This improves application scoping (Typeahead -> People) and uses a more consitent and concise name (Parameterized -> Function). Test Plan: - `grep` - Used affected datasource. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12532
2015-04-23 17:06:46 +02:00
'PhabricatorPeopleUserFunctionDatasource' => 'applications/people/typeahead/PhabricatorPeopleUserFunctionDatasource.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorPeopleUserPHIDType' => 'applications/people/phid/PhabricatorPeopleUserPHIDType.php',
Move "Send Welcome Email" to profiles and nuke old weird edit UI Summary: Ref T4065. Moves the last of the weird alternate edit UI to profiles. The old "Edit" controller is now for creation only, and the funky pencil icon is gone. Test Plan: Created accounts; sent welcome email. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8670
2014-04-02 21:06:17 +02:00
'PhabricatorPeopleWelcomeController' => 'applications/people/controller/PhabricatorPeopleWelcomeController.php',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorPersonaAuthProvider' => 'applications/auth/provider/PhabricatorPersonaAuthProvider.php',
Auth - restore Phabricator OAuth as a provider Summary: So meta it hurts. Fixes T887. Test Plan: created a second instance of phabricator locally. made an account on oauth server phabricator. set up my normal dev phabricator to use this new oauth phabricator. noted the form worked. created an account via the oauth method and it worked. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T887 Differential Revision: https://secure.phabricator.com/D11287
2015-01-09 01:28:04 +01:00
'PhabricatorPhabricatorAuthProvider' => 'applications/auth/provider/PhabricatorPhabricatorAuthProvider.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPhameApplication' => 'applications/phame/application/PhabricatorPhameApplication.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorPhameBlogPHIDType' => 'applications/phame/phid/PhabricatorPhameBlogPHIDType.php',
'PhabricatorPhamePostPHIDType' => 'applications/phame/phid/PhabricatorPhamePostPHIDType.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPhluxApplication' => 'applications/phlux/application/PhabricatorPhluxApplication.php',
'PhabricatorPholioApplication' => 'applications/pholio/application/PhabricatorPholioApplication.php',
MetaMTA: Owners, Pholio, Macro Summary: Port MetaMTA options for Owners, Pholio and Macro. At some point I'd like to get rid of all these options (provide one "reply domain", and not allow overrides of reply handlers -- use events instead) but that's a battle we can fight later. Test Plan: Looked at options, looked at setup issues, edited something. Reviewers: codeblock, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4469
2013-01-16 19:52:30 +01:00
'PhabricatorPholioConfigOptions' => 'applications/pholio/config/PhabricatorPholioConfigOptions.php',
Parse VCS revert langauge in commit messages Summary: Ref T1751. When commit messages include language like "reverts X", parse it. This change doesn't do anything with the commits yet. I attempted to cover all "natural" VCS messages and all reasonable human variations of these messages. Test Plan: Added unit tests. Added `var_dump()` and used `scripts/repository/reparse.php --message X` to reparse some commit messages, with expected results. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1751 Differential Revision: https://secure.phabricator.com/D5840
2013-05-06 21:33:37 +02:00
'PhabricatorPholioMockTestDataGenerator' => 'applications/pholio/lipsum/PhabricatorPholioMockTestDataGenerator.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPhortuneApplication' => 'applications/phortune/application/PhabricatorPhortuneApplication.php',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorPhortuneContentSource' => 'applications/phortune/contentsource/PhabricatorPhortuneContentSource.php',
Add some of a billing daemon skeleton Summary: Ref T6881. This adds the worker, and a script to make it easier to test. It doesn't actually invoice anything. I'm intentionally allowing the script to double-bill since it makes testing way easier (by letting you bill the same period over and over again), and provides a tool for recovery if billing screws up. (This diff isn't very interesting, just trying to avoid a 5K-line diff at the end.) Test Plan: Used `bin/phortune invoice ...` to get the worker to print out some date ranges which it would theoretically invoice. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11577
2015-01-30 20:29:05 +01:00
'PhabricatorPhortuneManagementInvoiceWorkflow' => 'applications/phortune/management/PhabricatorPhortuneManagementInvoiceWorkflow.php',
'PhabricatorPhortuneManagementWorkflow' => 'applications/phortune/management/PhabricatorPhortuneManagementWorkflow.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPhragmentApplication' => 'applications/phragment/application/PhabricatorPhragmentApplication.php',
'PhabricatorPhrequentApplication' => 'applications/phrequent/application/PhabricatorPhrequentApplication.php',
Implemented Phrequent time tracking functionality. Summary: This differential implements Phrequent's time tracking functionality for users and hooks it up to Maniphest. It also includes a basic "Time Tracked" list for the Phrequent application, where users can review what they've spent time working on. Test Plan: Apply the patch and track some things in Maniphest. They should appear in the "Time Tracked" view of Phrequent. There is also a `phrequent.show-prompt` option which toggles whether to display a prompt when tracking time. I'm unsure of whether the prompt is useful or is more likely to cause people to click "Track Time", go off and do the task and then come back to the prompt still waiting for them to confirm. A potential solution to the "accidentally clicking the button and recording 2 seconds of time" might be to show a prompt on stop if the total time is under 10 seconds, asking whether the user wants to keep or discard the tracked time. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2857 Differential Revision: https://secure.phabricator.com/D5479
2013-03-30 17:32:29 +01:00
'PhabricatorPhrequentConfigOptions' => 'applications/phrequent/config/PhabricatorPhrequentConfigOptions.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPhrictionApplication' => 'applications/phriction/application/PhabricatorPhrictionApplication.php',
Phriction setting. Summary: One setting. Test Plan: - Looked at the setting in the web interface. - Waved to it - Introduced myself - Had a nice conversation - Made a new friend - Turns out `phriction.enabled` is a nice guy. Reviewers: epriestley, chad Reviewed By: chad CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4436
2013-01-15 15:31:53 +01:00
'PhabricatorPhrictionConfigOptions' => 'applications/phriction/config/PhabricatorPhrictionConfigOptions.php',
DRAFT - throw together Phurl skeleton. Summary: DRAFT - throw together Phurl skeleton. Test Plan: The idea is that `some/long/url` will become `install/Udet4d` and can be viewed and edited at `install/Udet4d/view` and `install/Udet4d/edit`, respectively? Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: joshuaspence, chad, epriestley, Korvin Maniphest Tasks: T6049 Differential Revision: https://secure.phabricator.com/D13681
2015-07-24 20:06:27 +02:00
'PhabricatorPhurlApplication' => 'applications/phurl/application/PhabricatorPhurlApplication.php',
Allow a domain other than the install domain to serve as a short Phurl domain Summary: Ref T8995, config option for Phurl short domain to share shortened URL's Test Plan: - Configure Phurl short domain to something like "zz.us" - Navigate to `zz.us`; get 404 - Navigate to `zz.us/u/3` or `zz.us/u/alias` where `U3` is an existing Phurl; redirect to correct destination Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Maniphest Tasks: T8995 Differential Revision: https://secure.phabricator.com/D14447
2015-11-09 19:09:19 +01:00
'PhabricatorPhurlConfigOptions' => 'applications/config/option/PhabricatorPhurlConfigOptions.php',
DRAFT - throw together Phurl skeleton. Summary: DRAFT - throw together Phurl skeleton. Test Plan: The idea is that `some/long/url` will become `install/Udet4d` and can be viewed and edited at `install/Udet4d/view` and `install/Udet4d/edit`, respectively? Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: joshuaspence, chad, epriestley, Korvin Maniphest Tasks: T6049 Differential Revision: https://secure.phabricator.com/D13681
2015-07-24 20:06:27 +02:00
'PhabricatorPhurlController' => 'applications/phurl/controller/PhabricatorPhurlController.php',
'PhabricatorPhurlDAO' => 'applications/phurl/storage/PhabricatorPhurlDAO.php',
Add Phurl Remarkup Summary: Ref T9722, Add Phurl Remarkup as `((id))` or `((alias))` Test Plan: Add a comment to any object as `((id))` or `((alias))`. Make sure comment renders as a link. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T9722 Differential Revision: https://secure.phabricator.com/D14427
2015-11-06 22:47:52 +01:00
'PhabricatorPhurlLinkRemarkupRule' => 'applications/phurl/remarkup/PhabricatorPhurlLinkRemarkupRule.php',
'PhabricatorPhurlRemarkupRule' => 'applications/phurl/remarkup/PhabricatorPhurlRemarkupRule.php',
DRAFT - throw together Phurl skeleton. Summary: DRAFT - throw together Phurl skeleton. Test Plan: The idea is that `some/long/url` will become `install/Udet4d` and can be viewed and edited at `install/Udet4d/view` and `install/Udet4d/edit`, respectively? Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: joshuaspence, chad, epriestley, Korvin Maniphest Tasks: T6049 Differential Revision: https://secure.phabricator.com/D13681
2015-07-24 20:06:27 +02:00
'PhabricatorPhurlSchemaSpec' => 'applications/phurl/storage/PhabricatorPhurlSchemaSpec.php',
Allow a domain other than the install domain to serve as a short Phurl domain Summary: Ref T8995, config option for Phurl short domain to share shortened URL's Test Plan: - Configure Phurl short domain to something like "zz.us" - Navigate to `zz.us`; get 404 - Navigate to `zz.us/u/3` or `zz.us/u/alias` where `U3` is an existing Phurl; redirect to correct destination Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Maniphest Tasks: T8995 Differential Revision: https://secure.phabricator.com/D14447
2015-11-09 19:09:19 +01:00
'PhabricatorPhurlShortURLController' => 'applications/phurl/controller/PhabricatorPhurlShortURLController.php',
'PhabricatorPhurlShortURLDefaultController' => 'applications/phurl/controller/PhabricatorPhurlShortURLDefaultController.php',
DRAFT - throw together Phurl skeleton. Summary: DRAFT - throw together Phurl skeleton. Test Plan: The idea is that `some/long/url` will become `install/Udet4d` and can be viewed and edited at `install/Udet4d/view` and `install/Udet4d/edit`, respectively? Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: joshuaspence, chad, epriestley, Korvin Maniphest Tasks: T6049 Differential Revision: https://secure.phabricator.com/D13681
2015-07-24 20:06:27 +02:00
'PhabricatorPhurlURL' => 'applications/phurl/storage/PhabricatorPhurlURL.php',
Ref T8989, Phurl "Visit URL" link should route through a separate controller. Summary: Ref T8989, Phurl "Visit URL" should now route to an access controller that decides if the URL is valid whether to open it, or redirect back to Phurl object. New route is `local.install.com/u/1` to open link. Test Plan: - open Phurl object with invalid URL, "Visit URL" link should redirect back to object - open Phurl object with valid URL, "Visit URL" link should open the link - open `local.install.com/u/1` for `U1` with valid URL should open the link - open `local.install.com/u/1` for `U1` with invalid URL should redirect to `local.install.com/U1` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: joshuaspence, Korvin Maniphest Tasks: T8989 Differential Revision: https://secure.phabricator.com/D14381
2015-11-02 21:08:47 +01:00
'PhabricatorPhurlURLAccessController' => 'applications/phurl/controller/PhabricatorPhurlURLAccessController.php',
Remarkup links to link to short url instead of long and fix commenting on Phurl's Summary: Ref T6049, remarkup links to use short URLs and make commenting on Phurl's actually work Test Plan: - Create Phurl `U123` - Comment on that Phurl `((123))` Comment should link to `/u/123` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T6049 Differential Revision: https://secure.phabricator.com/D14477
2015-11-13 23:36:58 +01:00
'PhabricatorPhurlURLCommentController' => 'applications/phurl/controller/PhabricatorPhurlURLCommentController.php',
Ref T6049, Add Phurl URL create capability Summary: Ref T6049, Add Phurl URL create capability Test Plan: - Change {nav Home > Applications > Phurl > Configure} to allow no one to create Phurl URLs - Attempt {nav Phurl > Shorten URL}. Should not be able to create a Phurl. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T6049 Differential Revision: https://secure.phabricator.com/D14510
2015-11-18 21:24:09 +01:00
'PhabricatorPhurlURLCreateCapability' => 'applications/phurl/capability/PhabricatorPhurlURLCreateCapability.php',
DRAFT - throw together Phurl skeleton. Summary: DRAFT - throw together Phurl skeleton. Test Plan: The idea is that `some/long/url` will become `install/Udet4d` and can be viewed and edited at `install/Udet4d/view` and `install/Udet4d/edit`, respectively? Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: joshuaspence, chad, epriestley, Korvin Maniphest Tasks: T6049 Differential Revision: https://secure.phabricator.com/D13681
2015-07-24 20:06:27 +02:00
'PhabricatorPhurlURLEditController' => 'applications/phurl/controller/PhabricatorPhurlURLEditController.php',
'PhabricatorPhurlURLEditor' => 'applications/phurl/editor/PhabricatorPhurlURLEditor.php',
'PhabricatorPhurlURLListController' => 'applications/phurl/controller/PhabricatorPhurlURLListController.php',
Fix two issues with Phurl / Badges mail generation Summary: - Phurl is missing a ReplyHandler / MailReceiver (all of this code should get cleaned up eventually, but I don't plan to get to it for a while). - Badges has a bad call. This should clean up some bad daemon tasks. Test Plan: Saw fewer daemon errors after these changes. Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D14852
2015-12-22 17:05:56 +01:00
'PhabricatorPhurlURLMailReceiver' => 'applications/phurl/mail/PhabricatorPhurlURLMailReceiver.php',
DRAFT - throw together Phurl skeleton. Summary: DRAFT - throw together Phurl skeleton. Test Plan: The idea is that `some/long/url` will become `install/Udet4d` and can be viewed and edited at `install/Udet4d/view` and `install/Udet4d/edit`, respectively? Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: joshuaspence, chad, epriestley, Korvin Maniphest Tasks: T6049 Differential Revision: https://secure.phabricator.com/D13681
2015-07-24 20:06:27 +02:00
'PhabricatorPhurlURLPHIDType' => 'applications/phurl/phid/PhabricatorPhurlURLPHIDType.php',
'PhabricatorPhurlURLQuery' => 'applications/phurl/query/PhabricatorPhurlURLQuery.php',
Fix two issues with Phurl / Badges mail generation Summary: - Phurl is missing a ReplyHandler / MailReceiver (all of this code should get cleaned up eventually, but I don't plan to get to it for a while). - Badges has a bad call. This should clean up some bad daemon tasks. Test Plan: Saw fewer daemon errors after these changes. Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D14852
2015-12-22 17:05:56 +01:00
'PhabricatorPhurlURLReplyHandler' => 'applications/phurl/mail/PhabricatorPhurlURLReplyHandler.php',
DRAFT - throw together Phurl skeleton. Summary: DRAFT - throw together Phurl skeleton. Test Plan: The idea is that `some/long/url` will become `install/Udet4d` and can be viewed and edited at `install/Udet4d/view` and `install/Udet4d/edit`, respectively? Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: joshuaspence, chad, epriestley, Korvin Maniphest Tasks: T6049 Differential Revision: https://secure.phabricator.com/D13681
2015-07-24 20:06:27 +02:00
'PhabricatorPhurlURLSearchEngine' => 'applications/phurl/query/PhabricatorPhurlURLSearchEngine.php',
'PhabricatorPhurlURLTransaction' => 'applications/phurl/storage/PhabricatorPhurlURLTransaction.php',
'PhabricatorPhurlURLTransactionComment' => 'applications/phurl/storage/PhabricatorPhurlURLTransactionComment.php',
'PhabricatorPhurlURLTransactionQuery' => 'applications/phurl/query/PhabricatorPhurlURLTransactionQuery.php',
'PhabricatorPhurlURLViewController' => 'applications/phurl/controller/PhabricatorPhurlURLViewController.php',
Add a pirate translation Summary: Basic Pirate, mostly Maniphest Test Plan: Play lots with Maniphest Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14830
2015-12-20 16:03:07 +01:00
'PhabricatorPirateEnglishTranslation' => 'infrastructure/internationalization/translation/PhabricatorPirateEnglishTranslation.php',
Modularize Aphront "sites" Summary: Fixes T5702. The path here is long and windy: - I want to move `blog.phacility.com` to the new `secure` host. - That host has `security.require-https` set, which I want to keep set (before, this was handled in a sort of hacky way at the nginx/preamble level, but I've cleaned up everything else now). - Currently, that setting forces blogs to HTTPS too, which won't work. - To let blogs be individually configurable, we need to either modularize site config or make things hackier. - Modularize rather than increasing hackiness. - Also add a little "modules" panel in Config. See T6859. This feels like a reasonable middle ground between putting this stuff in Applications and burying it in `bin/somewhere`. Test Plan: - Visited normal site. - Visited phame on-domain site. - Visited phame off-domain site. - Viewed static resources. {F561897} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D13474
2015-06-29 23:04:48 +02:00
'PhabricatorPlatformSite' => 'aphront/site/PhabricatorPlatformSite.php',
Support enabling a formal points field in Maniphest Summary: Ref T4427. - New config option for labels, enabling, etc., but no UI/niceness yet. - When enabled, add a field. - Allow nonnegative values, including fractional values. - EditEngine is nice and Conduit / actions basically just work with a tiny bit of extra support code. Test Plan: - Edited points via "Edit". - Edited points via Conduit. - Edited points via stacked actions. - Tried to set "zebra" points. - Tried to set -1 points. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4427 Differential Revision: https://secure.phabricator.com/D15220
2016-02-09 00:24:52 +01:00
'PhabricatorPointsEditField' => 'applications/transactions/editfield/PhabricatorPointsEditField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPolicies' => 'applications/policy/constants/PhabricatorPolicies.php',
Add storage for custom policies Summary: Ref T603. Allows custom policies to be saved. No integration with policy controls yet. Test Plan: mysql> select * from policy where id = 3\G *************************** 1. row *************************** id: 3 phid: PHID-PLCY-e4v2fnbyuibi4supl5tn rules: [{"action":"allow","rule":"PhabricatorPolicyRuleAdministrators","value":null},{"action":"allow","rule":"PhabricatorPolicyRuleProjects","value":["PHID-PROJ-cwovm5gn2ilubjehcdgd"]},{"action":"allow","rule":"PhabricatorPolicyRuleLunarPhase","value":"new"}] defaultAction: deny dateCreated: 1381437466 dateModified: 1381437466 1 row in set (0.00 sec) Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7282
2013-10-11 01:09:51 +02:00
'PhabricatorPolicy' => 'applications/policy/storage/PhabricatorPolicy.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPolicyApplication' => 'applications/policy/application/PhabricatorPolicyApplication.php',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorPolicyAwareQuery' => 'infrastructure/query/policy/PhabricatorPolicyAwareQuery.php',
'PhabricatorPolicyAwareTestQuery' => 'applications/policy/__tests__/PhabricatorPolicyAwareTestQuery.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'PhabricatorPolicyCanEditCapability' => 'applications/policy/capability/PhabricatorPolicyCanEditCapability.php',
'PhabricatorPolicyCanJoinCapability' => 'applications/policy/capability/PhabricatorPolicyCanJoinCapability.php',
'PhabricatorPolicyCanViewCapability' => 'applications/policy/capability/PhabricatorPolicyCanViewCapability.php',
Allow applications to define new policy capabilities Summary: Ref T603. I want to let applications define new capabilities (like "can manage global rules" in Herald) and get full support for them, including reasonable error strings in the UI. Currently, this is difficult for a couple of reasons. Partly this is just a code organization issue, which is easy to fix. The bigger thing is that we have a bunch of strings which depend on both the policy and capability, like: "You must be an administrator to view this object." "Administrator" is the policy, and "view" is the capability. That means every new capability has to add a string for each policy, and every new policy (should we introduce any) needs to add a string for each capability. And we can't do any piecemeal "You must be a {$role} to {$action} this object" becuase it's impossible to translate. Instead, make all the strings depend on //only// the policy, //only// the capability, or //only// the object type. This makes the dialogs read a little more strangely, but I think it's still pretty easy to understand, and it makes adding new stuff way way easier. Also provide more context, and more useful exception messages. Test Plan: - See screenshots. - Also triggered a policy exception and verified it was dramatically more useful than it used to be. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7260
2013-10-07 22:28:58 +02:00
'PhabricatorPolicyCapability' => 'applications/policy/capability/PhabricatorPolicyCapability.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorPolicyCapabilityTestCase' => 'applications/policy/capability/__tests__/PhabricatorPolicyCapabilityTestCase.php',
Move policy config to "Policy" app and make `policy.allow-public` description scarier Summary: Ref T603. We have a real policy app now, so put the config options there. Revise the description of the public policy switch to make it clear that enabling it immediately opens up the user directory and various other interfaces. Test Plan: Viewed/edited config setting. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7154
2013-09-27 19:50:19 +02:00
'PhabricatorPolicyConfigOptions' => 'applications/policy/config/PhabricatorPolicyConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPolicyConstants' => 'applications/policy/constants/PhabricatorPolicyConstants.php',
Explain policy exception rules to users Summary: Ref T603. Adds clarifying text which expands on policies and explains exceptions and rules. The goal is to provide an easy way for users to learn about special policy rules, like "task owners can always see a task". This presentation might be a little aggressive. That's probably OK as we introduce policies, but something a little more tempered might be better down the road. Test Plan: See screenshot. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7150
2013-09-27 17:43:41 +02:00
'PhabricatorPolicyController' => 'applications/policy/controller/PhabricatorPolicyController.php',
Add storage for custom policies Summary: Ref T603. Allows custom policies to be saved. No integration with policy controls yet. Test Plan: mysql> select * from policy where id = 3\G *************************** 1. row *************************** id: 3 phid: PHID-PLCY-e4v2fnbyuibi4supl5tn rules: [{"action":"allow","rule":"PhabricatorPolicyRuleAdministrators","value":null},{"action":"allow","rule":"PhabricatorPolicyRuleProjects","value":["PHID-PROJ-cwovm5gn2ilubjehcdgd"]},{"action":"allow","rule":"PhabricatorPolicyRuleLunarPhase","value":"new"}] defaultAction: deny dateCreated: 1381437466 dateModified: 1381437466 1 row in set (0.00 sec) Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7282
2013-10-11 01:09:51 +02:00
'PhabricatorPolicyDAO' => 'applications/policy/storage/PhabricatorPolicyDAO.php',
Make Maniphest list page react to viewer capabilities Summary: Ref T603. Basically: - Hide "Reports". - Hide "batch edit" and "export to excel". - Hide reprioritization controls. - I left the edit controls, they show a "login to continue" dialog when hit. - Allow tokenizer results to fill for public users. - Fix a bug where membership in projects was computed incorrectly in certain cases. - Add a unit test covering the project membership bug. Test Plan: Viewed /maniphest/ when logged out, and while logged in. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7126
2013-09-25 22:45:04 +02:00
'PhabricatorPolicyDataTestCase' => 'applications/policy/__tests__/PhabricatorPolicyDataTestCase.php',
Custom Policy Editor Summary: Ref T603. This isn't remotely usable yet, but I wanted to get any feedback before I build it out anymore. I think this is a reasonable interface for defining custom policies? It's basically similar to Herald, although it's a bit simpler. I imagine users will rarely interact with this, but this will service the high end of policy complexity (and allow the definition of things like "is member of LDAP group" or whatever). Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, asherkin Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7217
2013-10-09 23:05:10 +02:00
'PhabricatorPolicyEditController' => 'applications/policy/controller/PhabricatorPolicyEditController.php',
Modularize application extensions to EditEngine Summary: Ref T9132. Currently, EditEngine had some branchy-`instanceof` code like this: ``` if ($object instanceof Whatever) { do_magic(); } if ($object instanceof SomethingElse) { do_other_magic(); } ``` ...where `Whatever` and `SomethingElse` are first-party applications like ProjectsInterface and SubscribersInterface. This kind of code is generally bad because third-parties can't add new stuff, and it suggest something is kind of hacky in its architecture. Ideally, we would eventually get rid of almost all of this. T9789 is a similar discussion of this for the next layer down (`TransactionEditor`) and plans to get rid of branchy-instanceofs there too. Since I'm about to add more stuff here (for Custom Fields), split it out first so I'm not digging us any deeper than I already dug us. Broadly, this allows third-party extensions to add fields to every EditEngine UI if they want, like we do for Policies, Subscribers, Projects and Comments today (and CustomFields soon). Test Plan: {F1007575} - Observed that all fields still appear on the form and seem to work correctly. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14599
2015-11-29 19:05:41 +01:00
'PhabricatorPolicyEditEngineExtension' => 'applications/policy/editor/PhabricatorPolicyEditEngineExtension.php',
Implement a basic version of ApplicationEditor in Paste Summary: Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste. This mostly looks and works like ApplicationSearch, and is heavily modeled on it. Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else. This has no functional changes, except: - I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it. - Subscribers are now editable. - Form field order is a little goofy (this will be fixed in a future diff). - Subscribers and projects are now race-resistant. The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits. Test Plan: - Created pastes. - Created pastes via API. - Edited pastes. - Edited every field. - Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4768, T9132 Differential Revision: https://secure.phabricator.com/D14390
2015-11-03 03:58:32 +01:00
'PhabricatorPolicyEditField' => 'applications/transactions/editfield/PhabricatorPolicyEditField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPolicyException' => 'applications/policy/exception/PhabricatorPolicyException.php',
Explain policy exception rules to users Summary: Ref T603. Adds clarifying text which expands on policies and explains exceptions and rules. The goal is to provide an easy way for users to learn about special policy rules, like "task owners can always see a task". This presentation might be a little aggressive. That's probably OK as we introduce policies, but something a little more tempered might be better down the road. Test Plan: See screenshot. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7150
2013-09-27 17:43:41 +02:00
'PhabricatorPolicyExplainController' => 'applications/policy/controller/PhabricatorPolicyExplainController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPolicyFilter' => 'applications/policy/filter/PhabricatorPolicyFilter.php',
'PhabricatorPolicyInterface' => 'applications/policy/interface/PhabricatorPolicyInterface.php',
Add a very simple `bin/policy` script for CLI policy administration Summary: Ref T603. I want to provide at least a basic CLI tool for fixing policy problems, since there are various ways users can lock themselves out of objects right now. Although I imagine we'll solve most of them in the application eventually, having a workaround in the meantime will probably make support a lot easier. This implements `bin/policy show <object>`, which shows an object's policy settings. In a future diff, I'll implement something like `bin/policy set --capability view --policy users <object>`, although maybe just `bin/policy unlock <object>` (which sets view and edit to "all users") would be better for now. Whichever way we go, it will be some blanket answer to people showing up in IRC having locked themselves out of objects which unblocks them while we work on preventing the issue in the first place. Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7171
2013-09-29 18:06:41 +02:00
'PhabricatorPolicyManagementShowWorkflow' => 'applications/policy/management/PhabricatorPolicyManagementShowWorkflow.php',
Add `bin/policy unlock` Summary: Ref T603. We might need a fine-grained CLI tool later on, but here's a bat we can bludgeon things with. Test Plan: - Ran `bin/policy unlock D12` (adjusted policies). - Ran `bin/policy unlock rPca85c457ebcb` (got "not mutable" stuff). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7189
2013-10-02 01:01:15 +02:00
'PhabricatorPolicyManagementUnlockWorkflow' => 'applications/policy/management/PhabricatorPolicyManagementUnlockWorkflow.php',
Add a very simple `bin/policy` script for CLI policy administration Summary: Ref T603. I want to provide at least a basic CLI tool for fixing policy problems, since there are various ways users can lock themselves out of objects right now. Although I imagine we'll solve most of them in the application eventually, having a workaround in the meantime will probably make support a lot easier. This implements `bin/policy show <object>`, which shows an object's policy settings. In a future diff, I'll implement something like `bin/policy set --capability view --policy users <object>`, although maybe just `bin/policy unlock <object>` (which sets view and edit to "all users") would be better for now. Whichever way we go, it will be some blanket answer to people showing up in IRC having locked themselves out of objects which unblocks them while we work on preventing the issue in the first place. Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7171
2013-09-29 18:06:41 +02:00
'PhabricatorPolicyManagementWorkflow' => 'applications/policy/management/PhabricatorPolicyManagementWorkflow.php',
Add storage for custom policies Summary: Ref T603. Allows custom policies to be saved. No integration with policy controls yet. Test Plan: mysql> select * from policy where id = 3\G *************************** 1. row *************************** id: 3 phid: PHID-PLCY-e4v2fnbyuibi4supl5tn rules: [{"action":"allow","rule":"PhabricatorPolicyRuleAdministrators","value":null},{"action":"allow","rule":"PhabricatorPolicyRuleProjects","value":["PHID-PROJ-cwovm5gn2ilubjehcdgd"]},{"action":"allow","rule":"PhabricatorPolicyRuleLunarPhase","value":"new"}] defaultAction: deny dateCreated: 1381437466 dateModified: 1381437466 1 row in set (0.00 sec) Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7282
2013-10-11 01:09:51 +02:00
'PhabricatorPolicyPHIDTypePolicy' => 'applications/policy/phid/PhabricatorPolicyPHIDTypePolicy.php',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorPolicyQuery' => 'applications/policy/query/PhabricatorPolicyQuery.php',
Modularize Aphront exception handling Summary: Ref T1806. Ref T7173. Depends on D14047. Currently, all exception handling is in this big messy clump in `AphrontDefaultApplicationConfiguration`. Split it out into modular classes. This will let a future change add new classes in the Phacility cluster which intercept particular exceptions we care about and replaces the default, generic responses with more useful, tailored responses. Test Plan: {F777391} - Hit a Conduit error (made a method throw). - Hit an Ajax error (made comment preview throw). - Hit a high security error (tried to edit TOTP). - Hit a rate limiting error (added a bunch of email addresses). - Hit a policy error (tried to look at something with no permission). - Hit an arbitrary exception (made a randomc ontroller throw). Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14049
2015-09-03 19:04:42 +02:00
'PhabricatorPolicyRequestExceptionHandler' => 'aphront/handler/PhabricatorPolicyRequestExceptionHandler.php',
Custom Policy Editor Summary: Ref T603. This isn't remotely usable yet, but I wanted to get any feedback before I build it out anymore. I think this is a reasonable interface for defining custom policies? It's basically similar to Herald, although it's a bit simpler. I imagine users will rarely interact with this, but this will service the high end of policy complexity (and allow the definition of things like "is member of LDAP group" or whatever). Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, asherkin Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7217
2013-10-09 23:05:10 +02:00
'PhabricatorPolicyRule' => 'applications/policy/rule/PhabricatorPolicyRule.php',
Implement a rough initial version of ApplicationSearch-driven Conduit read endpoints Summary: Ref T9964. See that task for some context and discussion. Ref T7715, which has the bigger picture here. Basically, I want Conduit read endpoints to be full-power, ApplicationSearch-driven endpoints, so that applications can: - Write one EditEngine and get web + conduit writes for free. - Write one SearchEngine and get web + conduit reads for free. I previously made some steps toward this, but this puts more of the structure in place. Test Plan: Viewed API console endpoint and read 20 pages of docs: {F1021961} Made various calls: with query keys, constraints, pagination, and limits. Viewed new {nav Config > Modules} page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7715, T9964 Differential Revision: https://secure.phabricator.com/D14743
2015-12-11 17:45:56 +01:00
'PhabricatorPolicySearchEngineExtension' => 'applications/policy/engineextension/PhabricatorPolicySearchEngineExtension.php',
Move policy tests back into policy/ Summary: These were in an unusual location, but are better back in policy/ Test Plan: implicit arc unit Reviewers: vrana Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2638
2012-06-01 21:39:29 +02:00
'PhabricatorPolicyTestCase' => 'applications/policy/__tests__/PhabricatorPolicyTestCase.php',
'PhabricatorPolicyTestObject' => 'applications/policy/__tests__/PhabricatorPolicyTestObject.php',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorPolicyType' => 'applications/policy/constants/PhabricatorPolicyType.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPonderApplication' => 'applications/ponder/application/PhabricatorPonderApplication.php',
Begin modularizing profile panel/link construction Summary: Ref T10054. This has no product impact, but prepares us for customizable side nav on "profiles" (today, projects; probably users some day; and maybe other stuff down the road). Test Plan: Clicked all links on a profile, everything was exactly the same as before. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15007
2016-01-12 19:27:39 +01:00
'PhabricatorProfilePanel' => 'applications/search/profilepanel/PhabricatorProfilePanel.php',
'PhabricatorProfilePanelConfiguration' => 'applications/search/storage/PhabricatorProfilePanelConfiguration.php',
'PhabricatorProfilePanelConfigurationQuery' => 'applications/search/query/PhabricatorProfilePanelConfigurationQuery.php',
'PhabricatorProfilePanelConfigurationTransaction' => 'applications/search/storage/PhabricatorProfilePanelConfigurationTransaction.php',
Add a missing transaction query class for panel transactions Summary: Ref T10054. The daemons look for this but currently can't find it. Test Plan: Ran daemons, clean exit on profile menu edits instead of permanent failure. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15053
2016-01-19 16:28:10 +01:00
'PhabricatorProfilePanelConfigurationTransactionQuery' => 'applications/search/query/PhabricatorProfilePanelConfigurationTransactionQuery.php',
Make "profile menu" configuration mostly work Summary: Ref T10054. This does a big chunk of the legwork to let users reconfigure profile menus (currently, just project menus). This includes: - Editing builtin items (e.g., you can rename the default items). - Creating new items (for now, only links are available). This does not yet include: - Hiding items. - Reordering items. - Lots of fancy types of items (dashboards, etc). - Any UI changes. - Documentation (does feature: TODO link for documentation). Test Plan: {F1060695} {F1060696} {F1060697} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15010
2016-01-13 00:06:43 +01:00
'PhabricatorProfilePanelEditEngine' => 'applications/search/editor/PhabricatorProfilePanelEditEngine.php',
'PhabricatorProfilePanelEditor' => 'applications/search/editor/PhabricatorProfilePanelEditor.php',
Begin modularizing profile panel/link construction Summary: Ref T10054. This has no product impact, but prepares us for customizable side nav on "profiles" (today, projects; probably users some day; and maybe other stuff down the road). Test Plan: Clicked all links on a profile, everything was exactly the same as before. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15007
2016-01-12 19:27:39 +01:00
'PhabricatorProfilePanelEngine' => 'applications/search/engine/PhabricatorProfilePanelEngine.php',
Make "profile menu" configuration mostly work Summary: Ref T10054. This does a big chunk of the legwork to let users reconfigure profile menus (currently, just project menus). This includes: - Editing builtin items (e.g., you can rename the default items). - Creating new items (for now, only links are available). This does not yet include: - Hiding items. - Reordering items. - Lots of fancy types of items (dashboards, etc). - Any UI changes. - Documentation (does feature: TODO link for documentation). Test Plan: {F1060695} {F1060696} {F1060697} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15010
2016-01-13 00:06:43 +01:00
'PhabricatorProfilePanelIconSet' => 'applications/search/profilepanel/PhabricatorProfilePanelIconSet.php',
Begin modularizing profile panel/link construction Summary: Ref T10054. This has no product impact, but prepares us for customizable side nav on "profiles" (today, projects; probably users some day; and maybe other stuff down the road). Test Plan: Clicked all links on a profile, everything was exactly the same as before. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15007
2016-01-12 19:27:39 +01:00
'PhabricatorProfilePanelPHIDType' => 'applications/search/phidtype/PhabricatorProfilePanelPHIDType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProject' => 'applications/project/storage/PhabricatorProject.php',
Modularize "add projects" and "remove projects" Herald actions Summary: Ref T8726. Convert these to be modular. Test Plan: - Created rules using these actions. - Upgraded them. - Verified they still work. {F659266} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13705
2015-07-24 19:56:52 +02:00
'PhabricatorProjectAddHeraldAction' => 'applications/project/herald/PhabricatorProjectAddHeraldAction.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorProjectApplication' => 'applications/project/application/PhabricatorProjectApplication.php',
Move "Archive Project" to a standard, separate action Summary: Ref T4379. Projects currently include their "delete/disable" function as part of edit, which is atypical. Instead, provide it as a first-class action. This is primarily for consistency between applications. (The action list on projects is getting pretty huge, but we can deal with that separately; I have some ideas.) Test Plan: Archived/unarchived a project. Edited a project. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4379 Differential Revision: https://secure.phabricator.com/D8177
2014-02-10 23:30:47 +01:00
'PhabricatorProjectArchiveController' => 'applications/project/controller/PhabricatorProjectArchiveController.php',
Allow workboard background colors to be configured Summary: Adds a UI for selecting background colors. You can choose "Use Parent", which is the default, and allows you to set a color that all descendants inherit. You can also choose "None", if a parent has a WHACKY BACKGROUND that you refuse to put up with. Test Plan: {F1114588} {F1114589} Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15279
2016-02-16 15:52:32 +01:00
'PhabricatorProjectBoardBackgroundController' => 'applications/project/controller/PhabricatorProjectBoardBackgroundController.php',
Add a secret board view to Projects Summary: Ref T1344. This is //very// rough. Some UI issues: - Empty states for the board and columns are junky. - Column widths are crazy. I think we need to set them to fixed-width, since we may have an arbitrarily large number of columns? - I don't think we have the header UI elements in M10 yet and that mock is pretty old, so I sort of very roughly approximated it. - What should we do when you click a task title? Popping the whole task in a dialog is possible but needs a bunch of work to actually work. Might need to build "sheets" or something. - Icons are slightly clipped for some reason. - All the backend stuff is totally faked. Generally, my plan is just to use these to implement all of T390. Specifically: - "Kanban" projects will have "Backlog" on the left. You'll drag them toward the right as you make progress. - "Milestone" projects will have "No Milestone" on the left, then "Milestone 9", "Milestone 8", etc. - "Sprint" projects will have "Backlog" on the left, then "Sprint 31", "Sprint 30", etc. So all of these things end up being pretty much exactly the same, with some minor text changes and new columns showing up on the left vs the right or whatever. Test Plan: See screenshot. Reviewers: chad, btrahan Reviewed By: btrahan CC: chad, aran, sascha-egerer Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7374
2013-10-22 06:11:36 +02:00
'PhabricatorProjectBoardController' => 'applications/project/controller/PhabricatorProjectBoardController.php',
Allow workboards to be disabled, hiding "(Backlog)" column annotations Summary: Fixes T7410. - Adds a "Disable Workboard" action to the "Manage Backlog" menu. - We'll probably move this somewhere else if/when that column gets too messy. - Disabling a board hides it, prevents it from being recreated by non-editors, and hides the "Project (Backlog)" annotations. - Resotring a board puts it back in pristine condition. Test Plan: - Disabled a board. - Verified "(Backlog)" annotations vanished. - Enabled a board. Reviewers: chad Reviewed By: chad Subscribers: mbishopim3 Maniphest Tasks: T7410 Differential Revision: https://secure.phabricator.com/D15215
2016-02-08 20:24:32 +01:00
'PhabricatorProjectBoardDisableController' => 'applications/project/controller/PhabricatorProjectBoardDisableController.php',
Workboards - add new "initialization" flow Summary: Currently, we just create a default "backlog" column if / when you visit a workboard for the first time. Post this patch, instead you see a blocking dialog that lets you either create the default backlog column or import columns from another project. In the case of the latter, the user gets another dialog which lets them select any project of which they are a member that also has columns in it. Note that only not hidden columns get imported. Fixes T4431. Test Plan: - made a new workboard and got my new dialog. made a default backlog and it worked! - made a new workboard again and tried the import flow - it also worked. - verified projects with no columns do not show up in import dialog - verified project with / without columns still all show up in maniphest project typeahead Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4431 Differential Revision: https://secure.phabricator.com/D10153
2014-08-05 22:40:41 +02:00
'PhabricatorProjectBoardImportController' => 'applications/project/controller/PhabricatorProjectBoardImportController.php',
Move uncommon workboard management options to "Manage Board" view Summary: This gives us room for less-common workboard management options like "Disable Board" without overloading the menus on the main board. Particularly, we can add background color options here without anything getting weird. I've left "Add Column" on the main UI since I think it's common enough to leave there. We could probably move "Hide Column" to this UI in the future, though. Test Plan: {F1114475} Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15278
2016-02-16 15:24:15 +01:00
'PhabricatorProjectBoardManageController' => 'applications/project/controller/PhabricatorProjectBoardManageController.php',
Allow board columns to be reordered Summary: Fixes T4567. This isn't going to win design awards and we have some leaky CSS, but it works fine. Test Plan: {F176743} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T4567 Differential Revision: https://secure.phabricator.com/D9905
2014-07-12 04:27:07 +02:00
'PhabricatorProjectBoardReorderController' => 'applications/project/controller/PhabricatorProjectBoardReorderController.php',
Workboards - add column detail page Summary: followup to D8544. This ends up creating an editor + transactions to get the job done. Test Plan: made a column - saw a nice created transaction. edited the name - saw a nice name edit. deleted the column - saw a deleted transaction, updated "deleted" ui, and hte action change to activate. "Activated" the column and saw a transaction and updated UI. Tried to delete a column with tasks in it and got an error. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D8620
2014-03-26 22:40:47 +01:00
'PhabricatorProjectBoardViewController' => 'applications/project/controller/PhabricatorProjectBoardViewController.php',
Add ProjectCardView, use on Hovercards Summary: Builds a new ProjectCardView, starts basic Project Hovercard redesign (needs milestone, subproject support). Ref T10055 Test Plan: View all the colors. {F1092622} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T10055 Differential Revision: https://secure.phabricator.com/D15186
2016-02-05 05:11:36 +01:00
'PhabricatorProjectCardView' => 'applications/project/view/PhabricatorProjectCardView.php',
Allow project colors to be relabeled Summary: Fixes T5819. Adds configuration for setting color labels on projects and changing the default. Options are locked to what we make available. Test Plan: {F1066823} Reviewers: chad Reviewed By: chad Maniphest Tasks: T5819 Differential Revision: https://secure.phabricator.com/D15088
2016-01-22 13:33:23 +01:00
'PhabricatorProjectColorsConfigOptionType' => 'applications/project/config/PhabricatorProjectColorsConfigOptionType.php',
Add a secret board view to Projects Summary: Ref T1344. This is //very// rough. Some UI issues: - Empty states for the board and columns are junky. - Column widths are crazy. I think we need to set them to fixed-width, since we may have an arbitrarily large number of columns? - I don't think we have the header UI elements in M10 yet and that mock is pretty old, so I sort of very roughly approximated it. - What should we do when you click a task title? Popping the whole task in a dialog is possible but needs a bunch of work to actually work. Might need to build "sheets" or something. - Icons are slightly clipped for some reason. - All the backend stuff is totally faked. Generally, my plan is just to use these to implement all of T390. Specifically: - "Kanban" projects will have "Backlog" on the left. You'll drag them toward the right as you make progress. - "Milestone" projects will have "No Milestone" on the left, then "Milestone 9", "Milestone 8", etc. - "Sprint" projects will have "Backlog" on the left, then "Sprint 31", "Sprint 30", etc. So all of these things end up being pretty much exactly the same, with some minor text changes and new columns showing up on the left vs the right or whatever. Test Plan: See screenshot. Reviewers: chad, btrahan Reviewed By: btrahan CC: chad, aran, sascha-egerer Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7374
2013-10-22 06:11:36 +02:00
'PhabricatorProjectColumn' => 'applications/project/storage/PhabricatorProjectColumn.php',
Workboards - add column detail page Summary: followup to D8544. This ends up creating an editor + transactions to get the job done. Test Plan: made a column - saw a nice created transaction. edited the name - saw a nice name edit. deleted the column - saw a deleted transaction, updated "deleted" ui, and hte action change to activate. "Activated" the column and saw a transaction and updated UI. Tried to delete a column with tasks in it and got an error. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D8620
2014-03-26 22:40:47 +01:00
'PhabricatorProjectColumnDetailController' => 'applications/project/controller/PhabricatorProjectColumnDetailController.php',
Allow columns to have a point limit Summary: Fixes T5885. This implements optional soft point limits for workboard columns, per traditional Kanban. - Allow columns to have a point limit set. - When a column has a point limit, show it in the header. - If a column has too many points in it, show the column and point count in red. @chad, this could probably use some design tweaks. In particular: - I changed the color of "hidden" columns to avoid confusion with "overfull" columns. We might be able to find a better color. - UI hints for overfull columns might need adjustment. (After T4427, we'll let you sum some custom field instead of total number of tasks, which is why this is called "points" rather than "number of tasks".) Test Plan: {F190914} Note that: - "Pre-planning" has a limit, so it shows "4/12". - "Planning" has a limit and is overfull, so it shows "5 / 4". - Other columns do not have limits. - "Post-planning" is a hidden column. This might be too muted now. Transactions: {F190915} Error messages / edit screen: {F190916} Reviewers: btrahan, chad Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T5885 Differential Revision: https://secure.phabricator.com/D10276
2014-08-15 20:16:08 +02:00
'PhabricatorProjectColumnEditController' => 'applications/project/controller/PhabricatorProjectColumnEditController.php',
Move column hide/show to the column context menu on workboards Summary: Fixes T5993. Now that we have a context menu we can make some edit operations easier to access. Test Plan: Toggled column visibility. Verified board state (columns shown/hidden, ordering) was retained. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5993 Differential Revision: https://secure.phabricator.com/D10417
2014-09-04 21:47:32 +02:00
'PhabricatorProjectColumnHideController' => 'applications/project/controller/PhabricatorProjectColumnHideController.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorProjectColumnPHIDType' => 'applications/project/phid/PhabricatorProjectColumnPHIDType.php',
Move board relationships to dedicated storage Summary: Fixes T5476. Using edges to store which objects are on which board columns ends up being pretty awkward. In particular, it makes T4807 very difficult to implement. Introduce a dedicated `BoardColumnPosition` storage. This doesn't affect ordering rules (T4807) yet: boards are still arranged by priority. We just read which tasks are on which columns out of a new table. Test Plan: - Migrated data, then viewed some boards. Saw exactly the same data. - Dragged tasks from column to column. - Created a task directly into a column. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5476 Differential Revision: https://secure.phabricator.com/D10160
2014-08-07 00:09:09 +02:00
'PhabricatorProjectColumnPosition' => 'applications/project/storage/PhabricatorProjectColumnPosition.php',
'PhabricatorProjectColumnPositionQuery' => 'applications/project/query/PhabricatorProjectColumnPositionQuery.php',
Add a secret board view to Projects Summary: Ref T1344. This is //very// rough. Some UI issues: - Empty states for the board and columns are junky. - Column widths are crazy. I think we need to set them to fixed-width, since we may have an arbitrarily large number of columns? - I don't think we have the header UI elements in M10 yet and that mock is pretty old, so I sort of very roughly approximated it. - What should we do when you click a task title? Popping the whole task in a dialog is possible but needs a bunch of work to actually work. Might need to build "sheets" or something. - Icons are slightly clipped for some reason. - All the backend stuff is totally faked. Generally, my plan is just to use these to implement all of T390. Specifically: - "Kanban" projects will have "Backlog" on the left. You'll drag them toward the right as you make progress. - "Milestone" projects will have "No Milestone" on the left, then "Milestone 9", "Milestone 8", etc. - "Sprint" projects will have "Backlog" on the left, then "Sprint 31", "Sprint 30", etc. So all of these things end up being pretty much exactly the same, with some minor text changes and new columns showing up on the left vs the right or whatever. Test Plan: See screenshot. Reviewers: chad, btrahan Reviewed By: btrahan CC: chad, aran, sascha-egerer Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7374
2013-10-22 06:11:36 +02:00
'PhabricatorProjectColumnQuery' => 'applications/project/query/PhabricatorProjectColumnQuery.php',
Workboards - add column detail page Summary: followup to D8544. This ends up creating an editor + transactions to get the job done. Test Plan: made a column - saw a nice created transaction. edited the name - saw a nice name edit. deleted the column - saw a deleted transaction, updated "deleted" ui, and hte action change to activate. "Activated" the column and saw a transaction and updated UI. Tried to delete a column with tasks in it and got an error. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D8620
2014-03-26 22:40:47 +01:00
'PhabricatorProjectColumnTransaction' => 'applications/project/storage/PhabricatorProjectColumnTransaction.php',
'PhabricatorProjectColumnTransactionEditor' => 'applications/project/editor/PhabricatorProjectColumnTransactionEditor.php',
'PhabricatorProjectColumnTransactionQuery' => 'applications/project/query/PhabricatorProjectColumnTransactionQuery.php',
Implement custom fields in Projects Summary: Ref T4379. Ref T3794. Fixes T4010. This brings CustomFields to projects. My primary goal is to get rid of the special casing around project profiles and profile editing, so all edits are ApplicationTransactions. Particularly, I want to make the "blurb/description" field a custom field which goes through builtin infrastructure. A distant secondary goal is that this is a feature which users like/want because users like/want features. Test Plan: Added a custom field and examined it in the edit, view, and search interfaces. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3794, T4010, T4379 Differential Revision: https://secure.phabricator.com/D8180
2014-02-10 23:31:34 +01:00
'PhabricatorProjectConfigOptions' => 'applications/project/config/PhabricatorProjectConfigOptions.php',
'PhabricatorProjectConfiguredCustomField' => 'applications/project/customfield/PhabricatorProjectConfiguredCustomField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProjectController' => 'applications/project/controller/PhabricatorProjectController.php',
Simplify ProjectQuery handling of viewer membership Summary: Ref T10010. Currently, we do an unusual JOIN to make testing for viewer membership in projects a little cheaper. This won't work as-is once we have subprojects, so standardize, simplify, and cover it with more tests for now. (I may be able to get a similar optimization later, but want a correct implementation first.) Test Plan: This change should create no behavioral differences. - Added tests. - Ran tests. - Viewed projects. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14859
2015-12-23 12:42:42 +01:00
'PhabricatorProjectCoreTestCase' => 'applications/project/__tests__/PhabricatorProjectCoreTestCase.php',
Support drag-and-drop to set cover images on workboard cards Summary: This was slightly more complex than I believed, but not too terrible. Test Plan: {F1096126} - Also used some normal file uploaders to make sure I didn't break that. Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15202
2016-02-06 23:05:15 +01:00
'PhabricatorProjectCoverController' => 'applications/project/controller/PhabricatorProjectCoverController.php',
Implement custom fields in Projects Summary: Ref T4379. Ref T3794. Fixes T4010. This brings CustomFields to projects. My primary goal is to get rid of the special casing around project profiles and profile editing, so all edits are ApplicationTransactions. Particularly, I want to make the "blurb/description" field a custom field which goes through builtin infrastructure. A distant secondary goal is that this is a feature which users like/want because users like/want features. Test Plan: Added a custom field and examined it in the edit, view, and search interfaces. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3794, T4010, T4379 Differential Revision: https://secure.phabricator.com/D8180
2014-02-10 23:31:34 +01:00
'PhabricatorProjectCustomField' => 'applications/project/customfield/PhabricatorProjectCustomField.php',
Add a secret board view to Projects Summary: Ref T1344. This is //very// rough. Some UI issues: - Empty states for the board and columns are junky. - Column widths are crazy. I think we need to set them to fixed-width, since we may have an arbitrarily large number of columns? - I don't think we have the header UI elements in M10 yet and that mock is pretty old, so I sort of very roughly approximated it. - What should we do when you click a task title? Popping the whole task in a dialog is possible but needs a bunch of work to actually work. Might need to build "sheets" or something. - Icons are slightly clipped for some reason. - All the backend stuff is totally faked. Generally, my plan is just to use these to implement all of T390. Specifically: - "Kanban" projects will have "Backlog" on the left. You'll drag them toward the right as you make progress. - "Milestone" projects will have "No Milestone" on the left, then "Milestone 9", "Milestone 8", etc. - "Sprint" projects will have "Backlog" on the left, then "Sprint 31", "Sprint 30", etc. So all of these things end up being pretty much exactly the same, with some minor text changes and new columns showing up on the left vs the right or whatever. Test Plan: See screenshot. Reviewers: chad, btrahan Reviewed By: btrahan CC: chad, aran, sascha-egerer Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7374
2013-10-22 06:11:36 +02:00
'PhabricatorProjectCustomFieldNumericIndex' => 'applications/project/storage/PhabricatorProjectCustomFieldNumericIndex.php',
'PhabricatorProjectCustomFieldStorage' => 'applications/project/storage/PhabricatorProjectCustomFieldStorage.php',
'PhabricatorProjectCustomFieldStringIndex' => 'applications/project/storage/PhabricatorProjectCustomFieldStringIndex.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProjectDAO' => 'applications/project/storage/PhabricatorProjectDAO.php',
Modernize "projects" typeahead datasource Summary: Ref T4420. Update "projects" source. Test Plan: - Edited projects on a Differential revision. - Edited projects on a commit. - Edited projects on a repository. - Edited projects in feed search. - Edited projects in a Herald rule field. - Edited projects in a Herald rule action. - Edited projects in Maniphest batch editor. - Edited projects on Maniphest task. - Edited projects in "Associate Projects..." action in Maniphest. - Edited projects on Maniphest search in "all projects", "any project" and "not projects" fields. - Edited projects on a Paste. - Edited projects on a Pholio mock. - Edited projects on a custom policy rule. - Edited projects on a Ponder question. - Edited projects on a Diffusion search query. - Edited projects on a global search query. - Edited projects on a slowvote. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9884
2014-07-11 02:28:29 +02:00
'PhabricatorProjectDatasource' => 'applications/project/typeahead/PhabricatorProjectDatasource.php',
Allow workboard sorting and filtering to be saved as defaults Summary: Fixes T6641. This allows users who have permission to edit a project to use "Save as Default" to save the current order and filter as defaults for the project. These are per-board defaults, and apply to all users. The rationale is that I think the best default ordering/filtering depends mostly on the board, not the viewer. This seems to align with most requests in the task, although rationale is a bit light. But, for example, it seems reasonable you might want to change the default filter to "All Tasks" on a sprint board, so you can see what's in the "Done" column. This also fixes some minor issues I ran into: - Herald could hit an issue while checking permissions if the project was a subproject and a non-member had a triggering rule. - "Advanced filter..." did not prefill with the current filter. Test Plan: - Set default order and filter on a workboard. - Reloaded board, saw settings stick. - Tried to edit a board as an unprivileged user (disabled menu items, error). - Reviewed transaction log. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6641 Differential Revision: https://secure.phabricator.com/D15260
2016-02-12 15:19:26 +01:00
'PhabricatorProjectDefaultController' => 'applications/project/controller/PhabricatorProjectDefaultController.php',
Migrate project blurb/description to standard custom field storage Summary: Ref T4379. Major goal here is to remove `ProjectProfile` so all edits use ApplicationTransactions. This also makes things more flexible, allowing users to disable this field if they don't like it. Test Plan: Ran migration, verified data survived, edited/created projects, reordered fields. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4379 Differential Revision: https://secure.phabricator.com/D8182
2014-02-10 23:31:57 +01:00
'PhabricatorProjectDescriptionField' => 'applications/project/customfield/PhabricatorProjectDescriptionField.php',
Begin modularizing profile panel/link construction Summary: Ref T10054. This has no product impact, but prepares us for customizable side nav on "profiles" (today, projects; probably users some day; and maybe other stuff down the road). Test Plan: Clicked all links on a profile, everything was exactly the same as before. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15007
2016-01-12 19:27:39 +01:00
'PhabricatorProjectDetailsProfilePanel' => 'applications/project/profilepanel/PhabricatorProjectDetailsProfilePanel.php',
Convert projects to EditEngine Summary: Ref T10010. This is pretty straightforward with a couple of very minor new behaviors, like the icon selector edit field. Test Plan: - Created projects. - Edited projects. - Saw "Create Project" in quick create menu. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14896
2015-12-27 15:45:53 +01:00
'PhabricatorProjectEditController' => 'applications/project/controller/PhabricatorProjectEditController.php',
'PhabricatorProjectEditEngine' => 'applications/project/engine/PhabricatorProjectEditEngine.php',
Merge some of the project editing options into an edit UI Summary: Ref T4426. This moves "Edit Details", "Edit Picture", and "Archive" to a separate "Edit" interface. "History" becomes part of this UI. Test Plan: {F114417} {F114418} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T4426 Differential Revision: https://secure.phabricator.com/D8248
2014-02-17 05:17:52 +01:00
'PhabricatorProjectEditPictureController' => 'applications/project/controller/PhabricatorProjectEditPictureController.php',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorProjectFulltextEngine' => 'applications/project/search/PhabricatorProjectFulltextEngine.php',
Modularize "add projects" and "remove projects" Herald actions Summary: Ref T8726. Convert these to be modular. Test Plan: - Created rules using these actions. - Upgraded them. - Verified they still work. {F659266} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13705
2015-07-24 19:56:52 +02:00
'PhabricatorProjectHeraldAction' => 'applications/project/herald/PhabricatorProjectHeraldAction.php',
Add Herald support for projects Summary: Ref T10054. Ref T6113. I'm going to remove subscribers from projects to fix the confusion between "watch" and "subscribe". Users who have unusual use cases where they legitimately want to know when a project's description is updated or members change can use Herald to follow it. This is also useful in general and improves consistency, although I don't have too many use cases for it. Test Plan: Wrote a Herald rule, edited a project, saw the rule fire and send me email about the change. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6113, T10054 Differential Revision: https://secure.phabricator.com/D15061
2016-01-20 02:18:17 +01:00
'PhabricatorProjectHeraldAdapter' => 'applications/project/herald/PhabricatorProjectHeraldAdapter.php',
'PhabricatorProjectHeraldFieldGroup' => 'applications/project/herald/PhabricatorProjectHeraldFieldGroup.php',
New People Hovercards Summary: Mimics the Project Hovercards, more custom UI. Test Plan: Hover over person with and without badges, hover over project. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15253
2016-02-11 23:55:44 +01:00
'PhabricatorProjectHovercardEngineExtension' => 'applications/project/engineextension/PhabricatorProjectHovercardEngineExtension.php',
Provide a "PHUIFormIconSetControl" Summary: Ref T9992. This is a step on the path to getting EditEngine working in Badges, Projects and Calendar. This doesn't add a new `EditField` for icons yet, just standardizes the old stuff. New stuff is more general and I saved 150 lines of code. I put the endpoint in Files because the similar "choose a profile picture" endpoint will definitely go there, and this endpoint might eventually feature, like, "draw your own icon~~" or something. Test Plan: - Created events, projects and badges with custom icons. - Edited events, projects and badges, changing their icons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9992 Differential Revision: https://secure.phabricator.com/D14799
2015-12-16 16:53:13 +01:00
'PhabricatorProjectIconSet' => 'applications/project/icon/PhabricatorProjectIconSet.php',
Allow project colors to be relabeled Summary: Fixes T5819. Adds configuration for setting color labels on projects and changing the default. Options are locked to what we make available. Test Plan: {F1066823} Reviewers: chad Reviewed By: chad Maniphest Tasks: T5819 Differential Revision: https://secure.phabricator.com/D15088
2016-01-22 13:33:23 +01:00
'PhabricatorProjectIconsConfigOptionType' => 'applications/project/config/PhabricatorProjectIconsConfigOptionType.php',
Implement PhabricatorProjectInterface for marking that objects can be tagged with projects Summary: Ref T2628. This makes Transactions understand objects that can have project relationships, extract project mentions, and handle watching. Test Plan: See next diff. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2628 Differential Revision: https://secure.phabricator.com/D9340
2014-06-04 02:19:40 +02:00
'PhabricatorProjectInterface' => 'applications/project/interface/PhabricatorProjectInterface.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProjectListController' => 'applications/project/controller/PhabricatorProjectListController.php',
Add very basic UI for creating milestones and subprojects Summary: Ref T10010. This has a lot of UI/UX problems but I think it: - technically allows subproject creation; - technically allows milestone creation; - doesn't let users unwittingly destroy their installs (probably). Test Plan: - Created milestones. - Created subprojects. - Created and edited normal projects. - Observed some reasonable interactions (e.g., you can't create milestones for a milestone or edit a superproject's members). - Observed plenty of silly/confusing interactions that need additional work. {F1046657} {F1046658} {F1046655} {F1046656} {F1046654} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14904
2015-12-27 14:16:36 +01:00
'PhabricatorProjectListView' => 'applications/project/view/PhabricatorProjectListView.php',
Move "Lock Project" to a separate action Summary: Ref T10010. Three motivations: - Primarily: this makes conversion to EditEngine easier since I don't have to convert this weird control. - This probably needs to have "Lock", "Unlock" and "Use Parent Project Setting" values after subprojects? But maybe just locking any parent locks all the children? Anyway, doesn't make sense to put it on the main edit form if it's weird like this, I think, since we'll want some kind of explanatory text. - I probably want to move this to the "Members" tab anyway, and this won't be available on milestone projects at all. Test Plan: Locked, unlocked, edited projects. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14895
2015-12-27 15:56:15 +01:00
'PhabricatorProjectLockController' => 'applications/project/controller/PhabricatorProjectLockController.php',
Make queries for Project "X" mean "X, or any subproject of X" Summary: Ref T10010. I think this is the desired/expected default behavior (e.g., searching for "Maniphest" should find tasks in any subproject or sprint of that project). I'll probably add an "exact(...)" function later to mean "only the Maniphest superproject, exactly, not any of its children". Test Plan: - Added and executed unit tests. - Ran various queries from the web UI. - Got sensible-seeming results. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14910
2015-12-29 14:06:47 +01:00
'PhabricatorProjectLogicalAncestorDatasource' => 'applications/project/typeahead/PhabricatorProjectLogicalAncestorDatasource.php',
Make "user's projects" a logical datasource and add viewerprojects() Summary: Ref T4100. Ref T5595. This converts `projects(user)` into a logical datasource. Also adds a viewerprojects() logical datasource. Test Plan: {F375546} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4100, T5595 Differential Revision: https://secure.phabricator.com/D12462
2015-04-18 20:04:50 +02:00
'PhabricatorProjectLogicalDatasource' => 'applications/project/typeahead/PhabricatorProjectLogicalDatasource.php',
Implement a project logic datasource Summary: Ref T4100. Ref T5595. This allows you to execute all "Projects", "Any Project", "Not in projects" and "include no projects" operations in one field. It doesn't actually implement such a field yet. Test Plan: {F375516} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5595, T4100 Differential Revision: https://secure.phabricator.com/D12460
2015-04-18 18:58:33 +02:00
'PhabricatorProjectLogicalOrNotDatasource' => 'applications/project/typeahead/PhabricatorProjectLogicalOrNotDatasource.php',
Make "user's projects" a logical datasource and add viewerprojects() Summary: Ref T4100. Ref T5595. This converts `projects(user)` into a logical datasource. Also adds a viewerprojects() logical datasource. Test Plan: {F375546} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4100, T5595 Differential Revision: https://secure.phabricator.com/D12462
2015-04-18 20:04:50 +02:00
'PhabricatorProjectLogicalUserDatasource' => 'applications/project/typeahead/PhabricatorProjectLogicalUserDatasource.php',
'PhabricatorProjectLogicalViewerDatasource' => 'applications/project/typeahead/PhabricatorProjectLogicalViewerDatasource.php',
First cut of new Project Home Summary: First pass at a new Project Home page. This is starting to sprawl, so punting this up now before it gets too large. - Project homes now have "large header" - Custom Fields / Descriptions are in the main column - Feed is simpler visually - new "Background" option for PHUIObjectBoxView - move header buttons globally to "Grey" instead of "Simple" - New color and hover states for "Grey" - Transitions on Buttons haha - Edit Icon on Nav is now under "Manage" panel - New "Manage" Panel TODO: - More testing of bad cases of Custom Fields - Members Page in flux, needs design - Um still not sure how to make Custom Field not show UI Test Plan: Lots of random Project page visits. Save project, watch project, edit project, etc. {F1068191} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15097
2016-01-24 01:02:29 +01:00
'PhabricatorProjectManageController' => 'applications/project/controller/PhabricatorProjectManageController.php',
'PhabricatorProjectManageProfilePanel' => 'applications/project/profilepanel/PhabricatorProjectManageProfilePanel.php',
Materialize parent project memberships Summary: Ref T10010. Subprojects have the following general membership rule: if you are a member of a subproject ("Engineering > Backend"), you are also a member of the parent project. It would be unreasonably difficult to implement this rule directly in SQL when querying `withMemberPHIDs()`, because we'd have to do an arbitrarily large number of arbitrarily deep joins, or fetch and then requery a lot of data. Instead, introduce "materailized members", which are just a copy of all the effective members of a project. When a subproject has a membership change, we go recompute the effective membership of all the parent projects. Then we can just JOIN to satisfy `withMemberPHIDs()`. Having this process avialable will also be useful in the future, when a project's membership might be defined by some external source. Also make milestones mostly work like we'd expect them to with respect to membership and visibility. Test Plan: - Added and executed unit tests. - Changed project members, verified materialized members populated correctly in the database. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14863
2015-12-23 12:12:20 +01:00
'PhabricatorProjectMaterializedMemberEdgeType' => 'applications/project/edge/PhabricatorProjectMaterializedMemberEdgeType.php',
Move member/watch actions to "Members/Watchers" page Summary: Ref T10054. This tries to make the members page a bit more consistent and provide hints to users about subproject/milestone membership rules. In particular: - You now join, leave, watch, unwatch, add and remove members, and lock and unlock membership from the members screen. - We now explain the membership rule for the project on this screen. There are currently four rules: - Normal Project: Join/leave normally. - Parent Project: Uses subprojects to determine members. - Milestone: Uses parent project to determine members. - Locked: Membership is locked. - (Future) Imported from LDAP/other external sources: Membership is determined by something else. Test Plan: {F1064878} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15059
2016-01-20 01:27:36 +01:00
'PhabricatorProjectMemberListView' => 'applications/project/view/PhabricatorProjectMemberListView.php',
Migrate Project edges to subclass `PhabricatorEdgeType` Summary: Modernize Project edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Add a member to a project, saw new rows in the `phabricator_project.edge` and `phabricator_user.edge` tables. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11111
2015-01-02 00:10:58 +01:00
'PhabricatorProjectMemberOfProjectEdgeType' => 'applications/project/edge/PhabricatorProjectMemberOfProjectEdgeType.php',
Move member/watch actions to "Members/Watchers" page Summary: Ref T10054. This tries to make the members page a bit more consistent and provide hints to users about subproject/milestone membership rules. In particular: - You now join, leave, watch, unwatch, add and remove members, and lock and unlock membership from the members screen. - We now explain the membership rule for the project on this screen. There are currently four rules: - Normal Project: Join/leave normally. - Parent Project: Uses subprojects to determine members. - Milestone: Uses parent project to determine members. - Locked: Membership is locked. - (Future) Imported from LDAP/other external sources: Membership is determined by something else. Test Plan: {F1064878} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15059
2016-01-20 01:27:36 +01:00
'PhabricatorProjectMembersAddController' => 'applications/project/controller/PhabricatorProjectMembersAddController.php',
Implement viewer() and members(project) typeahead functions Summary: Ref T4100. This is still a bit rough around the edges, but mostly does what we're after. - Implements viewer() and members(...) functions. - The new browse workflow makes these discoverable. Test Plan: {F374201} Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12444
2015-04-17 00:30:41 +02:00
'PhabricatorProjectMembersDatasource' => 'applications/project/typeahead/PhabricatorProjectMembersDatasource.php',
Implement a "Project Members" object policy rule Summary: Fixes T9019. Pretty much ripped from D14467. I added the "policy hint" stuff so that you can create a project with this policy immediately. I really dislike how the "hint" code works, but we //almost// never need to use it and the badness feels fairly well-contained. Also pick up a quick feedback fix from D14863. Test Plan: - Added test coverage, got it to pass. - Created a project with "Visible To: Project Members". Reviewers: joshuaspence, chad Reviewed By: chad Maniphest Tasks: T9019 Differential Revision: https://secure.phabricator.com/D14869
2015-12-24 01:34:01 +01:00
'PhabricatorProjectMembersPolicyRule' => 'applications/project/policyrule/PhabricatorProjectMembersPolicyRule.php',
Begin modularizing profile panel/link construction Summary: Ref T10054. This has no product impact, but prepares us for customizable side nav on "profiles" (today, projects; probably users some day; and maybe other stuff down the road). Test Plan: Clicked all links on a profile, everything was exactly the same as before. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15007
2016-01-12 19:27:39 +01:00
'PhabricatorProjectMembersProfilePanel' => 'applications/project/profilepanel/PhabricatorProjectMembersProfilePanel.php',
Use standard UI kit on project member page Summary: Fixes T4400. Removes very, very old "PhabricatorObjectListView", which was only used here. Test Plan: {F132249} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley, chad Maniphest Tasks: T4400 Differential Revision: https://secure.phabricator.com/D8574
2014-03-20 03:30:27 +01:00
'PhabricatorProjectMembersRemoveController' => 'applications/project/controller/PhabricatorProjectMembersRemoveController.php',
Move member/watch actions to "Members/Watchers" page Summary: Ref T10054. This tries to make the members page a bit more consistent and provide hints to users about subproject/milestone membership rules. In particular: - You now join, leave, watch, unwatch, add and remove members, and lock and unlock membership from the members screen. - We now explain the membership rule for the project on this screen. There are currently four rules: - Normal Project: Join/leave normally. - Parent Project: Uses subprojects to determine members. - Milestone: Uses parent project to determine members. - Locked: Membership is locked. - (Future) Imported from LDAP/other external sources: Membership is determined by something else. Test Plan: {F1064878} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15059
2016-01-20 01:27:36 +01:00
'PhabricatorProjectMembersViewController' => 'applications/project/controller/PhabricatorProjectMembersViewController.php',
Send appropriate requests to the server when dragging cards on project boards Summary: Ref T1344. Makes requests to the server, which are received and ignored. Performs appropriate locking/unlocking/enabling/disabling on the client. Test Plan: Dragged stuff around, saw it enable/disable/send correctly. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7943
2014-01-13 21:24:36 +01:00
'PhabricatorProjectMoveController' => 'applications/project/controller/PhabricatorProjectMoveController.php',
Improve lipsum generation of projects Summary: Fixes T9156. - Fix hashtag generation. - Fix various badnesses. - Improve project name generator. Test Plan: ``` $ ./bin/lipsum generate projects GENERATORS Selected generators: Projects. WARNING This command generates synthetic test data, including user accounts. It is intended for use in development environments so you can test features more easily. There is no easy way to delete this data or undo the effects of this command. If you run it in a production environment, it will pollute your data with large amounts of meaningless garbage that you can not get rid of. Are you sure you want to generate piles of garbage? [y/N] y LIPSUM Generating synthetic test objects forever. Use ^C to stop when satisfied. Generated "Project": Self-Flying Data Center Swag Performance Generated "Project": Optimize Cars Generated "Project": Triaging Culture Optimization Generated "Project": Automating Experience Generated "Project": Accelerating NUX Performance Generated "Project": Optimizing Culture Optimization Generated "Project": Optimize Hardware ``` {F1042949} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9156 Differential Revision: https://secure.phabricator.com/D14874
2015-12-24 14:29:57 +01:00
'PhabricatorProjectNameContextFreeGrammar' => 'applications/project/lipsum/PhabricatorProjectNameContextFreeGrammar.php',
Implement a project logic datasource Summary: Ref T4100. Ref T5595. This allows you to execute all "Projects", "Any Project", "Not in projects" and "include no projects" operations in one field. It doesn't actually implement such a field yet. Test Plan: {F375516} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5595, T4100 Differential Revision: https://secure.phabricator.com/D12460
2015-04-18 18:58:33 +02:00
'PhabricatorProjectNoProjectsDatasource' => 'applications/project/typeahead/PhabricatorProjectNoProjectsDatasource.php',
Modernize Project/Object edges Summary: Ref T5245. Updates the project/object edge to use a modern class definition. Moves further toward real edges. Test Plan: Added projects to some objects, viewed transactions in transaction record. Reviewers: chad, btrahan, joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5245 Differential Revision: https://secure.phabricator.com/D9849
2014-07-18 00:42:19 +02:00
'PhabricatorProjectObjectHasProjectEdgeType' => 'applications/project/edge/PhabricatorProjectObjectHasProjectEdgeType.php',
Modernize "user or project" typeahead datasources Summary: Ref T4420. These are used for some stuff like "reviewer". Test Plan: - Edited "reviewers" in differential edit. - Edited "reviewers" in differential search. - Edited "reviewers" in Differential "add reviewers..." action on detail page. - Edited a "reviewers" field in a herald rule. - Edited "owner" in owners search. - Edited "primary owner", "owners" on owners edit. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9887
2014-07-18 00:45:07 +02:00
'PhabricatorProjectOrUserDatasource' => 'applications/project/typeahead/PhabricatorProjectOrUserDatasource.php',
Modernize Audit search engine Summary: Fixes T9279. Modernizes the SearchEngine and Query classes. User-facing changes: - Added order by commit date, default to order by commit date with newest commits first. - Added explicit "Needs Audit by". - Added new `packages(...)` typeahead function. - Picked up automatic subscribers, projects, and order fields. This changes behavior a little bit: we previously attempted to exclude, e.g., commits which a package you own needs to audit, but which you have resigned from. This is difficult in general and I think it needs a more comprehensive solution. This shouldn't impact users much, anyway. Test Plan: {F767628} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9279 Differential Revision: https://secure.phabricator.com/D14013
2015-08-31 19:17:54 +02:00
'PhabricatorProjectOrUserFunctionDatasource' => 'applications/project/typeahead/PhabricatorProjectOrUserFunctionDatasource.php',
Provide formal Users/Projects/Mailable fields for EditEngine Summary: Ref T9132. This allows you to prefill EditEngine forms with stuff like `?subscribers=epriestley`, and we'll figure out what you mean. Test Plan: - Did `/?subscribers=...` with various values (good, bad, mis-capitalized). - Did `/?projects=...` with various values (good, bad, mis-capitalized). - Reviewed documentation. - Reviewed {nav Config > HTTP Parameter Types}. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14404
2015-11-04 19:20:38 +01:00
'PhabricatorProjectPHIDResolver' => 'applications/phid/resolver/PhabricatorProjectPHIDResolver.php',
Make "profile menu" configuration mostly work Summary: Ref T10054. This does a big chunk of the legwork to let users reconfigure profile menus (currently, just project menus). This includes: - Editing builtin items (e.g., you can rename the default items). - Creating new items (for now, only links are available). This does not yet include: - Hiding items. - Reordering items. - Lots of fancy types of items (dashboards, etc). - Any UI changes. - Documentation (does feature: TODO link for documentation). Test Plan: {F1060695} {F1060696} {F1060697} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15010
2016-01-13 00:06:43 +01:00
'PhabricatorProjectPanelController' => 'applications/project/controller/PhabricatorProjectPanelController.php',
Add a basic progress bar for milestones Summary: Ref T4427. This kind of works. Test Plan: {F1100578} Reviewers: chad Reviewed By: chad Maniphest Tasks: T4427 Differential Revision: https://secure.phabricator.com/D15221
2016-02-09 02:31:21 +01:00
'PhabricatorProjectPointsProfilePanel' => 'applications/project/profilepanel/PhabricatorProjectPointsProfilePanel.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProjectProfileController' => 'applications/project/controller/PhabricatorProjectProfileController.php',
Prepare Profile Panels for adoption in other applications Summary: Ref T10054. Take specialization off the objects and put it on Engine subclasses instead. One reason for this is that certain objects (like users) might have multiple different sets of panels in the future (e.g., their user profile and their home page). Test Plan: - No user-visible changes. - PanelEngine no longer has any hardcoded "project" stuff. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15018
2016-01-14 14:59:25 +01:00
'PhabricatorProjectProfilePanelEngine' => 'applications/project/engine/PhabricatorProjectProfilePanelEngine.php',
Migrate Project edges to subclass `PhabricatorEdgeType` Summary: Modernize Project edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Add a member to a project, saw new rows in the `phabricator_project.edge` and `phabricator_user.edge` tables. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11111
2015-01-02 00:10:58 +01:00
'PhabricatorProjectProjectHasMemberEdgeType' => 'applications/project/edge/PhabricatorProjectProjectHasMemberEdgeType.php',
Modernize Project/Object edges Summary: Ref T5245. Updates the project/object edge to use a modern class definition. Moves further toward real edges. Test Plan: Added projects to some objects, viewed transactions in transaction record. Reviewers: chad, btrahan, joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5245 Differential Revision: https://secure.phabricator.com/D9849
2014-07-18 00:42:19 +02:00
'PhabricatorProjectProjectHasObjectEdgeType' => 'applications/project/edge/PhabricatorProjectProjectHasObjectEdgeType.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorProjectProjectPHIDType' => 'applications/project/phid/PhabricatorProjectProjectPHIDType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProjectQuery' => 'applications/project/query/PhabricatorProjectQuery.php',
Modularize "add projects" and "remove projects" Herald actions Summary: Ref T8726. Convert these to be modular. Test Plan: - Created rules using these actions. - Upgraded them. - Verified they still work. {F659266} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13705
2015-07-24 19:56:52 +02:00
'PhabricatorProjectRemoveHeraldAction' => 'applications/project/herald/PhabricatorProjectRemoveHeraldAction.php',
Generate expected Project schemata Summary: Ref T1191. Notes: - Drops the project affiliation table. This is a very old membership table which was migrated to edges. - Drops the subproject table. This is a very old table for a removed feature. Test Plan: - Grepped for dropped tables. - Saw ~100 fewer setup issues. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10581
2014-10-01 16:37:01 +02:00
'PhabricatorProjectSchemaSpec' => 'applications/project/storage/PhabricatorProjectSchemaSpec.php',
Use ApplicationSearch in projects Summary: Ref T2715. I stripped a bunch of stuff from the list since it was buggy, slow, or both. Some day, we'll rebuild it. Test Plan: {F51128} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6525
2013-07-22 17:34:35 +02:00
'PhabricatorProjectSearchEngine' => 'applications/project/query/PhabricatorProjectSearchEngine.php',
Move some PhabricatorSearchField subclasses Summary: Move some `PhabricatorSearchField` subclasses to be adjacent to the application to which they belong. This seems generally better to me than lumping them all together in the `src/applications/search/field/` directory. I was also wondering if it makes sense to rename these subclasses as `PhabricatorXSearchField` rather than `PhabricatorSearchXField` (as per T5655), but wasn't really sure if these objects are meant to be search-fields, or just fields belonging to the #search application. Test Plan: N/A. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13374
2015-07-06 14:52:04 +02:00
'PhabricatorProjectSearchField' => 'applications/project/searchfield/PhabricatorProjectSearchField.php',
Replace subscribe/unsubscribe for projects with explicit mail setting Summary: Ref T10054. Ref T6113. Users can currently subscribe to projects, which causes them to receive: # mail about project membership changes, description changes, etc; and # mail to the project, e.g. when the project is added as a subscriber on a task, or a reviewer on a revision. Almost no one cares about (1), and after D15061 you can use Herald to get this stuff if you really want it. (It will get progressively more annoying in the future with external membership sources causing automated project membership updates.) A lot of users are confused about (2) and how it relates to membership, watching, etc, and most users who want (2) don't want (1). Instead, add an explicit option for this and explain what it does. This is fairly verbose but I've hidden it on the member/watch screen, which is now the "explain how projects work" screen, I guess. Test Plan: {F1064929} {F1064930} {F1064931} - Disabled/enabled mail for a project. - Sent mail to a project with mail disabled, verified I didn't get a copy. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6113, T10054 Differential Revision: https://secure.phabricator.com/D15065
2016-01-20 03:56:15 +01:00
'PhabricatorProjectSilenceController' => 'applications/project/controller/PhabricatorProjectSilenceController.php',
'PhabricatorProjectSilencedEdgeType' => 'applications/project/edge/PhabricatorProjectSilencedEdgeType.php',
Projects - add "Additional Hashtags" to projects Summary: Fixes T4021. Chooses to keep a "primary" slug based off the name - including all that lovely logic - and allow the user to specify "additional" slugs. Expose these as "hashtags" to the user. Sets us up for a fun diff where we can delete all the Project => Phriction automagicalness. In terms of this diff, see the TODOs i added. Test Plan: added a primary slug as an additional slug - got an error. added a slug in use on another project - got an error. added multiple good slugs and they worked. removed slugs and it worked. made some remark using multiple new slugs and they all linked to the correct project ran epriestley's case - Create project "A". - Give it additional slug "B". - Try to create project "B". and i got a nice error about hashtag collision Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4021 Differential Revision: https://secure.phabricator.com/D9250
2014-05-22 20:19:03 +02:00
'PhabricatorProjectSlug' => 'applications/project/storage/PhabricatorProjectSlug.php',
Migrate project blurb/description to standard custom field storage Summary: Ref T4379. Major goal here is to remove `ProjectProfile` so all edits use ApplicationTransactions. This also makes things more flexible, allowing users to disable this field if they don't like it. Test Plan: Ran migration, verified data survived, edited/created projects, reordered fields. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4379 Differential Revision: https://secure.phabricator.com/D8182
2014-02-10 23:31:57 +01:00
'PhabricatorProjectStandardCustomField' => 'applications/project/customfield/PhabricatorProjectStandardCustomField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProjectStatus' => 'applications/project/constants/PhabricatorProjectStatus.php',
Put subprojects and milestones back into the Project UI Summary: Ref T10010. Restores subprojects and milestones to the UI with a more modern style and more warnings. Test Plan: {F1085207} {F1085208} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D15152
2016-02-01 16:04:19 +01:00
'PhabricatorProjectSubprojectWarningController' => 'applications/project/controller/PhabricatorProjectSubprojectWarningController.php',
Add empty subproject/milestone controllers Summary: Ref T10010. These do nothing yet. Test Plan: Clicked 'em. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14894
2015-12-27 13:47:08 +01:00
'PhabricatorProjectSubprojectsController' => 'applications/project/controller/PhabricatorProjectSubprojectsController.php',
Put subprojects and milestones back into the Project UI Summary: Ref T10010. Restores subprojects and milestones to the UI with a more modern style and more warnings. Test Plan: {F1085207} {F1085208} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D15152
2016-02-01 16:04:19 +01:00
'PhabricatorProjectSubprojectsProfilePanel' => 'applications/project/profilepanel/PhabricatorProjectSubprojectsProfilePanel.php',
Finished Project Generation Summary: Progress on T2903 Test Plan: Projects are generating. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5794
2013-04-29 21:17:55 +02:00
'PhabricatorProjectTestDataGenerator' => 'applications/project/lipsum/PhabricatorProjectTestDataGenerator.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProjectTransaction' => 'applications/project/storage/PhabricatorProjectTransaction.php',
Implement "Edit Members" and "Join/Leave" with real ApplicationTransactions Summary: Ref T4379. Projects has been partially converted to ApplicationTransactions, but the rough state of the world is that all the //storage// is modern, but most of the stuff on top isn't yet. Particularly, there's a `PhabricatorProjectEditor` which is //not// a subclass of `PhabricatorApplicationTransactionEditor`, but which fakes its way through writing reasonable data into modern storage. This introduces a real transaction editor, `PhabricatorProjectTransactionEditor`, with the eventual goal of moving all of the old functionality into it and deleting the old class. This diff only moves the membership transaction into new code (it doesn't even move all of it -- when we create a project, we add the author as a member, and that can't move quite yet since there are other transactions at the same time). Test Plan: - Created a new project. - Edited members. - Joined / left project. - This already has a pile of unit test coverage. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4379 Differential Revision: https://secure.phabricator.com/D8167
2014-02-10 23:30:00 +01:00
'PhabricatorProjectTransactionEditor' => 'applications/project/editor/PhabricatorProjectTransactionEditor.php',
Add project history and title strings Summary: Ref T4010. Adds a history page and restores the transaction title strings, which previously sort-of existed in the defunct feed story class. Test Plan: See screenshots. Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T4010 Differential Revision: https://secure.phabricator.com/D7371
2013-10-22 22:49:37 +02:00
'PhabricatorProjectTransactionQuery' => 'applications/project/query/PhabricatorProjectTransactionQuery.php',
Implement PhabricatorProjectInterface for marking that objects can be tagged with projects Summary: Ref T2628. This makes Transactions understand objects that can have project relationships, extract project mentions, and handle watching. Test Plan: See next diff. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2628 Differential Revision: https://secure.phabricator.com/D9340
2014-06-04 02:19:40 +02:00
'PhabricatorProjectUIEventListener' => 'applications/project/events/PhabricatorProjectUIEventListener.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProjectUpdateController' => 'applications/project/controller/PhabricatorProjectUpdateController.php',
Modernize Audit search engine Summary: Fixes T9279. Modernizes the SearchEngine and Query classes. User-facing changes: - Added order by commit date, default to order by commit date with newest commits first. - Added explicit "Needs Audit by". - Added new `packages(...)` typeahead function. - Picked up automatic subscribers, projects, and order fields. This changes behavior a little bit: we previously attempted to exclude, e.g., commits which a package you own needs to audit, but which you have resigned from. This is difficult in general and I think it needs a more comprehensive solution. This shouldn't impact users much, anyway. Test Plan: {F767628} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9279 Differential Revision: https://secure.phabricator.com/D14013
2015-08-31 19:17:54 +02:00
'PhabricatorProjectUserFunctionDatasource' => 'applications/project/typeahead/PhabricatorProjectUserFunctionDatasource.php',
Move member/watch actions to "Members/Watchers" page Summary: Ref T10054. This tries to make the members page a bit more consistent and provide hints to users about subproject/milestone membership rules. In particular: - You now join, leave, watch, unwatch, add and remove members, and lock and unlock membership from the members screen. - We now explain the membership rule for the project on this screen. There are currently four rules: - Normal Project: Join/leave normally. - Parent Project: Uses subprojects to determine members. - Milestone: Uses parent project to determine members. - Locked: Membership is locked. - (Future) Imported from LDAP/other external sources: Membership is determined by something else. Test Plan: {F1064878} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15059
2016-01-20 01:27:36 +01:00
'PhabricatorProjectUserListView' => 'applications/project/view/PhabricatorProjectUserListView.php',
Revamp Projects with new navigation Summary: A refresh of Projects including a new navigations UI. - New Navigation UI. - Auto switch default page if Workboard has been initialized - Move Feed to it's own page - Increase 'tasks' on Project Home to 50 over 10 - Fix various display bugs on Workboards - Remove 'crumbs' from Project portal (unneeded). Test Plan: - clicked a link for a project with no workboard and saw the profile - clicked a link for a project with a workboard and saw the workboard - navigated around the various edit pages, inspecting links and making sure things linked back to the new profile uri {F266460} {F266461} {F266462} {F266463} {F266464} Reviewers: epriestley, btrahan Reviewed By: epriestley, btrahan Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11272
2015-01-12 19:04:01 +01:00
'PhabricatorProjectViewController' => 'applications/project/controller/PhabricatorProjectViewController.php',
Allow projects to be "watched", sort of a super-subscribe Summary: Ref T4967. Adds a "Watch" relationship to projects, which is stronger than member/subscribed. Specifically, when a task is tagged with a project, we'll include all project watchers in the email/notifications. Normally we don't include projects unless they're explicitly CC'd, or have some other active role in the object (like being a reviewer or auditor). This allows you to closely follow a project without needing to write a Herald rule for every project you care about. Test Plan: - Watched/unwatched a project. - Tested the watch/subscribe/member relationships: - Watching implies subscribe. - Joining implies subscribe. - Leaving implies unsubscribe + unwatch. - You can't unsubscribe until you unwatch (slightly better would be unsubscribe implies unwatch, but this is a bit tricky). - Watched a project, then recevied email about a tagged task without otherwise being involved. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4967 Differential Revision: https://secure.phabricator.com/D9185
2014-05-19 21:40:57 +02:00
'PhabricatorProjectWatchController' => 'applications/project/controller/PhabricatorProjectWatchController.php',
Move member/watch actions to "Members/Watchers" page Summary: Ref T10054. This tries to make the members page a bit more consistent and provide hints to users about subproject/milestone membership rules. In particular: - You now join, leave, watch, unwatch, add and remove members, and lock and unlock membership from the members screen. - We now explain the membership rule for the project on this screen. There are currently four rules: - Normal Project: Join/leave normally. - Parent Project: Uses subprojects to determine members. - Milestone: Uses parent project to determine members. - Locked: Membership is locked. - (Future) Imported from LDAP/other external sources: Membership is determined by something else. Test Plan: {F1064878} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15059
2016-01-20 01:27:36 +01:00
'PhabricatorProjectWatcherListView' => 'applications/project/view/PhabricatorProjectWatcherListView.php',
Allow workboard background colors to be configured Summary: Adds a UI for selecting background colors. You can choose "Use Parent", which is the default, and allows you to set a color that all descendants inherit. You can also choose "None", if a parent has a WHACKY BACKGROUND that you refuse to put up with. Test Plan: {F1114588} {F1114589} Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15279
2016-02-16 15:52:32 +01:00
'PhabricatorProjectWorkboardBackgroundColor' => 'applications/project/constants/PhabricatorProjectWorkboardBackgroundColor.php',
Begin modularizing profile panel/link construction Summary: Ref T10054. This has no product impact, but prepares us for customizable side nav on "profiles" (today, projects; probably users some day; and maybe other stuff down the road). Test Plan: Clicked all links on a profile, everything was exactly the same as before. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15007
2016-01-12 19:27:39 +01:00
'PhabricatorProjectWorkboardProfilePanel' => 'applications/project/profilepanel/PhabricatorProjectWorkboardProfilePanel.php',
Introduce "Curtain" views, panels, and extensions Summary: This opens up the new action column to have specialized rendering and behavior. Briefly: - Converted applications (right now, only Paste) render a `CurtainView` to build the column content. - This view uses new extensions to build panels (projects, subscribers, tokens). - The panel extension code and rendering can be changed without breaking old stuff. Minor changes: - Token awards now load their tokens, for consistency/simplicity. - Removed the rest of the "fork of" / "forked from" UI in Paste -- I essentially removed these features a while ago, and no one has complained. Test Plan: UI is a bit rough, but works, and it's going to get changed now anyway: {F1160550} {F1160551} Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15414
2016-03-05 23:45:56 +01:00
'PhabricatorProjectsCurtainExtension' => 'applications/project/engineextension/PhabricatorProjectsCurtainExtension.php',
Modularize SearchEngine extensions Summary: Ref T9964. ApplicationSearch currently has a bunch of hard-coded `if ($object instanceof thing)` stuff. Pull that out so it can live in extensions. Test Plan: - Searched by spaces, subscribers, projects. {F1023921} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14764
2015-12-13 13:12:34 +01:00
'PhabricatorProjectsEditEngineExtension' => 'applications/project/engineextension/PhabricatorProjectsEditEngineExtension.php',
Provide formal Users/Projects/Mailable fields for EditEngine Summary: Ref T9132. This allows you to prefill EditEngine forms with stuff like `?subscribers=epriestley`, and we'll figure out what you mean. Test Plan: - Did `/?subscribers=...` with various values (good, bad, mis-capitalized). - Did `/?projects=...` with various values (good, bad, mis-capitalized). - Reviewed documentation. - Reviewed {nav Config > HTTP Parameter Types}. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14404
2015-11-04 19:20:38 +01:00
'PhabricatorProjectsEditField' => 'applications/transactions/editfield/PhabricatorProjectsEditField.php',
Modularize fulltext indexing of Projects, Subscriptions and Custom Fields Summary: Ref T9979. This is going to become `FulltextEngine`, but pave the way for that by pulling extensions out of it. Test Plan: {F1036624} - Used `bin/search index Txxx`, saw projects, subscribers and custom fields rebuild in the index. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14835
2015-12-21 15:31:31 +01:00
'PhabricatorProjectsFulltextEngineExtension' => 'applications/project/engineextension/PhabricatorProjectsFulltextEngineExtension.php',
Add more information (colors, members, watchers) to project.search Summary: Fixes T6501. This adds more API information to the newish `project.search` API method. Test Plan: Called `project.search`, used attachments. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6501 Differential Revision: https://secure.phabricator.com/D15105
2016-01-24 16:19:54 +01:00
'PhabricatorProjectsMembersSearchEngineAttachment' => 'applications/project/engineextension/PhabricatorProjectsMembersSearchEngineAttachment.php',
Materialize parent project memberships Summary: Ref T10010. Subprojects have the following general membership rule: if you are a member of a subproject ("Engineering > Backend"), you are also a member of the parent project. It would be unreasonably difficult to implement this rule directly in SQL when querying `withMemberPHIDs()`, because we'd have to do an arbitrarily large number of arbitrarily deep joins, or fetch and then requery a lot of data. Instead, introduce "materailized members", which are just a copy of all the effective members of a project. When a subproject has a membership change, we go recompute the effective membership of all the parent projects. Then we can just JOIN to satisfy `withMemberPHIDs()`. Having this process avialable will also be useful in the future, when a project's membership might be defined by some external source. Also make milestones mostly work like we'd expect them to with respect to membership and visibility. Test Plan: - Added and executed unit tests. - Changed project members, verified materialized members populated correctly in the database. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14863
2015-12-23 12:12:20 +01:00
'PhabricatorProjectsMembershipIndexEngineExtension' => 'applications/project/engineextension/PhabricatorProjectsMembershipIndexEngineExtension.php',
Move some files around Summary: Move some `PhabricatorPolicyRule` implementations to a subdirectory of the parent application. Test Plan: N/A Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14478
2015-11-16 20:26:13 +01:00
'PhabricatorProjectsPolicyRule' => 'applications/project/policyrule/PhabricatorProjectsPolicyRule.php',
Add a "projects" Search attachment for Conduit APIs Summary: Ref T9964. Builds on D14772. Allows callers to request project PHIDs for objects. Test Plan: {F1025468} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14773
2015-12-14 14:41:26 +01:00
'PhabricatorProjectsSearchEngineAttachment' => 'applications/project/engineextension/PhabricatorProjectsSearchEngineAttachment.php',
Modularize SearchEngine extensions Summary: Ref T9964. ApplicationSearch currently has a bunch of hard-coded `if ($object instanceof thing)` stuff. Pull that out so it can live in extensions. Test Plan: - Searched by spaces, subscribers, projects. {F1023921} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14764
2015-12-13 13:12:34 +01:00
'PhabricatorProjectsSearchEngineExtension' => 'applications/project/engineextension/PhabricatorProjectsSearchEngineExtension.php',
Add more information (colors, members, watchers) to project.search Summary: Fixes T6501. This adds more API information to the newish `project.search` API method. Test Plan: Called `project.search`, used attachments. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6501 Differential Revision: https://secure.phabricator.com/D15105
2016-01-24 16:19:54 +01:00
'PhabricatorProjectsWatchersSearchEngineAttachment' => 'applications/project/engineextension/PhabricatorProjectsWatchersSearchEngineAttachment.php',
Rename protocol adapter classes Summary: Ref T5655. Rename protocol adapter classes to remove `Base` from the class name. Test Plan: Unit tests still pass. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D12563
2015-05-18 00:20:11 +02:00
'PhabricatorProtocolAdapter' => 'infrastructure/daemon/bot/adapter/PhabricatorProtocolAdapter.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorPygmentSetupCheck' => 'applications/config/check/PhabricatorPygmentSetupCheck.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorQuery' => 'infrastructure/query/PhabricatorQuery.php',
Add "Edge Logic" support to PolicyAwareQuery Summary: Ref T4100. Ref T5595. This allows PolicyAwareQuery to write all the logic for AND, OR, NOT, and NULL (i.e., "not in any projects") queries against any edge type. It accepts an edge type and a list of constraints (which are basically just operator-value pairs, like `<NOT, PHID-X-Y>`, meaning the results must not have an edge connecting them to `PHID-X-Y`). This doesn't actually do anything yet; see future diffs. Test Plan: `arc unit --everything` Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4100, T5595 Differential Revision: https://secure.phabricator.com/D12455
2015-04-18 16:53:43 +02:00
'PhabricatorQueryConstraint' => 'infrastructure/query/constraint/PhabricatorQueryConstraint.php',
Begin formalizing query orders Summary: Ref T7803. Queries currently have a single `getPagingColumn()`, which is oversimplified and insufficient to describe many ordering operations. Frequently, orders must span multiple columns. Move toward an "order vector", which is a list of orderable values like "name, id". These map directly to columns, and are sufficient to actually describe orders. The more modern Query classes (Maniphest, Repository) essentially do this manually anyway. Test Plan: - Added and executed unit tests. - Browsed around, verified the correct ORDER BY clauses were generated. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7803 Differential Revision: https://secure.phabricator.com/D12352
2015-04-11 21:10:35 +02:00
'PhabricatorQueryOrderItem' => 'infrastructure/query/order/PhabricatorQueryOrderItem.php',
'PhabricatorQueryOrderTestCase' => 'infrastructure/query/order/__tests__/PhabricatorQueryOrderTestCase.php',
'PhabricatorQueryOrderVector' => 'infrastructure/query/order/PhabricatorQueryOrderVector.php',
Modularize Aphront exception handling Summary: Ref T1806. Ref T7173. Depends on D14047. Currently, all exception handling is in this big messy clump in `AphrontDefaultApplicationConfiguration`. Split it out into modular classes. This will let a future change add new classes in the Phacility cluster which intercept particular exceptions we care about and replaces the default, generic responses with more useful, tailored responses. Test Plan: {F777391} - Hit a Conduit error (made a method throw). - Hit an Ajax error (made comment preview throw). - Hit a high security error (tried to edit TOTP). - Hit a rate limiting error (added a bunch of email addresses). - Hit a policy error (tried to look at something with no permission). - Hit an arbitrary exception (made a randomc ontroller throw). Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14049
2015-09-03 19:04:42 +02:00
'PhabricatorRateLimitRequestExceptionHandler' => 'aphront/handler/PhabricatorRateLimitRequestExceptionHandler.php',
Move Recaptcha config to PHP Summary: Bring these over. Also sort the group list. Test Plan: Viewed config. Reviewers: btrahan, codeblock, chad Reviewed By: chad CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4338
2013-01-03 18:17:38 +01:00
'PhabricatorRecaptchaConfigOptions' => 'applications/config/option/PhabricatorRecaptchaConfigOptions.php',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorRecipientHasBadgeEdgeType' => 'applications/badges/edge/PhabricatorRecipientHasBadgeEdgeType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRedirectController' => 'applications/base/controller/PhabricatorRedirectController.php',
'PhabricatorRefreshCSRFController' => 'applications/auth/controller/PhabricatorRefreshCSRFController.php',
New Registration Workflow Summary: Currently, registration and authentication are pretty messy. Two concrete problems: - The `PhabricatorLDAPRegistrationController` and `PhabricatorOAuthDefaultRegistrationController` controllers are giant copy/pastes of one another. This is really bad. - We can't practically implement OpenID because we can't reissue the authentication request. Additionally, the OAuth registration controller can be replaced wholesale by config, which is a huge API surface area and a giant mess. Broadly, the problem right now is that registration does too much: we hand it some set of indirect credentials (like OAuth tokens) and expect it to take those the entire way to a registered user. Instead, break registration into smaller steps: - User authenticates with remote service. - Phabricator pulls information (remote account ID, username, email, real name, profile picture, etc) from the remote service and saves it as `PhabricatorUserCredentials`. - Phabricator hands the `PhabricatorUserCredentials` to the registration form, which is agnostic about where they originate from: it can process LDAP credentials, OAuth credentials, plain old email credentials, HTTP basic auth credentials, etc. This doesn't do anything yet -- there is no way to create credentials objects (and no storage patch), but I wanted to get any initial feedback, especially about the event call for T2394. In particular, I think the implementation would look something like this: $profile = $event->getValue('profile') $username = $profile->getDefaultUsername(); $is_employee = is_this_a_facebook_employee($username); if (!$is_employee) { throw new Exception("You are not employed at Facebook."); } $fbid = get_fbid_for_facebook_username($username); $profile->setDefaultEmail($fbid); $profile->setCanEditUsername(false); $profile->setCanEditEmail(false); $profile->setCanEditRealName(false); $profile->setShouldVerifyEmail(true); Seem reasonable? Test Plan: N/A yet, probably fatals. Reviewers: vrana, btrahan, codeblock, chad Reviewed By: btrahan CC: aran, asherkin, nh, wez Maniphest Tasks: T1536, T2394 Differential Revision: https://secure.phabricator.com/D4647
2013-06-16 19:13:49 +02:00
'PhabricatorRegistrationProfile' => 'applications/people/storage/PhabricatorRegistrationProfile.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorReleephApplication' => 'applications/releeph/application/PhabricatorReleephApplication.php',
'PhabricatorReleephApplicationConfigOptions' => 'applications/releeph/config/PhabricatorReleephApplicationConfigOptions.php',
Make a PhabricatorRemarkupControl to de-duplicate code usage around adding a Remarkup reference to a TextAreaControl. Summary: ...also makes Maniphest Task Edit Controller use this when its not appropriate to upsell email. Test Plan: played around with each tool and verified the Remarkup reference was present Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1756 Differential Revision: https://secure.phabricator.com/D3468
2012-09-19 21:27:28 +02:00
'PhabricatorRemarkupControl' => 'view/form/control/PhabricatorRemarkupControl.php',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhabricatorRemarkupCowsayBlockInterpreter' => 'infrastructure/markup/interpreter/PhabricatorRemarkupCowsayBlockInterpreter.php',
Make remarkup rules runtime-pluggable in a reasonable way Summary: Gets rid of some old Differential-specific nonsense and replaces it with general runtime-pluggable Remarkup rules. Facebook: This removes two options which may be in use. Have any classes being added via config here just subclass the new abstract bases instead. This should take 5 seconds to fix. You can adjust order by overriding `getPriority()` on the rules, if necessary. Test Plan: See comments. Reviewers: btrahan Reviewed By: btrahan CC: FacebookPOC, andrewjcg, aran Differential Revision: https://secure.phabricator.com/D7393
2013-10-25 02:26:07 +02:00
'PhabricatorRemarkupCustomBlockRule' => 'infrastructure/markup/rule/PhabricatorRemarkupCustomBlockRule.php',
'PhabricatorRemarkupCustomInlineRule' => 'infrastructure/markup/rule/PhabricatorRemarkupCustomInlineRule.php',
Allow form configurations to retitle and reorder forms and add preambles Summary: Ref T9132. This just makes edited forms do //something//, albeit not anything very useful yet. You can now edit a form and: - Retitle it; - add a preamble (instructions on top of the form); and - reorder the form's fields. Test Plan: {F974632} {F974633} {F974634} {F974635} {F974636} Reviewers: chad Reviewed By: chad Subscribers: hach-que Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14503
2015-11-17 18:33:06 +01:00
'PhabricatorRemarkupEditField' => 'applications/transactions/editfield/PhabricatorRemarkupEditField.php',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhabricatorRemarkupFigletBlockInterpreter' => 'infrastructure/markup/interpreter/PhabricatorRemarkupFigletBlockInterpreter.php',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorRemarkupUIExample' => 'applications/uiexample/examples/PhabricatorRemarkupUIExample.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorRepositoriesSetupCheck' => 'applications/config/check/PhabricatorRepositoriesSetupCheck.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepository' => 'applications/repository/storage/PhabricatorRepository.php',
'PhabricatorRepositoryAuditRequest' => 'applications/repository/storage/PhabricatorRepositoryAuditRequest.php',
Allow saving lint errors to database Summary: This saves lint errors to the path change of current commit. It requires pushed revision. It doesn't save difference from previous commit mentioned in T2038#comment-4 - I don't plan doing it after all, everything would be much more complicated and the amount of data saved with this approach isn't that bad. Test Plan: Applied patch, ran script, verified DB. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2038 Differential Revision: https://secure.phabricator.com/D3899
2012-11-06 08:09:36 +01:00
'PhabricatorRepositoryBranch' => 'applications/repository/storage/PhabricatorRepositoryBranch.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryCommit' => 'applications/repository/storage/PhabricatorRepositoryCommit.php',
'PhabricatorRepositoryCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/PhabricatorRepositoryCommitChangeParserWorker.php',
'PhabricatorRepositoryCommitData' => 'applications/repository/storage/PhabricatorRepositoryCommitData.php',
'PhabricatorRepositoryCommitHeraldWorker' => 'applications/repository/worker/PhabricatorRepositoryCommitHeraldWorker.php',
'PhabricatorRepositoryCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/PhabricatorRepositoryCommitMessageParserWorker.php',
'PhabricatorRepositoryCommitOwnersWorker' => 'applications/repository/worker/PhabricatorRepositoryCommitOwnersWorker.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorRepositoryCommitPHIDType' => 'applications/repository/phid/PhabricatorRepositoryCommitPHIDType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryCommitParserWorker' => 'applications/repository/worker/PhabricatorRepositoryCommitParserWorker.php',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorRepositoryCommitRef' => 'applications/repository/engine/PhabricatorRepositoryCommitRef.php',
Add getGroup to ConfigOptions Summary: Adds core and apps grouping to configuration options, makes it somewhat easier to browse config options. Test Plan: Set each option, review list. Breakdown is nearly 50/50 apps/core. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11722
2015-02-09 22:10:56 +01:00
'PhabricatorRepositoryConfigOptions' => 'applications/repository/config/PhabricatorRepositoryConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryDAO' => 'applications/repository/storage/PhabricatorRepositoryDAO.php',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorRepositoryDiscoveryEngine' => 'applications/repository/engine/PhabricatorRepositoryDiscoveryEngine.php',
Begin transacitonalizing repository edits and provide a more sensible edit interface Summary: Ref T2231, T603. Plan of attack here is pretty much: - Built out a new (currently not linked in the UI) edit interface in Diffusion which is transaction-based and has a sensible layout. - Build out a new create interface based on PagedForm which dumps into the new edit interface. - Throw the old stuff away. - Everyone lives happily ever after. Test Plan: {F44163} {F44164} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D6029
2013-05-24 21:37:42 +02:00
'PhabricatorRepositoryEditor' => 'applications/repository/editor/PhabricatorRepositoryEditor.php',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorRepositoryEngine' => 'applications/repository/engine/PhabricatorRepositoryEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryGitCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/PhabricatorRepositoryGitCommitChangeParserWorker.php',
'PhabricatorRepositoryGitCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/PhabricatorRepositoryGitCommitMessageParserWorker.php',
Implement a Git LFS link table and basic batch API Summary: Ref T7789. This implements: - A new table to store the `<objectHash, filePHID>` relationship between Git LFS files and Phabricator file objects. - A basic response to `batch` commands, which return actions for a list of files. Test Plan: Ran `git lfs push origin master`, got a little further than previously: ``` epriestley@orbital ~/dev/scratch/poemslocal $ git lfs push origin master Git LFS: (2 of 1 files) 174.24 KB / 87.12 KB Git LFS operation "upload/b7e0aeb82a03d627c6aa5fc1bbfd454b6789d9d9affc8607d40168fa18cf6c69" is not supported by this server. Git LFS operation "upload/b7e0aeb82a03d627c6aa5fc1bbfd454b6789d9d9affc8607d40168fa18cf6c69" is not supported by this server. ``` With `GIT_TRACE=1`, this shows the batch part of the API going through. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7789 Differential Revision: https://secure.phabricator.com/D15489
2016-03-17 20:49:18 +01:00
'PhabricatorRepositoryGitLFSRef' => 'applications/repository/storage/PhabricatorRepositoryGitLFSRef.php',
'PhabricatorRepositoryGitLFSRefQuery' => 'applications/repository/query/PhabricatorRepositoryGitLFSRefQuery.php',
Implement a chunked, APC-backed graph cache Summary: Ref T2683. This is a refinement and simplification of D5257. In particular: - D5257 only cached the commit chain, not path changes. This meant that we had to go issue an awkward query (which was slow on Facebook's install) periodically while reading the cache. This was reasonable locally but killed performance at FB scale. Instead, we can include path information in the cache. It is very rare that this is large except in Subversion, and we do not need to use this cache in Subversion. In other VCSes, the scale of this data is quite small (a handful of bytes per commit on average). - D5257 required a large, slow offline computation step. This relies on D9044 to populate parent data so we can build the cache online at will, and let it expire with normal LRU/LFU/whatever semantics. We need this parent data for other reasons anyway. - D5257 separated graph chunks per-repository. This change assumes we'll be able to pull stuff from APC most of the time and that the cost of switching chunks is not very large, so we can just build one chunk cache across all repositories. This allows the cache to be simpler. - D5257 needed an offline cache, and used a unique cache structure. Since this one can be built online it can mostly use normal cache code. - This also supports online appends to the cache. - Finally, this has a timeout to guarantee a ceiling on the worst case: the worst case is something like a query for a file that has never existed, in a repository which receives exactly 1 commit every time other repositories receive 4095 commits, on a cold cache. If we hit cases like this we can bail after warming the cache up a bit and fall back to asking the VCS for an answer. This cache isn't perfect, but I believe it will give us substantial gains in the average case. It can often satisfy "average-looking" queries in 4-8ms, and pathological-ish queries in 20ms on my machine; `hg` usually can't even start up in less than 100ms. The major thing that's attractive about this approach is that it does not require anything external or complicated, and will "just work", even producing reasonble improvements for users without APC. In followups, I'll modify queries to use this cache and see if it holds up in more realistic workloads. Test Plan: - Used `bin/repository cache` to examine the behavior of this cache. - Did some profiling/testing from the web UI using `debug.php`. - This //appears// to provide a reasonable fast way to issue this query very quickly in the average case, without the various issues that plagued D5257. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley, jhurwitz Maniphest Tasks: T2683 Differential Revision: https://secure.phabricator.com/D9045
2014-05-10 19:10:13 +02:00
'PhabricatorRepositoryGraphCache' => 'applications/repository/graphcache/PhabricatorRepositoryGraphCache.php',
Move Git discovery into DiscoveryEngine Summary: Ref T4327. Consolidates and simplifies infrastructure: - Moves Git discovery into DiscoveryEngine. - Collapses a bunch of the Git and Mercurial code related to stream discovery. - Removes all cach code from PullLocal daemon (it's no longer called). - Adds basic unit tests for Git and Mercurial discovery. Various cleanup: - Makes GitStream and MercurialStream extend a common base. - Improves performance of MercurialStream in some cases, by requiring fewer commits be output and parsed. - Makes mirroring exceptions easier to debug. - Fixes discovery of Mercurial repositories with multiple branch heads. - Adds some missing `pht()`. Test Plan: I tested this fairly throughly because I think this phase is complete: - Made new repositories in multiple VCSes and did full imports. - Particularly, I reimported Arcanist to make sure that TODO was resolved. I think it was related to the toposort stuff. - Pushed commits to multiple VCSes. - Pushed commits to a non-close branch, then pushed a merge commit. Observed commits import initially as non-close, then get flagged for close. - Started full daemons and resolved various minor issues that showed up in the daemon log until everything ran cleanly. - Basically spent about 30 minutes banging on this in every way I could think of to try to break it. I found and fixed some minor stuff, but it seems solid. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7987
2014-01-17 00:31:52 +01:00
'PhabricatorRepositoryGraphStream' => 'applications/repository/daemon/PhabricatorRepositoryGraphStream.php',
Implement a chunked, APC-backed graph cache Summary: Ref T2683. This is a refinement and simplification of D5257. In particular: - D5257 only cached the commit chain, not path changes. This meant that we had to go issue an awkward query (which was slow on Facebook's install) periodically while reading the cache. This was reasonable locally but killed performance at FB scale. Instead, we can include path information in the cache. It is very rare that this is large except in Subversion, and we do not need to use this cache in Subversion. In other VCSes, the scale of this data is quite small (a handful of bytes per commit on average). - D5257 required a large, slow offline computation step. This relies on D9044 to populate parent data so we can build the cache online at will, and let it expire with normal LRU/LFU/whatever semantics. We need this parent data for other reasons anyway. - D5257 separated graph chunks per-repository. This change assumes we'll be able to pull stuff from APC most of the time and that the cost of switching chunks is not very large, so we can just build one chunk cache across all repositories. This allows the cache to be simpler. - D5257 needed an offline cache, and used a unique cache structure. Since this one can be built online it can mostly use normal cache code. - This also supports online appends to the cache. - Finally, this has a timeout to guarantee a ceiling on the worst case: the worst case is something like a query for a file that has never existed, in a repository which receives exactly 1 commit every time other repositories receive 4095 commits, on a cold cache. If we hit cases like this we can bail after warming the cache up a bit and fall back to asking the VCS for an answer. This cache isn't perfect, but I believe it will give us substantial gains in the average case. It can often satisfy "average-looking" queries in 4-8ms, and pathological-ish queries in 20ms on my machine; `hg` usually can't even start up in less than 100ms. The major thing that's attractive about this approach is that it does not require anything external or complicated, and will "just work", even producing reasonble improvements for users without APC. In followups, I'll modify queries to use this cache and see if it holds up in more realistic workloads. Test Plan: - Used `bin/repository cache` to examine the behavior of this cache. - Did some profiling/testing from the web UI using `debug.php`. - This //appears// to provide a reasonable fast way to issue this query very quickly in the average case, without the various issues that plagued D5257. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley, jhurwitz Maniphest Tasks: T2683 Differential Revision: https://secure.phabricator.com/D9045
2014-05-10 19:10:13 +02:00
'PhabricatorRepositoryManagementCacheWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementCacheWorkflow.php',
Add `bin/repository clusterize` and document setup and migration for clusters Summary: Ref T4292. This provides at least some sort of hint about how to set up cluster repositories. Test Plan: - Read documentation. - Ran `bin/repository clusterize` to add + remove clusters. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4292 Differential Revision: https://secure.phabricator.com/D15798
2016-04-25 16:45:10 +02:00
'PhabricatorRepositoryManagementClusterizeWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementClusterizeWorkflow.php',
Introduce "bin/repository" for repository management Summary: Nothing new or exciting here yet, just moving the random scripts/repositories/ things to bin/repository. Also add `repository list`. (Console stuff comes from D2841.) Test Plan: Ran `repository list`, `repository pull`, `repository discover`, `repository discover --verbose`, `repository help`. Reviewers: jungejason, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2849
2012-06-25 21:35:37 +02:00
'PhabricatorRepositoryManagementDiscoverWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementDiscoverWorkflow.php',
Add an administrative `bin/repository importing` command to list importing commits Summary: Ref T4068. Adds a command to list all commits in an "importing" status. This will allow users to use `reparse.php` to diagnose and repair issues. Test Plan: - Ran `bin/repository importing P`, etc. - Used `reparse.php` to reparse some commit stages and saw status update correctly. - Ran on a repo with no importing commits. - Ran with `... --simple | xargs`, which saves us having to put an `awk` or something in there for users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4068 Differential Revision: https://secure.phabricator.com/D7515
2013-11-06 20:26:41 +01:00
'PhabricatorRepositoryManagementImportingWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementImportingWorkflow.php',
Add `repository list-paths` and `repository move-paths` Summary: Ref T7149. These formalize the local path adjustment step for cluster imports, rather than relying on an ad-hoc script. Test Plan: Used `list-paths` and `move-paths` to list and move repositories. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D13621
2015-07-16 23:11:33 +02:00
'PhabricatorRepositoryManagementListPathsWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementListPathsWorkflow.php',
Introduce "bin/repository" for repository management Summary: Nothing new or exciting here yet, just moving the random scripts/repositories/ things to bin/repository. Also add `repository list`. (Console stuff comes from D2841.) Test Plan: Ran `repository list`, `repository pull`, `repository discover`, `repository discover --verbose`, `repository help`. Reviewers: jungejason, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2849
2012-06-25 21:35:37 +02:00
'PhabricatorRepositoryManagementListWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementListWorkflow.php',
Provide a standalone query for resolution of commit author/committer into Phabricator users Summary: Ref T4195. To implement the "Author" and "Committer" rules, I need to resolve author/committer strings into Phabricator users. The code to do this is currently buried in the daemons. Extract it into a standalone query. I also added `bin/repository lookup-users <commit>` to test this query, both to improve confidence I'm getting this right and to provide a diagnostic command for users, since there's occasionally some confusion over how author/committer strings resolve into valid users. Test Plan: I tested this using `bin/repository lookup-users` and `reparse.php --message` on Git, Mercurial and SVN commits. Here's the `lookup-users` output: >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rINIS3 Examining commit rINIS3... Raw author string: epriestley Phabricator user: epriestley (Evan Priestley ) Raw committer string: null >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rPOEMS165b6c54f487c8 Examining commit rPOEMS165b6c54f487... Raw author string: epriestley <git@epriestley.com> Phabricator user: epriestley (Evan Priestley ) Raw committer string: epriestley <git@epriestley.com> Phabricator user: epriestley (Evan Priestley ) >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rINIH6d24c1aee7741e Examining commit rINIH6d24c1aee774... Raw author string: epriestley <hg@yghe.net> Phabricator user: epriestley (Evan Priestley ) Raw committer string: null >>> orbital ~/devtools/phabricator $ The `reparse.php` output was similar, and all VCSes resolved authors correctly. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1731, T4195 Differential Revision: https://secure.phabricator.com/D7801
2013-12-19 20:05:17 +01:00
'PhabricatorRepositoryManagementLookupUsersWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementLookupUsersWorkflow.php',
Add an administrative `bin/repository mark-imported` command Summary: Ref T4068. In some cases like that one, I anticipate a repository not fully importing when a handful of random commits are broken. In the long run we should just deal with that properly, but in the meantime provide an administrative escape hatch so you can mark the repository as imported and get it running normally. The major reason to do this is that Herald, Feed, Harbormaster, etc., won't activate until a repository is "imported". Test Plan: - Tried to mark an imported repository as imported, got an "already imported" message. - Same for not-imported. - Marked a repository not-imported. - Marked a repository imported. - Marked a repository not-imported, then waited for the daemons to mark it imported again automatically. Reviewers: btrahan Reviewed By: btrahan CC: aran, kbrownlees Maniphest Tasks: T4068 Differential Revision: https://secure.phabricator.com/D7514
2013-11-06 20:26:24 +01:00
'PhabricatorRepositoryManagementMarkImportedWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementMarkImportedWorkflow.php',
Separate repository mirroring into an Engine and provide `bin/repository mirror` Summary: Ref T4338. Currently, there's no diagnostic command to execute mirroring (so I can't give users an easy command to run), and it's roughly the last piece of real logic left in the PullLocal daemon. Separate mirroring out, and provide `bin/repository mirror`. Test Plan: - Ran `bin/repository mirror` to mirror a repository. - Ran PullLocalDaemon and verified it also continued mirroring normally. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4338 Differential Revision: https://secure.phabricator.com/D8066
2014-01-25 23:01:58 +01:00
'PhabricatorRepositoryManagementMirrorWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementMirrorWorkflow.php',
Add `repository list-paths` and `repository move-paths` Summary: Ref T7149. These formalize the local path adjustment step for cluster imports, rather than relying on an ad-hoc script. Test Plan: Used `list-paths` and `move-paths` to list and move repositories. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D13621
2015-07-16 23:11:33 +02:00
'PhabricatorRepositoryManagementMovePathsWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementMovePathsWorkflow.php',
Record parent relationships when discovering commits Summary: Ref T4455. This adds a `repository_parents` table which stores `<childCommitID, parentCommitID>` relationships. For new commits, it is populated when commits are discovered. For older commits, there's a `bin/repository parents` script to rebuild the data. Right now, there's no UI suggestion that you should run the script. I haven't come up with a super clean way to do this, and this table will only improve performance for now, so it's not important that we get everyone to run the script right away. I'm just leaving it for the moment, and we can figure out how to tell admins to run it later. The ultimate goal is to solve T2683, but solving T4455 gets us some stuff anyway (for example, we can serve `diffusion.commitparentsquery` faster out of this cache). Test Plan: - Used `bin/repository discover` to discover new commits in Git, SVN and Mercurial repositories. - Used `bin/repository parents` to rebuild Git and Mercurial repositories (SVN repos just exit with a message). - Verified that the table appears to be sensible. Reviewers: btrahan Reviewed By: btrahan Subscribers: jhurwitz, epriestley Maniphest Tasks: T4455 Differential Revision: https://secure.phabricator.com/D9044
2014-05-10 21:41:18 +02:00
'PhabricatorRepositoryManagementParentsWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementParentsWorkflow.php',
Introduce "bin/repository" for repository management Summary: Nothing new or exciting here yet, just moving the random scripts/repositories/ things to bin/repository. Also add `repository list`. (Console stuff comes from D2841.) Test Plan: Ran `repository list`, `repository pull`, `repository discover`, `repository discover --verbose`, `repository help`. Reviewers: jungejason, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2849
2012-06-25 21:35:37 +02:00
'PhabricatorRepositoryManagementPullWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementPullWorkflow.php',
Introduce ref cursors for repository parsing Summary: Ref T4327. I want to make change parsing testable; one thing which is blocking this is that the Git discovery process is still part of `PullLocal` daemon instead of being part of `DiscoveryEngine`. The unit test stuff which I want to use for change parsing relies on `DiscoveryEngine` to discover repositories during unit tests. The major reason git discovery isn't part of `DiscoveryEngine` is that it relies on the messy "autoclose" logic, which we never implemented for Mercurial. Generally, I don't like how autoclose was implemented: it's complicated and gross and too hard to figure out and extend. Instead, I want to do something more similar to what we do for pushes, which is cleaner overall. Basically this means remembering the old branch heads from the last time we parsed a repository, and figuring out what's new by comparing the old and new branch heads. This should give us several advantages: - It should be simpler to understand than the autoclose stuff, which is pretty mind-numbing, at least for me. - It will let us satisfy branch and tag queries cheaply (from the database) instead of having to go to the repository. We could also satisfy some ref-resolve queries from the database. - It should be easier to extend to Mercurial. This implements the basics -- pretty much a table to store the cursors, which we update only for Git for now. Test Plan: - Ran migration. - Ran `bin/repository discover X --trace --verbose` on various repositories with branches and tags, before and after modifying pushes. - Pushed commits to a git repo. - Looked at database tables. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7982
2014-01-16 21:05:30 +01:00
'PhabricatorRepositoryManagementRefsWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementRefsWorkflow.php',
Repositories - Move scripts/repository/reparse.php to bin/repository reparse Summary: Fixes T5966. Accomplishes a few things - see title - adds a force-autoclose flag and the plumbing for it - removes references to some HarborMaster thing that used to key off commits and seems long dead, but forgotten :/ Test Plan: ran a few commands. These first three had great success: `./repository reparse --all FIRSTREPO --message --change --herald --owners` `./repository reparse --all FIRSTREPO --message --change --herald --owners --min-date yesterday` `./repository reparse --all FIRSTREPO --message --change --herald --owners --min-date yesterday --force-autoclose` ...and these next two showed me some errors as expected: `./repository reparse --all FIRSTREPO --message --change --herald --owners --min-date garbagedata` `./repository reparse --all GARBAGEREPO --message --change --herald --owners` Also, made a diff in a repository with autoclose disabled and commited the diff. Later, reparse the diff with force-autoclose. Verified the diff closed and that the reason "why" had the proper message text. Reviewers: epriestley Reviewed By: epriestley Subscribers: joshuaspence, epriestley, Korvin Maniphest Tasks: T5966 Differential Revision: https://secure.phabricator.com/D10492
2015-01-06 20:42:15 +01:00
'PhabricatorRepositoryManagementReparseWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementReparseWorkflow.php',
Implement `bin/repository thaw` for unfreezing cluster repositories Summary: Ref T10751. Add support tooling for manually prying your way out of trouble if disaster strikes. Refine documentation, try to refer to devices as "devices" more consistently instead of sometimes calling them "nodes". Test Plan: Promoted and demoted repository devices with `bin/repository thaw`. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10751 Differential Revision: https://secure.phabricator.com/D15768
2016-04-20 15:54:53 +02:00
'PhabricatorRepositoryManagementThawWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementThawWorkflow.php',
Separate repository updates from the pull daemon Summary: Ref T4605. Currently, the PullLocal daemon is responsible for two relatively distinct things: - scheduling repository updates; and - actually updating repositories. Move the "actually updating" part into a new `bin/repository update` command, which basically runs the pull, discover, refs and mirror commands. This will let the parent process focus on scheduling in a more understandable way and update multiple repositories at once. It also makes it easier to debug and understand update behavior since the non-scheduling pipeline can be run separately. Test Plan: - Ran `update --trace` on SVN, Mercurial and Git repos. - Ran PullLocal daemon for a while without issues. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4605 Differential Revision: https://secure.phabricator.com/D8780
2014-04-16 22:00:29 +02:00
'PhabricatorRepositoryManagementUpdateWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementUpdateWorkflow.php',
Introduce "bin/repository" for repository management Summary: Nothing new or exciting here yet, just moving the random scripts/repositories/ things to bin/repository. Also add `repository list`. (Console stuff comes from D2841.) Test Plan: Ran `repository list`, `repository pull`, `repository discover`, `repository discover --verbose`, `repository help`. Reviewers: jungejason, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2849
2012-06-25 21:35:37 +02:00
'PhabricatorRepositoryManagementWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementWorkflow.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryMercurialCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/PhabricatorRepositoryMercurialCommitChangeParserWorker.php',
'PhabricatorRepositoryMercurialCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/PhabricatorRepositoryMercurialCommitMessageParserWorker.php',
Add UI for defining repository mirrors Summary: Ref T4038. This adds everything except the actual pushing part for mirrors. This isn't the most beautiful or sophisticated UI, but I want get the authoritative repositories self-hosted and get users beta-ing hosting as soon as possible. We can do transactions, etc., later on. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4038 Differential Revision: https://secure.phabricator.com/D7632
2013-11-23 00:23:50 +01:00
'PhabricatorRepositoryMirror' => 'applications/repository/storage/PhabricatorRepositoryMirror.php',
Separate repository mirroring into an Engine and provide `bin/repository mirror` Summary: Ref T4338. Currently, there's no diagnostic command to execute mirroring (so I can't give users an easy command to run), and it's roughly the last piece of real logic left in the PullLocal daemon. Separate mirroring out, and provide `bin/repository mirror`. Test Plan: - Ran `bin/repository mirror` to mirror a repository. - Ran PullLocalDaemon and verified it also continued mirroring normally. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4338 Differential Revision: https://secure.phabricator.com/D8066
2014-01-25 23:01:58 +01:00
'PhabricatorRepositoryMirrorEngine' => 'applications/repository/engine/PhabricatorRepositoryMirrorEngine.php',
Begin making change parsers testable Summary: Ref T4327. There are a bunch of other probably-related tasks too, some linked there. We have some rare/unusual bugs in the change parsers, mostly in Subversion, but it's terrifying to touch them because they're complicated and fragile and have no test coverage. To fix this stuff, I want to make them more testable. In particular, they basically end with this big INSERT right now. Instead, I'm going to make them return objects representing the data to be inserted, then have the common infrastructure do the insert. This gives us two benefits: - Reduced code duplication on the insert; - we can stop before the insert and have unit tests examine the objects. This swaps the Git parser over, but doesn't swap the hg/svn parsers yet. I'll do those separately, the SVN one looks a bit tricky. Test Plan: - Used `scripts/repository/reparse.php` to reparse a Git commit, with `--trace`. Verified it looked the same as before and the SQL that was executed seemed reasonable. - Did the same for `hg` / `svn` commits, to make sure I didn't derp anything. These aren't expected to do anything differently. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7980
2014-01-20 22:12:44 +01:00
'PhabricatorRepositoryParsedChange' => 'applications/repository/data/PhabricatorRepositoryParsedChange.php',
Make repository pulls testable Summary: Ref T2784. This moves us toward being able to test the background and Conduit pipelines for repositories. In particular: - Separate the logic for pulling repositories (`git pull`, `hg pull`) out of `PhabricatorRepositoryPullLocalDaemon` and put it in `PhabricatorRepositoryPullEngine`. This allows repositories to be pulled directly without invoking the daemons. - Add tests for the engine, including a future-looking base test case. - Add basic `PhutilDirectoryFixture`-based repositories. Next steps: # Do the same for repo discovery. # Then we can start writing tests against specific Conduit methods. Test Plan: Ran unit tests. Ran `bin/repository pull` on SVN, Hg and Git repositories. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran, nh Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5904
2013-05-13 04:05:52 +02:00
'PhabricatorRepositoryPullEngine' => 'applications/repository/engine/PhabricatorRepositoryPullEngine.php',
Add a basic pull event log for debugging repository cloning Summary: Ref T10228. This is currently quite limited: - No UI. - No SSH support. My primary goal is to debug the issue in T10228. In the long run we can expand this to be a bit fancier. Test Plan: Made various valid and invalid clones, got sucess responses and not-so-successful responses, viewed the log table for general corresponding messages and broad sanity. Ran GC via `bin/phd debug trigger`, no issues. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10228 Differential Revision: https://secure.phabricator.com/D15127
2016-01-28 14:21:38 +01:00
'PhabricatorRepositoryPullEvent' => 'applications/repository/storage/PhabricatorRepositoryPullEvent.php',
'PhabricatorRepositoryPullEventPHIDType' => 'applications/repository/phid/PhabricatorRepositoryPullEventPHIDType.php',
'PhabricatorRepositoryPullEventQuery' => 'applications/repository/query/PhabricatorRepositoryPullEventQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryPullLocalDaemon' => 'applications/repository/daemon/PhabricatorRepositoryPullLocalDaemon.php',
Provide a real object ("PhabricatorRepositoryPushEvent") to represent an entire push transaction Summary: Ref T4677. Currently, we record individual actions in a push as PhabricatorRepositoryPushLogs, but tie them together only loosely with a `transactionKey`. Provide a real PushEvent object, and move some of the denormalized fields to it. This primarily just gives us more robust infrastructure for building, e.g., email about pushes, for T4677, since we can act on real PHIDs rather than passing awkward identifiers around. Test Plan: - Performed migration. - Looked at database for consistency. - Browsed/queried push logs. - Pushed a bunch of stuff. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4677 Differential Revision: https://secure.phabricator.com/D8615
2014-03-26 03:43:26 +01:00
'PhabricatorRepositoryPushEvent' => 'applications/repository/storage/PhabricatorRepositoryPushEvent.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorRepositoryPushEventPHIDType' => 'applications/repository/phid/PhabricatorRepositoryPushEventPHIDType.php',
Provide a real object ("PhabricatorRepositoryPushEvent") to represent an entire push transaction Summary: Ref T4677. Currently, we record individual actions in a push as PhabricatorRepositoryPushLogs, but tie them together only loosely with a `transactionKey`. Provide a real PushEvent object, and move some of the denormalized fields to it. This primarily just gives us more robust infrastructure for building, e.g., email about pushes, for T4677, since we can act on real PHIDs rather than passing awkward identifiers around. Test Plan: - Performed migration. - Looked at database for consistency. - Browsed/queried push logs. - Pushed a bunch of stuff. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4677 Differential Revision: https://secure.phabricator.com/D8615
2014-03-26 03:43:26 +01:00
'PhabricatorRepositoryPushEventQuery' => 'applications/repository/query/PhabricatorRepositoryPushEventQuery.php',
Add a basic push log for recording repository push events Summary: Ref T4195. This log serves two purposes: - It's a log, so you can see what happened. Particularly, in Git/Hg, there is no other way to tell: - Who //pushed// a change (vs committed / authored)? - When was a change pushed? - What was the old value of some tag/branch before someone destroyed it? - We can hand these objects off to Herald to implement pre-commit rules. This is a very basic implementation, but gets some data written and has a basic UI for it. Test Plan: {F87339} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7705
2013-12-05 20:56:14 +01:00
'PhabricatorRepositoryPushLog' => 'applications/repository/storage/PhabricatorRepositoryPushLog.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorRepositoryPushLogPHIDType' => 'applications/repository/phid/PhabricatorRepositoryPushLogPHIDType.php',
Add a basic push log for recording repository push events Summary: Ref T4195. This log serves two purposes: - It's a log, so you can see what happened. Particularly, in Git/Hg, there is no other way to tell: - Who //pushed// a change (vs committed / authored)? - When was a change pushed? - What was the old value of some tag/branch before someone destroyed it? - We can hand these objects off to Herald to implement pre-commit rules. This is a very basic implementation, but gets some data written and has a basic UI for it. Test Plan: {F87339} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7705
2013-12-05 20:56:14 +01:00
'PhabricatorRepositoryPushLogQuery' => 'applications/repository/query/PhabricatorRepositoryPushLogQuery.php',
'PhabricatorRepositoryPushLogSearchEngine' => 'applications/repository/query/PhabricatorRepositoryPushLogSearchEngine.php',
Allow users to receive email about pushes via Herald Summary: Fixes T4677. Implements a "send an email" pre-receive action, which sends push summaries. For use cases where features are often pushed as a large number of commits (e.g., checkpoint commits are retained), using commit emails means users get a ton of email. Instead, this allows you to get an email about a push, which summarizes what changed. Overall, this is basically the same as commit email, but more suitable for some workflows. Test Plan: Wrote some rules, then made a bunch of pushes. Got email like this: {F134929} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4677 Differential Revision: https://secure.phabricator.com/D8618
2014-03-26 18:44:06 +01:00
'PhabricatorRepositoryPushMailWorker' => 'applications/repository/worker/PhabricatorRepositoryPushMailWorker.php',
'PhabricatorRepositoryPushReplyHandler' => 'applications/repository/mail/PhabricatorRepositoryPushReplyHandler.php',
Make Repositories partially policy-aware Summary: Small step toward repository hosting. No user-visible changes. Test Plan: Looked at repositories in Diffusion. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D4227
2012-12-19 20:07:06 +01:00
'PhabricatorRepositoryQuery' => 'applications/repository/query/PhabricatorRepositoryQuery.php',
Introduce ref cursors for repository parsing Summary: Ref T4327. I want to make change parsing testable; one thing which is blocking this is that the Git discovery process is still part of `PullLocal` daemon instead of being part of `DiscoveryEngine`. The unit test stuff which I want to use for change parsing relies on `DiscoveryEngine` to discover repositories during unit tests. The major reason git discovery isn't part of `DiscoveryEngine` is that it relies on the messy "autoclose" logic, which we never implemented for Mercurial. Generally, I don't like how autoclose was implemented: it's complicated and gross and too hard to figure out and extend. Instead, I want to do something more similar to what we do for pushes, which is cleaner overall. Basically this means remembering the old branch heads from the last time we parsed a repository, and figuring out what's new by comparing the old and new branch heads. This should give us several advantages: - It should be simpler to understand than the autoclose stuff, which is pretty mind-numbing, at least for me. - It will let us satisfy branch and tag queries cheaply (from the database) instead of having to go to the repository. We could also satisfy some ref-resolve queries from the database. - It should be easier to extend to Mercurial. This implements the basics -- pretty much a table to store the cursors, which we update only for Git for now. Test Plan: - Ran migration. - Ran `bin/repository discover X --trace --verbose` on various repositories with branches and tags, before and after modifying pushes. - Pushed commits to a git repo. - Looked at database tables. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7982
2014-01-16 21:05:30 +01:00
'PhabricatorRepositoryRefCursor' => 'applications/repository/storage/PhabricatorRepositoryRefCursor.php',
Add proper PHIDs to RefCursors Summary: Ref T9952. See discussion there. This change is primarily aimed at letting me build a typeahead of branches in a repository so that we can land to arbitrary branches a few diffs from now. Test Plan: - Ran migrations. - Verified database populated properly with PHIDs (`SELECT * FROM repository_refcursor;`). - Ran `bin/repository update`. - Viewed a Git repository in Diffusion. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9952 Differential Revision: https://secure.phabricator.com/D14731
2015-12-10 21:59:25 +01:00
'PhabricatorRepositoryRefCursorPHIDType' => 'applications/repository/phid/PhabricatorRepositoryRefCursorPHIDType.php',
Introduce ref cursors for repository parsing Summary: Ref T4327. I want to make change parsing testable; one thing which is blocking this is that the Git discovery process is still part of `PullLocal` daemon instead of being part of `DiscoveryEngine`. The unit test stuff which I want to use for change parsing relies on `DiscoveryEngine` to discover repositories during unit tests. The major reason git discovery isn't part of `DiscoveryEngine` is that it relies on the messy "autoclose" logic, which we never implemented for Mercurial. Generally, I don't like how autoclose was implemented: it's complicated and gross and too hard to figure out and extend. Instead, I want to do something more similar to what we do for pushes, which is cleaner overall. Basically this means remembering the old branch heads from the last time we parsed a repository, and figuring out what's new by comparing the old and new branch heads. This should give us several advantages: - It should be simpler to understand than the autoclose stuff, which is pretty mind-numbing, at least for me. - It will let us satisfy branch and tag queries cheaply (from the database) instead of having to go to the repository. We could also satisfy some ref-resolve queries from the database. - It should be easier to extend to Mercurial. This implements the basics -- pretty much a table to store the cursors, which we update only for Git for now. Test Plan: - Ran migration. - Ran `bin/repository discover X --trace --verbose` on various repositories with branches and tags, before and after modifying pushes. - Pushed commits to a git repo. - Looked at database tables. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7982
2014-01-16 21:05:30 +01:00
'PhabricatorRepositoryRefCursorQuery' => 'applications/repository/query/PhabricatorRepositoryRefCursorQuery.php',
'PhabricatorRepositoryRefEngine' => 'applications/repository/engine/PhabricatorRepositoryRefEngine.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorRepositoryRepositoryPHIDType' => 'applications/repository/phid/PhabricatorRepositoryRepositoryPHIDType.php',
Generate expected schemata for Repository Summary: Ref T1191. Add specs for repository tables. Test Plan: Saw ~300 fewer schema warnings. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10575
2014-09-29 00:12:21 +02:00
'PhabricatorRepositorySchemaSpec' => 'applications/repository/storage/PhabricatorRepositorySchemaSpec.php',
Use ApplicationSearch in Diffusion Summary: Ref T2625. Switches Diffusion to ApplicationSearch. Notes: - Rendering is a bit rough, I'll clean that up next. - Ordering is a bit arbitrary, also coming shortly. Test Plan: Used `/diffusion/` to execute various searches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6917
2013-09-11 00:26:08 +02:00
'PhabricatorRepositorySearchEngine' => 'applications/repository/query/PhabricatorRepositorySearchEngine.php',
Add "RepositoryStatusMessage" and detailed information about initilization Summary: `RepositoryStatusMessage` is basically a key/value table associated with a repository that I'm using to let the daemons store the most recent event of a given type, so we can easily show it on the status dashboard. I think this will be a lot easier for users to figure out than digging through logfiles. I'm also going to write the "this needs a pull" status here eventually, for reducing the time lapse between pushes and discovery. - Add storage for these messages. - Have the pull engine populate the INIT phase. I'll do the FETCH phase next. - Update the status readout to show all the various states. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7461
2013-10-31 00:04:19 +01:00
'PhabricatorRepositoryStatusMessage' => 'applications/repository/storage/PhabricatorRepositoryStatusMessage.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositorySvnCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/PhabricatorRepositorySvnCommitChangeParserWorker.php',
'PhabricatorRepositorySvnCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/PhabricatorRepositorySvnCommitMessageParserWorker.php',
'PhabricatorRepositorySymbol' => 'applications/repository/storage/PhabricatorRepositorySymbol.php',
'PhabricatorRepositoryTestCase' => 'applications/repository/storage/__tests__/PhabricatorRepositoryTestCase.php',
Begin transacitonalizing repository edits and provide a more sensible edit interface Summary: Ref T2231, T603. Plan of attack here is pretty much: - Built out a new (currently not linked in the UI) edit interface in Diffusion which is transaction-based and has a sensible layout. - Build out a new create interface based on PagedForm which dumps into the new edit interface. - Throw the old stuff away. - Everyone lives happily ever after. Test Plan: {F44163} {F44164} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D6029
2013-05-24 21:37:42 +02:00
'PhabricatorRepositoryTransaction' => 'applications/repository/storage/PhabricatorRepositoryTransaction.php',
'PhabricatorRepositoryTransactionQuery' => 'applications/repository/query/PhabricatorRepositoryTransactionQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryType' => 'applications/repository/constants/PhabricatorRepositoryType.php',
Rough in the new custom URI panel Summary: Ref T10748. Ref T10366. No support for editing and no impact on the UI, but get some of the basics in place. Test Plan: {F1223279} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10366, T10748 Differential Revision: https://secure.phabricator.com/D15742
2016-04-17 17:17:49 +02:00
'PhabricatorRepositoryURI' => 'applications/repository/storage/PhabricatorRepositoryURI.php',
Move repository URIs to a dedicated index Summary: Ref T4705 (there are also some other adjacent related tasks dealing with URIs). Currently, we issue a "get repositories matching URIs: ..." query by loading every possible repository and then checking their URIs in PHP. Instead, put URIs in a separate table. I plan for each repository to potentially have multiple URIs soon, so this prepares for that. Test Plan: - Ran migrations. - Looked at index table, made sure it appeared sensible. - Ran some queries by `uri` to find repositories, found the repositories I expected. - Updated the remote URI of a repository, saw queries / index update appropriately. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4705 Differential Revision: https://secure.phabricator.com/D15005
2016-01-12 15:45:17 +01:00
'PhabricatorRepositoryURIIndex' => 'applications/repository/storage/PhabricatorRepositoryURIIndex.php',
Move repository URI normalization out of PullLocalDaemon Summary: Ref T4327. Moves us one small step forward toward testable change parsers by separating out this unrelated logic from the PullLocal daemon. We will also probably want to run this logic so we can do remote path lookups to limit the role of Arcanist Projects in the future, which is why I made the URI type (here, only "git") a parameter rather than calling this a `GitURINormalizer` or something. Test Plan: - Ran unit tests. - Ran `repository discover` on a correctly-configured remote repository. - Ran `repository discover` on an incorrectly-configured remote, got an error message. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7981
2014-01-16 19:49:03 +01:00
'PhabricatorRepositoryURINormalizer' => 'applications/repository/data/PhabricatorRepositoryURINormalizer.php',
'PhabricatorRepositoryURINormalizerTestCase' => 'applications/repository/data/__tests__/PhabricatorRepositoryURINormalizerTestCase.php',
Rough sketch of new repository URI editing Summary: Ref T10748. Ref T10366. This adds a new EditEngine, EditController, Editor, Query, and Transaction for RepositoryURIs. None of these really do anything helpful yet, and these URIs are still unused in the actual application. Test Plan: {F1249794} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10366, T10748 Differential Revision: https://secure.phabricator.com/D15815
2016-04-28 17:33:44 +02:00
'PhabricatorRepositoryURIPHIDType' => 'applications/repository/phid/PhabricatorRepositoryURIPHIDType.php',
'PhabricatorRepositoryURIQuery' => 'applications/repository/query/PhabricatorRepositoryURIQuery.php',
Fix some repository URI handling issues in Git and Mercurial Summary: See <https://github.com/facebook/phabricator/issues/467>. @dctrwatson also ran into an issue where we were trying to `setPass()` a GitURI. - For Git and Mercurial, properly generate credential URIs where relevant. - Don't try to `setPass()` on Git-style URIs. This isn't perfect but should clean things up a bit. Test Plan: Added unit tests. Lots of `grep`. Reviewers: btrahan Reviewed By: btrahan CC: dctrwatson, aran Differential Revision: https://secure.phabricator.com/D7759
2013-12-12 18:45:27 +01:00
'PhabricatorRepositoryURITestCase' => 'applications/repository/storage/__tests__/PhabricatorRepositoryURITestCase.php',
Rough sketch of new repository URI editing Summary: Ref T10748. Ref T10366. This adds a new EditEngine, EditController, Editor, Query, and Transaction for RepositoryURIs. None of these really do anything helpful yet, and these URIs are still unused in the actual application. Test Plan: {F1249794} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10366, T10748 Differential Revision: https://secure.phabricator.com/D15815
2016-04-28 17:33:44 +02:00
'PhabricatorRepositoryURITransaction' => 'applications/repository/storage/PhabricatorRepositoryURITransaction.php',
Add repository URI view pages and IO/Display edit logic Summary: Ref T10748. - New View page for repository URIs. - Make display and I/O behavior (observe, mirror, read, read/write) editable. - Add a bunch of checks to prevent you from completely screwing up a repository by making it writable from a bunch of differnet sources. Test Plan: {F1249866} {F1249867} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15816
2016-04-28 19:40:35 +02:00
'PhabricatorRepositoryURITransactionQuery' => 'applications/repository/query/PhabricatorRepositoryURITransactionQuery.php',
Implementation of VCS passwords against user. Summary: This allows users to set their HTTP access passwords via Diffusion interface. Test Plan: Clicked the "Set HTTP Access Password" link, set a password and saw it appear in the DB. Reviewers: #blessed_reviewers, hach-que, btrahan Reviewed By: hach-que CC: Korvin, epriestley, aran, jamesr Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7462
2013-11-01 16:34:11 +01:00
'PhabricatorRepositoryVCSPassword' => 'applications/repository/storage/PhabricatorRepositoryVCSPassword.php',
Fix Mercurial command injection vulnerability Summary: See <http://chargen.matasano.com/chargen/2015/3/17/this-new-vulnerability-mercurial-command-injection-cve-2014-9462.html>. Test Plan: Crafted bad remote URL; got error instead of code execution. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D12112
2015-03-20 17:26:32 +01:00
'PhabricatorRepositoryVersion' => 'applications/repository/constants/PhabricatorRepositoryVersion.php',
Move toward multi-master replicated repositories Summary: Ref T4292. This mostly implements the locking/versioning logic for multi-master repositories. It is only active on Git SSH pathways, and doesn't actually do anything useful yet: it just does bookkeeping so far. When we read (e.g., `git fetch`) the logic goes like this: - Get the read lock (unique to device + repository). - Read all the versions of the repository on every other device. - If any node has a newer version: - Fetch the newer version. - Increment our version to be the same as the version we fetched. - Release the read lock. - Actually do the fetch. This makes sure that any time you do a read, you always read the most recently acknowledged write. You may have to wait for an internal fetch to happen (this isn't actually implemented yet) but the operation will always work like you expect it to. When we write (e.g., `git push`) the logic goes like this: - Get the write lock (unique to the repository). - Do all the read steps so we're up to date. - Mark a write pending. - Do the actual write. - Bump our version and mark our write finished. - Release the write lock. This allows you to write to any replica. Again, you might have to wait for a fetch first, but everything will work like you expect. There's one notable failure mode here: if the network connection between the repository node and the database fails during the write, the write lock might be released even though a write is ongoing. The "isWriting" column protects against that, by staying locked if we lose our connection to the database. This will currently "freeze" the repository (prevent any new writes) until an administrator can sort things out, since it'd dangerous to continue doing writes (we may lose data). (Since we won't actually acknowledge the write, I think, we could probably smooth this out a bit and make it self-healing //most// of the time: basically, have the broken node rewind itself by updating from another good node. But that's a little more complex.) Test Plan: - Pushed changes to a cluster-mode repository. - Viewed web interface, saw "writing" flag and version changes. - Pulled changes. - Faked various failures, got sensible states. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4292 Differential Revision: https://secure.phabricator.com/D15688
2016-04-11 20:58:02 +02:00
'PhabricatorRepositoryWorkingCopyVersion' => 'applications/repository/storage/PhabricatorRepositoryWorkingCopyVersion.php',
Modularize Aphront exception handling Summary: Ref T1806. Ref T7173. Depends on D14047. Currently, all exception handling is in this big messy clump in `AphrontDefaultApplicationConfiguration`. Split it out into modular classes. This will let a future change add new classes in the Phacility cluster which intercept particular exceptions we care about and replaces the default, generic responses with more useful, tailored responses. Test Plan: {F777391} - Hit a Conduit error (made a method throw). - Hit an Ajax error (made comment preview throw). - Hit a high security error (tried to edit TOTP). - Hit a rate limiting error (added a bunch of email addresses). - Hit a policy error (tried to look at something with no permission). - Hit an arbitrary exception (made a randomc ontroller throw). Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14049
2015-09-03 19:04:42 +02:00
'PhabricatorRequestExceptionHandler' => 'aphront/handler/PhabricatorRequestExceptionHandler.php',
Also update the resource map This is not my morning. Auditors: chad
2015-12-11 17:23:39 +01:00
'PhabricatorResourceSite' => 'aphront/site/PhabricatorResourceSite.php',
Add a robots.txt file to disallow /diffusion/ Summary: Fixes T4610. Open to suggestions, etc., if there's anything I'm missing. Also: - Moves these "system" endpoints into a real application. - Makes `isUnlisted()` work a little more consistently. Test Plan: Accessed `/robots.txt`, `/status/` and `/debug/`. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4610 Differential Revision: https://secure.phabricator.com/D8532
2014-03-14 19:53:17 +01:00
'PhabricatorRobotsController' => 'applications/system/controller/PhabricatorRobotsController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorS3FileStorageEngine' => 'applications/files/engine/PhabricatorS3FileStorageEngine.php',
Add SMS support Summary: Provides a working SMS implementation with support for Twilio. This version doesn't really retry if we get any gruff at all. Future versions should retry. Test Plan: used bin/sms to send messages and look at them. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: aurelijus, epriestley, Korvin Maniphest Tasks: T920 Differential Revision: https://secure.phabricator.com/D8930
2014-05-09 21:47:21 +02:00
'PhabricatorSMS' => 'infrastructure/sms/storage/PhabricatorSMS.php',
'PhabricatorSMSConfigOptions' => 'applications/config/option/PhabricatorSMSConfigOptions.php',
'PhabricatorSMSDAO' => 'infrastructure/sms/storage/PhabricatorSMSDAO.php',
'PhabricatorSMSDemultiplexWorker' => 'infrastructure/sms/worker/PhabricatorSMSDemultiplexWorker.php',
'PhabricatorSMSImplementationAdapter' => 'infrastructure/sms/adapter/PhabricatorSMSImplementationAdapter.php',
'PhabricatorSMSImplementationTestBlackholeAdapter' => 'infrastructure/sms/adapter/PhabricatorSMSImplementationTestBlackholeAdapter.php',
'PhabricatorSMSImplementationTwilioAdapter' => 'infrastructure/sms/adapter/PhabricatorSMSImplementationTwilioAdapter.php',
'PhabricatorSMSManagementListOutboundWorkflow' => 'infrastructure/sms/management/PhabricatorSMSManagementListOutboundWorkflow.php',
'PhabricatorSMSManagementSendTestWorkflow' => 'infrastructure/sms/management/PhabricatorSMSManagementSendTestWorkflow.php',
'PhabricatorSMSManagementShowOutboundWorkflow' => 'infrastructure/sms/management/PhabricatorSMSManagementShowOutboundWorkflow.php',
'PhabricatorSMSManagementWorkflow' => 'infrastructure/sms/management/PhabricatorSMSManagementWorkflow.php',
'PhabricatorSMSSendWorker' => 'infrastructure/sms/worker/PhabricatorSMSSendWorker.php',
'PhabricatorSMSWorker' => 'infrastructure/sms/worker/PhabricatorSMSWorker.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'PhabricatorSQLPatchList' => 'infrastructure/storage/patch/PhabricatorSQLPatchList.php',
Add a "Generate Keypair" option on the SSH Keys panel Summary: Ref T4587. Add an option to automatically generate a keypair, associate the public key, and save the private key. Test Plan: Generated some keypairs. Hit error conditions, etc. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4587 Differential Revision: https://secure.phabricator.com/D8513
2014-03-13 02:17:11 +01:00
'PhabricatorSSHKeyGenerator' => 'infrastructure/util/PhabricatorSSHKeyGenerator.php',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorSSHKeysSettingsPanel' => 'applications/settings/panel/PhabricatorSSHKeysSettingsPanel.php',
Add an SSH access log Summary: Ref T4107. Ref T4189. This implements an SSH access log, similar to the HTTP access log. Test Plan: [Thu, 05 Dec 2013 13:45:41 -0800] 77841 orbital ::1 dweller epriestley epriestley git-receive-pack /diffusion/POEMS/ 0 324765 402 232 [Thu, 05 Dec 2013 13:45:48 -0800] 77860 orbital ::1 dweller epriestley epriestley git-receive-pack /diffusion/POEMS/ 0 325634 402 232 Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4107, T4189 Differential Revision: https://secure.phabricator.com/D7719
2013-12-06 02:00:48 +01:00
'PhabricatorSSHLog' => 'infrastructure/log/PhabricatorSSHLog.php',
Generalize SSH passthru for repository hosting Summary: Ref T2230. In Git, we can determine if a command is read-only or read/write from the command itself, but this isn't the case in Mercurial or SVN. For Mercurial and SVN, we need to proxy the protocol that's coming over the wire, look at each request from the client, and then check if it's a read or a write. To support this, provide a more flexible version of `passthruIO`. The way this will work is: - The SSH IO channel is wrapped in a `ProtocolChannel` which can parse the the incoming stream into message objects. - The `willWriteCallback` will look at those messages and determine if they're reads or writes. - If they're writes, it will check for write permission. - If we're good to go, the message object is converted back into a byte stream and handed to the underlying command. Test Plan: Executed `git clone`, `git clone --depth 3`, `git push` (against no-write repo, got error), `git push` (against valid repo). Reviewers: btrahan Reviewed By: btrahan CC: hach-que, asherkin, aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7551
2013-11-11 21:12:21 +01:00
'PhabricatorSSHPassthruCommand' => 'infrastructure/ssh/PhabricatorSSHPassthruCommand.php',
Separate SSH key management from the settings panel Summary: Ref T5833. I want to add SSH keys to Almanac devices, but the edit workflows for them are currently bound tightly to users. Instead, decouple key management from users and the settings panel. Test Plan: - Uploaded, generated, edited and deleted SSH keys. - Hit missing name, missing key, bad key format, duplicate key errors. - Edited/generated/deleted/etc keys for a bot user as an administrator. - Got HiSec'd on everything. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10824
2014-11-11 17:18:26 +01:00
'PhabricatorSSHPublicKeyInterface' => 'applications/auth/sshkey/PhabricatorSSHPublicKeyInterface.php',
Implement SSHD glue and Conduit SSH endpoint Summary: - Build "sshd-auth" (for authentication) and "sshd-exec" (for command execution) binaries. These are callable by "sshd-vcs", located [[https://github.com/epriestley/sshd-vcs | in my account on GitHub]]. They are based on precursors [[https://github.com/epriestley/sshd-vcs-glue | here on GitHub]] which I deployed for TenXer about a year ago, so I have some confidence they at least basically work. - The problem this solves is that normally every user would need an account on a machine to connect to it, and/or their public keys would all need to be listed in `~/.authorized_keys`. This is a big pain in most installs. Software like Gitosis/Gitolite solve this problem by giving you an easy way to add public keys to `~/.authorized_keys`, but this is pretty gross. - Roughly, instead of looking in `~/.authorized_keys` when a user connects, the patched sshd instead runs `echo <public key> | sshd-auth`. The `sshd-auth` script looks up the public key and authorizes the matching user, if they exist. It also forces sshd to run `sshd-exec` instead of a normal shell. - `sshd-exec` receives the authenticated user and any command which was passed to ssh (like `git receive-pack`) and can route them appropriately. - Overall, this permits a single account to be set up on a server which all Phabricator users can connect to without any extra work, and which can safely execute commands and apply appropriate permissions, and disable users when they are disabled in Phabricator and all that stuff. - Build out "sshd-exec" to do more thorough checks and setup, and delegate command execution to Workflows (they now exist, and did not when I originally built this stuff). - Convert @btrahan's conduit API script into a workflow and slightly simplify it (ConduitCall did not exist at the time it was written). The next steps here on the Repository side are to implement Workflows for Git, SVN and HG wire protocols. These will mostly just proxy the protocols, but also need to enforce permissions. So the approach will basically be: - Implement workflows for stuff like `git receive-pack`. - These workflows will implement enough of the underlying protocol to determine what resource the user is trying to access, and whether they want to read or write it. - They'll then do a permissons check, and kick the user out if they don't have permission to do whatever they are trying to do. - If the user does have permission, we just proxy the rest of the transaction. Next steps on the Conduit side are more simple: - Make ConduitClient understand "ssh://" URLs. Test Plan: Ran `sshd-exec --phabricator-ssh-user epriestley conduit differential.query`, etc. This will get a more comprehensive test once I set up sshd-vcs. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T550 Differential Revision: https://secure.phabricator.com/D4229
2012-12-19 20:08:07 +01:00
'PhabricatorSSHWorkflow' => 'infrastructure/ssh/PhabricatorSSHWorkflow.php',
Move paste search to generic search. Summary: Begin implementing generic application search and refactoring paste search. Test Plan: See if the paste search still works. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5621
2013-04-14 15:53:20 +02:00
'PhabricatorSavedQuery' => 'applications/search/storage/PhabricatorSavedQuery.php',
Introduce PhabricatorSavedQueryQuery Summary: Same as D6051, but for SavedQueries instead of NamedQueries. These are POLICY_PUBLIC because you need to know the hash to access them, and because we want to let users copy/paste query URLs. Ref T2625. Test Plan: Saved a query, reused a saved query. Reviewers: btrahan, blc Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6054
2013-05-27 22:41:20 +02:00
'PhabricatorSavedQueryQuery' => 'applications/search/query/PhabricatorSavedQueryQuery.php',
Add a "schedule task" trigger action Summary: Ref T6881. Add a standard "just queue a task" trigger action; I expect almost all application code to use this. Test Plan: Will test in Instances. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11429
2015-01-20 01:55:23 +01:00
'PhabricatorScheduleTaskTriggerAction' => 'infrastructure/daemon/workers/action/PhabricatorScheduleTaskTriggerAction.php',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorScopedEnv' => 'infrastructure/env/PhabricatorScopedEnv.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSearchAbstractDocument' => 'applications/search/index/PhabricatorSearchAbstractDocument.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorSearchApplication' => 'applications/search/application/PhabricatorSearchApplication.php',
Partially use ApplicationSearch in main search Summary: Ref T4365. Primary search currently uses `PhabricatorSearchQuery` for storage, which is pretty much the same as `PhabricatorSavedQuery`, except that it's old and not used anywhere else anymore. Maniphest used to also use this table, but no longer does after Septmeber, 2013. We need to retain the class so the migration can work. This introduces `PhabricatorSearchApplicationSearchEngine` and `PhabricatorSearchDocumentQuery`, but they're both stubs that I just needed for technical reasons and/or to pass lint. The next couple patches will move logic into them and use ApplicationSearch properly. Test Plan: - Searched for stuff. - Searched for stuff with filters. - Searched for fulltext in Maniphest. - Grepped for `PhabricatorSearchQuery`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4365 Differential Revision: https://secure.phabricator.com/D8120
2014-02-03 21:51:08 +01:00
'PhabricatorSearchApplicationSearchEngine' => 'applications/search/query/PhabricatorSearchApplicationSearchEngine.php',
Modernize search engine selection Summary: Remove the `PhabricatorDefaultSearchEngineSelector` class. This is quite similar to D12053. Test Plan: Went to `/view/PhabricatorSearchApplication/` and saw the storage engine configuration. Set `search.elastic.host` and saw the highlighted storage engine change. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D12670
2015-05-19 22:59:58 +02:00
'PhabricatorSearchApplicationStorageEnginePanel' => 'applications/search/applicationpanel/PhabricatorSearchApplicationStorageEnginePanel.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSearchAttachController' => 'applications/search/controller/PhabricatorSearchAttachController.php',
'PhabricatorSearchBaseController' => 'applications/search/controller/PhabricatorSearchBaseController.php',
Move Pholio to SearchFields Summary: Ref T8441. Ref T7715. - Update PholioSearchEngine. - Automatically add project fields. - Update Paste to support project search. - Simplify common Query class construction. Test Plan: - Searched for pastes. - Searched for mocks. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13174
2015-06-07 16:31:28 +02:00
'PhabricatorSearchCheckboxesField' => 'applications/search/field/PhabricatorSearchCheckboxesField.php',
Search options. Test Plan: - Looked at the new options - Saved `search.engine-selector` successfully. Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4410
2013-01-12 00:28:16 +01:00
'PhabricatorSearchConfigOptions' => 'applications/search/config/PhabricatorSearchConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSearchController' => 'applications/search/controller/PhabricatorSearchController.php',
Move Projects to SearchFields Summary: Ref T8441. Ref T7715. This is mostly about getting SearchFields + CustomFields working. (This includes a couple of SearchFields which aren't used quite yet.) Test Plan: - Used all search controls. - Defined custom fields and searched for them. - Created an old saved search which searches on custom fields on master, switched to this patch, search worked exaclty as written. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13189
2015-06-08 21:20:16 +02:00
'PhabricatorSearchCustomFieldProxyField' => 'applications/search/field/PhabricatorSearchCustomFieldProxyField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSearchDAO' => 'applications/search/storage/PhabricatorSearchDAO.php',
Modernize global search typeahead datasource Summary: Ref T4420. Bring the global search up to date. Test Plan: Typed various things into global search. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9889
2014-07-18 00:48:36 +02:00
'PhabricatorSearchDatasource' => 'applications/search/typeahead/PhabricatorSearchDatasource.php',
Move Projects to SearchFields Summary: Ref T8441. Ref T7715. This is mostly about getting SearchFields + CustomFields working. (This includes a couple of SearchFields which aren't used quite yet.) Test Plan: - Used all search controls. - Defined custom fields and searched for them. - Created an old saved search which searches on custom fields on master, switched to this patch, search worked exaclty as written. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13189
2015-06-08 21:20:16 +02:00
'PhabricatorSearchDatasourceField' => 'applications/search/field/PhabricatorSearchDatasourceField.php',
Refactor Calendar Search, and implement Projects on events Summary: Ref T7950, Refactor Calendar Search, and implement Projects on events Test Plan: Verify that all queries in Calendar search still work, and that events can now have associated Projects that you can search by in Calendar Search. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T7950 Differential Revision: https://secure.phabricator.com/D13393
2015-06-22 22:27:37 +02:00
'PhabricatorSearchDateControlField' => 'applications/search/field/PhabricatorSearchDateControlField.php',
Begin modularizing fields in SearchEngines Summary: Ref T8441. Ref T7715. Add a layer of indirection to fields in search engines. This will allow us to: - Simplify SearchEngine code, which has collected a lot of duplication around expressing what is effectively field types. - Automatically add fields like "Spaces" and "Projects" (primary driver for T8441). - Reorder or hide fields (not sure if we really want to do this, but it seems plausible, and this will let us play around with it, at least). - Drive Conduit Query methods via SearchEngines, so the same code specifies both the search UI and the `application.query` endpoint (primary driver in T7715). Test Plan: - Searched for stuff in Paste, everything behaved exaclty like it used to (except that I removed the "no language" checkbox, which seemed like fluff from a bygone era). - Searched for stuff in other applications, saw no changes. - Hit date field errors. - Used query strings to specify values. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13169
2015-06-05 20:21:08 +02:00
'PhabricatorSearchDateField' => 'applications/search/field/PhabricatorSearchDateField.php',
Allow custom queries to be deleted Summary: Ref T2625. Currently, custom saved queries can be edited but not deleted. Allow them to be deleted. Also: - Clean up an unused property in `PhabricatorPasteViewController`. - Fix an issue with left nav highlighting of builtin queries. - Improve submit behavior for edits. - Add a cancel button on edits. Test Plan: Saved, edited and deleted queries. Reviewers: btrahan, blc Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6059
2013-05-27 22:42:44 +02:00
'PhabricatorSearchDeleteController' => 'applications/search/controller/PhabricatorSearchDeleteController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSearchDocument' => 'applications/search/storage/document/PhabricatorSearchDocument.php',
'PhabricatorSearchDocumentField' => 'applications/search/storage/document/PhabricatorSearchDocumentField.php',
Rename `PhabricatorSearchField` to `PhabricatorSearchFieldDocumentType` Summary: Ref T8441. I want to use `PhabricatorSearchField` for a better, more useful object. Test Plan: `grep`, `arc lint` Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8441 Differential Revision: https://secure.phabricator.com/D13168
2015-06-05 20:01:25 +02:00
'PhabricatorSearchDocumentFieldType' => 'applications/search/constants/PhabricatorSearchDocumentFieldType.php',
Partially use ApplicationSearch in main search Summary: Ref T4365. Primary search currently uses `PhabricatorSearchQuery` for storage, which is pretty much the same as `PhabricatorSavedQuery`, except that it's old and not used anywhere else anymore. Maniphest used to also use this table, but no longer does after Septmeber, 2013. We need to retain the class so the migration can work. This introduces `PhabricatorSearchApplicationSearchEngine` and `PhabricatorSearchDocumentQuery`, but they're both stubs that I just needed for technical reasons and/or to pass lint. The next couple patches will move logic into them and use ApplicationSearch properly. Test Plan: - Searched for stuff. - Searched for stuff with filters. - Searched for fulltext in Maniphest. - Grepped for `PhabricatorSearchQuery`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4365 Differential Revision: https://secure.phabricator.com/D8120
2014-02-03 21:51:08 +01:00
'PhabricatorSearchDocumentQuery' => 'applications/search/query/PhabricatorSearchDocumentQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSearchDocumentRelationship' => 'applications/search/storage/document/PhabricatorSearchDocumentRelationship.php',
Use a typeahead for "document types" in global search Summary: - Now that we have "browse", this is a much more reasonable control for random sets of things. - The new explicit search scope selector reduces the need to fiddle with this field manually, too. Test Plan: {F379292} {F379293} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D12510
2015-04-23 00:25:34 +02:00
'PhabricatorSearchDocumentTypeDatasource' => 'applications/search/typeahead/PhabricatorSearchDocumentTypeDatasource.php',
Make saved queries editable Summary: Ref T2625. Rename the "Name" controller to "Edit" and allow it to edit named queries. Also some UI touchups. Add an edit link to the saved query browse view. Test Plan: Created and edited named queries. Reviewers: btrahan, blc Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6056
2013-05-27 22:42:01 +02:00
'PhabricatorSearchEditController' => 'applications/search/controller/PhabricatorSearchEditController.php',
Implement a rough initial version of ApplicationSearch-driven Conduit read endpoints Summary: Ref T9964. See that task for some context and discussion. Ref T7715, which has the bigger picture here. Basically, I want Conduit read endpoints to be full-power, ApplicationSearch-driven endpoints, so that applications can: - Write one EditEngine and get web + conduit writes for free. - Write one SearchEngine and get web + conduit reads for free. I previously made some steps toward this, but this puts more of the structure in place. Test Plan: Viewed API console endpoint and read 20 pages of docs: {F1021961} Made various calls: with query keys, constraints, pagination, and limits. Viewed new {nav Config > Modules} page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7715, T9964 Differential Revision: https://secure.phabricator.com/D14743
2015-12-11 17:45:56 +01:00
'PhabricatorSearchEngineAPIMethod' => 'applications/search/engine/PhabricatorSearchEngineAPIMethod.php',
Implement an "Attachments" behavior for Conduit Search APIs Summary: Ref T9964. We have various kinds of secondary data on objects (like subscribers, projects, paste content, Owners paths, file attachments, etc) which is somewhat slow, or somewhat large, or both. Some approaches to handling this in the API include: - Always return all of it (very easy, but slow). - Require users to make separate API calls to get each piece of data (very simple, but inefficient and really cumbersome to use). - Implement a hierarchical query language like GraphQL (powerful, but very complex). - Kind of mix-and-match a half-power query language and some extra calls? (fairly simple, not too terrible?) We currently mix-and-match internally, with `->needStuff(true)`. This is not a general-purpose, full-power graph query language like GraphQL, and it occasionally does limit us. For example, there is no way to do this sort of thing: $conpherence_thread_query = id(new ConpherenceThreadQuery()) ->setViewer($viewer) // ... ->setNeedMessages(true) ->setWhenYouLoadTheMessagesTheyNeedProfilePictures(true); However, we almost never actually need to do this and when we do want to do it we usually don't //really// want to do it, so I don't think this is a major limit to the practical power of the system for the kinds of things we really want to do with it. Put another way, we have a lot of 1-level hierarchical queries (get pictures or repositories or projects or files or content for these objects) but few-to-no 2+ level queries (get files for these objects, then get all the projects for those files). So even though 1-level hierarchies are not a beautiful, general-purpose, fully-abstract system, they've worked well so far in practice and I'm comfortable moving forward with them in the API. If we do need N-level queries in the future, there is no technical reason we can't put GraphQL (or something similar) on top of this eventually, and this would represent a solid step toward that. However, I suspect we'll never need them. Upshot: I'm pretty happy with "->needX()" for all practical purposes, so this is just adding a way to say "->needX()" to the API. Specifically, you say: ``` { "attachments": { "subscribers": true, } } ``` ...and get back subscriber data. In the future (or for certain attachments), `true` might become a dictionary of extra parameters, if necessary, and could do so without breaking the API. Test Plan: - Ran queries to get attachments. {F1025449} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14772
2015-12-14 13:58:34 +01:00
'PhabricatorSearchEngineAttachment' => 'applications/search/engineextension/PhabricatorSearchEngineAttachment.php',
Implement a rough initial version of ApplicationSearch-driven Conduit read endpoints Summary: Ref T9964. See that task for some context and discussion. Ref T7715, which has the bigger picture here. Basically, I want Conduit read endpoints to be full-power, ApplicationSearch-driven endpoints, so that applications can: - Write one EditEngine and get web + conduit writes for free. - Write one SearchEngine and get web + conduit reads for free. I previously made some steps toward this, but this puts more of the structure in place. Test Plan: Viewed API console endpoint and read 20 pages of docs: {F1021961} Made various calls: with query keys, constraints, pagination, and limits. Viewed new {nav Config > Modules} page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7715, T9964 Differential Revision: https://secure.phabricator.com/D14743
2015-12-11 17:45:56 +01:00
'PhabricatorSearchEngineExtension' => 'applications/search/engineextension/PhabricatorSearchEngineExtension.php',
'PhabricatorSearchEngineExtensionModule' => 'applications/search/engineextension/PhabricatorSearchEngineExtensionModule.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorSearchEngineTestCase' => 'applications/search/engine/__tests__/PhabricatorSearchEngineTestCase.php',
Begin modularizing fields in SearchEngines Summary: Ref T8441. Ref T7715. Add a layer of indirection to fields in search engines. This will allow us to: - Simplify SearchEngine code, which has collected a lot of duplication around expressing what is effectively field types. - Automatically add fields like "Spaces" and "Projects" (primary driver for T8441). - Reorder or hide fields (not sure if we really want to do this, but it seems plausible, and this will let us play around with it, at least). - Drive Conduit Query methods via SearchEngines, so the same code specifies both the search UI and the `application.query` endpoint (primary driver in T7715). Test Plan: - Searched for stuff in Paste, everything behaved exaclty like it used to (except that I removed the "no language" checkbox, which seemed like fluff from a bygone era). - Searched for stuff in other applications, saw no changes. - Hit date field errors. - Used query strings to specify values. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13169
2015-06-05 20:21:08 +02:00
'PhabricatorSearchField' => 'applications/search/field/PhabricatorSearchField.php',
Added basic hovercard controller Summary: Refs T1048; Depends on D5542, D5543, D5544 - It currently just renders multiple hovercards nicely for test purposes. More is on the way. Mode `test`: Human test chamber. Mode `retrieve`: For JS. Added so it would not clash with search key routing. badassery Test Plan: `/search/hovercard/test/?phids[hover-T4]=PHID-TASK-g5pduvwrrwvkq5gkx736&phids[hover-T2]=PHID-TASK-gta6lzaaagziavkktima` Verified the appearance of two tasks with correct rendering and correct ids Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1048 Differential Revision: https://secure.phabricator.com/D5545
2013-04-03 17:31:27 +02:00
'PhabricatorSearchHovercardController' => 'applications/search/controller/PhabricatorSearchHovercardController.php',
Allow index extensions to skip indexing if the object has not changed Summary: Fixes T9890. This allows IndexExtensions to emit an object version. Before we build indexes, we check if the indexed version is the same as the current version. If it is, we just don't call that extension. T9890 has a case where this is useful: a script went crazy and posted thousands of comments to a single task. Without versioning, that results in the same comments being indexed over and over again. With versioning, most of the queue could just exit without doing any work. Test Plan: - Added a `sleep(1)` to the actual indexing, used `bin/search index --background` to queue up a lot of tasks, ran them with `bin/phd debug task`, saw them complete very quickly with only one actual index operation performed. - Used `bin/search index --trace` and `bin/search index --trace --background` to observe the behavior of queries against the index version store, which looked sensible. - Made comments/transactions, saw versions update. - Used `bin/remove destroy`, verified index versions were purged. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9890 Differential Revision: https://secure.phabricator.com/D14845
2015-12-21 20:04:08 +01:00
'PhabricatorSearchIndexVersion' => 'applications/search/storage/PhabricatorSearchIndexVersion.php',
'PhabricatorSearchIndexVersionDestructionEngineExtension' => 'applications/search/engineextension/PhabricatorSearchIndexVersionDestructionEngineExtension.php',
Improve Search architecture Summary: The search indexing API has several problems right now: - Always runs in-process. - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it. - Being able to use the task queue will also make rebuilding indexes faster. - Instead, make the API phid-oriented. - No uniform indexing API. - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird. - Instead, provide a uniform API. - No uniform CLI. - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers. - Instead, let indexers expose documents for indexing. - Not application-oriented. - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world. - Instead, move indexers to applications and load them with SymbolLoader. Test Plan: - `bin/search index` - Indexed one revision, one task. - Indexed `--type TASK`, `--type DREV`, etc., for all types. - Indexed `--all`. - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it. - Creating users is a pain; searched for a user after indexing. - Creating commits is a pain; searched for a commit after indexing. - Mocks aren't currently loadable in the result view, so their indexing is moot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: 20after4, aran Maniphest Tasks: T1991, T2104 Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
'PhabricatorSearchManagementIndexWorkflow' => 'applications/search/management/PhabricatorSearchManagementIndexWorkflow.php',
Properly create Elasticsearch index Summary: When the index does not exist and auto_create_index isn't enabled, running ./bin/index results in a failure. That's T5990 Instead create an index properly. This also allows us to do nice things like do a proper mapping and analysis like for substring matching like outlined by @fabe in T6552. Test Plan: Deleted and created index multiple times to verify proper index creation and usage. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, manybubbles, chasemp, fabe, epriestley Differential Revision: https://secure.phabricator.com/D10955
2014-12-22 22:10:52 +01:00
'PhabricatorSearchManagementInitWorkflow' => 'applications/search/management/PhabricatorSearchManagementInitWorkflow.php',
Improve Search architecture Summary: The search indexing API has several problems right now: - Always runs in-process. - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it. - Being able to use the task queue will also make rebuilding indexes faster. - Instead, make the API phid-oriented. - No uniform indexing API. - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird. - Instead, provide a uniform API. - No uniform CLI. - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers. - Instead, let indexers expose documents for indexing. - Not application-oriented. - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world. - Instead, move indexers to applications and load them with SymbolLoader. Test Plan: - `bin/search index` - Indexed one revision, one task. - Indexed `--type TASK`, `--type DREV`, etc., for all types. - Indexed `--all`. - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it. - Creating users is a pain; searched for a user after indexing. - Creating commits is a pain; searched for a commit after indexing. - Mocks aren't currently loadable in the result view, so their indexing is moot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: 20after4, aran Maniphest Tasks: T1991, T2104 Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
'PhabricatorSearchManagementWorkflow' => 'applications/search/management/PhabricatorSearchManagementWorkflow.php',
Implement basic ngram search for Owners Package names Summary: Ref T9979. This uses ngrams (specifically, trigrams) to build a reasonably efficient index for substring matching. Specifically, for a package like "Example", with ID 123, we store rows like this: ``` < ex, 123> <exa, 123> <xam, 123> <amp, 123> <mpl, 123> <ple, 123> <le , 123> ``` When the user searches for `exam`, we join this table for packages with tokens `exa` and `xam`. MySQL can do this a lot more efficiently than it can process a `LIKE "%exam%"` query against a huge table. When the user searches for a one-letter or two-letter string, we only search the beginnings of words. This is probably what they want, the only thing we can do quickly, and a reasonable/expected behavior for typeaheads. Test Plan: - Ran storage upgrades and search indexer. - Searched for stuff with "name contains". - Used typehaead and got sensible results. - Searched for `aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz` and saw only 16 joins. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14846
2015-12-21 21:22:07 +01:00
'PhabricatorSearchNgrams' => 'applications/search/ngrams/PhabricatorSearchNgrams.php',
'PhabricatorSearchNgramsDestructionEngineExtension' => 'applications/search/engineextension/PhabricatorSearchNgramsDestructionEngineExtension.php',
Allow named queries to be reordered by dragging Summary: Also you have to drop them. So drag, and then drop. This needs some cleanup and reconciliation/generalization with the Maniphest implementation. In particular, you can't drag things to the very top right now, and they should share more CSS and more behaviors. Test Plan: Look I alphabetized them: {F45286} Reviewers: chad Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6136
2013-06-06 01:22:27 +02:00
'PhabricatorSearchOrderController' => 'applications/search/controller/PhabricatorSearchOrderController.php',
Support ordering in SearchField Summary: Ref T8441. Ref T7715. Automatically generate a modern "Order" control in ApplicationSearch for engines which fully support SearchField. Notably, this allows the standard "Order" control to automatically support custom field orders. We do this in Maniphest today, but in an ad-hoc way. Test Plan: Performed order-by queries in Almanac (Services), Pholio, Files, People, Projects, and Paste. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13193
2015-06-08 21:21:48 +02:00
'PhabricatorSearchOrderField' => 'applications/search/field/PhabricatorSearchOrderField.php',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorSearchPreferencesSettingsPanel' => 'applications/settings/panel/PhabricatorSearchPreferencesSettingsPanel.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSearchRelationship' => 'applications/search/constants/PhabricatorSearchRelationship.php',
'PhabricatorSearchResultView' => 'applications/search/view/PhabricatorSearchResultView.php',
Add an edge table to the `search` database Summary: Fixes T10778. This is a result of T10262: when we save a form configuration and adjust the policy, we try to scramble attached file secrets. There aren't going to be any attached files, but there's also no edge table, so we fail. We could skip this code, but we'll likely need an edge table here sooner or later so it's probably simpler in the long run to just add an empty one. Test Plan: - Ran `bin/storage upgrade`, got a clean bill of health. - Saved a form configuration after making a policy edit, no more `edge` exception. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10778 Differential Revision: https://secure.phabricator.com/D15803
2016-04-26 20:19:03 +02:00
'PhabricatorSearchSchemaSpec' => 'applications/search/storage/PhabricatorSearchSchemaSpec.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSearchSelectController' => 'applications/search/controller/PhabricatorSearchSelectController.php',
Move Projects to SearchFields Summary: Ref T8441. Ref T7715. This is mostly about getting SearchFields + CustomFields working. (This includes a couple of SearchFields which aren't used quite yet.) Test Plan: - Used all search controls. - Defined custom fields and searched for them. - Created an old saved search which searches on custom fields on master, switched to this patch, search worked exaclty as written. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13189
2015-06-08 21:20:16 +02:00
'PhabricatorSearchSelectField' => 'applications/search/field/PhabricatorSearchSelectField.php',
Begin modularizing fields in SearchEngines Summary: Ref T8441. Ref T7715. Add a layer of indirection to fields in search engines. This will allow us to: - Simplify SearchEngine code, which has collected a lot of duplication around expressing what is effectively field types. - Automatically add fields like "Spaces" and "Projects" (primary driver for T8441). - Reorder or hide fields (not sure if we really want to do this, but it seems plausible, and this will let us play around with it, at least). - Drive Conduit Query methods via SearchEngines, so the same code specifies both the search UI and the `application.query` endpoint (primary driver in T7715). Test Plan: - Searched for stuff in Paste, everything behaved exaclty like it used to (except that I removed the "no language" checkbox, which seemed like fluff from a bygone era). - Searched for stuff in other applications, saw no changes. - Hit date field errors. - Used query strings to specify values. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13169
2015-06-05 20:21:08 +02:00
'PhabricatorSearchStringListField' => 'applications/search/field/PhabricatorSearchStringListField.php',
Make Subscribers automatically provide working SearchFields Summary: Ref T8441. Ref T7715. For modern Query classes, automatically make subscriber queries and SearchField integrations work. In particular, we can just drive this query with EdgeLogic and don't need to do anything specific on these Query classes beyond making sure they're implemented in a way that picks up all of the EdgeLogic clauses. Test Plan: - Searched for subscribers in Pholio, Files, Paste, and Projects. - Searched for all other fields in Projects to check that Query changes are OK. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13191
2015-06-08 21:20:53 +02:00
'PhabricatorSearchSubscribersField' => 'applications/search/field/PhabricatorSearchSubscribersField.php',
Move Projects to SearchFields Summary: Ref T8441. Ref T7715. This is mostly about getting SearchFields + CustomFields working. (This includes a couple of SearchFields which aren't used quite yet.) Test Plan: - Used all search controls. - Defined custom fields and searched for them. - Created an old saved search which searches on custom fields on master, switched to this patch, search worked exaclty as written. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13189
2015-06-08 21:20:16 +02:00
'PhabricatorSearchTextField' => 'applications/search/field/PhabricatorSearchTextField.php',
Convert Files to SearchFields Summary: Ref T8441. Ref T7715. - Update FileSearchEngine. - Nothing too special/fancy. Test Plan: - Searched for various files. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13175
2015-06-07 16:32:09 +02:00
'PhabricatorSearchThreeStateField' => 'applications/search/field/PhabricatorSearchThreeStateField.php',
Begin modularizing fields in SearchEngines Summary: Ref T8441. Ref T7715. Add a layer of indirection to fields in search engines. This will allow us to: - Simplify SearchEngine code, which has collected a lot of duplication around expressing what is effectively field types. - Automatically add fields like "Spaces" and "Projects" (primary driver for T8441). - Reorder or hide fields (not sure if we really want to do this, but it seems plausible, and this will let us play around with it, at least). - Drive Conduit Query methods via SearchEngines, so the same code specifies both the search UI and the `application.query` endpoint (primary driver in T7715). Test Plan: - Searched for stuff in Paste, everything behaved exaclty like it used to (except that I removed the "no language" checkbox, which seemed like fluff from a bygone era). - Searched for stuff in other applications, saw no changes. - Hit date field errors. - Used query strings to specify values. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13169
2015-06-05 20:21:08 +02:00
'PhabricatorSearchTokenizerField' => 'applications/search/field/PhabricatorSearchTokenizerField.php',
Perform search indexing in the worker queue and respect `bin/search index --background` Summary: Fixes T3857. Earlier work made this trivial and just left product questions, which I've answered by requiring the daemons to run on reasonable installs. Test Plan: Ran `bin/search index` and `bin/search index --background`. Observed indexes write in the former case and tasks queue in the latter case. Commented with a unique string on a revision and searched for it a moment later, got exactly one result (that revision), verifying that reindexing works correctly. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3857 Differential Revision: https://secure.phabricator.com/D7966
2014-01-14 22:22:56 +01:00
'PhabricatorSearchWorker' => 'applications/search/worker/PhabricatorSearchWorker.php',
Add the "Security" config group options. Summary: Added all the "Security" group options listed in T2255. Test Plan: - Looked at all the options. - Tested validation on `security.alternate-file-domain` Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4334
2013-01-03 14:45:23 +01:00
'PhabricatorSecurityConfigOptions' => 'applications/config/option/PhabricatorSecurityConfigOptions.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorSecuritySetupCheck' => 'applications/config/check/PhabricatorSecuritySetupCheck.php',
Implement a basic version of ApplicationEditor in Paste Summary: Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste. This mostly looks and works like ApplicationSearch, and is heavily modeled on it. Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else. This has no functional changes, except: - I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it. - Subscribers are now editable. - Form field order is a little goofy (this will be fixed in a future diff). - Subscribers and projects are now race-resistant. The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits. Test Plan: - Created pastes. - Created pastes via API. - Edited pastes. - Edited every field. - Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4768, T9132 Differential Revision: https://secure.phabricator.com/D14390
2015-11-03 03:58:32 +01:00
'PhabricatorSelectEditField' => 'applications/transactions/editfield/PhabricatorSelectEditField.php',
Bring SendGrid configuration into PHP Summary: Port more settings. Test Plan: Looked at, edited settings. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4442
2013-01-15 21:04:05 +01:00
'PhabricatorSendGridConfigOptions' => 'applications/config/option/PhabricatorSendGridConfigOptions.php',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorSessionsSettingsPanel' => 'applications/settings/panel/PhabricatorSessionsSettingsPanel.php',
Add semi-generic rate limiting infrastructure Summary: This adds a system which basically keeps a record of recent actions, who took them, and how many "points" they were worth, like: epriestley email.add 1 1233989813 epriestley email.add 1 1234298239 epriestley email.add 1 1238293981 We can use this to rate-limit actions by examining how many actions the user has taken in the past hour (i.e., their total score) and comparing that to an allowed limit. One major thing I want to use this for is to limit the amount of error email we'll send to an email address. A big concern I have with sending more error email is that we'll end up in loops. We have some protections against this in headers already, but hard-limiting the system so it won't send more than a few errors to a particular address per hour should provide a reasonable secondary layer of protection. This use case (where the "actor" needs to be an email address) is why the table uses strings + hashes instead of PHIDs. For external users, it might be appropriate to rate limit by cookies or IPs, too. To prove it works, I rate limited adding email addresses. This is a very, very low-risk security thing where a user with an account can enumerate addresses (by checking if they get an error) and sort of spam/annoy people (by adding their address over and over again). Limiting them to 6 actions / hour should satisfy all real users while preventing these behaviors. Test Plan: This dialog is uggos but I'll fix that in a sec: {F137406} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8683
2014-04-03 20:22:38 +02:00
'PhabricatorSettingsAddEmailAction' => 'applications/settings/action/PhabricatorSettingsAddEmailAction.php',
Move Settings to a separate directory Summary: We currently have two relatively distinct applications, "People" and "Settings", living in /people/. Move settings to its own directory. This renames a couple of classes but makes no real code changes. Test Plan: Browsed /settings/, changed some settings. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569, T631 Differential Revision: https://secure.phabricator.com/D3256
2012-08-13 21:37:18 +02:00
'PhabricatorSettingsAdjustController' => 'applications/settings/controller/PhabricatorSettingsAdjustController.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorSettingsApplication' => 'applications/settings/application/PhabricatorSettingsApplication.php',
Move Settings to a separate directory Summary: We currently have two relatively distinct applications, "People" and "Settings", living in /people/. Move settings to its own directory. This renames a couple of classes but makes no real code changes. Test Plan: Browsed /settings/, changed some settings. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569, T631 Differential Revision: https://secure.phabricator.com/D3256
2012-08-13 21:37:18 +02:00
'PhabricatorSettingsMainController' => 'applications/settings/controller/PhabricatorSettingsMainController.php',
Begin modularizing main menu items Summary: Ref T10077. Ref T8918. The way the main menu is built is not very modular and fairly hacky. It assumes menus are provided by applications, but this isn't exactly true. Notably, the "Quick Create" menu is not per-application. The current method of building this menu is very inefficient (see T10077). Particularly, we have to build it //twice// because we need to build it once to render the item and then again to render the dropdown options. Start cleaning this up. This diff doesn't actually have any behavioral changes, since I can't swap the menu over until we get rid of all the other items and I haven't extended this to Notifications/Conpherence yet so it doesn't actually fix T8918. Test Plan: Viewed menus while logged in, logged out, in different applications, in desktop/mobile. Nothing appeared different. Reviewers: chad Reviewed By: chad Maniphest Tasks: T8918, T10077 Differential Revision: https://secure.phabricator.com/D14922
2016-01-01 13:26:36 +01:00
'PhabricatorSettingsMainMenuBarExtension' => 'applications/settings/extension/PhabricatorSettingsMainMenuBarExtension.php',
Make settings panels more modular and modern Summary: Currently, we have a hard-coded list of settings panels. Make them a bit more modular. - Allow new settings panels to be defined by third-party code (see {D2340}, for example -- @ptarjan). - This makes the OAuth stuff more flexible for {T887} / {T1536}. - Reduce the number of hard-coded URIs in various places. Test Plan: Viewed / edited every option in every panel. Grepped for all references to these URIs. Reviewers: btrahan, vrana, ptarjan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3257
2012-08-13 21:37:26 +02:00
'PhabricatorSettingsPanel' => 'applications/settings/panel/PhabricatorSettingsPanel.php',
Detect and raise setup warnings from within Phabricator Summary: This is basicaly a light version of D4286. The major problem with D4286 is that it's a huge leap and completely replaces the setup process in one step. Instead, I want to do this: - Add the post-setup warnings (yellow bar with "6 unresolved warnings..."). - Copy all setup checks into post-setup warnings (so every check has an old-style check and a new-style check). - Run that for a little bit and make sure it's stable. - Implement fatal post-setup checks (the red screen, vs the yellow bar). - Run that for a little bit. - Nuke setup mode and delete all the old checks. This should give us a bunch of very gradual steps toward the brave new world of simpler setup. Test Plan: - Faked APC setup failures, saw warnings raise. - Verified that this runs after restart (get + set). - Verified that this costs us only one cache hit after first-run (get only). Reviewers: btrahan, codeblock, vrana, chad Reviewed By: codeblock CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4295
2012-12-30 15:37:49 +01:00
'PhabricatorSetupCheck' => 'applications/config/check/PhabricatorSetupCheck.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorSetupCheckTestCase' => 'applications/config/check/__tests__/PhabricatorSetupCheckTestCase.php',
Detect and raise setup warnings from within Phabricator Summary: This is basicaly a light version of D4286. The major problem with D4286 is that it's a huge leap and completely replaces the setup process in one step. Instead, I want to do this: - Add the post-setup warnings (yellow bar with "6 unresolved warnings..."). - Copy all setup checks into post-setup warnings (so every check has an old-style check and a new-style check). - Run that for a little bit and make sure it's stable. - Implement fatal post-setup checks (the red screen, vs the yellow bar). - Run that for a little bit. - Nuke setup mode and delete all the old checks. This should give us a bunch of very gradual steps toward the brave new world of simpler setup. Test Plan: - Faked APC setup failures, saw warnings raise. - Verified that this runs after restart (get + set). - Verified that this costs us only one cache hit after first-run (get only). Reviewers: btrahan, codeblock, vrana, chad Reviewed By: codeblock CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4295
2012-12-30 15:37:49 +01:00
'PhabricatorSetupIssue' => 'applications/config/issue/PhabricatorSetupIssue.php',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorSetupIssueUIExample' => 'applications/uiexample/examples/PhabricatorSetupIssueUIExample.php',
Detect and raise setup warnings from within Phabricator Summary: This is basicaly a light version of D4286. The major problem with D4286 is that it's a huge leap and completely replaces the setup process in one step. Instead, I want to do this: - Add the post-setup warnings (yellow bar with "6 unresolved warnings..."). - Copy all setup checks into post-setup warnings (so every check has an old-style check and a new-style check). - Run that for a little bit and make sure it's stable. - Implement fatal post-setup checks (the red screen, vs the yellow bar). - Run that for a little bit. - Nuke setup mode and delete all the old checks. This should give us a bunch of very gradual steps toward the brave new world of simpler setup. Test Plan: - Faked APC setup failures, saw warnings raise. - Verified that this runs after restart (get + set). - Verified that this costs us only one cache hit after first-run (get only). Reviewers: btrahan, codeblock, vrana, chad Reviewed By: codeblock CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4295
2012-12-30 15:37:49 +01:00
'PhabricatorSetupIssueView' => 'applications/config/view/PhabricatorSetupIssueView.php',
Allow a domain other than the install domain to serve as a short Phurl domain Summary: Ref T8995, config option for Phurl short domain to share shortened URL's Test Plan: - Configure Phurl short domain to something like "zz.us" - Navigate to `zz.us`; get 404 - Navigate to `zz.us/u/3` or `zz.us/u/alias` where `U3` is an existing Phurl; redirect to correct destination Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Maniphest Tasks: T8995 Differential Revision: https://secure.phabricator.com/D14447
2015-11-09 19:09:19 +01:00
'PhabricatorShortSite' => 'aphront/site/PhabricatorShortSite.php',
Roughly generate transaction-oriented API methods from EditEngines Summary: Ref T5873. Ref T9132. This is really rough and feels pretty flimsy at the edges (missing validation, generality, modularity, clean error handling, etc) but gets us most of the way toward generating plausible "whatever.edit" Conduit API methods from EditEngines. These methods are full-power methods which can do everything the edit form can, automatically support the same range of operations, and update when new fields are added. Test Plan: - Used new `paste.edit` to create a new Paste. - Used new `paste.edit` to update an existing paste. - Applied a variety of different transactions. - Hit a reasonable set of errors. {F941144} {F941145} {F941146} {F941147} Reviewers: chad Reviewed By: chad Maniphest Tasks: T5873, T9132 Differential Revision: https://secure.phabricator.com/D14393
2015-11-03 17:45:00 +01:00
'PhabricatorSimpleEditType' => 'applications/transactions/edittype/PhabricatorSimpleEditType.php',
Modularize Aphront "sites" Summary: Fixes T5702. The path here is long and windy: - I want to move `blog.phacility.com` to the new `secure` host. - That host has `security.require-https` set, which I want to keep set (before, this was handled in a sort of hacky way at the nginx/preamble level, but I've cleaned up everything else now). - Currently, that setting forces blogs to HTTPS too, which won't work. - To let blogs be individually configurable, we need to either modularize site config or make things hackier. - Modularize rather than increasing hackiness. - Also add a little "modules" panel in Config. See T6859. This feels like a reasonable middle ground between putting this stuff in Applications and burying it in `bin/somewhere`. Test Plan: - Visited normal site. - Visited phame on-domain site. - Visited phame off-domain site. - Viewed static resources. {F561897} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D13474
2015-06-29 23:04:48 +02:00
'PhabricatorSite' => 'aphront/site/PhabricatorSite.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorSlowvoteApplication' => 'applications/slowvote/application/PhabricatorSlowvoteApplication.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSlowvoteChoice' => 'applications/slowvote/storage/PhabricatorSlowvoteChoice.php',
Ability to close poll Summary: Fixes T3566 List of poll actions should include ability to close an open poll or reopen a closed poll. Test Plan: Poll author should be able to close/reopen poll. Non-author should get policy screen when attempting to close/reopen poll. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T3566 Differential Revision: https://secure.phabricator.com/D8846
2014-04-24 21:00:31 +02:00
'PhabricatorSlowvoteCloseController' => 'applications/slowvote/controller/PhabricatorSlowvoteCloseController.php',
Restore Slowvote commenting with ApplicationTransactions Summary: Now it works like everything else does. Test Plan: {F50168} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6455
2013-07-15 13:45:43 +02:00
'PhabricatorSlowvoteCommentController' => 'applications/slowvote/controller/PhabricatorSlowvoteCommentController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSlowvoteController' => 'applications/slowvote/controller/PhabricatorSlowvoteController.php',
'PhabricatorSlowvoteDAO' => 'applications/slowvote/storage/PhabricatorSlowvoteDAO.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'PhabricatorSlowvoteDefaultViewCapability' => 'applications/slowvote/capability/PhabricatorSlowvoteDefaultViewCapability.php',
Make most slowvote fields edit transactionally Summary: No support for responses yet, since they're more complicated, but put everything else on the transactions plan. This also prepares polls for editability, shortly. Test Plan: {F50205} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6460
2013-07-15 19:50:38 +02:00
'PhabricatorSlowvoteEditController' => 'applications/slowvote/controller/PhabricatorSlowvoteEditController.php',
Restore Slowvote commenting with ApplicationTransactions Summary: Now it works like everything else does. Test Plan: {F50168} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6455
2013-07-15 13:45:43 +02:00
'PhabricatorSlowvoteEditor' => 'applications/slowvote/editor/PhabricatorSlowvoteEditor.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSlowvoteListController' => 'applications/slowvote/controller/PhabricatorSlowvoteListController.php',
Add mail/feed to Slowvote Summary: Adds mailkeys, basic structure for publishing to feed, sending mail. Test Plan: New Poll, vote, comment, etc. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13749
2015-08-02 00:41:08 +02:00
'PhabricatorSlowvoteMailReceiver' => 'applications/slowvote/mail/PhabricatorSlowvoteMailReceiver.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSlowvoteOption' => 'applications/slowvote/storage/PhabricatorSlowvoteOption.php',
'PhabricatorSlowvotePoll' => 'applications/slowvote/storage/PhabricatorSlowvotePoll.php',
'PhabricatorSlowvotePollController' => 'applications/slowvote/controller/PhabricatorSlowvotePollController.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorSlowvotePollPHIDType' => 'applications/slowvote/phid/PhabricatorSlowvotePollPHIDType.php',
Add PhabricatorSlowvoteQuery Summary: Ref T603. Ref T2625. Start pushing Slowvote (the greatest app of all time) into the modern era. Test Plan: Looked at vote detail. Used `V1` and `{V1}` embeds. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6444
2013-07-13 19:41:30 +02:00
'PhabricatorSlowvoteQuery' => 'applications/slowvote/query/PhabricatorSlowvoteQuery.php',
Add mail/feed to Slowvote Summary: Adds mailkeys, basic structure for publishing to feed, sending mail. Test Plan: New Poll, vote, comment, etc. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13749
2015-08-02 00:41:08 +02:00
'PhabricatorSlowvoteReplyHandler' => 'applications/slowvote/mail/PhabricatorSlowvoteReplyHandler.php',
Generate expected schemata for Workers, XHProf, PHPAAST, Tokens, System, Slowvote Summary: T1191. Nothing very notable here. Test Plan: Saw more blue in web UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D10522
2014-09-19 14:45:24 +02:00
'PhabricatorSlowvoteSchemaSpec' => 'applications/slowvote/storage/PhabricatorSlowvoteSchemaSpec.php',
Use ApplicationSearch in Slowvote Summary: Ref T2625. Ref T603. Make the vote list policy-aware, mobile-friendly, and use ApplicationSearch. Test Plan: {F50022} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6445
2013-07-13 19:41:49 +02:00
'PhabricatorSlowvoteSearchEngine' => 'applications/slowvote/query/PhabricatorSlowvoteSearchEngine.php',
Migrate Slowvote comments to ApplicationTransactions Summary: Move comments from the old table to ApplicationTransactions. Patch dances around which objects it uses since I intend to delete the comment table. NOTE: This temporarily disables comment writes. I'll restore them shortly. Test Plan: {F50166} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6454
2013-07-15 13:20:10 +02:00
'PhabricatorSlowvoteTransaction' => 'applications/slowvote/storage/PhabricatorSlowvoteTransaction.php',
'PhabricatorSlowvoteTransactionComment' => 'applications/slowvote/storage/PhabricatorSlowvoteTransactionComment.php',
'PhabricatorSlowvoteTransactionQuery' => 'applications/slowvote/query/PhabricatorSlowvoteTransactionQuery.php',
Embed slowvotes have basic interaction Summary: User can now vote through embed slowvote Test Plan: Voted'n stuff Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad, AnhNhan Maniphest Tasks: T2883 Differential Revision: https://secure.phabricator.com/D5743
2013-05-04 00:48:59 +02:00
'PhabricatorSlowvoteVoteController' => 'applications/slowvote/controller/PhabricatorSlowvoteVoteController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSlug' => 'infrastructure/util/PhabricatorSlug.php',
'PhabricatorSlugTestCase' => 'infrastructure/util/__tests__/PhabricatorSlugTestCase.php',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorSortTableUIExample' => 'applications/uiexample/examples/PhabricatorSortTableUIExample.php',
Modernize Paste Summary: - Add a PhabricatorApplication. - Make most of the views work well on tablets / phones. The actual "Create" form doesn't, but everything else is good -- need to make device-friendly form layouts before I can do the form. Test Plan: Will attach screenshots. Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3293
2012-08-15 19:45:06 +02:00
'PhabricatorSourceCodeView' => 'view/layout/PhabricatorSourceCodeView.php',
Implement a basic version of ApplicationEditor in Paste Summary: Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste. This mostly looks and works like ApplicationSearch, and is heavily modeled on it. Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else. This has no functional changes, except: - I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it. - Subscribers are now editable. - Form field order is a little goofy (this will be fixed in a future diff). - Subscribers and projects are now race-resistant. The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits. Test Plan: - Created pastes. - Created pastes via API. - Edited pastes. - Edited every field. - Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4768, T9132 Differential Revision: https://secure.phabricator.com/D14390
2015-11-03 03:58:32 +01:00
'PhabricatorSpaceEditField' => 'applications/transactions/editfield/PhabricatorSpaceEditField.php',
Spaces - re-jigger application name for new Spaces application Summary: got some errors in my sandbox when I updated. this fixes them and I think is the right naming convention. Test Plan: /settings/panel/emailpreferences/ started working again! /spaces/ also loaded unit tests passed without errors Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T8377 Differential Revision: https://secure.phabricator.com/D13103
2015-06-01 23:54:18 +02:00
'PhabricatorSpacesApplication' => 'applications/spaces/application/PhabricatorSpacesApplication.php',
Allow Spaces to be archived Summary: Ref T8377. This adds a standard disable/enable feature to Spaces, with a couple of twists: - You can't create new stuff in an archived space, and you can't move stuff into an archived space. - We don't show results from an archived space by default in ApplicationSearch queries. You can still find these objects if you explicitly search for "Spaces: <the archived space>". So this is a "put it in a box in the attic" sort of operation, but that seems fairly nice/reasonable. Test Plan: - Archived and activated spaces. - Used ApplicationSearch, which omitted archived objects by default but allowed searches for them, specifically, to succeed. - Tried to create objects into an archived space (this is not allowed). - Edited objects in an archived space (this is OK). Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8377 Differential Revision: https://secure.phabricator.com/D13238
2015-06-11 19:13:47 +02:00
'PhabricatorSpacesArchiveController' => 'applications/spaces/controller/PhabricatorSpacesArchiveController.php',
Add "Spaces", an application for managing policy namespaces Summary: Ref T3820. This doesn't actually do anything yet, but dumps in all the plumbing. Test Plan: {F156989} {F156990} {F156991} Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, wienczny, jdloft, devurandom, thz, hwinkel, 20after4, sascha-egerer, seporaitis, joshuaspence, chad, epriestley Maniphest Tasks: T3820 Differential Revision: https://secure.phabricator.com/D9204
2015-06-01 20:28:38 +02:00
'PhabricatorSpacesCapabilityCreateSpaces' => 'applications/spaces/capability/PhabricatorSpacesCapabilityCreateSpaces.php',
'PhabricatorSpacesCapabilityDefaultEdit' => 'applications/spaces/capability/PhabricatorSpacesCapabilityDefaultEdit.php',
'PhabricatorSpacesCapabilityDefaultView' => 'applications/spaces/capability/PhabricatorSpacesCapabilityDefaultView.php',
'PhabricatorSpacesController' => 'applications/spaces/controller/PhabricatorSpacesController.php',
'PhabricatorSpacesDAO' => 'applications/spaces/storage/PhabricatorSpacesDAO.php',
'PhabricatorSpacesEditController' => 'applications/spaces/controller/PhabricatorSpacesEditController.php',
'PhabricatorSpacesInterface' => 'applications/spaces/interface/PhabricatorSpacesInterface.php',
'PhabricatorSpacesListController' => 'applications/spaces/controller/PhabricatorSpacesListController.php',
'PhabricatorSpacesNamespace' => 'applications/spaces/storage/PhabricatorSpacesNamespace.php',
Support PhabricatorSpacesInterface in ApplicationSearch UI Summary: Ref T8441. Does what it says, provided other conditions (like using the new SearchField stuff) are fulfilled. Test Plan: {F473836} {F473837} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8441 Differential Revision: https://secure.phabricator.com/D13171
2015-06-05 20:21:45 +02:00
'PhabricatorSpacesNamespaceDatasource' => 'applications/spaces/typeahead/PhabricatorSpacesNamespaceDatasource.php',
Add "Spaces", an application for managing policy namespaces Summary: Ref T3820. This doesn't actually do anything yet, but dumps in all the plumbing. Test Plan: {F156989} {F156990} {F156991} Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, wienczny, jdloft, devurandom, thz, hwinkel, 20after4, sascha-egerer, seporaitis, joshuaspence, chad, epriestley Maniphest Tasks: T3820 Differential Revision: https://secure.phabricator.com/D9204
2015-06-01 20:28:38 +02:00
'PhabricatorSpacesNamespaceEditor' => 'applications/spaces/editor/PhabricatorSpacesNamespaceEditor.php',
'PhabricatorSpacesNamespacePHIDType' => 'applications/spaces/phid/PhabricatorSpacesNamespacePHIDType.php',
'PhabricatorSpacesNamespaceQuery' => 'applications/spaces/query/PhabricatorSpacesNamespaceQuery.php',
'PhabricatorSpacesNamespaceSearchEngine' => 'applications/spaces/query/PhabricatorSpacesNamespaceSearchEngine.php',
'PhabricatorSpacesNamespaceTransaction' => 'applications/spaces/storage/PhabricatorSpacesNamespaceTransaction.php',
'PhabricatorSpacesNamespaceTransactionQuery' => 'applications/spaces/query/PhabricatorSpacesNamespaceTransactionQuery.php',
When an install has spaces but a user has no access, roadblock them Summary: Ref T8449. If a user doesn't have access to any spaces, most applications just don't work, and they fail in confusing ways. Just lock users out of everything explicitly up front with a clear message instead of letting them stumble into a big broken mess. Test Plan: Locked a user out of all spaces, saw error to that effect. Reviewers: btrahan, eadler Reviewed By: eadler Subscribers: eadler, epriestley Maniphest Tasks: T8449 Differential Revision: https://secure.phabricator.com/D13545
2015-07-03 22:03:33 +02:00
'PhabricatorSpacesNoAccessController' => 'applications/spaces/controller/PhabricatorSpacesNoAccessController.php',
Add a Spaces remarkup rule Summary: Ref T8449. Test Plan: {F474032} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8449 Differential Revision: https://secure.phabricator.com/D13172
2015-06-05 23:19:40 +02:00
'PhabricatorSpacesRemarkupRule' => 'applications/spaces/remarkup/PhabricatorSpacesRemarkupRule.php',
Add a "Description" field to Spaces Summary: Ref T8377. - Add a description field. - Add edges so files can be attached. Test Plan: {F492410} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8377 Differential Revision: https://secure.phabricator.com/D13235
2015-06-11 00:53:51 +02:00
'PhabricatorSpacesSchemaSpec' => 'applications/spaces/storage/PhabricatorSpacesSchemaSpec.php',
Implement a rough initial version of ApplicationSearch-driven Conduit read endpoints Summary: Ref T9964. See that task for some context and discussion. Ref T7715, which has the bigger picture here. Basically, I want Conduit read endpoints to be full-power, ApplicationSearch-driven endpoints, so that applications can: - Write one EditEngine and get web + conduit writes for free. - Write one SearchEngine and get web + conduit reads for free. I previously made some steps toward this, but this puts more of the structure in place. Test Plan: Viewed API console endpoint and read 20 pages of docs: {F1021961} Made various calls: with query keys, constraints, pagination, and limits. Viewed new {nav Config > Modules} page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7715, T9964 Differential Revision: https://secure.phabricator.com/D14743
2015-12-11 17:45:56 +01:00
'PhabricatorSpacesSearchEngineExtension' => 'applications/spaces/engineextension/PhabricatorSpacesSearchEngineExtension.php',
Move some PhabricatorSearchField subclasses Summary: Move some `PhabricatorSearchField` subclasses to be adjacent to the application to which they belong. This seems generally better to me than lumping them all together in the `src/applications/search/field/` directory. I was also wondering if it makes sense to rename these subclasses as `PhabricatorXSearchField` rather than `PhabricatorSearchXField` (as per T5655), but wasn't really sure if these objects are meant to be search-fields, or just fields belonging to the #search application. Test Plan: N/A. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13374
2015-07-06 14:52:04 +02:00
'PhabricatorSpacesSearchField' => 'applications/spaces/searchfield/PhabricatorSpacesSearchField.php',
Implement DestructibleInterface on Spaces, add some basic tests Summary: Ref T8377. Mostly just a framework for test coverage. Test Plan: Tests pass. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8377 Differential Revision: https://secure.phabricator.com/D13102
2015-06-01 21:02:20 +02:00
'PhabricatorSpacesTestCase' => 'applications/spaces/__tests__/PhabricatorSpacesTestCase.php',
Add "Spaces", an application for managing policy namespaces Summary: Ref T3820. This doesn't actually do anything yet, but dumps in all the plumbing. Test Plan: {F156989} {F156990} {F156991} Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, wienczny, jdloft, devurandom, thz, hwinkel, 20after4, sascha-egerer, seporaitis, joshuaspence, chad, epriestley Maniphest Tasks: T3820 Differential Revision: https://secure.phabricator.com/D9204
2015-06-01 20:28:38 +02:00
'PhabricatorSpacesViewController' => 'applications/spaces/controller/PhabricatorSpacesViewController.php',
Use classes to define standard field types and implement an "int" type Summary: Currently, `ManiphestAuxiliaryFieldDefaultSpecification` uses about a dozen giant `switch` statements to implement stadard field types (int, string, date, bool, select, user, remarkup, etc). This is: - pretty gross; - not extensible; and - doesn't really let us share that much code. I got about halfway through porting a similar implementation into StandardField but I wasn't thrilled with it. Subclass StandardField instead to implement custom field types. Test Plan: Added an "int" custom field, verified it had integer semantics and indexed into the integer index. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7005
2013-09-17 01:03:24 +02:00
'PhabricatorStandardCustomField' => 'infrastructure/customfield/standard/PhabricatorStandardCustomField.php',
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 16:15:25 +02:00
'PhabricatorStandardCustomFieldBlueprints' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldBlueprints.php',
Implement standard field "bool" type Summary: Depends on D7005. Implements the existing "bool" type. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7006
2013-09-17 01:03:51 +02:00
'PhabricatorStandardCustomFieldBool' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldBool.php',
Implement a "credential" standard custom field Summary: Ref T4590. Ref T1049. This is primarily intended to support HTTP auth in Harbormaster. Test Plan: Added a field, edited it, etc. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4590, T1049 Differential Revision: https://secure.phabricator.com/D8607
2014-03-26 00:13:27 +01:00
'PhabricatorStandardCustomFieldCredential' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldCredential.php',
Provide a generic "Datasource" StandardCustomField Summary: Ref T9253. See discussion in D13843. I want to let Drydock blueprints for Almanac services choose those services from a typeahead, but only list appropriate services in the typeahead. To do this: - Provide a StandardCustomField for an arbitrary datasource. - Adjust the AlmanacServiceDatasource to allow filtering by service class. This implementation is substantially the same as the one in D13843, with some adjustments: - I lifted most of the code in the `Users` standard custom field into a new `Tokenizer` standard custom field. - The `Users` and `Datasource` custom fields now extend the `Tokenizer` custom field and can share most of the code it uses. - I exposed this field fully as a configurable field. I don't think anyone will ever use it, but this generality costs us nearly nothing and improves consistency. - The code in D13843 didn't actually pass the parameters over the wire, since the object that responds to the request is not the same object that renders the field. Use the "parameters" mechanism in datasources to get things passed over the wire. Test Plan: - Created a custom "users" field in Maniphest and made sure it still wokred. - Created a custom "almanc services" field in Maniphest and selected some services for a task. - With additional changes from D13843, selected an appropriate Almanac service in a new Drydock blueprint. Reviewers: hach-que, chad Reviewed By: hach-que, chad Maniphest Tasks: T9253 Differential Revision: https://secure.phabricator.com/D14111
2015-09-21 13:41:52 +02:00
'PhabricatorStandardCustomFieldDatasource' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldDatasource.php',
Add a "date" standard custom field Summary: See previous revisions. As maniphest. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7009
2013-09-17 01:04:31 +02:00
'PhabricatorStandardCustomFieldDate' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldDate.php',
Add a "Header" standard custom field Summary: Ref T418. This is the last of the Maniphest field types, although I have a few more capabilities/options to port over. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D7018
2013-09-17 23:22:04 +02:00
'PhabricatorStandardCustomFieldHeader' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldHeader.php',
Use classes to define standard field types and implement an "int" type Summary: Currently, `ManiphestAuxiliaryFieldDefaultSpecification` uses about a dozen giant `switch` statements to implement stadard field types (int, string, date, bool, select, user, remarkup, etc). This is: - pretty gross; - not extensible; and - doesn't really let us share that much code. I got about halfway through porting a similar implementation into StandardField but I wasn't thrilled with it. Subclass StandardField instead to implement custom field types. Test Plan: Added an "int" custom field, verified it had integer semantics and indexed into the integer index. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7005
2013-09-17 01:03:24 +02:00
'PhabricatorStandardCustomFieldInt' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldInt.php',
Support configuration-driven custom fields Summary: Ref T1702. Ref T3718. There are a couple of things going on here: **PhabricatorCustomFieldList**: I added `PhabricatorCustomFieldList`, which is just a convenience class for dealing with lists of fields. Often, current field code does something like this inline in a Controller: foreach ($fields as $field) { // do some junk } Often, that junk has some slightly subtle implications. Move all of it to `$list->doSomeJunk()` methods (like `appendFieldsToForm()`, `loadFieldsFromStorage()`) to reduce code duplication and prevent errors. This additionally moves an existing list-convenience method there, out of `PhabricatorPropertyListView`. **PhabricatorUserConfiguredCustomFieldStorage**: Adds `PhabricatorUserConfiguredCustomFieldStorage` for storing custom field data (like "ICQ Handle", "Phone Number", "Desk", "Favorite Flower", etc). **Configuration-Driven Custom Fields**: Previously, I was thinking about doing these with interfaces, but as I thought about it more I started to dislike that approach. Instead, I built proxies into `PhabricatorCustomField`. Basically, this means that fields (like a custom, configuration-driven "Favorite Flower" field) can just use some other Field to actually provide their implementation (like a "standard" field which knows how to render text areas). The previous approach would have involed subclasssing the "standard" field and implementing an interface, but that would mean that every application would have at least two "base" fields and generally just seemed bleh as I worked through it. The cost of this approach is that we need a bunch of `proxy` junk in the base class, but that's a one-time cost and I think it simplifies all the implementations and makes them a lot less magical (e.g., all of the custom fields now extend the right base field classes). **Fixed Some Bugs**: Some of this code hadn't really been run yet and had minor bugs. Test Plan: {F54240} {F54241} {F54242} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1702, T1703, T3718 Differential Revision: https://secure.phabricator.com/D6749
2013-08-14 17:10:16 +02:00
'PhabricatorStandardCustomFieldInterface' => 'infrastructure/customfield/interface/PhabricatorStandardCustomFieldInterface.php',
Add link custom field. Summary: Ref T3868. Adds a link custom field that verifies and links to the text provided. Test Plan: Add a custom field with type "link", then enter a well-formed URL in the provided box in the edit task screen. Verify that the URL displays correctly on the task display page. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T3868 Differential Revision: https://secure.phabricator.com/D12543
2015-04-24 20:49:11 +02:00
'PhabricatorStandardCustomFieldLink' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldLink.php',
Add "user" and "users" standard custom fields Summary: These end up a little weird with subclassing instead of `switch`, but some day we could alias them to one another or something I guess. If I'm feeling brave, I might get rid of the "user" variant when I migrate Maniphest custom field specs, and turn it into "users, limit = 1" or something like that. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7010
2013-09-17 01:04:46 +02:00
'PhabricatorStandardCustomFieldPHIDs' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldPHIDs.php',
Implement a "remarkup" standard field type Summary: See D7006, etc. This one's easy since exposing it to ApplicationSearch doesn't make much sense. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7008
2013-09-17 01:04:18 +02:00
'PhabricatorStandardCustomFieldRemarkup' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldRemarkup.php',
Implement a "select" standard custom field type Summary: See D7006, etc. Brings this from Maniphest. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7007
2013-09-17 01:04:08 +02:00
'PhabricatorStandardCustomFieldSelect' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldSelect.php',
Use classes to define standard field types and implement an "int" type Summary: Currently, `ManiphestAuxiliaryFieldDefaultSpecification` uses about a dozen giant `switch` statements to implement stadard field types (int, string, date, bool, select, user, remarkup, etc). This is: - pretty gross; - not extensible; and - doesn't really let us share that much code. I got about halfway through porting a similar implementation into StandardField but I wasn't thrilled with it. Subclass StandardField instead to implement custom field types. Test Plan: Added an "int" custom field, verified it had integer semantics and indexed into the integer index. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7005
2013-09-17 01:03:24 +02:00
'PhabricatorStandardCustomFieldText' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldText.php',
Provide a generic "Datasource" StandardCustomField Summary: Ref T9253. See discussion in D13843. I want to let Drydock blueprints for Almanac services choose those services from a typeahead, but only list appropriate services in the typeahead. To do this: - Provide a StandardCustomField for an arbitrary datasource. - Adjust the AlmanacServiceDatasource to allow filtering by service class. This implementation is substantially the same as the one in D13843, with some adjustments: - I lifted most of the code in the `Users` standard custom field into a new `Tokenizer` standard custom field. - The `Users` and `Datasource` custom fields now extend the `Tokenizer` custom field and can share most of the code it uses. - I exposed this field fully as a configurable field. I don't think anyone will ever use it, but this generality costs us nearly nothing and improves consistency. - The code in D13843 didn't actually pass the parameters over the wire, since the object that responds to the request is not the same object that renders the field. Use the "parameters" mechanism in datasources to get things passed over the wire. Test Plan: - Created a custom "users" field in Maniphest and made sure it still wokred. - Created a custom "almanc services" field in Maniphest and selected some services for a task. - With additional changes from D13843, selected an appropriate Almanac service in a new Drydock blueprint. Reviewers: hach-que, chad Reviewed By: hach-que, chad Maniphest Tasks: T9253 Differential Revision: https://secure.phabricator.com/D14111
2015-09-21 13:41:52 +02:00
'PhabricatorStandardCustomFieldTokenizer' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldTokenizer.php',
Add "user" and "users" standard custom fields Summary: These end up a little weird with subclassing instead of `switch`, but some day we could alias them to one another or something I guess. If I'm feeling brave, I might get rid of the "user" variant when I migrate Maniphest custom field specs, and turn it into "users, limit = 1" or something like that. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7010
2013-09-17 01:04:46 +02:00
'PhabricatorStandardCustomFieldUsers' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldUsers.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorStandardPageView' => 'view/page/PhabricatorStandardPageView.php',
Support "Select" custom fields in Herald rules Summary: Fixes T5016. Ref T655. Ref T8434. Ref T8726. For "select" custom fields, permit construction of Herald rules. Test Plan: {F602997} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T655, T5016, T8434, T8726 Differential Revision: https://secure.phabricator.com/D13618
2015-07-16 23:12:54 +02:00
'PhabricatorStandardSelectCustomFieldDatasource' => 'infrastructure/customfield/datasource/PhabricatorStandardSelectCustomFieldDatasource.php',
Convert DrydockBlueprints to EditEngine Summary: Ref T10457. Fixes T10024. This primarily just modernizes blueprints to use EditEngine. This also fixes T10024, which was an issue with stored properties not being flagged correctly. Also slightly improves typeaheads for blueprints (more information, disabled state). Test Plan: - Created and edited various types of blueprints. - Set and removed limits. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10024, T10457 Differential Revision: https://secure.phabricator.com/D15390
2016-03-03 13:34:47 +01:00
'PhabricatorStaticEditField' => 'applications/transactions/editfield/PhabricatorStaticEditField.php',
Add a robots.txt file to disallow /diffusion/ Summary: Fixes T4610. Open to suggestions, etc., if there's anything I'm missing. Also: - Moves these "system" endpoints into a real application. - Makes `isUnlisted()` work a little more consistently. Test Plan: Accessed `/robots.txt`, `/status/` and `/debug/`. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4610 Differential Revision: https://secure.phabricator.com/D8532
2014-03-14 19:53:17 +01:00
'PhabricatorStatusController' => 'applications/system/controller/PhabricatorStatusController.php',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorStatusUIExample' => 'applications/uiexample/examples/PhabricatorStatusUIExample.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorStorageFixtureScopeGuard' => 'infrastructure/testing/fixture/PhabricatorStorageFixtureScopeGuard.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'PhabricatorStorageManagementAPI' => 'infrastructure/storage/management/PhabricatorStorageManagementAPI.php',
Add `bin/storage adjust`, for adjusting schemata Summary: Ref T1191. Adds a new workflow which can apply schema adjustments. For now, it only performs database and table collation/charset adjustments. I believe these are extremely safe/minor, because they only affect the default values for newly created columns. Test Plan: - Ran migration on various database states, database/table changes went through cleanly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10595
2014-10-01 17:16:31 +02:00
'PhabricatorStorageManagementAdjustWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementAdjustWorkflow.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'PhabricatorStorageManagementDatabasesWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementDatabasesWorkflow.php',
'PhabricatorStorageManagementDestroyWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementDestroyWorkflow.php',
'PhabricatorStorageManagementDumpWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementDumpWorkflow.php',
Move "scripts/sql/probe.php" to "bin/storage probe" Summary: This makes it namespace/database/connection aware and a little easier to find. Also use pht() / PhutilConsole. Test Plan: Ran `bin/storage probe`. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6341
2013-07-03 01:34:17 +02:00
'PhabricatorStorageManagementProbeWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementProbeWorkflow.php',
Provide `bin/storage quickstart` to automate generation of `quickstart.sql` Summary: Ref T1191. Currently, the `quickstart.sql` gets generated in a pretty manual fashion. This is a pain, and will become more of a pain in the world of utf8mb4. Provide a workflow which does upgrade + adjust + dump + destroy, then massages the output to produce a workable `quickstart.sql`. Test Plan: Inspected output; I'll test this more throughly before actually generating a new quickstart, but that's some ways away. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10603
2014-10-01 17:22:37 +02:00
'PhabricatorStorageManagementQuickstartWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementQuickstartWorkflow.php',
Add a `storage renamespace` for mangling SQL dumpfiles into a new namespace Summary: Ref T7149. When users give us dumpfiles for import, they will almost inevitably use the `phabricator` namespace. They need to be renamed to use an instance namespace. We can do this either by: - importing the data first, then renaming; or - renaming first, then importing. This implements the second one, basically `storage renamespace --in dump.sql --from phabricator --to instancename > instance.sql`. Renaming first is a little hackier since we have to `preg_match()` a SQL dump file, but I think it's better overall: - With only one database, it lets you dump/import without downtime. - If you have development stuff in a development environment in the `phabricator` namespace, you don't have to move it aside to do an import. - No possibility that two people doing an import at the same time on the same box will collide with each other. - You can do the rename once and then repeat the import process with the renamed dump more easily. - No tricky stuff with modern Phabricator running against an old dump and the database names not matching up. None of this is super important, but it just makes large dumps a bit easier to work with, and the dumpfile format is regular enough that this seems unlikely to ever really not work. Test Plan: Renamespaced a dump, did a `diff -u`, saw all the relevant parts changed (and only those parts changed). Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12105
2015-03-18 02:29:01 +01:00
'PhabricatorStorageManagementRenamespaceWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementRenamespaceWorkflow.php',
Add a `./bin/storage shell` command Summary: Fixes T7078. Adds a `./bin/storage shell` command which passes through to a MySQL shell. This is slightly more convenient than running `mysql` manually. Test Plan: Ran `./bin/storage shell` and got a MySQL shell. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7078 Differential Revision: https://secure.phabricator.com/D11548
2015-01-29 21:15:27 +01:00
'PhabricatorStorageManagementShellWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementShellWorkflow.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'PhabricatorStorageManagementStatusWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementStatusWorkflow.php',
'PhabricatorStorageManagementUpgradeWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementUpgradeWorkflow.php',
'PhabricatorStorageManagementWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementWorkflow.php',
'PhabricatorStoragePatch' => 'infrastructure/storage/management/PhabricatorStoragePatch.php',
Generate expected schemata for MetaMTA, Nuance, MetaData, OAuthServer Summary: Ref T1191. Handful of minor things here (T6150, T6149, T6148, T6147, T6146) but nothing very noteworthy. Test Plan: Viewed web UI, saw fewer errors. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10527
2014-09-24 22:50:00 +02:00
'PhabricatorStorageSchemaSpec' => 'infrastructure/storage/schema/PhabricatorStorageSchemaSpec.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorStorageSetupCheck' => 'applications/config/check/PhabricatorStorageSetupCheck.php',
Rename protocol adapter classes Summary: Ref T5655. Rename protocol adapter classes to remove `Base` from the class name. Test Plan: Unit tests still pass. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D12563
2015-05-18 00:20:11 +02:00
'PhabricatorStreamingProtocolAdapter' => 'infrastructure/daemon/bot/adapter/PhabricatorStreamingProtocolAdapter.php',
Convert projects to EditEngine Summary: Ref T10010. This is pretty straightforward with a couple of very minor new behaviors, like the icon selector edit field. Test Plan: - Created projects. - Edited projects. - Saw "Create Project" in quick create menu. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14896
2015-12-27 15:45:53 +01:00
'PhabricatorStringListEditField' => 'applications/transactions/editfield/PhabricatorStringListEditField.php',
Add basic "Subscriptions" application Summary: Basic infrastructure for generalizing subscriptions/CCs for T1808, T1514 and T1663. - Implement `PhabricatorSubscribableInterface` and you'll get a subscribe/unsubscribe button for free. - If there are any auto-subscribed users (like the question author) you can specify them; this makes more sense for Tasks and Revisions than Ponder probably, but maybe the author should be auto-subscribed. - Subscriptions are either "explicit" (the user clicked 'subscribe') or "implicit" (the user did something which causes them to become subscribed naturally). If a user unsubscribes, they'll no longer be added by implicit subscriptions. This may or may not be relevant to Ponder but is an existing Herald feature in Differential. - Helper method on PhabricatorSubscribersQuery to load subscribers. - This doesn't handle actually sending email, etc. I think that's all so application-specific that it doesn't belong here. - Now seems to work. Test Plan: {F20552} {F20553} Reviewers: pieter, btrahan Reviewed By: pieter CC: aran Maniphest Tasks: T1663, T1514, T1808 Differential Revision: https://secure.phabricator.com/D3637
2012-10-05 22:18:05 +02:00
'PhabricatorSubscribableInterface' => 'applications/subscriptions/interface/PhabricatorSubscribableInterface.php',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorSubscribedToObjectEdgeType' => 'applications/transactions/edges/PhabricatorSubscribedToObjectEdgeType.php',
Provide formal Users/Projects/Mailable fields for EditEngine Summary: Ref T9132. This allows you to prefill EditEngine forms with stuff like `?subscribers=epriestley`, and we'll figure out what you mean. Test Plan: - Did `/?subscribers=...` with various values (good, bad, mis-capitalized). - Did `/?projects=...` with various values (good, bad, mis-capitalized). - Reviewed documentation. - Reviewed {nav Config > HTTP Parameter Types}. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14404
2015-11-04 19:20:38 +01:00
'PhabricatorSubscribersEditField' => 'applications/transactions/editfield/PhabricatorSubscribersEditField.php',
Add basic "Subscriptions" application Summary: Basic infrastructure for generalizing subscriptions/CCs for T1808, T1514 and T1663. - Implement `PhabricatorSubscribableInterface` and you'll get a subscribe/unsubscribe button for free. - If there are any auto-subscribed users (like the question author) you can specify them; this makes more sense for Tasks and Revisions than Ponder probably, but maybe the author should be auto-subscribed. - Subscriptions are either "explicit" (the user clicked 'subscribe') or "implicit" (the user did something which causes them to become subscribed naturally). If a user unsubscribes, they'll no longer be added by implicit subscriptions. This may or may not be relevant to Ponder but is an existing Herald feature in Differential. - Helper method on PhabricatorSubscribersQuery to load subscribers. - This doesn't handle actually sending email, etc. I think that's all so application-specific that it doesn't belong here. - Now seems to work. Test Plan: {F20552} {F20553} Reviewers: pieter, btrahan Reviewed By: pieter CC: aran Maniphest Tasks: T1663, T1514, T1808 Differential Revision: https://secure.phabricator.com/D3637
2012-10-05 22:18:05 +02:00
'PhabricatorSubscribersQuery' => 'applications/subscriptions/query/PhabricatorSubscribersQuery.php',
Implement "trigger clocks" for scheduling events Summary: Ref T6881. This will probably make more sense in a couple of diffs, but this is a class that implements scheduling/recurrence rules. Two rules are provided: - Trigger an event at a specific time (e.g., a meeting reminder notification). - Trigger an event on the Nth day of every month (e.g., a subscription bill). At some point, we'll presumably add a rule for T2896 (maybe using the "RRULE" spec) so you can do stuff like "the second to last thursday of every month", etc., but we don't need that for now. (The "Nth day of every month, or move it back if no such day exists" rule doesn't seem to be expressible with the "RRULE" format, so implementing that wouldn't give us a superset of this. I think this rule is correct and desirable for this purpose, though.) Test Plan: Added and executed unit tests. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11403
2015-01-16 00:57:45 +01:00
'PhabricatorSubscriptionTriggerClock' => 'infrastructure/daemon/workers/clock/PhabricatorSubscriptionTriggerClock.php',
Make "Add Subscribers" and "Remove Subscribers" Herald actions modular Summary: Ref T8726. Converts these actions to be modular. No real surprises in this change. Test Plan: {F658709} - Wrote some rules. - Migrated them forward. - Used a bunch of these rules. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13699
2015-07-18 17:07:31 +02:00
'PhabricatorSubscriptionsAddSelfHeraldAction' => 'applications/subscriptions/herald/PhabricatorSubscriptionsAddSelfHeraldAction.php',
'PhabricatorSubscriptionsAddSubscribersHeraldAction' => 'applications/subscriptions/herald/PhabricatorSubscriptionsAddSubscribersHeraldAction.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorSubscriptionsApplication' => 'applications/subscriptions/application/PhabricatorSubscriptionsApplication.php',
Introduce "Curtain" views, panels, and extensions Summary: This opens up the new action column to have specialized rendering and behavior. Briefly: - Converted applications (right now, only Paste) render a `CurtainView` to build the column content. - This view uses new extensions to build panels (projects, subscribers, tokens). - The panel extension code and rendering can be changed without breaking old stuff. Minor changes: - Token awards now load their tokens, for consistency/simplicity. - Removed the rest of the "fork of" / "forked from" UI in Paste -- I essentially removed these features a while ago, and no one has complained. Test Plan: UI is a bit rough, but works, and it's going to get changed now anyway: {F1160550} {F1160551} Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15414
2016-03-05 23:45:56 +01:00
'PhabricatorSubscriptionsCurtainExtension' => 'applications/subscriptions/engineextension/PhabricatorSubscriptionsCurtainExtension.php',
Add basic "Subscriptions" application Summary: Basic infrastructure for generalizing subscriptions/CCs for T1808, T1514 and T1663. - Implement `PhabricatorSubscribableInterface` and you'll get a subscribe/unsubscribe button for free. - If there are any auto-subscribed users (like the question author) you can specify them; this makes more sense for Tasks and Revisions than Ponder probably, but maybe the author should be auto-subscribed. - Subscriptions are either "explicit" (the user clicked 'subscribe') or "implicit" (the user did something which causes them to become subscribed naturally). If a user unsubscribes, they'll no longer be added by implicit subscriptions. This may or may not be relevant to Ponder but is an existing Herald feature in Differential. - Helper method on PhabricatorSubscribersQuery to load subscribers. - This doesn't handle actually sending email, etc. I think that's all so application-specific that it doesn't belong here. - Now seems to work. Test Plan: {F20552} {F20553} Reviewers: pieter, btrahan Reviewed By: pieter CC: aran Maniphest Tasks: T1663, T1514, T1808 Differential Revision: https://secure.phabricator.com/D3637
2012-10-05 22:18:05 +02:00
'PhabricatorSubscriptionsEditController' => 'applications/subscriptions/controller/PhabricatorSubscriptionsEditController.php',
Modularize SearchEngine extensions Summary: Ref T9964. ApplicationSearch currently has a bunch of hard-coded `if ($object instanceof thing)` stuff. Pull that out so it can live in extensions. Test Plan: - Searched by spaces, subscribers, projects. {F1023921} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14764
2015-12-13 13:12:34 +01:00
'PhabricatorSubscriptionsEditEngineExtension' => 'applications/subscriptions/engineextension/PhabricatorSubscriptionsEditEngineExtension.php',
Add basic "Subscriptions" application Summary: Basic infrastructure for generalizing subscriptions/CCs for T1808, T1514 and T1663. - Implement `PhabricatorSubscribableInterface` and you'll get a subscribe/unsubscribe button for free. - If there are any auto-subscribed users (like the question author) you can specify them; this makes more sense for Tasks and Revisions than Ponder probably, but maybe the author should be auto-subscribed. - Subscriptions are either "explicit" (the user clicked 'subscribe') or "implicit" (the user did something which causes them to become subscribed naturally). If a user unsubscribes, they'll no longer be added by implicit subscriptions. This may or may not be relevant to Ponder but is an existing Herald feature in Differential. - Helper method on PhabricatorSubscribersQuery to load subscribers. - This doesn't handle actually sending email, etc. I think that's all so application-specific that it doesn't belong here. - Now seems to work. Test Plan: {F20552} {F20553} Reviewers: pieter, btrahan Reviewed By: pieter CC: aran Maniphest Tasks: T1663, T1514, T1808 Differential Revision: https://secure.phabricator.com/D3637
2012-10-05 22:18:05 +02:00
'PhabricatorSubscriptionsEditor' => 'applications/subscriptions/editor/PhabricatorSubscriptionsEditor.php',
Modularize fulltext indexing of Projects, Subscriptions and Custom Fields Summary: Ref T9979. This is going to become `FulltextEngine`, but pave the way for that by pulling extensions out of it. Test Plan: {F1036624} - Used `bin/search index Txxx`, saw projects, subscribers and custom fields rebuild in the index. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14835
2015-12-21 15:31:31 +01:00
'PhabricatorSubscriptionsFulltextEngineExtension' => 'applications/subscriptions/engineextension/PhabricatorSubscriptionsFulltextEngineExtension.php',
Make "Add Subscribers" and "Remove Subscribers" Herald actions modular Summary: Ref T8726. Converts these actions to be modular. No real surprises in this change. Test Plan: {F658709} - Wrote some rules. - Migrated them forward. - Used a bunch of these rules. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13699
2015-07-18 17:07:31 +02:00
'PhabricatorSubscriptionsHeraldAction' => 'applications/subscriptions/herald/PhabricatorSubscriptionsHeraldAction.php',
Subscriptions - make a dialog for massive subscription lists Summary: Ref T4430. This just deploys it on the property lists. (Help on how to do translations better? I tried a more traditional pht('%s, %s, %s, and %d other(s)') but I think the string lookup assumes the %d comes as the second param or something?) Test Plan: Made a Maniphest Task with a hojillion subscribers and noted the working dialogue. Also made a Pholio Mock with lots of subscribers and it worked. Reviewers: epriestley Reviewed By: epriestley Subscribers: aran, epriestley, Korvin, chad Maniphest Tasks: T4430 Differential Revision: https://secure.phabricator.com/D8525
2014-03-14 19:22:00 +01:00
'PhabricatorSubscriptionsListController' => 'applications/subscriptions/controller/PhabricatorSubscriptionsListController.php',
Make "Add Subscribers" and "Remove Subscribers" Herald actions modular Summary: Ref T8726. Converts these actions to be modular. No real surprises in this change. Test Plan: {F658709} - Wrote some rules. - Migrated them forward. - Used a bunch of these rules. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13699
2015-07-18 17:07:31 +02:00
'PhabricatorSubscriptionsRemoveSelfHeraldAction' => 'applications/subscriptions/herald/PhabricatorSubscriptionsRemoveSelfHeraldAction.php',
'PhabricatorSubscriptionsRemoveSubscribersHeraldAction' => 'applications/subscriptions/herald/PhabricatorSubscriptionsRemoveSubscribersHeraldAction.php',
Implement an "Attachments" behavior for Conduit Search APIs Summary: Ref T9964. We have various kinds of secondary data on objects (like subscribers, projects, paste content, Owners paths, file attachments, etc) which is somewhat slow, or somewhat large, or both. Some approaches to handling this in the API include: - Always return all of it (very easy, but slow). - Require users to make separate API calls to get each piece of data (very simple, but inefficient and really cumbersome to use). - Implement a hierarchical query language like GraphQL (powerful, but very complex). - Kind of mix-and-match a half-power query language and some extra calls? (fairly simple, not too terrible?) We currently mix-and-match internally, with `->needStuff(true)`. This is not a general-purpose, full-power graph query language like GraphQL, and it occasionally does limit us. For example, there is no way to do this sort of thing: $conpherence_thread_query = id(new ConpherenceThreadQuery()) ->setViewer($viewer) // ... ->setNeedMessages(true) ->setWhenYouLoadTheMessagesTheyNeedProfilePictures(true); However, we almost never actually need to do this and when we do want to do it we usually don't //really// want to do it, so I don't think this is a major limit to the practical power of the system for the kinds of things we really want to do with it. Put another way, we have a lot of 1-level hierarchical queries (get pictures or repositories or projects or files or content for these objects) but few-to-no 2+ level queries (get files for these objects, then get all the projects for those files). So even though 1-level hierarchies are not a beautiful, general-purpose, fully-abstract system, they've worked well so far in practice and I'm comfortable moving forward with them in the API. If we do need N-level queries in the future, there is no technical reason we can't put GraphQL (or something similar) on top of this eventually, and this would represent a solid step toward that. However, I suspect we'll never need them. Upshot: I'm pretty happy with "->needX()" for all practical purposes, so this is just adding a way to say "->needX()" to the API. Specifically, you say: ``` { "attachments": { "subscribers": true, } } ``` ...and get back subscriber data. In the future (or for certain attachments), `true` might become a dictionary of extra parameters, if necessary, and could do so without breaking the API. Test Plan: - Ran queries to get attachments. {F1025449} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14772
2015-12-14 13:58:34 +01:00
'PhabricatorSubscriptionsSearchEngineAttachment' => 'applications/subscriptions/engineextension/PhabricatorSubscriptionsSearchEngineAttachment.php',
Modularize SearchEngine extensions Summary: Ref T9964. ApplicationSearch currently has a bunch of hard-coded `if ($object instanceof thing)` stuff. Pull that out so it can live in extensions. Test Plan: - Searched by spaces, subscribers, projects. {F1023921} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14764
2015-12-13 13:12:34 +01:00
'PhabricatorSubscriptionsSearchEngineExtension' => 'applications/subscriptions/engineextension/PhabricatorSubscriptionsSearchEngineExtension.php',
Implement a "!subscribe" mail command Summary: Ref T7199. Implements "!subscribe". Test Plan: Used `bin/mail receive-test` to apply the command to objects. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12247
2015-04-01 18:45:18 +02:00
'PhabricatorSubscriptionsSubscribeEmailCommand' => 'applications/subscriptions/command/PhabricatorSubscriptionsSubscribeEmailCommand.php',
Add a "Subscribers" object policy Summary: Ref T5681. Getting this to work correctly is a bit tricky, mostly because of the policy checks we do prior to applying an edit. I think I came up with a mostly-reasonable approach, although it's a little bit gross. It uses `spl_object_hash()` so it shouldn't be able to do anything bad/dangerous (the hints are strictly bound to the hinted object, which is a clone that we destroy moments later). Test Plan: - Added + ran a unit test. - Created a task with a "Subscribers" policy with me as a subscriber (without the hint stuff, this isn't possible: since you aren't a subscriber *yet*, you get a "you won't be able to see it" error). - Unsubscribed from a task with a "Subscribers" policy, was immediately unable to see it. - Created a task with a "subscribers" policy and a project subscriber with/without me as a member (error / success, respectively). Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5681 Differential Revision: https://secure.phabricator.com/D13259
2015-06-14 00:45:17 +02:00
'PhabricatorSubscriptionsSubscribersPolicyRule' => 'applications/subscriptions/policyrule/PhabricatorSubscriptionsSubscribersPolicyRule.php',
Transactions - add "and X others" dialog support to application transactions Summary: Fixes T4430. Basically does a little code massage from the new stuff in D8525 and application transactions to get this working. Adds a new controller to the subscriptions app to make rendering these pretty easy peasy. Test Plan: Used my test task in D8525 to verify both add and rem versions of these dialogs worked correctly. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, chad, Korvin Maniphest Tasks: T4430 Differential Revision: https://secure.phabricator.com/D8540
2014-03-14 22:27:45 +01:00
'PhabricatorSubscriptionsTransactionController' => 'applications/subscriptions/controller/PhabricatorSubscriptionsTransactionController.php',
Add basic "Subscriptions" application Summary: Basic infrastructure for generalizing subscriptions/CCs for T1808, T1514 and T1663. - Implement `PhabricatorSubscribableInterface` and you'll get a subscribe/unsubscribe button for free. - If there are any auto-subscribed users (like the question author) you can specify them; this makes more sense for Tasks and Revisions than Ponder probably, but maybe the author should be auto-subscribed. - Subscriptions are either "explicit" (the user clicked 'subscribe') or "implicit" (the user did something which causes them to become subscribed naturally). If a user unsubscribes, they'll no longer be added by implicit subscriptions. This may or may not be relevant to Ponder but is an existing Herald feature in Differential. - Helper method on PhabricatorSubscribersQuery to load subscribers. - This doesn't handle actually sending email, etc. I think that's all so application-specific that it doesn't belong here. - Now seems to work. Test Plan: {F20552} {F20553} Reviewers: pieter, btrahan Reviewed By: pieter CC: aran Maniphest Tasks: T1663, T1514, T1808 Differential Revision: https://secure.phabricator.com/D3637
2012-10-05 22:18:05 +02:00
'PhabricatorSubscriptionsUIEventListener' => 'applications/subscriptions/events/PhabricatorSubscriptionsUIEventListener.php',
Fully modularize mail commands Summary: Ref T7199. Everyone can have a mail command! You can have a mail command! You can have a mail command! Mail commands for everyone! Test Plan: Used `bin/mail receive-test` to issue commands against files and pastes. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12238
2015-04-01 17:40:00 +02:00
'PhabricatorSubscriptionsUnsubscribeEmailCommand' => 'applications/subscriptions/command/PhabricatorSubscriptionsUnsubscribeEmailCommand.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorSupportApplication' => 'applications/support/application/PhabricatorSupportApplication.php',
Minor, move all remarkup code to src/infrastructure/markup/
2012-07-02 19:44:37 +02:00
'PhabricatorSyntaxHighlighter' => 'infrastructure/markup/PhabricatorSyntaxHighlighter.php',
Add syntax highlighting options. Test Plan: Quick view of each option in the web interface. Reviewers: epriestley, btrahan, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4386
2013-01-10 18:56:36 +01:00
'PhabricatorSyntaxHighlightingConfigOptions' => 'applications/config/option/PhabricatorSyntaxHighlightingConfigOptions.php',
Generate syntax highlighting CSS from a reusable map Summary: Ref T9790. This prepares the syntax color rules to be reused in mail. This goes about halfway toward T5701 by sort-of supporting different styles but not really. Test Plan: - Ran `bin/celerity syntax` to regenerate syntax map. - Viewed some highlighted code, didn't see any differences. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9790 Differential Revision: https://secure.phabricator.com/D15846
2016-05-05 03:24:59 +02:00
'PhabricatorSyntaxStyle' => 'infrastructure/syntax/PhabricatorSyntaxStyle.php',
Add semi-generic rate limiting infrastructure Summary: This adds a system which basically keeps a record of recent actions, who took them, and how many "points" they were worth, like: epriestley email.add 1 1233989813 epriestley email.add 1 1234298239 epriestley email.add 1 1238293981 We can use this to rate-limit actions by examining how many actions the user has taken in the past hour (i.e., their total score) and comparing that to an allowed limit. One major thing I want to use this for is to limit the amount of error email we'll send to an email address. A big concern I have with sending more error email is that we'll end up in loops. We have some protections against this in headers already, but hard-limiting the system so it won't send more than a few errors to a particular address per hour should provide a reasonable secondary layer of protection. This use case (where the "actor" needs to be an email address) is why the table uses strings + hashes instead of PHIDs. For external users, it might be appropriate to rate limit by cookies or IPs, too. To prove it works, I rate limited adding email addresses. This is a very, very low-risk security thing where a user with an account can enumerate addresses (by checking if they get an error) and sort of spam/annoy people (by adding their address over and over again). Limiting them to 6 actions / hour should satisfy all real users while preventing these behaviors. Test Plan: This dialog is uggos but I'll fix that in a sec: {F137406} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8683
2014-04-03 20:22:38 +02:00
'PhabricatorSystemAction' => 'applications/system/action/PhabricatorSystemAction.php',
'PhabricatorSystemActionEngine' => 'applications/system/engine/PhabricatorSystemActionEngine.php',
'PhabricatorSystemActionGarbageCollector' => 'applications/system/garbagecollector/PhabricatorSystemActionGarbageCollector.php',
'PhabricatorSystemActionLog' => 'applications/system/storage/PhabricatorSystemActionLog.php',
'PhabricatorSystemActionRateLimitException' => 'applications/system/exception/PhabricatorSystemActionRateLimitException.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorSystemApplication' => 'applications/system/application/PhabricatorSystemApplication.php',
Add semi-generic rate limiting infrastructure Summary: This adds a system which basically keeps a record of recent actions, who took them, and how many "points" they were worth, like: epriestley email.add 1 1233989813 epriestley email.add 1 1234298239 epriestley email.add 1 1238293981 We can use this to rate-limit actions by examining how many actions the user has taken in the past hour (i.e., their total score) and comparing that to an allowed limit. One major thing I want to use this for is to limit the amount of error email we'll send to an email address. A big concern I have with sending more error email is that we'll end up in loops. We have some protections against this in headers already, but hard-limiting the system so it won't send more than a few errors to a particular address per hour should provide a reasonable secondary layer of protection. This use case (where the "actor" needs to be an email address) is why the table uses strings + hashes instead of PHIDs. For external users, it might be appropriate to rate limit by cookies or IPs, too. To prove it works, I rate limited adding email addresses. This is a very, very low-risk security thing where a user with an account can enumerate addresses (by checking if they get an error) and sort of spam/annoy people (by adding their address over and over again). Limiting them to 6 actions / hour should satisfy all real users while preventing these behaviors. Test Plan: This dialog is uggos but I'll fix that in a sec: {F137406} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8683
2014-04-03 20:22:38 +02:00
'PhabricatorSystemDAO' => 'applications/system/storage/PhabricatorSystemDAO.php',
Implement bin/remove, for structured destruction of objects Summary: Ref T4749. Ref T3265. Ref T4909. Several goals here: - Move user destruction to the CLI to limit the power of rogue admins. - Start consolidating all "destroy named object" scripts into a single UI, to make it easier to know how to destroy things. - Structure object destruction so we can do a better and more automatic job of cleaning up transactions, edges, search indexes, etc. - Log when we destroy objects so there's a record if data goes missing. Test Plan: Used `bin/remove destroy` to destroy several users. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3265, T4749, T4909 Differential Revision: https://secure.phabricator.com/D8940
2014-05-02 03:23:31 +02:00
'PhabricatorSystemDestructionGarbageCollector' => 'applications/system/garbagecollector/PhabricatorSystemDestructionGarbageCollector.php',
'PhabricatorSystemDestructionLog' => 'applications/system/storage/PhabricatorSystemDestructionLog.php',
When Phabricator is in read-only mode, explain why Summary: Ref T4571. Allows users to click the "read-only mode" notification to get more information about why an install is in read-only mode. Installs can be in this mode for several reasons (explicit administrative action, no masters defined, no masters reachable), and it's useful to be able to tell the difference. Test Plan: {F1212930} Reviewers: chad Reviewed By: chad Maniphest Tasks: T4571 Differential Revision: https://secure.phabricator.com/D15671
2016-04-10 13:26:53 +02:00
'PhabricatorSystemReadOnlyController' => 'applications/system/controller/PhabricatorSystemReadOnlyController.php',
Implement bin/remove, for structured destruction of objects Summary: Ref T4749. Ref T3265. Ref T4909. Several goals here: - Move user destruction to the CLI to limit the power of rogue admins. - Start consolidating all "destroy named object" scripts into a single UI, to make it easier to know how to destroy things. - Structure object destruction so we can do a better and more automatic job of cleaning up transactions, edges, search indexes, etc. - Log when we destroy objects so there's a record if data goes missing. Test Plan: Used `bin/remove destroy` to destroy several users. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3265, T4749, T4909 Differential Revision: https://secure.phabricator.com/D8940
2014-05-02 03:23:31 +02:00
'PhabricatorSystemRemoveDestroyWorkflow' => 'applications/system/management/PhabricatorSystemRemoveDestroyWorkflow.php',
'PhabricatorSystemRemoveLogWorkflow' => 'applications/system/management/PhabricatorSystemRemoveLogWorkflow.php',
'PhabricatorSystemRemoveWorkflow' => 'applications/system/management/PhabricatorSystemRemoveWorkflow.php',
Substantially support character encodings and "Highlight As" in changesets Summary: Ref T5179. Ref T4045. Ref T832. We can now write non-utf8 hunks into the database, so try to do more reasonable things with them in the UI. Test Plan: (See screenshots...) Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T832, T4045, T5179 Differential Revision: https://secure.phabricator.com/D9294
2014-06-20 20:49:41 +02:00
'PhabricatorSystemSelectEncodingController' => 'applications/system/controller/PhabricatorSystemSelectEncodingController.php',
'PhabricatorSystemSelectHighlightController' => 'applications/system/controller/PhabricatorSystemSelectHighlightController.php',
Rename the `PhabricatorAuthFactorTOTP` class for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11191
2015-01-06 12:56:03 +01:00
'PhabricatorTOTPAuthFactor' => 'applications/auth/factor/PhabricatorTOTPAuthFactor.php',
'PhabricatorTOTPAuthFactorTestCase' => 'applications/auth/factor/__tests__/PhabricatorTOTPAuthFactorTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorTaskmasterDaemon' => 'infrastructure/daemon/workers/PhabricatorTaskmasterDaemon.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorTestApplication' => 'applications/base/controller/__tests__/PhabricatorTestApplication.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorTestCase' => 'infrastructure/testing/PhabricatorTestCase.php',
Fix controller-level access rules Summary: Ref T603. I had to partially revert this earlier because it accidentally blocked access to Conduit and File data for installs without "policy.allow-public", since the applications are available to "all users" but some endpoints actually need to be available even when not logged in. This readjusts the gating in the controller to properly apply application visibility restrictions, and then adds a giant pile of unit test coverage to make sure it sticks and all the weird cases are covered. Test Plan: - Added and executed unit tests. - Executed most of the tests manually, by using logged in / admin / public / disabled users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7211
2013-10-04 04:05:47 +02:00
'PhabricatorTestController' => 'applications/base/controller/__tests__/PhabricatorTestController.php',
Successfully Generated People Summary: Ref T2903 Test Plan: Added new person whose profile was visible afterwards. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan, btrahan Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5682
2013-04-15 04:09:20 +02:00
'PhabricatorTestDataGenerator' => 'applications/lipsum/generator/PhabricatorTestDataGenerator.php',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorTestNoCycleEdgeType' => 'applications/transactions/edges/PhabricatorTestNoCycleEdgeType.php',
Make file storage more testable Summary: Fixes T2474. Adds a storage dummy storage engine for unit tests, and adds a couple of simple tests for basic file storage. Test Plan: Ran `arc unit` to execute unit tests. Reviewers: kwadwon Reviewed By: kwadwon CC: aran Maniphest Tasks: T2474 Differential Revision: https://secure.phabricator.com/D4777
2013-02-06 22:37:42 +01:00
'PhabricatorTestStorageEngine' => 'applications/files/engine/PhabricatorTestStorageEngine.php',
Factor out task execution and formalize permanent failures Summary: - Clean up a TODO about permanent failures. - Clean up a TODO about failing tasks after too many retries. - Clean up a TODO about testing for bad leases. - Make the lease/retry implementation more flexible and natural. - Make completely bogus tasks fail permanently. - Make PhabricatorMetaMTAWorker use new `getWaitBeforeRetry()` (as intended), not hackily implement logic in `getRequiredLeaseTime()`. - Document worker hooks for failures and retries. - Provide coverage on everything. Test Plan: Ran unit tests. Ran `bin/phd debug taskmaster`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3859
2012-11-01 19:30:23 +01:00
'PhabricatorTestWorker' => 'infrastructure/daemon/workers/__tests__/PhabricatorTestWorker.php',
Implement a basic version of ApplicationEditor in Paste Summary: Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste. This mostly looks and works like ApplicationSearch, and is heavily modeled on it. Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else. This has no functional changes, except: - I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it. - Subscribers are now editable. - Form field order is a little goofy (this will be fixed in a future diff). - Subscribers and projects are now race-resistant. The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits. Test Plan: - Created pastes. - Created pastes via API. - Edited pastes. - Edited every field. - Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4768, T9132 Differential Revision: https://secure.phabricator.com/D14390
2015-11-03 03:58:32 +01:00
'PhabricatorTextAreaEditField' => 'applications/transactions/editfield/PhabricatorTextAreaEditField.php',
'PhabricatorTextEditField' => 'applications/transactions/editfield/PhabricatorTextEditField.php',
Consolidate some datetime code and add unit tests Summary: See D6115. Test Plan: - Ran unit tests. - Viewed reports. - Created a countdown. - Searched chatlog. - Searched pastes by created date. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6116
2013-06-03 21:58:11 +02:00
'PhabricatorTime' => 'infrastructure/time/PhabricatorTime.php',
'PhabricatorTimeGuard' => 'infrastructure/time/PhabricatorTimeGuard.php',
'PhabricatorTimeTestCase' => 'infrastructure/time/__tests__/PhabricatorTimeTestCase.php',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorTimezoneSetupCheck' => 'applications/config/check/PhabricatorTimezoneSetupCheck.php',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorToken' => 'applications/tokens/storage/PhabricatorToken.php',
'PhabricatorTokenController' => 'applications/tokens/controller/PhabricatorTokenController.php',
'PhabricatorTokenCount' => 'applications/tokens/storage/PhabricatorTokenCount.php',
Surface token counts for Pholio Summary: Provide this data so the list view can present it somehow. Test Plan: {F34520} Reviewers: chad Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D5210
2013-03-04 20:47:58 +01:00
'PhabricatorTokenCountQuery' => 'applications/tokens/query/PhabricatorTokenCountQuery.php',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorTokenDAO' => 'applications/tokens/storage/PhabricatorTokenDAO.php',
Fully modularize DestructionEngine Summary: Ref T9979. Convert all DestructionEngine behaviors to extensions. Test Plan: {F1033244} Destroyed an object, verifying: - Herald transcripts were destroyed; - edges were destroyed; - flags were destroyed; - tokens were destroyed; - transactions were destroyed; - worker tasks were cancelled. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14832
2015-12-20 17:11:59 +01:00
'PhabricatorTokenDestructionEngineExtension' => 'applications/tokens/engineextension/PhabricatorTokenDestructionEngineExtension.php',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorTokenGiveController' => 'applications/tokens/controller/PhabricatorTokenGiveController.php',
'PhabricatorTokenGiven' => 'applications/tokens/storage/PhabricatorTokenGiven.php',
'PhabricatorTokenGivenController' => 'applications/tokens/controller/PhabricatorTokenGivenController.php',
'PhabricatorTokenGivenEditor' => 'applications/tokens/editor/PhabricatorTokenGivenEditor.php',
Notify users when an object they created gets awarded a token Summary: - Publish feed/notification. - I think this is too lightweight for an email? - We don't tell them which token right now. Laziness? Or intentional aura of mystery?! - For tasks, notify both author and current owner. - Fixes T2562. Test Plan: {F33187} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2562 Differential Revision: https://secure.phabricator.com/D5007
2013-02-19 02:44:45 +01:00
'PhabricatorTokenGivenFeedStory' => 'applications/tokens/feed/PhabricatorTokenGivenFeedStory.php',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorTokenGivenQuery' => 'applications/tokens/query/PhabricatorTokenGivenQuery.php',
Add basic token leader board functionality. Summary: Implement basic token leader board. No pagination yet. Test Plan: Assign some tasks tokens and check that they are displayed properly. Reviewers: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2689 Differential Revision: https://secure.phabricator.com/D5379
2013-03-22 00:04:29 +01:00
'PhabricatorTokenLeaderController' => 'applications/tokens/controller/PhabricatorTokenLeaderController.php',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorTokenQuery' => 'applications/tokens/query/PhabricatorTokenQuery.php',
'PhabricatorTokenReceiverInterface' => 'applications/tokens/interface/PhabricatorTokenReceiverInterface.php',
Add basic token leader board functionality. Summary: Implement basic token leader board. No pagination yet. Test Plan: Assign some tasks tokens and check that they are displayed properly. Reviewers: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2689 Differential Revision: https://secure.phabricator.com/D5379
2013-03-22 00:04:29 +01:00
'PhabricatorTokenReceiverQuery' => 'applications/tokens/query/PhabricatorTokenReceiverQuery.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorTokenTokenPHIDType' => 'applications/tokens/phid/PhabricatorTokenTokenPHIDType.php',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorTokenUIEventListener' => 'applications/tokens/event/PhabricatorTokenUIEventListener.php',
Implement a basic version of ApplicationEditor in Paste Summary: Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste. This mostly looks and works like ApplicationSearch, and is heavily modeled on it. Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else. This has no functional changes, except: - I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it. - Subscribers are now editable. - Form field order is a little goofy (this will be fixed in a future diff). - Subscribers and projects are now race-resistant. The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits. Test Plan: - Created pastes. - Created pastes via API. - Edited pastes. - Edited every field. - Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4768, T9132 Differential Revision: https://secure.phabricator.com/D14390
2015-11-03 03:58:32 +01:00
'PhabricatorTokenizerEditField' => 'applications/transactions/editfield/PhabricatorTokenizerEditField.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorTokensApplication' => 'applications/tokens/application/PhabricatorTokensApplication.php',
Introduce "Curtain" views, panels, and extensions Summary: This opens up the new action column to have specialized rendering and behavior. Briefly: - Converted applications (right now, only Paste) render a `CurtainView` to build the column content. - This view uses new extensions to build panels (projects, subscribers, tokens). - The panel extension code and rendering can be changed without breaking old stuff. Minor changes: - Token awards now load their tokens, for consistency/simplicity. - Removed the rest of the "fork of" / "forked from" UI in Paste -- I essentially removed these features a while ago, and no one has complained. Test Plan: UI is a bit rough, but works, and it's going to get changed now anyway: {F1160550} {F1160551} Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15414
2016-03-05 23:45:56 +01:00
'PhabricatorTokensCurtainExtension' => 'applications/tokens/engineextension/PhabricatorTokensCurtainExtension.php',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorTokensSettingsPanel' => 'applications/settings/panel/PhabricatorTokensSettingsPanel.php',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorTooltipUIExample' => 'applications/uiexample/examples/PhabricatorTooltipUIExample.php',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorTransactions' => 'applications/transactions/constants/PhabricatorTransactions.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorTransactionsApplication' => 'applications/transactions/application/PhabricatorTransactionsApplication.php',
Fully modularize DestructionEngine Summary: Ref T9979. Convert all DestructionEngine behaviors to extensions. Test Plan: {F1033244} Destroyed an object, verifying: - Herald transcripts were destroyed; - edges were destroyed; - flags were destroyed; - tokens were destroyed; - transactions were destroyed; - worker tasks were cancelled. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14832
2015-12-20 17:11:59 +01:00
'PhabricatorTransactionsDestructionEngineExtension' => 'applications/transactions/engineextension/PhabricatorTransactionsDestructionEngineExtension.php',
Modularize transaction/comment indexing in the FulltextEngine Summary: Ref T9979. This is currently hard-coded but can be done in a generic way. This has one minor behavioral changes: answer text is no longer included in the question text index in Ponder. I'm not planning to accommodate that for now since I don't want to dig this hole any deeper than I already have. This behavior should be different anyway (e.g., index the answer, then show the question in the results or something). Test Plan: - Put a unique word in a Maniphest comment. - Searched for the word. - Found the task. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14837
2015-12-21 16:08:17 +01:00
'PhabricatorTransactionsFulltextEngineExtension' => 'applications/transactions/engineextension/PhabricatorTransactionsFulltextEngineExtension.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorTransformedFile' => 'applications/files/storage/PhabricatorTransformedFile.php',
Add translations config group. Summary: Adds the translations group as per T2255. Currently `translation.override` is `wild` -- it should be changed to dict<string, string> when that exists. Also fixes a small bug from D4326 which caused "class" types to not ever validate. Test Plan: - Looked at the settings. - Successfully saved a setting relating to classes. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4350
2013-01-05 01:22:52 +01:00
'PhabricatorTranslationsConfigOptions' => 'applications/config/option/PhabricatorTranslationsConfigOptions.php',
Implement clock/trigger infrastructure for scheduling actions Summary: Ref T6881. Hopefully, this is the hard part. This adds a new daemon (the "trigger" daemon) which processes triggers, schedules them, and then executes them at the scheduled time. The design is a little complicated, but has these goals: - High resistance to race conditions: only the application writes to the trigger table; only the daemon writes to the event table. We won't lose events if someone saves a meeting at the same time as we're sending a reminder out for it. - Execution guarantees: scheduled events are guaranteed to execute exactly once. - Support for arbitrarily large queues: the daemon will make progress even if there are millions of triggers in queue. The cost to update the queue is proportional to the number of changes in it; the cost to process the queue is proportional to the number of events to execute. - Relatively good observability: you can monitor the state of the trigger queue reasonably well from the web UI. - Modular Infrastructure: this is a very low-level construct that Calendar, Phortune, etc., should be able to build on top of. It doesn't have this stuff yet: - Not very robust to bad actions: a misbehaving trigger can stop the queue fairly easily. This is OK for now since we aren't planning to make it part of any other applications for a while. We do still get execute-exaclty-once, but it might not happen for a long time (until someone goes and fixes the queue), when we could theoretically continue executing other events. - Doesn't start automatically: normal users don't need to run this thing yet so I'm not starting it by default. - Not super well tested: I've vetted the basics but haven't run real workloads through this yet. - No sophisticated tooling: I added some basic stuff but it's missing some pieces we'll have to build sooner or later, e.g. `bin/trigger cancel` or whatever. - Intentionally not realtime: This design puts execution guarantees far above realtime concerns, and will not give you precise event execution at 1-second resolution. I think this is the correct goal to pursue architecturally, and certainly correct for subscriptions and meeting reminders. Events which execute after they have become irrelevant can simply decline to do anything (like a meeting reminder which executes after the meeting is over). In general, the expectation for applications is: - When creating an object (like a calendar event) that needs to trigger a scheduled action, write a trigger (and save the PHID if you plan to update it later). - The daemon will process the event and schedule the action efficiently, in a race-free way. - If you want to move the action, update the trigger and the daemon will take care of it. - Your action will eventually dump a task into the task queue, and the task daemons will actually perform it. Test Plan: Using a test script like this: ``` <?php require_once 'scripts/__init_script__.php'; $trigger = id(new PhabricatorWorkerTrigger()) ->setAction( new PhabricatorLogTriggerAction( array( 'message' => 'test', ))) ->setClock( new PhabricatorMetronomicTriggerClock( array( 'period' => 33, ))) ->save(); var_dump($trigger); ``` ...I queued triggers and ran the daemon: - Verified triggers fire; - verified triggers reschedule; - verified trigger events show up in the web UI; - tried different periods; - added some triggers while the daemon was running; - examined `phd debug` output for anything suspicious. It seems to work in trivial use case, at least. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11419
2015-01-16 21:13:31 +01:00
'PhabricatorTriggerAction' => 'infrastructure/daemon/workers/action/PhabricatorTriggerAction.php',
Implement "trigger clocks" for scheduling events Summary: Ref T6881. This will probably make more sense in a couple of diffs, but this is a class that implements scheduling/recurrence rules. Two rules are provided: - Trigger an event at a specific time (e.g., a meeting reminder notification). - Trigger an event on the Nth day of every month (e.g., a subscription bill). At some point, we'll presumably add a rule for T2896 (maybe using the "RRULE" spec) so you can do stuff like "the second to last thursday of every month", etc., but we don't need that for now. (The "Nth day of every month, or move it back if no such day exists" rule doesn't seem to be expressible with the "RRULE" format, so implementing that wouldn't give us a superset of this. I think this rule is correct and desirable for this purpose, though.) Test Plan: Added and executed unit tests. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11403
2015-01-16 00:57:45 +01:00
'PhabricatorTriggerClock' => 'infrastructure/daemon/workers/clock/PhabricatorTriggerClock.php',
'PhabricatorTriggerClockTestCase' => 'infrastructure/daemon/workers/clock/__tests__/PhabricatorTriggerClockTestCase.php',
Implement clock/trigger infrastructure for scheduling actions Summary: Ref T6881. Hopefully, this is the hard part. This adds a new daemon (the "trigger" daemon) which processes triggers, schedules them, and then executes them at the scheduled time. The design is a little complicated, but has these goals: - High resistance to race conditions: only the application writes to the trigger table; only the daemon writes to the event table. We won't lose events if someone saves a meeting at the same time as we're sending a reminder out for it. - Execution guarantees: scheduled events are guaranteed to execute exactly once. - Support for arbitrarily large queues: the daemon will make progress even if there are millions of triggers in queue. The cost to update the queue is proportional to the number of changes in it; the cost to process the queue is proportional to the number of events to execute. - Relatively good observability: you can monitor the state of the trigger queue reasonably well from the web UI. - Modular Infrastructure: this is a very low-level construct that Calendar, Phortune, etc., should be able to build on top of. It doesn't have this stuff yet: - Not very robust to bad actions: a misbehaving trigger can stop the queue fairly easily. This is OK for now since we aren't planning to make it part of any other applications for a while. We do still get execute-exaclty-once, but it might not happen for a long time (until someone goes and fixes the queue), when we could theoretically continue executing other events. - Doesn't start automatically: normal users don't need to run this thing yet so I'm not starting it by default. - Not super well tested: I've vetted the basics but haven't run real workloads through this yet. - No sophisticated tooling: I added some basic stuff but it's missing some pieces we'll have to build sooner or later, e.g. `bin/trigger cancel` or whatever. - Intentionally not realtime: This design puts execution guarantees far above realtime concerns, and will not give you precise event execution at 1-second resolution. I think this is the correct goal to pursue architecturally, and certainly correct for subscriptions and meeting reminders. Events which execute after they have become irrelevant can simply decline to do anything (like a meeting reminder which executes after the meeting is over). In general, the expectation for applications is: - When creating an object (like a calendar event) that needs to trigger a scheduled action, write a trigger (and save the PHID if you plan to update it later). - The daemon will process the event and schedule the action efficiently, in a race-free way. - If you want to move the action, update the trigger and the daemon will take care of it. - Your action will eventually dump a task into the task queue, and the task daemons will actually perform it. Test Plan: Using a test script like this: ``` <?php require_once 'scripts/__init_script__.php'; $trigger = id(new PhabricatorWorkerTrigger()) ->setAction( new PhabricatorLogTriggerAction( array( 'message' => 'test', ))) ->setClock( new PhabricatorMetronomicTriggerClock( array( 'period' => 33, ))) ->save(); var_dump($trigger); ``` ...I queued triggers and ran the daemon: - Verified triggers fire; - verified triggers reschedule; - verified trigger events show up in the web UI; - tried different periods; - added some triggers while the daemon was running; - examined `phd debug` output for anything suspicious. It seems to work in trivial use case, at least. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11419
2015-01-16 21:13:31 +01:00
'PhabricatorTriggerDaemon' => 'infrastructure/daemon/workers/PhabricatorTriggerDaemon.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorTrivialTestCase' => 'infrastructure/testing/__tests__/PhabricatorTrivialTestCase.php',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorTwitchAuthProvider' => 'applications/auth/provider/PhabricatorTwitchAuthProvider.php',
'PhabricatorTwitterAuthProvider' => 'applications/auth/provider/PhabricatorTwitterAuthProvider.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorTypeaheadApplication' => 'applications/typeahead/application/PhabricatorTypeaheadApplication.php',
Begin modularizing typeahead sources Summary: Ref T4420. This sets up the basics for modular typeahead sources. Basically, the huge `switch()` is just replaced with class-based runtime dispatch. The only clever bit I'm doing here is with `CompositeDatasource`, which pretty much just combines the results from several other datasources. We can use this to implement some of the weird cases where we need multiple types of results, although I think I can entirely eliminate many of them entirely. It also makes top-level implementation simpler, since more logic can go inside the sources. Sources are also application-aware, will be responsible for placeholder text, and have a slightly nicer debug view. Test Plan: {F112859} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D8228
2014-02-14 19:23:25 +01:00
'PhabricatorTypeaheadCompositeDatasource' => 'applications/typeahead/datasource/PhabricatorTypeaheadCompositeDatasource.php',
'PhabricatorTypeaheadDatasource' => 'applications/typeahead/datasource/PhabricatorTypeaheadDatasource.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorTypeaheadDatasourceController' => 'applications/typeahead/controller/PhabricatorTypeaheadDatasourceController.php',
Add contextual typeahead function documentation Summary: Ref T4100. This integration into the "Browse" dialog is probably a little more heavy-handed than we should shoot for. Test Plan: {F377131} {F377132} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12482
2015-04-20 22:43:07 +02:00
'PhabricatorTypeaheadFunctionHelpController' => 'applications/typeahead/controller/PhabricatorTypeaheadFunctionHelpController.php',
Implement viewer() and members(project) typeahead functions Summary: Ref T4100. This is still a bit rough around the edges, but mostly does what we're after. - Implements viewer() and members(...) functions. - The new browse workflow makes these discoverable. Test Plan: {F374201} Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12444
2015-04-17 00:30:41 +02:00
'PhabricatorTypeaheadInvalidTokenException' => 'applications/typeahead/exception/PhabricatorTypeaheadInvalidTokenException.php',
Begin modularizing typeahead sources Summary: Ref T4420. This sets up the basics for modular typeahead sources. Basically, the huge `switch()` is just replaced with class-based runtime dispatch. The only clever bit I'm doing here is with `CompositeDatasource`, which pretty much just combines the results from several other datasources. We can use this to implement some of the weird cases where we need multiple types of results, although I think I can entirely eliminate many of them entirely. It also makes top-level implementation simpler, since more logic can go inside the sources. Sources are also application-aware, will be responsible for placeholder text, and have a slightly nicer debug view. Test Plan: {F112859} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D8228
2014-02-14 19:23:25 +01:00
'PhabricatorTypeaheadModularDatasourceController' => 'applications/typeahead/controller/PhabricatorTypeaheadModularDatasourceController.php',
'PhabricatorTypeaheadMonogramDatasource' => 'applications/typeahead/datasource/PhabricatorTypeaheadMonogramDatasource.php',
Make typeahead results more structured Summary: Get rid of this positional array garbage. Test Plan: Used typeaheads in menu, herald, maniphest, differential, repository/projects. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3116
2012-08-01 21:36:19 +02:00
'PhabricatorTypeaheadResult' => 'applications/typeahead/storage/PhabricatorTypeaheadResult.php',
Begin modularizing typeahead sources Summary: Ref T4420. This sets up the basics for modular typeahead sources. Basically, the huge `switch()` is just replaced with class-based runtime dispatch. The only clever bit I'm doing here is with `CompositeDatasource`, which pretty much just combines the results from several other datasources. We can use this to implement some of the weird cases where we need multiple types of results, although I think I can entirely eliminate many of them entirely. It also makes top-level implementation simpler, since more logic can go inside the sources. Sources are also application-aware, will be responsible for placeholder text, and have a slightly nicer debug view. Test Plan: {F112859} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D8228
2014-02-14 19:23:25 +01:00
'PhabricatorTypeaheadRuntimeCompositeDatasource' => 'applications/typeahead/datasource/PhabricatorTypeaheadRuntimeCompositeDatasource.php',
Make browse view show tokens instead of raw data Summary: Ref T5750. Move the server-side token rendering code to a shared location and use it in the browse view. Test Plan: {F372252} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5750 Differential Revision: https://secure.phabricator.com/D12424
2015-04-15 18:16:26 +02:00
'PhabricatorTypeaheadTokenView' => 'applications/typeahead/view/PhabricatorTypeaheadTokenView.php',
Add UI for choosing header color Summary: See D7731. Fixes T4194. Test Plan: {F88020} Reviewers: chad, btrahan Reviewed By: chad CC: aran, mbishopim3 Maniphest Tasks: T4194 Differential Revision: https://secure.phabricator.com/D7740
2013-12-07 19:46:09 +01:00
'PhabricatorUIConfigOptions' => 'applications/config/option/PhabricatorUIConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUIExample' => 'applications/uiexample/examples/PhabricatorUIExample.php',
'PhabricatorUIExampleRenderController' => 'applications/uiexample/controller/PhabricatorUIExampleRenderController.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorUIExamplesApplication' => 'applications/uiexample/application/PhabricatorUIExamplesApplication.php',
Update Phabricator to work with more modular translations Summary: Ref T7152. Ref T1139. This updates Phabricator so third-party libraries can translate their own stuff. Also: - Hide "All Caps" when not in development mode, since some users have found this a little confusing. - With other changes, adds a "Raw Strings" mode (development mode only). - Add an example silly translation to make sure the serious business flag works. - Add a basic British English translation. - Simplify handling of translation overrides. Test Plan: - Flipped serious business / development on and off and saw silly/development translations drop off. - Switched to "All Caps" and saw all caps. - Switched to Very English, Wow! - Switched to British english and saw "colour". Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152, T1139 Differential Revision: https://secure.phabricator.com/D11747
2015-02-11 22:02:35 +01:00
'PhabricatorUSEnglishTranslation' => 'infrastructure/internationalization/translation/PhabricatorUSEnglishTranslation.php',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorUnitTestContentSource' => 'infrastructure/contentsource/PhabricatorUnitTestContentSource.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUnitsTestCase' => 'view/__tests__/PhabricatorUnitsTestCase.php',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorUnknownContentSource' => 'infrastructure/contentsource/PhabricatorUnknownContentSource.php',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorUnsubscribedFromObjectEdgeType' => 'applications/transactions/edges/PhabricatorUnsubscribedFromObjectEdgeType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUser' => 'applications/people/storage/PhabricatorUser.php',
Add "Title" and "Blurb" to new profile editor Summary: Ref T1703. - Adds "Title". - Adds "Blurb". - Adds `user.fields` config for selecting and reordering. This will get UI in the next patch. Test Plan: {F45689} {F45690} Edited the fields, too. Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6153
2013-06-07 19:22:45 +02:00
'PhabricatorUserBlurbField' => 'applications/people/customfield/PhabricatorUserBlurbField.php',
New People Hovercards Summary: Mimics the Project Hovercards, more custom UI. Test Plan: Hover over person with and without badges, hover over project. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15253
2016-02-11 23:55:44 +01:00
'PhabricatorUserCardView' => 'applications/people/view/PhabricatorUserCardView.php',
Add "Title" and "Blurb" to new profile editor Summary: Ref T1703. - Adds "Title". - Adds "Blurb". - Adds `user.fields` config for selecting and reordering. This will get UI in the next patch. Test Plan: {F45689} {F45690} Edited the fields, too. Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6153
2013-06-07 19:22:45 +02:00
'PhabricatorUserConfigOptions' => 'applications/people/config/PhabricatorUserConfigOptions.php',
Support configuration-driven custom fields Summary: Ref T1702. Ref T3718. There are a couple of things going on here: **PhabricatorCustomFieldList**: I added `PhabricatorCustomFieldList`, which is just a convenience class for dealing with lists of fields. Often, current field code does something like this inline in a Controller: foreach ($fields as $field) { // do some junk } Often, that junk has some slightly subtle implications. Move all of it to `$list->doSomeJunk()` methods (like `appendFieldsToForm()`, `loadFieldsFromStorage()`) to reduce code duplication and prevent errors. This additionally moves an existing list-convenience method there, out of `PhabricatorPropertyListView`. **PhabricatorUserConfiguredCustomFieldStorage**: Adds `PhabricatorUserConfiguredCustomFieldStorage` for storing custom field data (like "ICQ Handle", "Phone Number", "Desk", "Favorite Flower", etc). **Configuration-Driven Custom Fields**: Previously, I was thinking about doing these with interfaces, but as I thought about it more I started to dislike that approach. Instead, I built proxies into `PhabricatorCustomField`. Basically, this means that fields (like a custom, configuration-driven "Favorite Flower" field) can just use some other Field to actually provide their implementation (like a "standard" field which knows how to render text areas). The previous approach would have involed subclasssing the "standard" field and implementing an interface, but that would mean that every application would have at least two "base" fields and generally just seemed bleh as I worked through it. The cost of this approach is that we need a bunch of `proxy` junk in the base class, but that's a one-time cost and I think it simplifies all the implementations and makes them a lot less magical (e.g., all of the custom fields now extend the right base field classes). **Fixed Some Bugs**: Some of this code hadn't really been run yet and had minor bugs. Test Plan: {F54240} {F54241} {F54242} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1702, T1703, T3718 Differential Revision: https://secure.phabricator.com/D6749
2013-08-14 17:10:16 +02:00
'PhabricatorUserConfiguredCustomField' => 'applications/people/customfield/PhabricatorUserConfiguredCustomField.php',
'PhabricatorUserConfiguredCustomFieldStorage' => 'applications/people/storage/PhabricatorUserConfiguredCustomFieldStorage.php',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
'PhabricatorUserCustomField' => 'applications/people/customfield/PhabricatorUserCustomField.php',
Integrate ApplicationSearch with CustomField Summary: Ref T2625. Ref T3794. Ref T418. Ref T1703. This is a more general version of D5278. It expands CustomField support to include real integration with ApplicationSearch. Broadly, custom fields may elect to: - build indicies when objects are updated; - populate ApplicationSearch forms with new controls; - read inputs entered into those controls out of the request; and - apply constraints to search queries. Some utility/helper stuff is provided to make this easier. This part could be cleaner, but seems reasonable for a first cut. In particular, the Query and SearchEngine must manually call all the hooks right now instead of everything happening magically. I think that's fine for the moment; they're pretty easy to get right. Test Plan: I added a new searchable "Company" field to People: {F58229} This also cleaned up the disable/reorder view a little bit: {F58230} As it did before, this field appears on the edit screen: {F58231} However, because it has `search`, it also appears on the search screen: {F58232} When queried, it returns the expected results: {F58233} And the actually good bit of all this is that the query can take advantage of indexes: mysql> explain SELECT * FROM `user` user JOIN `user_customfieldstringindex` `appsearch_0` ON `appsearch_0`.objectPHID = user.phid AND `appsearch_0`.indexKey = 'mk3Ndy476ge6' AND `appsearch_0`.indexValue IN ('phacility') ORDER BY user.id DESC LIMIT 101; +----+-------------+-------------+--------+-------------------+----------+---------+------------------------------------------+------+----------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------------+--------+-------------------+----------+---------+------------------------------------------+------+----------------------------------------------+ | 1 | SIMPLE | appsearch_0 | ref | key_join,key_find | key_find | 232 | const,const | 1 | Using where; Using temporary; Using filesort | | 1 | SIMPLE | user | eq_ref | phid | phid | 194 | phabricator2_user.appsearch_0.objectPHID | 1 | | +----+-------------+-------------+--------+-------------------+----------+---------+------------------------------------------+------+----------------------------------------------+ 2 rows in set (0.00 sec) Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T1703, T2625, T3794 Differential Revision: https://secure.phabricator.com/D6992
2013-09-16 22:44:34 +02:00
'PhabricatorUserCustomFieldNumericIndex' => 'applications/people/storage/PhabricatorUserCustomFieldNumericIndex.php',
'PhabricatorUserCustomFieldStringIndex' => 'applications/people/storage/PhabricatorUserCustomFieldStringIndex.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUserDAO' => 'applications/people/storage/PhabricatorUserDAO.php',
Flesh out ApplicationTransactions/CustomField integration Summary: None of this code is reachable yet. See discussion in D6147. Ref T1703. Provide tighter integration between ApplicationTransactions and CustomField. Basically, I'm just trying to get all the shared stuff into the base implementation. Test Plan: Code not reachable. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6149
2013-06-06 23:53:07 +02:00
'PhabricatorUserEditor' => 'applications/people/editor/PhabricatorUserEditor.php',
Disallow email addresses which will overflow MySQL storage Summary: Via HackerOne. An attacker can bypass `auth.email-domains` by registering with an email like: aaaaa...aaaaa@evil.com@company.com We'll validate the full string, then insert it into the database where it will be truncated, removing the `@company.com` part. Then we'll send an email to `@evil.com`. Instead, reject email addresses which won't fit in the table. `STRICT_ALL_TABLES` stops this attack, I'm going to add a setup warning encouraging it. Test Plan: - Set `auth.email-domains` to `@company.com`. - Registered with `aaa...aaa@evil.com@company.com`. Previously this worked, now it is rejected. - Did a valid registration. - Tried to add `aaa...aaaa@evil.com@company.com` as an email address. Previously this worked, now it is rejected. - Did a valid email add. - Added and executed unit tests. Reviewers: btrahan, arice Reviewed By: arice CC: aran, chad Differential Revision: https://secure.phabricator.com/D8308
2014-02-23 19:19:35 +01:00
'PhabricatorUserEditorTestCase' => 'applications/people/editor/__tests__/PhabricatorUserEditorTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUserEmail' => 'applications/people/storage/PhabricatorUserEmail.php',
Add rough validation on email addresses Summary: Put a very rough filter on what we'll accept as an email address. We can expand this if anyone is actually using local delivery or other weird things. This is mostly to avoid a theoretical case where some input is parsed differently by `PhutilAddressParser` and the actual mail adapter, in some subtle hypothetical way. This should give us only "reasonable" email addresses which parsers would be hard-pressed to trip up on. Test Plan: Added and executed unit tests. Tried to add silly emails. Added valid emails. Reviewers: btrahan, arice Reviewed By: arice CC: arice, chad, aran Differential Revision: https://secure.phabricator.com/D8320
2014-02-24 02:31:46 +01:00
'PhabricatorUserEmailTestCase' => 'applications/people/storage/__tests__/PhabricatorUserEmailTestCase.php',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorUserFulltextEngine' => 'applications/people/search/PhabricatorUserFulltextEngine.php',
Allow users to have profile icons Summary: Ref T10054. This primarily improves aesthetics and consistency for member/wathcher lists in projects. Test Plan: {F1068873} {F1068874} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15103
2016-01-24 14:43:57 +01:00
'PhabricatorUserIconField' => 'applications/people/customfield/PhabricatorUserIconField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUserLog' => 'applications/people/storage/PhabricatorUserLog.php',
Let users review their own account activity logs Summary: Ref T4398. This adds a settings panel for account activity so users can review activity on their own account. Some goals are: - Make it easier for us to develop and support auth and credential information, see T4398. This is the primary driver. - Make it easier for users to understand and review auth and credential information (see T4842 for an example -- this isn't there yet, but builds toward it). - Improve user confidence in security by making logging more apparent and accessible. Minor corresponding changes: - Entering and exiting hisec mode is now logged. - This, sessions, and OAuth authorizations have moved to a new "Sessions and Logs" area, since "Authentication" was getting huge. Test Plan: - Viewed new panel. - Viewed old UI. - Entered/exited hisec and got prompted. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8871
2014-04-28 02:32:09 +02:00
'PhabricatorUserLogView' => 'applications/people/view/PhabricatorUserLogView.php',
Provide formal Users/Projects/Mailable fields for EditEngine Summary: Ref T9132. This allows you to prefill EditEngine forms with stuff like `?subscribers=epriestley`, and we'll figure out what you mean. Test Plan: - Did `/?subscribers=...` with various values (good, bad, mis-capitalized). - Did `/?projects=...` with various values (good, bad, mis-capitalized). - Reviewed documentation. - Reviewed {nav Config > HTTP Parameter Types}. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14404
2015-11-04 19:20:38 +01:00
'PhabricatorUserPHIDResolver' => 'applications/phid/resolver/PhabricatorUserPHIDResolver.php',
Move Settings to a separate directory Summary: We currently have two relatively distinct applications, "People" and "Settings", living in /people/. Move settings to its own directory. This renames a couple of classes but makes no real code changes. Test Plan: Browsed /settings/, changed some settings. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569, T631 Differential Revision: https://secure.phabricator.com/D3256
2012-08-13 21:37:18 +02:00
'PhabricatorUserPreferences' => 'applications/settings/storage/PhabricatorUserPreferences.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUserProfile' => 'applications/people/storage/PhabricatorUserProfile.php',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
'PhabricatorUserProfileEditor' => 'applications/people/editor/PhabricatorUserProfileEditor.php',
'PhabricatorUserRealNameField' => 'applications/people/customfield/PhabricatorUserRealNameField.php',
Move roles and status into properties on profile view Summary: See discussion in D6403. Test Plan: {F49488} Reviewers: chad, btrahan Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6409
2013-07-10 21:34:09 +02:00
'PhabricatorUserRolesField' => 'applications/people/customfield/PhabricatorUserRolesField.php',
Generate expected schemata for User/People tables Summary: Ref T1191. Some notes here: - Drops the old LDAP and OAuth info tables. These were migrated to the ExternalAccount table a very long time ago. - Separates surplus/missing keys from other types of surplus/missing things. In the long run, my plan is to have only two notice levels: - Error: something we can't fix (missing database, table, or column; overlong key). - Warning: something we can fix (surplus anything, missing key, bad column type, bad key columns, bad uniqueness, bad collation or charset). - For now, retaining three levels is helpful in generating all the expected scheamta. Test Plan: - Saw ~200 issues resolve, leaving ~1,300. - Grepped for removed tables. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10580
2014-10-01 16:36:47 +02:00
'PhabricatorUserSchemaSpec' => 'applications/people/storage/PhabricatorUserSchemaSpec.php',
Merge profile "About" into main profile and simplify some custom field stuff Summary: Ref T1703. Drive "user since" with a custom field and make the other fields render into a property list. Users can make their profiles a little more personal/obnoxious now. Also delete a bunch of code. Test Plan: {F49415} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6401
2013-07-10 14:09:59 +02:00
'PhabricatorUserSinceField' => 'applications/people/customfield/PhabricatorUserSinceField.php',
Move roles and status into properties on profile view Summary: See discussion in D6403. Test Plan: {F49488} Reviewers: chad, btrahan Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6409
2013-07-10 21:34:09 +02:00
'PhabricatorUserStatusField' => 'applications/people/customfield/PhabricatorUserStatusField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUserTestCase' => 'applications/people/storage/__tests__/PhabricatorUserTestCase.php',
Add "Title" and "Blurb" to new profile editor Summary: Ref T1703. - Adds "Title". - Adds "Blurb". - Adds `user.fields` config for selecting and reordering. This will get UI in the next patch. Test Plan: {F45689} {F45690} Edited the fields, too. Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6153
2013-06-07 19:22:45 +02:00
'PhabricatorUserTitleField' => 'applications/people/customfield/PhabricatorUserTitleField.php',
Flesh out ApplicationTransactions/CustomField integration Summary: None of this code is reachable yet. See discussion in D6147. Ref T1703. Provide tighter integration between ApplicationTransactions and CustomField. Basically, I'm just trying to get all the shared stuff into the base implementation. Test Plan: Code not reachable. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6149
2013-06-06 23:53:07 +02:00
'PhabricatorUserTransaction' => 'applications/people/storage/PhabricatorUserTransaction.php',
Provide formal Users/Projects/Mailable fields for EditEngine Summary: Ref T9132. This allows you to prefill EditEngine forms with stuff like `?subscribers=epriestley`, and we'll figure out what you mean. Test Plan: - Did `/?subscribers=...` with various values (good, bad, mis-capitalized). - Did `/?projects=...` with various values (good, bad, mis-capitalized). - Reviewed documentation. - Reviewed {nav Config > HTTP Parameter Types}. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14404
2015-11-04 19:20:38 +01:00
'PhabricatorUsersEditField' => 'applications/transactions/editfield/PhabricatorUsersEditField.php',
Move some files around Summary: Move some `PhabricatorPolicyRule` implementations to a subdirectory of the parent application. Test Plan: N/A Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14478
2015-11-16 20:26:13 +01:00
'PhabricatorUsersPolicyRule' => 'applications/people/policyrule/PhabricatorUsersPolicyRule.php',
Fix a broken class reference Summary: This was broken in D13374. Also rearranged a few classes. Test Plan: `arc lint` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13575
2015-07-07 14:53:13 +02:00
'PhabricatorUsersSearchField' => 'applications/people/searchfield/PhabricatorUsersSearchField.php',
Accept and route VCS HTTP requests Summary: Mostly ripped from D7391, with some changes: - Serve repositories at `/diffusion/X/`, with no special `/git/` or `/serve/` URI component. - This requires a little bit of magic, but I got the magic working for Git, Mercurial and SVN, and it seems reasonable. - I think having one URI for everything will make it easier for users to understand. - One downside is that git will clone into `X` by default, but I think that's not a big deal, and we can work around that in the future easily enough. - Accept HTTP requests for Git, SVN and Mercurial repositories. - Auth logic is a little different in order to be more consistent with how other things work. - Instead of AphrontBasicAuthResponse, added "VCSResponse". Mercurial can print strings we send it on the CLI if we're careful, so support that. I did a fair amount of digging and didn't have any luck with git or svn. - Commands we don't know about are assumed to require "Push" capability by default. No actual VCS data going over the wire yet. Test Plan: Ran a bunch of stuff like this: $ hg clone http://local.aphront.com:8080/diffusion/P/ abort: HTTP Error 403: This repository is not available over HTTP. ...and got pretty reasonable-seeming errors in all cases. All this can do is produce errors for now. Reviewers: hach-que, btrahan Reviewed By: hach-que CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7417
2013-10-26 16:56:17 +02:00
'PhabricatorVCSResponse' => 'applications/repository/response/PhabricatorVCSResponse.php',
Implement versioned drafts in EditEngine comment forms Summary: Ref T9132. Fixes T5031. This approximately implements the plan described in T5031#67988: When we recieve a preview request, don't write a draft if the form is from a version of the object before the last update the viewer made. This should fix the race-related (?) zombie draft comments that sometimes show up. I just added a new object for this stuff to make it easier to do stacked actions (or whatever we end up with) a little later, since I needed to do some schema adjustments anyway. Test Plan: - Typed some text. - Reloaded page. - Draft stayed there. - Tried real hard to get it to ghost by submitting stuff in multiple windows and typing a lot and couldn't, although I didn't bother specifically narrowing down the race condition. Reviewers: chad Reviewed By: chad Maniphest Tasks: T5031, T9132 Differential Revision: https://secure.phabricator.com/D14640
2015-12-02 21:25:24 +01:00
'PhabricatorVersionedDraft' => 'applications/draft/storage/PhabricatorVersionedDraft.php',
Update Phabricator to work with more modular translations Summary: Ref T7152. Ref T1139. This updates Phabricator so third-party libraries can translate their own stuff. Also: - Hide "All Caps" when not in development mode, since some users have found this a little confusing. - With other changes, adds a "Raw Strings" mode (development mode only). - Add an example silly translation to make sure the serious business flag works. - Add a basic British English translation. - Simplify handling of translation overrides. Test Plan: - Flipped serious business / development on and off and saw silly/development translations drop off. - Switched to "All Caps" and saw all caps. - Switched to Very English, Wow! - Switched to British english and saw "colour". Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152, T1139 Differential Revision: https://secure.phabricator.com/D11747
2015-02-11 22:02:35 +01:00
'PhabricatorVeryWowEnglishTranslation' => 'infrastructure/internationalization/translation/PhabricatorVeryWowEnglishTranslation.php',
Implement viewer() and members(project) typeahead functions Summary: Ref T4100. This is still a bit rough around the edges, but mostly does what we're after. - Implements viewer() and members(...) functions. - The new browse workflow makes these discoverable. Test Plan: {F374201} Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12444
2015-04-17 00:30:41 +02:00
'PhabricatorViewerDatasource' => 'applications/people/typeahead/PhabricatorViewerDatasource.php',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorWatcherHasObjectEdgeType' => 'applications/transactions/edges/PhabricatorWatcherHasObjectEdgeType.php',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorWebContentSource' => 'infrastructure/contentsource/PhabricatorWebContentSource.php',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorWordPressAuthProvider' => 'applications/auth/provider/PhabricatorWordPressAuthProvider.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorWorker' => 'infrastructure/daemon/workers/PhabricatorWorker.php',
Move completed tasks to an "archive" table and delete them in the GC Summary: Currently, when taskmasters complete a task it is immediately deleted. This prevents us from doing some general things, like: - Supporting the idea of permanent failure (e.g., after N failures just stop trying). - Showing the user how fast taskmasters are completing tasks. - Showing the user how long tasks took to complete. Having better visibility into this is important to Drydock, which builds on the task system. Also, generally buff debug output for task execution. Test Plan: Ran `bin/phd debug taskmaster`. Ran `bin/phd debug garbage`. Queued some tasks via various systems. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3852
2012-10-31 23:22:16 +01:00
'PhabricatorWorkerActiveTask' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerActiveTask.php',
'PhabricatorWorkerArchiveTask' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerArchiveTask.php',
Daemons - introduce PhabricatorWorkerArchiveTaskQuery Summary: Ref T5402. This cleans up some code and sets us up to use this sort of data more easily later. Test Plan: viewed the daemon console from the web and the log of a specific archived daemon. both looked good. for other callsites looked really, really carefully. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5402 Differential Revision: https://secure.phabricator.com/D11042
2014-12-24 00:45:42 +01:00
'PhabricatorWorkerArchiveTaskQuery' => 'infrastructure/daemon/workers/query/PhabricatorWorkerArchiveTaskQuery.php',
Execute Maniphest batch edits in the background with a web UI progress bar Summary: Ref T8637. This does nothing interesting, just has empty scaffolding for a bulk job queue. Basic idea is that when you do something like a batch edit in Maniphest, we: - Create a BulkJob with all the details. - Queue a worker to start the job. - Send you to a progress bar page for the job. In the background: - The "start job" worker creates a ton of Task objects, then queues worker tasks to do the work. In the foreground: - Fancy ajax animates the progress bar and it goes wooosh. In general: - Big jobs actually work. - Jobs get logged. - You can monitor jobs. - Terrible junk like T8637 should be much harder to write and much easier to catch and diagnose. Test Plan: No interesting code/beahavior yet. Clean `storage adjust`. {F526411} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8637 Differential Revision: https://secure.phabricator.com/D13392
2015-06-23 22:36:16 +02:00
'PhabricatorWorkerBulkJob' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerBulkJob.php',
'PhabricatorWorkerBulkJobCreateWorker' => 'infrastructure/daemon/workers/bulk/PhabricatorWorkerBulkJobCreateWorker.php',
'PhabricatorWorkerBulkJobEditor' => 'infrastructure/daemon/workers/editor/PhabricatorWorkerBulkJobEditor.php',
'PhabricatorWorkerBulkJobPHIDType' => 'infrastructure/daemon/workers/phid/PhabricatorWorkerBulkJobPHIDType.php',
'PhabricatorWorkerBulkJobQuery' => 'infrastructure/daemon/workers/query/PhabricatorWorkerBulkJobQuery.php',
'PhabricatorWorkerBulkJobSearchEngine' => 'infrastructure/daemon/workers/query/PhabricatorWorkerBulkJobSearchEngine.php',
'PhabricatorWorkerBulkJobTaskWorker' => 'infrastructure/daemon/workers/bulk/PhabricatorWorkerBulkJobTaskWorker.php',
'PhabricatorWorkerBulkJobTestCase' => 'infrastructure/daemon/workers/__tests__/PhabricatorWorkerBulkJobTestCase.php',
'PhabricatorWorkerBulkJobTransaction' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerBulkJobTransaction.php',
'PhabricatorWorkerBulkJobTransactionQuery' => 'infrastructure/daemon/workers/query/PhabricatorWorkerBulkJobTransactionQuery.php',
'PhabricatorWorkerBulkJobType' => 'infrastructure/daemon/workers/bulk/PhabricatorWorkerBulkJobType.php',
'PhabricatorWorkerBulkJobWorker' => 'infrastructure/daemon/workers/bulk/PhabricatorWorkerBulkJobWorker.php',
'PhabricatorWorkerBulkTask' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerBulkTask.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorWorkerDAO' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerDAO.php',
Fully modularize DestructionEngine Summary: Ref T9979. Convert all DestructionEngine behaviors to extensions. Test Plan: {F1033244} Destroyed an object, verifying: - Herald transcripts were destroyed; - edges were destroyed; - flags were destroyed; - tokens were destroyed; - transactions were destroyed; - worker tasks were cancelled. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14832
2015-12-20 17:11:59 +01:00
'PhabricatorWorkerDestructionEngineExtension' => 'infrastructure/daemon/workers/engineextension/PhabricatorWorkerDestructionEngineExtension.php',
Move task leasing to a dedicated query Summary: This simplifies the fairly thorny logic of leasing tasks a bit. I'm planning to introduce another callsite shortly for Drydock. Test Plan: Ran `bin/phd debug taskmaster`, observed sensible queries and correct operation. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3855
2012-11-01 19:30:16 +01:00
'PhabricatorWorkerLeaseQuery' => 'infrastructure/daemon/workers/query/PhabricatorWorkerLeaseQuery.php',
Move cancel/retry/free task queue actions to bin/worker Summary: Fixes T6702. Ref T3554. Currently, tasks can be cancelled, retried and freed from the web UI by any logged in user. This isn't appreciably dangerous (I can't come up with a way that a user could do anything security-affecting), but I think I probably intended this to be admin-only, but these actions should move to the CLI anyway. Move them to the CLI. Lay some groundwork for some future `bin/worker cancel --class SomeTaskClass`, but don't implement that yet. Test Plan: Used `cancel`, `retry` and `free` from the CLI. Hit all the error/success states. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3554, T6702 Differential Revision: https://secure.phabricator.com/D10939
2014-12-06 18:14:16 +01:00
'PhabricatorWorkerManagementCancelWorkflow' => 'infrastructure/daemon/workers/management/PhabricatorWorkerManagementCancelWorkflow.php',
Send emails for email invites Summary: Ref T7152. Ref T3554. - When an administrator clicks "send invites", queue tasks to send the invites. - Then, actually send the invites. - Make the links in the invites work properly. - Also provide `bin/worker execute` to make debugging one-off workers like this easier. - Clean up some UI, too. Test Plan: We now get as far as the exception which is a placeholder for a registration workflow. {F291213} {F291214} {F291215} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3554, T7152 Differential Revision: https://secure.phabricator.com/D11736
2015-02-11 15:06:09 +01:00
'PhabricatorWorkerManagementExecuteWorkflow' => 'infrastructure/daemon/workers/management/PhabricatorWorkerManagementExecuteWorkflow.php',
Add `bin/worker flood`, for flooding the task queue with work Summary: Ref T6615. Ref T3554. We need better tooling around the queue eventually, so start here. Test Plan: Added 100K+ tasks locally with `bin/worker flood`. Executed some of them with `bin/phd debug taskmaster` (we already have a TestWorker, used in unit tests). Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3554, T6615 Differential Revision: https://secure.phabricator.com/D10894
2014-11-24 20:10:15 +01:00
'PhabricatorWorkerManagementFloodWorkflow' => 'infrastructure/daemon/workers/management/PhabricatorWorkerManagementFloodWorkflow.php',
Move cancel/retry/free task queue actions to bin/worker Summary: Fixes T6702. Ref T3554. Currently, tasks can be cancelled, retried and freed from the web UI by any logged in user. This isn't appreciably dangerous (I can't come up with a way that a user could do anything security-affecting), but I think I probably intended this to be admin-only, but these actions should move to the CLI anyway. Move them to the CLI. Lay some groundwork for some future `bin/worker cancel --class SomeTaskClass`, but don't implement that yet. Test Plan: Used `cancel`, `retry` and `free` from the CLI. Hit all the error/success states. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3554, T6702 Differential Revision: https://secure.phabricator.com/D10939
2014-12-06 18:14:16 +01:00
'PhabricatorWorkerManagementFreeWorkflow' => 'infrastructure/daemon/workers/management/PhabricatorWorkerManagementFreeWorkflow.php',
'PhabricatorWorkerManagementRetryWorkflow' => 'infrastructure/daemon/workers/management/PhabricatorWorkerManagementRetryWorkflow.php',
Add `bin/worker flood`, for flooding the task queue with work Summary: Ref T6615. Ref T3554. We need better tooling around the queue eventually, so start here. Test Plan: Added 100K+ tasks locally with `bin/worker flood`. Executed some of them with `bin/phd debug taskmaster` (we already have a TestWorker, used in unit tests). Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3554, T6615 Differential Revision: https://secure.phabricator.com/D10894
2014-11-24 20:10:15 +01:00
'PhabricatorWorkerManagementWorkflow' => 'infrastructure/daemon/workers/management/PhabricatorWorkerManagementWorkflow.php',
Factor out task execution and formalize permanent failures Summary: - Clean up a TODO about permanent failures. - Clean up a TODO about failing tasks after too many retries. - Clean up a TODO about testing for bad leases. - Make the lease/retry implementation more flexible and natural. - Make completely bogus tasks fail permanently. - Make PhabricatorMetaMTAWorker use new `getWaitBeforeRetry()` (as intended), not hackily implement logic in `getRequiredLeaseTime()`. - Document worker hooks for failures and retries. - Provide coverage on everything. Test Plan: Ran unit tests. Ran `bin/phd debug taskmaster`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3859
2012-11-01 19:30:23 +01:00
'PhabricatorWorkerPermanentFailureException' => 'infrastructure/daemon/workers/exception/PhabricatorWorkerPermanentFailureException.php',
Execute Maniphest batch edits in the background with a web UI progress bar Summary: Ref T8637. This does nothing interesting, just has empty scaffolding for a bulk job queue. Basic idea is that when you do something like a batch edit in Maniphest, we: - Create a BulkJob with all the details. - Queue a worker to start the job. - Send you to a progress bar page for the job. In the background: - The "start job" worker creates a ton of Task objects, then queues worker tasks to do the work. In the foreground: - Fancy ajax animates the progress bar and it goes wooosh. In general: - Big jobs actually work. - Jobs get logged. - You can monitor jobs. - Terrible junk like T8637 should be much harder to write and much easier to catch and diagnose. Test Plan: No interesting code/beahavior yet. Clean `storage adjust`. {F526411} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8637 Differential Revision: https://secure.phabricator.com/D13392
2015-06-23 22:36:16 +02:00
'PhabricatorWorkerSchemaSpec' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerSchemaSpec.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorWorkerTask' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerTask.php',
'PhabricatorWorkerTaskData' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerTaskData.php',
'PhabricatorWorkerTaskDetailController' => 'applications/daemon/controller/PhabricatorWorkerTaskDetailController.php',
Factor out task execution and formalize permanent failures Summary: - Clean up a TODO about permanent failures. - Clean up a TODO about failing tasks after too many retries. - Clean up a TODO about testing for bad leases. - Make the lease/retry implementation more flexible and natural. - Make completely bogus tasks fail permanently. - Make PhabricatorMetaMTAWorker use new `getWaitBeforeRetry()` (as intended), not hackily implement logic in `getRequiredLeaseTime()`. - Document worker hooks for failures and retries. - Provide coverage on everything. Test Plan: Ran unit tests. Ran `bin/phd debug taskmaster`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3859
2012-11-01 19:30:23 +01:00
'PhabricatorWorkerTestCase' => 'infrastructure/daemon/workers/__tests__/PhabricatorWorkerTestCase.php',
Implement clock/trigger infrastructure for scheduling actions Summary: Ref T6881. Hopefully, this is the hard part. This adds a new daemon (the "trigger" daemon) which processes triggers, schedules them, and then executes them at the scheduled time. The design is a little complicated, but has these goals: - High resistance to race conditions: only the application writes to the trigger table; only the daemon writes to the event table. We won't lose events if someone saves a meeting at the same time as we're sending a reminder out for it. - Execution guarantees: scheduled events are guaranteed to execute exactly once. - Support for arbitrarily large queues: the daemon will make progress even if there are millions of triggers in queue. The cost to update the queue is proportional to the number of changes in it; the cost to process the queue is proportional to the number of events to execute. - Relatively good observability: you can monitor the state of the trigger queue reasonably well from the web UI. - Modular Infrastructure: this is a very low-level construct that Calendar, Phortune, etc., should be able to build on top of. It doesn't have this stuff yet: - Not very robust to bad actions: a misbehaving trigger can stop the queue fairly easily. This is OK for now since we aren't planning to make it part of any other applications for a while. We do still get execute-exaclty-once, but it might not happen for a long time (until someone goes and fixes the queue), when we could theoretically continue executing other events. - Doesn't start automatically: normal users don't need to run this thing yet so I'm not starting it by default. - Not super well tested: I've vetted the basics but haven't run real workloads through this yet. - No sophisticated tooling: I added some basic stuff but it's missing some pieces we'll have to build sooner or later, e.g. `bin/trigger cancel` or whatever. - Intentionally not realtime: This design puts execution guarantees far above realtime concerns, and will not give you precise event execution at 1-second resolution. I think this is the correct goal to pursue architecturally, and certainly correct for subscriptions and meeting reminders. Events which execute after they have become irrelevant can simply decline to do anything (like a meeting reminder which executes after the meeting is over). In general, the expectation for applications is: - When creating an object (like a calendar event) that needs to trigger a scheduled action, write a trigger (and save the PHID if you plan to update it later). - The daemon will process the event and schedule the action efficiently, in a race-free way. - If you want to move the action, update the trigger and the daemon will take care of it. - Your action will eventually dump a task into the task queue, and the task daemons will actually perform it. Test Plan: Using a test script like this: ``` <?php require_once 'scripts/__init_script__.php'; $trigger = id(new PhabricatorWorkerTrigger()) ->setAction( new PhabricatorLogTriggerAction( array( 'message' => 'test', ))) ->setClock( new PhabricatorMetronomicTriggerClock( array( 'period' => 33, ))) ->save(); var_dump($trigger); ``` ...I queued triggers and ran the daemon: - Verified triggers fire; - verified triggers reschedule; - verified trigger events show up in the web UI; - tried different periods; - added some triggers while the daemon was running; - examined `phd debug` output for anything suspicious. It seems to work in trivial use case, at least. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11419
2015-01-16 21:13:31 +01:00
'PhabricatorWorkerTrigger' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerTrigger.php',
'PhabricatorWorkerTriggerEvent' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerTriggerEvent.php',
Add bin/trigger, for testing event triggers Summary: Ref T6881. This makes it easier to fire a trigger and make sure it works properly. You can use the `--now` flag to travel through time, and test scheduling conditions with `--last` and `--next`. It will tell you when the trigger would reschedule. Better than waiting 24 hours to see if things work. Test Plan: Fired some backups, got useful output which made me think my code probably works correctly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11438
2015-01-20 20:31:32 +01:00
'PhabricatorWorkerTriggerManagementFireWorkflow' => 'infrastructure/daemon/workers/management/PhabricatorWorkerTriggerManagementFireWorkflow.php',
'PhabricatorWorkerTriggerManagementWorkflow' => 'infrastructure/daemon/workers/management/PhabricatorWorkerTriggerManagementWorkflow.php',
Implement clock/trigger infrastructure for scheduling actions Summary: Ref T6881. Hopefully, this is the hard part. This adds a new daemon (the "trigger" daemon) which processes triggers, schedules them, and then executes them at the scheduled time. The design is a little complicated, but has these goals: - High resistance to race conditions: only the application writes to the trigger table; only the daemon writes to the event table. We won't lose events if someone saves a meeting at the same time as we're sending a reminder out for it. - Execution guarantees: scheduled events are guaranteed to execute exactly once. - Support for arbitrarily large queues: the daemon will make progress even if there are millions of triggers in queue. The cost to update the queue is proportional to the number of changes in it; the cost to process the queue is proportional to the number of events to execute. - Relatively good observability: you can monitor the state of the trigger queue reasonably well from the web UI. - Modular Infrastructure: this is a very low-level construct that Calendar, Phortune, etc., should be able to build on top of. It doesn't have this stuff yet: - Not very robust to bad actions: a misbehaving trigger can stop the queue fairly easily. This is OK for now since we aren't planning to make it part of any other applications for a while. We do still get execute-exaclty-once, but it might not happen for a long time (until someone goes and fixes the queue), when we could theoretically continue executing other events. - Doesn't start automatically: normal users don't need to run this thing yet so I'm not starting it by default. - Not super well tested: I've vetted the basics but haven't run real workloads through this yet. - No sophisticated tooling: I added some basic stuff but it's missing some pieces we'll have to build sooner or later, e.g. `bin/trigger cancel` or whatever. - Intentionally not realtime: This design puts execution guarantees far above realtime concerns, and will not give you precise event execution at 1-second resolution. I think this is the correct goal to pursue architecturally, and certainly correct for subscriptions and meeting reminders. Events which execute after they have become irrelevant can simply decline to do anything (like a meeting reminder which executes after the meeting is over). In general, the expectation for applications is: - When creating an object (like a calendar event) that needs to trigger a scheduled action, write a trigger (and save the PHID if you plan to update it later). - The daemon will process the event and schedule the action efficiently, in a race-free way. - If you want to move the action, update the trigger and the daemon will take care of it. - Your action will eventually dump a task into the task queue, and the task daemons will actually perform it. Test Plan: Using a test script like this: ``` <?php require_once 'scripts/__init_script__.php'; $trigger = id(new PhabricatorWorkerTrigger()) ->setAction( new PhabricatorLogTriggerAction( array( 'message' => 'test', ))) ->setClock( new PhabricatorMetronomicTriggerClock( array( 'period' => 33, ))) ->save(); var_dump($trigger); ``` ...I queued triggers and ran the daemon: - Verified triggers fire; - verified triggers reschedule; - verified trigger events show up in the web UI; - tried different periods; - added some triggers while the daemon was running; - examined `phd debug` output for anything suspicious. It seems to work in trivial use case, at least. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11419
2015-01-16 21:13:31 +01:00
'PhabricatorWorkerTriggerPHIDType' => 'infrastructure/daemon/workers/phid/PhabricatorWorkerTriggerPHIDType.php',
'PhabricatorWorkerTriggerQuery' => 'infrastructure/daemon/workers/query/PhabricatorWorkerTriggerQuery.php',
Allow tasks to yield to other tasks Summary: For Harbormaster tasks which want to poll or wait, this lets them say "try again a little later" without having to sleep and hold a queue slot. This is basically the same as failing, except that we don't increment the failure counter. Instead, we just set the current lease to the correct length and then exit. The task will be retried after the lease expires. Test Plan: Using both `bin/harbormaster` and `phd debug taskmaster`, ran a lot of waiting tasks through the queue, faking them to either yield or not yield in a controlled manner. The queue responded as expected, yielding tasks appropraitely and retrying them later. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8792
2014-04-16 22:02:12 +02:00
'PhabricatorWorkerYieldException' => 'infrastructure/daemon/workers/exception/PhabricatorWorkerYieldException.php',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorWorkingCopyDiscoveryTestCase' => 'applications/repository/engine/__tests__/PhabricatorWorkingCopyDiscoveryTestCase.php',
Make repository pulls testable Summary: Ref T2784. This moves us toward being able to test the background and Conduit pipelines for repositories. In particular: - Separate the logic for pulling repositories (`git pull`, `hg pull`) out of `PhabricatorRepositoryPullLocalDaemon` and put it in `PhabricatorRepositoryPullEngine`. This allows repositories to be pulled directly without invoking the daemons. - Add tests for the engine, including a future-looking base test case. - Add basic `PhutilDirectoryFixture`-based repositories. Next steps: # Do the same for repo discovery. # Then we can start writing tests against specific Conduit methods. Test Plan: Ran unit tests. Ran `bin/repository pull` on SVN, Hg and Git repositories. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran, nh Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5904
2013-05-13 04:05:52 +02:00
'PhabricatorWorkingCopyPullTestCase' => 'applications/repository/engine/__tests__/PhabricatorWorkingCopyPullTestCase.php',
'PhabricatorWorkingCopyTestCase' => 'applications/repository/engine/__tests__/PhabricatorWorkingCopyTestCase.php',
Rename XHPAST database Summary: Rename the XHPAST database from `{$NAMESPACE}_xpastview` to `{$NAMESPACE}_xhpast`. Test Plan: Ran `./bin/storage --namespace test upgrade --no-quickstart`. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14442
2015-11-14 11:41:27 +01:00
'PhabricatorXHPASTDAO' => 'applications/phpast/storage/PhabricatorXHPASTDAO.php',
'PhabricatorXHPASTParseTree' => 'applications/phpast/storage/PhabricatorXHPASTParseTree.php',
Move Conduit methods inside applications Test Plan: /conduit/ /conduit/method/arcanist.projectinfo/ Call method $ echo '{}' | arc call-conduit user.whoami Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4268
2012-12-21 21:12:26 +01:00
'PhabricatorXHPASTViewController' => 'applications/phpast/controller/PhabricatorXHPASTViewController.php',
'PhabricatorXHPASTViewFrameController' => 'applications/phpast/controller/PhabricatorXHPASTViewFrameController.php',
'PhabricatorXHPASTViewFramesetController' => 'applications/phpast/controller/PhabricatorXHPASTViewFramesetController.php',
'PhabricatorXHPASTViewInputController' => 'applications/phpast/controller/PhabricatorXHPASTViewInputController.php',
'PhabricatorXHPASTViewPanelController' => 'applications/phpast/controller/PhabricatorXHPASTViewPanelController.php',
'PhabricatorXHPASTViewRunController' => 'applications/phpast/controller/PhabricatorXHPASTViewRunController.php',
'PhabricatorXHPASTViewStreamController' => 'applications/phpast/controller/PhabricatorXHPASTViewStreamController.php',
'PhabricatorXHPASTViewTreeController' => 'applications/phpast/controller/PhabricatorXHPASTViewTreeController.php',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorXHProfApplication' => 'applications/xhprof/application/PhabricatorXHProfApplication.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorXHProfController' => 'applications/xhprof/controller/PhabricatorXHProfController.php',
Do sampled profiling of requests Summary: People have occasionally complained about phabricator being slow. We have the access log to look at to see when slowness happens, but it doesn't tell us much about why it happened. Since it's usually a sporadic issue that's reported, it's hard to reproduce and then profile. This change will allow us to collect sampled profiles so we can look at them when slowness occurs. Test Plan: checking that sampling works correctly: - set rate to 0; do several page loads; check no new entries in table - set rate to 1; check that there's a new row in the table for each page load - set rate to 10; check that some requests write to table and some don't check new ui for samples: - load /xhprof/list/all/, see a list with a lot of samples - load /xhprof/list/sampled/, see only sampled runs - load /xhprof/list/manual/, see only non-sampled runs - load /xhprof/list/my-runs/, se only my manual runs Reviewers: vrana, epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3458
2012-08-25 00:14:38 +02:00
'PhabricatorXHProfDAO' => 'applications/xhprof/storage/PhabricatorXHProfDAO.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorXHProfProfileController' => 'applications/xhprof/controller/PhabricatorXHProfProfileController.php',
'PhabricatorXHProfProfileSymbolView' => 'applications/xhprof/view/PhabricatorXHProfProfileSymbolView.php',
'PhabricatorXHProfProfileTopLevelView' => 'applications/xhprof/view/PhabricatorXHProfProfileTopLevelView.php',
'PhabricatorXHProfProfileView' => 'applications/xhprof/view/PhabricatorXHProfProfileView.php',
Do sampled profiling of requests Summary: People have occasionally complained about phabricator being slow. We have the access log to look at to see when slowness happens, but it doesn't tell us much about why it happened. Since it's usually a sporadic issue that's reported, it's hard to reproduce and then profile. This change will allow us to collect sampled profiles so we can look at them when slowness occurs. Test Plan: checking that sampling works correctly: - set rate to 0; do several page loads; check no new entries in table - set rate to 1; check that there's a new row in the table for each page load - set rate to 10; check that some requests write to table and some don't check new ui for samples: - load /xhprof/list/all/, see a list with a lot of samples - load /xhprof/list/sampled/, see only sampled runs - load /xhprof/list/manual/, see only non-sampled runs - load /xhprof/list/my-runs/, se only my manual runs Reviewers: vrana, epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3458
2012-08-25 00:14:38 +02:00
'PhabricatorXHProfSample' => 'applications/xhprof/storage/PhabricatorXHProfSample.php',
'PhabricatorXHProfSampleListController' => 'applications/xhprof/controller/PhabricatorXHProfSampleListController.php',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhabricatorYoutubeRemarkupRule' => 'infrastructure/markup/rule/PhabricatorYoutubeRemarkupRule.php',
Phame - introduce blogs Summary: blogs are collections of posts. a blog also has metadata like a name, description and "bloggers" that can edit the metadata of the blog and contribute posts. changes include the post edit flow where bloggers can now select which blogs to publish to. also made various small tweaks throughout the UI to make things sensical and clean as the concept of blogs is introduced. there's edges powering this stuff. bloggers <=> blogs and posts <=> blogs in particular. Test Plan: made blogs, deleted blogs, tried to make blogs with no bloggers. all went well. verified ui to publish only showed up for public posts, published posts to blogs, un-published posts to blogs, re-published posts to blogs, deleted posts and verified they disappeared from blogs. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3003
2012-07-19 18:03:10 +02:00
'PhameBlog' => 'applications/phame/storage/PhameBlog.php',
Allow Phame Blogs to be archived instead of deleted Summary: Removes "delete" and uses "archive/activate" instead for Phame Blogs. Ref T9756 Test Plan: Archive a blog, see in search, activate blog, see in other search. Reviewers: epriestley Reviewed By: epriestley Subscribers: joshuaspence, Korvin Maniphest Tasks: T9756 Differential Revision: https://secure.phabricator.com/D14465
2015-11-21 17:51:07 +01:00
'PhameBlogArchiveController' => 'applications/phame/controller/blog/PhameBlogArchiveController.php',
Modernize Phame Summary: Updates Phame for new modern methods. Test Plan: New blog, edit blog, new post, edit post, publish post. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14419
2015-11-05 23:53:24 +01:00
'PhameBlogController' => 'applications/phame/controller/blog/PhameBlogController.php',
Add Can Create Policy Capability to Phame Blogs Summary: Larger (open) installs may want to restrict Blog to formal entities, like with Phriction. Test Plan: Set policy to administrators, have notchad try to create a blog. See error. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14433
2015-11-07 20:57:34 +01:00
'PhameBlogCreateCapability' => 'applications/phame/capability/PhameBlogCreateCapability.php',
Add a phame.blog.edit Conduit API endpoint Summary: Ref T9897. Test Plan: Used API to make a few changes to a blog. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14899
2015-12-28 12:57:03 +01:00
'PhameBlogEditConduitAPIMethod' => 'applications/phame/conduit/PhameBlogEditConduitAPIMethod.php',
Phame - introduce blogs Summary: blogs are collections of posts. a blog also has metadata like a name, description and "bloggers" that can edit the metadata of the blog and contribute posts. changes include the post edit flow where bloggers can now select which blogs to publish to. also made various small tweaks throughout the UI to make things sensical and clean as the concept of blogs is introduced. there's edges powering this stuff. bloggers <=> blogs and posts <=> blogs in particular. Test Plan: made blogs, deleted blogs, tried to make blogs with no bloggers. all went well. verified ui to publish only showed up for public posts, published posts to blogs, un-published posts to blogs, re-published posts to blogs, deleted posts and verified they disappeared from blogs. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3003
2012-07-19 18:03:10 +02:00
'PhameBlogEditController' => 'applications/phame/controller/blog/PhameBlogEditController.php',
Give PhameBlog an EditEngine Summary: This seems to work, but I couldn't figure out how to pass over a Caption for a text field. Test Plan: New blog, Edit blog. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14770
2015-12-16 20:56:41 +01:00
'PhameBlogEditEngine' => 'applications/phame/editor/PhameBlogEditEngine.php',
Phame - move over blog create + edit to transactions + editor Summary: Ref T7626. Modernizes the code a bit here so we can eventually make progress on T7626 and other stuff. Test Plan: made a blog, edited a blog, made errors - stuff looked good Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7626 Differential Revision: https://secure.phabricator.com/D12849
2015-05-15 02:05:58 +02:00
'PhameBlogEditor' => 'applications/phame/editor/PhameBlogEditor.php',
Add Atom export to Phame Summary: There's no link to this yet, I'll add it to some skin. Fixes T2272. Test Plan: http://validator.w3.org/appc/ Reviewers: btrahan, epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2272 Differential Revision: https://secure.phabricator.com/D4366
2013-01-09 04:53:34 +01:00
'PhameBlogFeedController' => 'applications/phame/controller/blog/PhameBlogFeedController.php',
Modernize blog UI Summary: Cleans up some of the mess I made in D3694. Basically: - All blogs have an "internal" view with posts that uses mobile-friendly UIs, etc., so we don't have to do as much work with skins -- they just have to look pretty. - Blogs now have a separate "live" view that we use to handle domains / skins. - Simplified some views and use IDs in some URLs for consistency. - Delete a bunch of edge/blogger/multi-blog code that's now obsolete. Test Plan: Will attach screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3695
2012-10-15 23:50:12 +02:00
'PhameBlogListController' => 'applications/phame/controller/blog/PhameBlogListController.php',
Add "Blogs" section to PhameHome Summary: Ref T9927. Adds a "Blogs" section to PhameHome. Removes "New Post" Controller. Adds flipped layout for PHUITwoColumnView Test Plan: Test PhameHome, Ponder, New Post, etc. Mobile and Desktop states. {F1022080} Reviewers: epriestley Reviewed By: epriestley Subscribers: johnny-bit, Korvin Maniphest Tasks: T9927 Differential Revision: https://secure.phabricator.com/D14744
2015-12-12 02:23:09 +01:00
'PhameBlogListView' => 'applications/phame/view/PhameBlogListView.php',
Update PhameBlogView UI Summary: Creates a new PhameBlogView which is more of a blog landing page with the latest posts. Management has moved to PhameManageController with a new timeline. Test Plan: Edit Blog, Publish, Subscribe, view posts. {F1008400} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9360 Differential Revision: https://secure.phabricator.com/D14608
2015-11-30 17:47:46 +01:00
'PhameBlogManageController' => 'applications/phame/controller/blog/PhameBlogManageController.php',
Add Profile Images to PhameBlog Summary: Will use these more in the upcoming unbeta design of PhameBlog, likely. Also curious how this works. Test Plan: Add an image to a blog, remove an image from a blog. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14587
2015-11-28 21:42:36 +01:00
'PhameBlogProfilePictureController' => 'applications/phame/controller/blog/PhameBlogProfilePictureController.php',
Phame - introduce blogs Summary: blogs are collections of posts. a blog also has metadata like a name, description and "bloggers" that can edit the metadata of the blog and contribute posts. changes include the post edit flow where bloggers can now select which blogs to publish to. also made various small tweaks throughout the UI to make things sensical and clean as the concept of blogs is introduced. there's edges powering this stuff. bloggers <=> blogs and posts <=> blogs in particular. Test Plan: made blogs, deleted blogs, tried to make blogs with no bloggers. all went well. verified ui to publish only showed up for public posts, published posts to blogs, un-published posts to blogs, re-published posts to blogs, deleted posts and verified they disappeared from blogs. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3003
2012-07-19 18:03:10 +02:00
'PhameBlogQuery' => 'applications/phame/query/PhameBlogQuery.php',
Add mail support to PhameBlog Summary: Add some mailkeys, allow feed stories to be published. Test Plan: New Blog, Edit Blog Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14434
2015-11-08 16:50:01 +01:00
'PhameBlogReplyHandler' => 'applications/phame/mail/PhameBlogReplyHandler.php',
Add phame.blog.search Conduit API endpoint Summary: Ref T9897. Adds basic blog query support. Test Plan: Ran some queries. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14900
2015-12-28 12:58:43 +01:00
'PhameBlogSearchConduitAPIMethod' => 'applications/phame/conduit/PhameBlogSearchConduitAPIMethod.php',
PhameBlogSearchEngine Summary: Modernize PhameBlogQuery, create a skeleton Search Engine. Test Plan: Built a dashboard for testing, verify view pages still work. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T6269 Differential Revision: https://secure.phabricator.com/D13670
2015-07-22 22:31:47 +02:00
'PhameBlogSearchEngine' => 'applications/phame/query/PhameBlogSearchEngine.php',
Modularize Aphront "sites" Summary: Fixes T5702. The path here is long and windy: - I want to move `blog.phacility.com` to the new `secure` host. - That host has `security.require-https` set, which I want to keep set (before, this was handled in a sort of hacky way at the nginx/preamble level, but I've cleaned up everything else now). - Currently, that setting forces blogs to HTTPS too, which won't work. - To let blogs be individually configurable, we need to either modularize site config or make things hackier. - Modularize rather than increasing hackiness. - Also add a little "modules" panel in Config. See T6859. This feels like a reasonable middle ground between putting this stuff in Applications and burying it in `bin/somewhere`. Test Plan: - Visited normal site. - Visited phame on-domain site. - Visited phame off-domain site. - Viewed static resources. {F561897} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D13474
2015-06-29 23:04:48 +02:00
'PhameBlogSite' => 'applications/phame/site/PhameBlogSite.php',
Phame - move over blog create + edit to transactions + editor Summary: Ref T7626. Modernizes the code a bit here so we can eventually make progress on T7626 and other stuff. Test Plan: made a blog, edited a blog, made errors - stuff looked good Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7626 Differential Revision: https://secure.phabricator.com/D12849
2015-05-15 02:05:58 +02:00
'PhameBlogTransaction' => 'applications/phame/storage/PhameBlogTransaction.php',
Add mail support to PhameBlog Summary: Add some mailkeys, allow feed stories to be published. Test Plan: New Blog, Edit Blog Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14434
2015-11-08 16:50:01 +01:00
'PhameBlogTransactionQuery' => 'applications/phame/query/PhameBlogTransactionQuery.php',
Phame - introduce blogs Summary: blogs are collections of posts. a blog also has metadata like a name, description and "bloggers" that can edit the metadata of the blog and contribute posts. changes include the post edit flow where bloggers can now select which blogs to publish to. also made various small tweaks throughout the UI to make things sensical and clean as the concept of blogs is introduced. there's edges powering this stuff. bloggers <=> blogs and posts <=> blogs in particular. Test Plan: made blogs, deleted blogs, tried to make blogs with no bloggers. all went well. verified ui to publish only showed up for public posts, published posts to blogs, un-published posts to blogs, re-published posts to blogs, deleted posts and verified they disappeared from blogs. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3003
2012-07-19 18:03:10 +02:00
'PhameBlogViewController' => 'applications/phame/controller/blog/PhameBlogViewController.php',
Add a transaction for PhamePost visibility Summary: Adds ability to set visibility when authoring a Post. New default is "Visible". If you write a post and save it as a Draft, and later click publish, a feed story and mail will go out. Test Plan: Write a new Post, see feed story and get email. Write a new Draft, get nothing. Click Publish, see story and email. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9360 Differential Revision: https://secure.phabricator.com/D14429
2015-11-07 15:52:42 +01:00
'PhameConstants' => 'applications/phame/constants/PhameConstants.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhameController' => 'applications/phame/controller/PhameController.php',
'PhameDAO' => 'applications/phame/storage/PhameDAO.php',
Separate out PhameDescriptionView Summary: Make this function re-usable in other views. Ref T9897 Test Plan: View a blog, see the same information Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14658
2015-12-03 23:28:44 +01:00
'PhameDescriptionView' => 'applications/phame/view/PhameDescriptionView.php',
Add Drafts to PhameHome Summary: Adds a list of your drafts. Fixes T9927y Test Plan: Load up home, see my drafts. Fake 0 drafts, see fallback message. {F1023139} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14756
2015-12-12 22:19:21 +01:00
'PhameDraftListView' => 'applications/phame/view/PhameDraftListView.php',
Add a homepage for Phame Summary: Sends `/phame/` to PhameHomeController, which is all published posts. Still some rough edges to work out for new posts, new blogs, but I think this is the right direction. Test Plan: go to Phame, see most recent posts, no drafts. click on find posts, see post list, click on find blogs, see blogs. {F1008800} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9742 Differential Revision: https://secure.phabricator.com/D14618
2015-12-01 01:25:59 +01:00
'PhameHomeController' => 'applications/phame/controller/PhameHomeController.php',
Remove skins from Phame Summary: Ref T9897. Purge a bunch of stuff: - Remove skins. - Remove all custom sites for skin resources. - Remove "framed", "notlive", "preview", separate "live" controllers (see below). - Merge "publish" and "unpublish" controllers into one. New behavior: - Blogs and posts have three views: - "View": Internal view URI, which is a normal detail page. - "Internal Live": Internal view URI which is a little prettier. - "External Live": External view URI for an external domain. Right now, the differences are pretty minor (basically, different crumbs/chrome). This mostly gives us room to put some milder flavor of skins back later (photography or more "presentation" elements, for example). This removes 9 million lines of code so I probably missed a couple of things, but I think it's like 95% of the way there. Test Plan: Here are some examples of what the "view", "internal" and "external" views look like for blogs (posts are similar): "View": Unchanged {F1021634} "Internal": No chrome or footer. Still write actions (edit, post commments). Has crumbs to get back into Phame. {F1021635} "External": No chrome or footer. No write actions. No Phabricator crumbs. No policy/status information. {F1021638} I figure we'll probably tweak these a bit to figure out what makes sense (like: maybe no actions on "internal, live"? and "external, live" probably needs a way to set a root "Company >" crumb?) but that they're reasonable-ish as a first cut? Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14740
2015-12-11 16:07:45 +01:00
'PhameLiveController' => 'applications/phame/controller/PhameLiveController.php',
Add Next and Previous UI to PhamePostView Summary: Creates a new next/previous UI for PhamePosts, and adds a setFoot to PHUIDocumentViewPro for future use in other apps. Test Plan: Test first, next, last posts on Phame in mobile, desktop, and tablet breakpoints. {F1050152} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14919
2015-12-31 22:08:33 +01:00
'PhameNextPostView' => 'applications/phame/view/PhameNextPostView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhamePost' => 'applications/phame/storage/PhamePost.php',
Add comments to internal Phame Posts Summary: Adds commenting to Phame Posts, also testing a new "document comment style". Unsure about it but Phame is a prototype so good place to explore. Test Plan: Leave some comments, see some comments, test show/hide. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9746 Differential Revision: https://secure.phabricator.com/D14451
2015-11-10 06:20:35 +01:00
'PhamePostCommentController' => 'applications/phame/controller/post/PhamePostCommentController.php',
Modernize Phame Summary: Updates Phame for new modern methods. Test Plan: New blog, edit blog, new post, edit post, publish post. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14419
2015-11-05 23:53:24 +01:00
'PhamePostController' => 'applications/phame/controller/post/PhamePostController.php',
Provide phame.post.edit Conduit API method Summary: Ref T9897. This one is a little more involved because of how getting a post on a blog works. I also changed moving posts to be a real transaction (which shows up in history, now). Test Plan: Created posts from web UI and conduit. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14902
2015-12-28 14:46:22 +01:00
'PhamePostEditConduitAPIMethod' => 'applications/phame/conduit/PhamePostEditConduitAPIMethod.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhamePostEditController' => 'applications/phame/controller/post/PhamePostEditController.php',
Update PhamePost to EditEngine Summary: Allows create and edit workflows through EditEngine. Not sure I did the 'blog' stuff correct. Test Plan: Create a new post, edit a post, move a post. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14802
2015-12-28 02:38:25 +01:00
'PhamePostEditEngine' => 'applications/phame/editor/PhamePostEditEngine.php',
Phame - move over post creation and edit to use an editor Summary: This adds the bare minimum transaction set for editing posts. Fixes T7626 because now files will be correctly attached to phame posts on subsequent edits. Future work here should be adding transaction types like `TYPE_BLOG` for when posts are moved between blogs, `TYPE_VISIBILITY` for when posts are moved to published, etc. Nothing too tricky there but keeping this diff relatively small seems prudent. Test Plan: made posts successfully. also made errors like no title, no phame title, and duplicate phame title and got correct errors. added a file to a post and verified file has phame post in "attached" tab, which should fix T7626. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7626 Differential Revision: https://secure.phabricator.com/D12864
2015-05-15 22:07:45 +02:00
'PhamePostEditor' => 'applications/phame/editor/PhamePostEditor.php',
Spiffy up PhamePostView Summary: Cleaner Author information, less "Properties", Build a History Page. Ref T9897 Test Plan: Review New Posts, Draft Posts, View History {F1012934} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14660
2015-12-04 00:27:01 +01:00
'PhamePostHistoryController' => 'applications/phame/controller/post/PhamePostHistoryController.php',
Modernize Phame post lists Summary: Use device UI for all post lists. Left menu is a bit wonky but I'll clean that up shortly. Test Plan: Will add screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3696
2012-10-15 23:50:37 +02:00
'PhamePostListController' => 'applications/phame/controller/post/PhamePostListController.php',
Add a homepage for Phame Summary: Sends `/phame/` to PhameHomeController, which is all published posts. Still some rough edges to work out for new posts, new blogs, but I think this is the right direction. Test Plan: go to Phame, see most recent posts, no drafts. click on find posts, see post list, click on find blogs, see blogs. {F1008800} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9742 Differential Revision: https://secure.phabricator.com/D14618
2015-12-01 01:25:59 +01:00
'PhamePostListView' => 'applications/phame/view/PhamePostListView.php',
Allow mail replies to Phame Posts Summary: Adds mail reply support to Phame Posts. Test Plan: Comment on a post, get mail. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9746 Differential Revision: https://secure.phabricator.com/D14454
2015-11-10 18:41:05 +01:00
'PhamePostMailReceiver' => 'applications/phame/mail/PhamePostMailReceiver.php',
Use AphrontDialog for New/Move Phame Posts Summary: Moves New Post and Move Post to be separate Controllers with Dialogs. Ref T9897 Test Plan: Move a post to a new blog, see message and see post. Click New Post, get dialog, pick blog, edit new post. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14698
2015-12-07 23:12:05 +01:00
'PhamePostMoveController' => 'applications/phame/controller/post/PhamePostMoveController.php',
Mostly modernize post edit/detail UIs Summary: Still some big chunks left but this moves us a bit closer to getting everything device-ready. Stuff not addressed here but which I'm planning to do soon: - Posts don't have a live URI yet. - Post detail pages don't actually show the post content. I'm going to tweak PhabricatorObjectPropertyListView for this since we need it some other places. - Some of the hinting about use/states is gone (e.g., "This post is a draft, publish it to make it live to the world."); I'm planning to restore it. - Left nav is still a bit of a mess with states/highlighting. Major changes are: - If you click "New Post" you get a screen asking you to pick a blog to post to. - "Publish/Preview" and Unpublish are now separate actions from the post detail screen. - "Publish/Preview" renders a preview of the post in an iframe and gives you a "Publish" button. Test Plan: Will attach screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3697
2012-10-15 23:50:45 +02:00
'PhamePostPublishController' => 'applications/phame/controller/post/PhamePostPublishController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhamePostQuery' => 'applications/phame/query/PhamePostQuery.php',
Add mail/feed support to PhamePost Summary: Allows feed stories and mail for new Phame Posts. Test Plan: Write Post, Get Mail Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14426
2015-11-07 02:40:13 +01:00
'PhamePostReplyHandler' => 'applications/phame/mail/PhamePostReplyHandler.php',
Add phame.post.search Conduit API endpoint Summary: Ref T9897. Mostly straightforward, but also modernize/fixup the Query a little so that posts never load with no blog. Test Plan: Queried posts via API. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14901
2015-12-28 13:25:01 +01:00
'PhamePostSearchConduitAPIMethod' => 'applications/phame/conduit/PhamePostSearchConduitAPIMethod.php',
PhamePostSearchEngine Summary: A very basic search engine for Phame Posts Test Plan: Built a dashboard to test various queries. Saw posts. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T6269 Differential Revision: https://secure.phabricator.com/D13671
2015-07-22 16:30:52 +02:00
'PhamePostSearchEngine' => 'applications/phame/query/PhamePostSearchEngine.php',
Phame - move over post creation and edit to use an editor Summary: This adds the bare minimum transaction set for editing posts. Fixes T7626 because now files will be correctly attached to phame posts on subsequent edits. Future work here should be adding transaction types like `TYPE_BLOG` for when posts are moved between blogs, `TYPE_VISIBILITY` for when posts are moved to published, etc. Nothing too tricky there but keeping this diff relatively small seems prudent. Test Plan: made posts successfully. also made errors like no title, no phame title, and duplicate phame title and got correct errors. added a file to a post and verified file has phame post in "attached" tab, which should fix T7626. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7626 Differential Revision: https://secure.phabricator.com/D12864
2015-05-15 22:07:45 +02:00
'PhamePostTransaction' => 'applications/phame/storage/PhamePostTransaction.php',
Add comments to internal Phame Posts Summary: Adds commenting to Phame Posts, also testing a new "document comment style". Unsure about it but Phame is a prototype so good place to explore. Test Plan: Leave some comments, see some comments, test show/hide. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9746 Differential Revision: https://secure.phabricator.com/D14451
2015-11-10 06:20:35 +01:00
'PhamePostTransactionComment' => 'applications/phame/storage/PhamePostTransactionComment.php',
Phame - move over post creation and edit to use an editor Summary: This adds the bare minimum transaction set for editing posts. Fixes T7626 because now files will be correctly attached to phame posts on subsequent edits. Future work here should be adding transaction types like `TYPE_BLOG` for when posts are moved between blogs, `TYPE_VISIBILITY` for when posts are moved to published, etc. Nothing too tricky there but keeping this diff relatively small seems prudent. Test Plan: made posts successfully. also made errors like no title, no phame title, and duplicate phame title and got correct errors. added a file to a post and verified file has phame post in "attached" tab, which should fix T7626. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7626 Differential Revision: https://secure.phabricator.com/D12864
2015-05-15 22:07:45 +02:00
'PhamePostTransactionQuery' => 'applications/phame/query/PhamePostTransactionQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhamePostViewController' => 'applications/phame/controller/post/PhamePostViewController.php',
Generate expected scheamta for Passphrase, Paste, Phlux, Phame Summary: Ref T1191. Nothing notable in these. Test Plan: Viewed web UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10528
2014-09-24 22:50:57 +02:00
'PhameSchemaSpec' => 'applications/phame/storage/PhameSchemaSpec.php',
Modularize Aphront "sites" Summary: Fixes T5702. The path here is long and windy: - I want to move `blog.phacility.com` to the new `secure` host. - That host has `security.require-https` set, which I want to keep set (before, this was handled in a sort of hacky way at the nginx/preamble level, but I've cleaned up everything else now). - Currently, that setting forces blogs to HTTPS too, which won't work. - To let blogs be individually configurable, we need to either modularize site config or make things hackier. - Modularize rather than increasing hackiness. - Also add a little "modules" panel in Config. See T6859. This feels like a reasonable middle ground between putting this stuff in Applications and burying it in `bin/somewhere`. Test Plan: - Visited normal site. - Visited phame on-domain site. - Visited phame off-domain site. - Viewed static resources. {F561897} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D13474
2015-06-29 23:04:48 +02:00
'PhameSite' => 'applications/phame/site/PhameSite.php',
Phlux v0 Summary: Yup, it's sitevars. No conduit or caching or fancy stuff yet. Ref T2793. Test Plan: {F36525} {F36526} {F36527} {F36528} {F36529} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2793 Differential Revision: https://secure.phabricator.com/D5397
2013-03-21 02:01:52 +01:00
'PhluxController' => 'applications/phlux/controller/PhluxController.php',
'PhluxDAO' => 'applications/phlux/storage/PhluxDAO.php',
'PhluxEditController' => 'applications/phlux/controller/PhluxEditController.php',
'PhluxListController' => 'applications/phlux/controller/PhluxListController.php',
'PhluxTransaction' => 'applications/phlux/storage/PhluxTransaction.php',
'PhluxTransactionQuery' => 'applications/phlux/query/PhluxTransactionQuery.php',
'PhluxVariable' => 'applications/phlux/storage/PhluxVariable.php',
'PhluxVariableEditor' => 'applications/phlux/editor/PhluxVariableEditor.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhluxVariablePHIDType' => 'applications/phlux/phid/PhluxVariablePHIDType.php',
Phlux v0 Summary: Yup, it's sitevars. No conduit or caching or fancy stuff yet. Ref T2793. Test Plan: {F36525} {F36526} {F36527} {F36528} {F36529} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2793 Differential Revision: https://secure.phabricator.com/D5397
2013-03-21 02:01:52 +01:00
'PhluxVariableQuery' => 'applications/phlux/query/PhluxVariableQuery.php',
'PhluxViewController' => 'applications/phlux/controller/PhluxViewController.php',
Make event-triggered actions more aware of application access Summary: Fixes T3675. - Maniphest had a couple of old non-event listeners; move them to events. - Make most of the similar listeners a little more similar. - Add checks for access to the application. Test Plan: - Viewed profile, project, task, revision. - Clicked all the actions. - Blocked access to various applications and verified the actions vanished. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7365
2013-10-22 02:00:50 +02:00
'PholioActionMenuEventListener' => 'applications/pholio/event/PholioActionMenuEventListener.php',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioController' => 'applications/pholio/controller/PholioController.php',
'PholioDAO' => 'applications/pholio/storage/PholioDAO.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'PholioDefaultEditCapability' => 'applications/pholio/capability/PholioDefaultEditCapability.php',
'PholioDefaultViewCapability' => 'applications/pholio/capability/PholioDefaultViewCapability.php',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioImage' => 'applications/pholio/storage/PholioImage.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PholioImagePHIDType' => 'applications/pholio/phid/PholioImagePHIDType.php',
Pholio - add concept of replacing images and primitive history view Summary: Now you can actually replace an image! Ref T3572. This ended up needing a wee bit of infrastructure to work... - add replace image transaction to pholio - add replacesImagePHID to PholioImage - tweaks to editor to properly update images with respect to replacement - add edges to track replacement - expose getNodes on graph query infrastructure to query the entire graph of who replaced who - move pholio image to new phid infrastructure Still TODO - the history view should get chopped out a bit from the current view - no more inline comments / generally less functionality plus maybe a tweak or two to make this more sensical. Test Plan: replaced images and played with history controller a little. works okay. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3572 Differential Revision: https://secure.phabricator.com/D6560
2013-07-26 01:59:25 +02:00
'PholioImageQuery' => 'applications/pholio/query/PholioImageQuery.php',
Pholio - make the form maintain client side edits between file uploads Summary: Fixes T3553. Did it by adding some code that refreshes the File object on keyup events within a given file entry. also fixes an html derp I found trying to fix this. Test Plan: added cool things like 'bbb' to every field and noted they were maintained when I added more files Reviewers: btrahan Reviewed By: btrahan CC: aran, Korvin, chad Maniphest Tasks: T3553 Differential Revision: https://secure.phabricator.com/D6488
2013-07-19 00:04:08 +02:00
'PholioImageUploadController' => 'applications/pholio/controller/PholioImageUploadController.php',
Show saved inline comments Summary: Saved inline comments are now shown for images. Test Plan: Verified that inline comments are loaded and shown. Reviewers: epriestley CC: aran, Korvin Maniphest Tasks: T2446 Differential Revision: https://secure.phabricator.com/D4866
2013-02-08 16:24:17 +01:00
'PholioInlineController' => 'applications/pholio/controller/PholioInlineController.php',
Remove inline gutter in Pholio Summary: This greatly simplifies inline comments while retaining their functionality. This is probably not where we want to end up, but will let us figure out what we're doing with the stage without worrying about inlines. Test Plan: See screenshots. Reviewers: chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9537
2014-06-15 03:41:45 +02:00
'PholioInlineListController' => 'applications/pholio/controller/PholioInlineListController.php',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioMock' => 'applications/pholio/storage/PholioMock.php',
Add PholioMockArchiveController Summary: Allows closing a mock from the action list. Ref T9414 Test Plan: New Mock, Edit Mock, Close Mock, Open Mock Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9414 Differential Revision: https://secure.phabricator.com/D14726
2015-12-09 21:56:27 +01:00
'PholioMockArchiveController' => 'applications/pholio/controller/PholioMockArchiveController.php',
Modularize all remaining Pholio Herald fields Summary: Ref T8726. Use modular fields for the Pholio adapter. Test Plan: - Created rule using all the old fields. - Migrated, saw upgrade apply correctly. - Created mock, reviewed transcript. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13513
2015-07-06 22:17:33 +02:00
'PholioMockAuthorHeraldField' => 'applications/pholio/herald/PholioMockAuthorHeraldField.php',
Allow users to add comments in Pholio Summary: Basic support for adding comments. Missing a lot of frills. Uses new comment/transaction UI. Test Plan: Added some comments. Tried to add an empty comment. Some comments: {F22361} No text provided: {F22362} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3834
2012-11-22 02:27:20 +01:00
'PholioMockCommentController' => 'applications/pholio/controller/PholioMockCommentController.php',
Modularize all remaining Pholio Herald fields Summary: Ref T8726. Use modular fields for the Pholio adapter. Test Plan: - Created rule using all the old fields. - Migrated, saw upgrade apply correctly. - Created mock, reviewed transcript. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13513
2015-07-06 22:17:33 +02:00
'PholioMockDescriptionHeraldField' => 'applications/pholio/herald/PholioMockDescriptionHeraldField.php',
Add very basic create interface for Pholio Summary: Nothing app-specific yet, just stitching groundwork together from readymade components. {F22347} Test Plan: Created some mocks via web UI. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3830
2012-11-22 02:23:28 +01:00
'PholioMockEditController' => 'applications/pholio/controller/PholioMockEditController.php',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioMockEditor' => 'applications/pholio/editor/PholioMockEditor.php',
Pholio mocks embed in a fancy way Summary: Pholio mocks are now embed in a fancy way Test Plan: {F34804} Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin, AnhNhan Maniphest Tasks: T2626 Differential Revision: https://secure.phabricator.com/D5249
2013-03-07 17:23:40 +01:00
'PholioMockEmbedView' => 'applications/pholio/view/PholioMockEmbedView.php',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PholioMockFulltextEngine' => 'applications/pholio/search/PholioMockFulltextEngine.php',
Modernize Pholio edges Summary: Modernize Pholio edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Attached a mock to a task, observed the expected comment in the transaction view (both ways). Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11113
2015-01-02 00:11:41 +01:00
'PholioMockHasTaskEdgeType' => 'applications/pholio/edge/PholioMockHasTaskEdgeType.php',
Modularize all remaining Pholio Herald fields Summary: Ref T8726. Use modular fields for the Pholio adapter. Test Plan: - Created rule using all the old fields. - Migrated, saw upgrade apply correctly. - Created mock, reviewed transcript. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13513
2015-07-06 22:17:33 +02:00
'PholioMockHeraldField' => 'applications/pholio/herald/PholioMockHeraldField.php',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'PholioMockHeraldFieldGroup' => 'applications/pholio/herald/PholioMockHeraldFieldGroup.php',
Pholio tile to home page and mock to show first image Summary: Pholio tile to show up on home page First image is shown at mock page. Test Plan: Pholio app shows up on home page. First image is shown at mock page. Reviewers: epriestley CC: aran, Korvin Maniphest Tasks: T2356 Differential Revision: https://secure.phabricator.com/D4553
2013-01-20 18:29:34 +01:00
'PholioMockImagesView' => 'applications/pholio/view/PholioMockImagesView.php',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioMockListController' => 'applications/pholio/controller/PholioMockListController.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PholioMockMailReceiver' => 'applications/pholio/mail/PholioMockMailReceiver.php',
Modularize all remaining Pholio Herald fields Summary: Ref T8726. Use modular fields for the Pholio adapter. Test Plan: - Created rule using all the old fields. - Migrated, saw upgrade apply correctly. - Created mock, reviewed transcript. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13513
2015-07-06 22:17:33 +02:00
'PholioMockNameHeraldField' => 'applications/pholio/herald/PholioMockNameHeraldField.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PholioMockPHIDType' => 'applications/pholio/phid/PholioMockPHIDType.php',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioMockQuery' => 'applications/pholio/query/PholioMockQuery.php',
Use ApplicationSearch in Pholio Summary: Ref T2637. Ref T2625. Convert Pholio to use ApplicationSearch. Test Plan: Viewed mocks, changed filters. Verified edit page works and no longer has a weird side nav on it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2625, T2637 Differential Revision: https://secure.phabricator.com/D6530
2013-07-22 21:21:15 +02:00
'PholioMockSearchEngine' => 'applications/pholio/query/PholioMockSearchEngine.php',
Turn thumbs into a history grid thing Summary: This could probably use some refinement (and, like, explanatory text, and stronger cues about what rows and columns mean) but feels fairly good to me, at least on test data. I didn't do any scrolling for now since we have to do full height on mobile anyway I think. I did swap it so the newer ones are on top. Left/right navigate you among current images only, but you can click any thumb to review history. Removed history view since it's no longer useful. Some things that would probably help: - Some kind of header explaining what this is ("Mock History" or something). - Stronger visual cue that columns are related by being the same image. - Clearer cues about obsolete/deleted images (e.g., on the stage itself?) - Maybe general tweaks. - Maybe a placeholder (like a grey "X") for images which have been deleted. (I'm planning to add comment counts too, which I think will be pretty useful, but that felt good to put in another diff.) Test Plan: See screenshots. Reviewers: chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9543
2014-06-15 06:12:19 +02:00
'PholioMockThumbGridView' => 'applications/pholio/view/PholioMockThumbGridView.php',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioMockViewController' => 'applications/pholio/controller/PholioMockViewController.php',
Prepare for hovercards Summary: - Unify all the reference/embed Remarkup rules for Differential, Maniphest, Paste and Ponder. - Add rules for Pholio. - Does not yet unify Diffusion or Files (both are a bit more involved). - Prepare for hovercards. Test Plan: {F33894} Reviewers: chad, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5120
2013-02-26 23:59:31 +01:00
'PholioRemarkupRule' => 'applications/pholio/remarkup/PholioRemarkupRule.php',
Add basic email support to Pholio Summary: These emails aren't yet useful, but thread/multiplex/etc correctly. Test Plan: Got some Pholio emails. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3842
2012-11-22 02:39:46 +01:00
'PholioReplyHandler' => 'applications/pholio/mail/PholioReplyHandler.php',
Generate expected schemata for Pholio, Phortune, Phragment, Phriction and Policy Summary: Ref T1191. Nothing too out-of-the-ordinary here. Test Plan: Saw fewer than 500 remaining issues. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley, hach-que Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10587
2014-10-01 16:52:26 +02:00
'PholioSchemaSpec' => 'applications/pholio/storage/PholioSchemaSpec.php',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioTransaction' => 'applications/pholio/storage/PholioTransaction.php',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PholioTransactionComment' => 'applications/pholio/storage/PholioTransactionComment.php',
Allow users to add comments in Pholio Summary: Basic support for adding comments. Missing a lot of frills. Uses new comment/transaction UI. Test Plan: Added some comments. Tried to add an empty comment. Some comments: {F22361} No text provided: {F22362} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3834
2012-11-22 02:27:20 +01:00
'PholioTransactionQuery' => 'applications/pholio/query/PholioTransactionQuery.php',
Group inline transactions in Pholio Summary: Fixes T2639 by grouping related transactions at display time, so all the inlines merge into a nice block. (Note that this does not do anything about T2709 yet, so there's still no way to figure out where the inlines actually are.) Test Plan: {F35262} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2639 Differential Revision: https://secure.phabricator.com/D5313
2013-03-10 04:23:50 +01:00
'PholioTransactionView' => 'applications/pholio/view/PholioTransactionView.php',
Pholio - support editing images - fixes T3489 Summary: Nice title. We add three new transactions - IMAGE_FILE, IMAGE_NAME, and IMAGE_DESCRIPTION. The first is a bit like subscribers as it is a list of file phids. The latter have values of the form ($file_phid => $data), where $data is $name or $description respectively. This is because we need to collate transactions based on $file_phid... Overall, this uses the _underyling files_ and not the "PholioImage" to determine if things are unique or not. That said, simply mark PholioImages as obsolete so inline comments about no-longer applicable PholioImages don't break. Does a reasonable job implementing the mock. Note you can't "update" an image at this time, though you can delete and add at will. Test Plan: played with pholio a ton. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3489 Differential Revision: https://secure.phabricator.com/D6441
2013-07-16 22:31:20 +02:00
'PholioUploadedImageView' => 'applications/pholio/view/PholioUploadedImageView.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneAccount' => 'applications/phortune/storage/PhortuneAccount.php',
Support multiple payment accounts and account switching in Phortune Summary: Ref T2787. Support multiple payment accounts so you can have personal vs company payment accounts. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10673
2014-10-10 01:59:03 +02:00
'PhortuneAccountEditController' => 'applications/phortune/controller/PhortuneAccountEditController.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneAccountEditor' => 'applications/phortune/editor/PhortuneAccountEditor.php',
Make Phortune account members editable and modernize the edge constant Summary: Ref T2787. - Account members can add and remove other members (major use case is corporate accounts). - Use a modern edge constant setup. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10678
2014-10-11 00:00:06 +02:00
'PhortuneAccountHasMemberEdgeType' => 'applications/phortune/edge/PhortuneAccountHasMemberEdgeType.php',
Support multiple payment accounts and account switching in Phortune Summary: Ref T2787. Support multiple payment accounts so you can have personal vs company payment accounts. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10673
2014-10-10 01:59:03 +02:00
'PhortuneAccountListController' => 'applications/phortune/controller/PhortuneAccountListController.php',
Modernize Phortune PHID constants Summary: Ref T2787. These were still stuck in the stone ages. (The handles are pretty skeletal but most aren't used anywehre.) Test Plan: Funded an initiative without anything breaking. Grepped for removed constants. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10647
2014-10-07 01:48:16 +02:00
'PhortuneAccountPHIDType' => 'applications/phortune/phid/PhortuneAccountPHIDType.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneAccountQuery' => 'applications/phortune/query/PhortuneAccountQuery.php',
'PhortuneAccountTransaction' => 'applications/phortune/storage/PhortuneAccountTransaction.php',
'PhortuneAccountTransactionQuery' => 'applications/phortune/query/PhortuneAccountTransactionQuery.php',
'PhortuneAccountViewController' => 'applications/phortune/controller/PhortuneAccountViewController.php',
Support basic ad-hoc invoices in Phortune Summary: This allows a merchant to send a user an invoice for something arbitrary, like services rendered. Two major missing parts: - These don't actually get marked as invoices. I'll fix that in the next diff, but it's not entirely trivial because `subscriptionPHID` is currently overloaded to also mean "is invoice". - We don't send email automatically. I don't plan to fix that for now, since all our invoicing needs are covered by personal email. Test Plan: Merchants have a new "new invoice" option: {F376999} This leads to selecting a user and account, and then you can generate the invoice (only one actual "purchase" / line item for the moment). You can add a longer-form remarkup description to contextualize the billable items: {F377001} This sends the invoice and takes you to the merchant order overview screen: {F377002} For now, you copy/paste that link into a nice personal enterprisey business-to-business email; the recipient sees this: {F377003} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D12478
2015-04-20 19:05:22 +02:00
'PhortuneAdHocCart' => 'applications/phortune/cart/PhortuneAdHocCart.php',
'PhortuneAdHocProduct' => 'applications/phortune/product/PhortuneAdHocProduct.php',
Add "Carts" to Phortune Summary: Although I imagine we aren't really going to have an "add to cart" type storefront, putting this in place makes a lot of other workflows simpler. No storage yet, just allows reasonable construction of a "buy stuff" page. Test Plan: {F41342} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5745
2013-04-25 18:45:07 +02:00
'PhortuneCart' => 'applications/phortune/storage/PhortuneCart.php',
Add a "Review" status to Phortune Summary: Ref T2787. Allow merchants to flag orders for review. For now, all orders are flagged for review. Eventually, I could imagine Herald rules for coarse things (e.g., require review of all orders over $1,000, or require review of all orders by users not on a whitelist) and maybe examining fraud data for the providers which support it. Test Plan: {F215848} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10675
2014-10-10 20:29:13 +02:00
'PhortuneCartAcceptController' => 'applications/phortune/controller/PhortuneCartAcceptController.php',
Mostly implement order refunds and cancellations Summary: Ref T2787. This has some rough edges but basically works. - Users can cancel orders that are in incomplete states (or in complete states, if the application allows them to -- for example, some future application might allow cancellation of billed-but-not-shipped orders). - Merchant controllers can partially or fully refund orders from any state after payment. Test Plan: This is still rough around the edges, but issued Stripe and WePay refunds. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10664
2014-10-09 00:33:25 +02:00
'PhortuneCartCancelController' => 'applications/phortune/controller/PhortuneCartCancelController.php',
Phortune Cart Status, some one-time support Summary: Ref T2787. Carts need a status so we can tell if they've been purchased. Also kind of get WePay working as a one-time provider, and let charges not have a methodPHID (they won't for one-time providers). All the status stuff is still super crazy rough and you can do things like start a checkout, add a bunch of stuff to your cart, complete the checkout, and have Phabricator think you paid for all the stuff you added. But this is fine for now since you can't actually edit carts, and also none of this is at all usable anyway. I'll refine some of the workflows in future diffs, for now I'm just getting things hooked up and technically working. Test Plan: - Purcahsed a cart and got a sort of status/done screen instead of a "your money is gone" exception. - Went through the WePay flow and got a successful test checkout. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10003
2014-07-23 19:36:25 +02:00
'PhortuneCartCheckoutController' => 'applications/phortune/controller/PhortuneCartCheckoutController.php',
'PhortuneCartController' => 'applications/phortune/controller/PhortuneCartController.php',
Add cart transactions to Phortune Summary: Ref T2787. I mostly just want these in place so I can glue emails to them, but they're also useful on their own. Test Plan: {F216515} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10688
2014-10-13 20:16:27 +02:00
'PhortuneCartEditor' => 'applications/phortune/editor/PhortuneCartEditor.php',
Give applications control over Phortune cart logic Summary: Ref T2787. Similar to D10634, give applications more control over the cart workflow. For now this just means they get to pick exit URIs, but in the future they can manage more details of cart behavior. Test Plan: Funded an initiative and got returned to the initiative instead of dead-ending in Phortune. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10638
2014-10-06 23:19:08 +02:00
'PhortuneCartImplementation' => 'applications/phortune/cart/PhortuneCartImplementation.php',
Allow merchant controllers to review orders in Phortune Summary: Ref T2787. Sets the stage for administrating / cancelling / refunding orders and hold orders. Test Plan: {F215140} {F215141} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10663
2014-10-08 23:40:02 +02:00
'PhortuneCartListController' => 'applications/phortune/controller/PhortuneCartListController.php',
Modernize Phortune PHID constants Summary: Ref T2787. These were still stuck in the stone ages. (The handles are pretty skeletal but most aren't used anywehre.) Test Plan: Funded an initiative without anything breaking. Grepped for removed constants. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10647
2014-10-07 01:48:16 +02:00
'PhortuneCartPHIDType' => 'applications/phortune/phid/PhortuneCartPHIDType.php',
Phortune Carts and Purchases Summary: Ref T2787. Make carts and purchases real objects, with storage, that kind-of work. Roughly, the idea here is that applications create "purchases" (like "1 large t-shirt") and add them to "carts" (a user can have a lot of different carts at the same time), then hand things off to Phortune to deal with actualy charging a card. Roughly this works like Paypal or other similar systems do, except Phortune is the thing the user gets handed off to. This doesn't do anything interesting/useful yet. Also fix some bugs and update some UI. Test Plan: Added a product to a cart, saw it in cart screen. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10001
2014-07-23 19:34:08 +02:00
'PhortuneCartQuery' => 'applications/phortune/query/PhortuneCartQuery.php',
Send mail about cart/order changes from Phortune Summary: Ref T2787. When order statuses change, send merchants and users email about it. Test Plan: Used `bin/mail` to review mail. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10694
2014-10-13 20:16:44 +02:00
'PhortuneCartReplyHandler' => 'applications/phortune/mail/PhortuneCartReplyHandler.php',
Allow merchant controllers to review orders in Phortune Summary: Ref T2787. Sets the stage for administrating / cancelling / refunding orders and hold orders. Test Plan: {F215140} {F215141} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10663
2014-10-08 23:40:02 +02:00
'PhortuneCartSearchEngine' => 'applications/phortune/query/PhortuneCartSearchEngine.php',
Add cart transactions to Phortune Summary: Ref T2787. I mostly just want these in place so I can glue emails to them, but they're also useful on their own. Test Plan: {F216515} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10688
2014-10-13 20:16:27 +02:00
'PhortuneCartTransaction' => 'applications/phortune/storage/PhortuneCartTransaction.php',
'PhortuneCartTransactionQuery' => 'applications/phortune/query/PhortuneCartTransactionQuery.php',
Add a HOLD state to Phortune and handle unusual states better Summary: Ref T2787. When Paypal comes back to us with funds on hold, dead-end the transaction but handle it properly. Generally, smooth out the user interaction on weird states. Implement refudnds/cancels for Paypal. Test Plan: {F215230} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10667
2014-10-09 13:30:47 +02:00
'PhortuneCartUpdateController' => 'applications/phortune/controller/PhortuneCartUpdateController.php',
Phortune Cart Status, some one-time support Summary: Ref T2787. Carts need a status so we can tell if they've been purchased. Also kind of get WePay working as a one-time provider, and let charges not have a methodPHID (they won't for one-time providers). All the status stuff is still super crazy rough and you can do things like start a checkout, add a bunch of stuff to your cart, complete the checkout, and have Phabricator think you paid for all the stuff you added. But this is fine for now since you can't actually edit carts, and also none of this is at all usable anyway. I'll refine some of the workflows in future diffs, for now I'm just getting things hooked up and technically working. Test Plan: - Purcahsed a cart and got a sort of status/done screen instead of a "your money is gone" exception. - Went through the WePay flow and got a successful test checkout. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10003
2014-07-23 19:36:25 +02:00
'PhortuneCartViewController' => 'applications/phortune/controller/PhortuneCartViewController.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneCharge' => 'applications/phortune/storage/PhortuneCharge.php',
Show only recent orders and charges on Phortune account profile page Summary: Ref T2787. Currently, we show all orders/charges, which won't scale well. Show the 10 most recent and link to full order/charge history. Test Plan: {F216325} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10685
2014-10-13 20:14:50 +02:00
'PhortuneChargeListController' => 'applications/phortune/controller/PhortuneChargeListController.php',
Modernize Phortune PHID constants Summary: Ref T2787. These were still stuck in the stone ages. (The handles are pretty skeletal but most aren't used anywehre.) Test Plan: Funded an initiative without anything breaking. Grepped for removed constants. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10647
2014-10-07 01:48:16 +02:00
'PhortuneChargePHIDType' => 'applications/phortune/phid/PhortuneChargePHIDType.php',
Phortune Charges Summary: Ref T2787. Makes charges a real object, allows providers to apply them. We are now (just barely) capable of stealing users' money. Test Plan: {F179584} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10002
2014-07-23 19:36:12 +02:00
'PhortuneChargeQuery' => 'applications/phortune/query/PhortuneChargeQuery.php',
Show only recent orders and charges on Phortune account profile page Summary: Ref T2787. Currently, we show all orders/charges, which won't scale well. Show the 10 most recent and link to full order/charge history. Test Plan: {F216325} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10685
2014-10-13 20:14:50 +02:00
'PhortuneChargeSearchEngine' => 'applications/phortune/query/PhortuneChargeSearchEngine.php',
'PhortuneChargeTableView' => 'applications/phortune/view/PhortuneChargeTableView.php',
General cleanup for adding payment methods in Phortune Summary: This has no real behavioral changes (except better error handling), it just factors things out to be a bit cleaner. In particular: - Move more shared form behaviors into the common JS form component. - Move more error handling into shared pathways. - Make the specialized Stripe / Balanced methods do less work. This needs some more polish for nontrival errors (especially on the Balanced side) but none of the error behavior is worse than it was and a lot of it is much better. Ref T2787. Test Plan: Hit all invalid form errors, added valid payment methods with Stripe and Balacned. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5771
2013-04-25 18:49:32 +02:00
'PhortuneConstants' => 'applications/phortune/constants/PhortuneConstants.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneController' => 'applications/phortune/controller/PhortuneController.php',
Clean up rendering of credit card form Summary: General cleanup and separation into generic vs Stripe blocks of code. - There was an old CC form view for Stripe stuff that I never cleaned up; clean that up. - Move non-Stripe CC form rendering into a base class (Balanced can reuse it). - Move non-Stripe CC form JS into a shareable class. - Simplify JS a bit (JX.Workflow can add extra parameters to a request, so we don't need hidden inputs). - Genericize CSS. - Depend on Stripe JS directly, if they're down we're not going to be able to add cards anyway. Ref T2787. Test Plan: Hit all Stripe errors and added new cards. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5758
2013-04-25 18:46:59 +02:00
'PhortuneCreditCardForm' => 'applications/phortune/view/PhortuneCreditCardForm.php',
Show prices in "$... USD" in Phortune Summary: Ref T2787. See discussion in D5834. - Replace `PhortuneUtil` with `PhortuneCurrency`, which feels a little better and more flexible / future-proof. - Add unit tests. - Display prices explicitly as "$... USD". Test Plan: Hit product list, cart, purchase flow, verified displays. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5841
2013-05-07 03:04:45 +02:00
'PhortuneCurrency' => 'applications/phortune/currency/PhortuneCurrency.php',
Make Currency a more formal type Summary: Ref T2787. Phortune currently stores a bunch of stuff as `...inUSDCents`. This ends up being pretty cumbersome and I worry it will create a huge headache down the road (and possibly not that far off if we do Coinbase/Bitcoin soon). Even now, it's more of a pain than I figured it would be. Instead: - Provide an application-level serialization mechanism. - Provide currency serialization. - Store currency in an abstract way (currently, as "1.23 USD") that can handle currencies in the future. - Change all `...inUSDCents` to `..asCurrency`. - This generally simplifies all the application code. - Also remove some columns which don't make sense or don't make sense anymore. Notably, `Product` is going to get more abstract and mostly be provided by applications. Test Plan: - Created a new product. - Purchased a product. - Backed an initiative. - Ran unit tests. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10633
2014-10-06 19:26:48 +02:00
'PhortuneCurrencySerializer' => 'applications/phortune/currency/PhortuneCurrencySerializer.php',
Show prices in "$... USD" in Phortune Summary: Ref T2787. See discussion in D5834. - Replace `PhortuneUtil` with `PhortuneCurrency`, which feels a little better and more flexible / future-proof. - Add unit tests. - Display prices explicitly as "$... USD". Test Plan: Hit product list, cart, purchase flow, verified displays. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5841
2013-05-07 03:04:45 +02:00
'PhortuneCurrencyTestCase' => 'applications/phortune/currency/__tests__/PhortuneCurrencyTestCase.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneDAO' => 'applications/phortune/storage/PhortuneDAO.php',
General cleanup for adding payment methods in Phortune Summary: This has no real behavioral changes (except better error handling), it just factors things out to be a bit cleaner. In particular: - Move more shared form behaviors into the common JS form component. - Move more error handling into shared pathways. - Make the specialized Stripe / Balanced methods do less work. This needs some more polish for nontrival errors (especially on the Balanced side) but none of the error behavior is worse than it was and a lot of it is much better. Ref T2787. Test Plan: Hit all invalid form errors, added valid payment methods with Stripe and Balacned. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5771
2013-04-25 18:49:32 +02:00
'PhortuneErrCode' => 'applications/phortune/constants/PhortuneErrCode.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneLandingController' => 'applications/phortune/controller/PhortuneLandingController.php',
Make Phortune account members editable and modernize the edge constant Summary: Ref T2787. - Account members can add and remove other members (major use case is corporate accounts). - Use a modern edge constant setup. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10678
2014-10-11 00:00:06 +02:00
'PhortuneMemberHasAccountEdgeType' => 'applications/phortune/edge/PhortuneMemberHasAccountEdgeType.php',
Give Phortune merchants explicit members Summary: Ref T2787. Make this a little more concrete with explicit membership instead of a general edit policy. In particular, we need to know who to email when orders happen, and can't reasonably do that with an edit policy. I imagine this might eventually get more nuanced (e.g., users who can only approve orders vs users who can manage the merchant itself) but that's a long ways away. Test Plan: {F216284} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10681
2014-10-13 20:13:50 +02:00
'PhortuneMemberHasMerchantEdgeType' => 'applications/phortune/edge/PhortuneMemberHasMerchantEdgeType.php',
Add Merchants to Phortune Summary: Ref T2787. Currently, you add payment providers (Stripe, Paypal, etc) in global configuration. Generally, this approach is cumbersome, limiting, and often hard for users to figure out. It also doesn't provide a natural way to segment payment receivers or provide web access to administrative payment functions like issuing refunds, canceling orders, etc. I think that stuff definitely needs to be in the web UI, and the rule for access to it can't reasonably just be "all administrators" in a lot of reasonable cases. The only real advantage is that it prevents an attacker from adjusting settings and pointing something at an account they control. But this attack can be mitigated through notifications, some sort of CLI-only merchant lock, payment accounts being relatively identifiable, etc. So introduce "merchants", which are basically payable entities. An individual merchant will have attached Paypal, Stripe, etc., accounts, and access rules. When you buy something in an application, the merchant to pay is also specified. They also provide an umbrella for dealing with permissions down the line. This may get a //little// cumbersome because if there are several merchants your saved card information is not shared across them. I think that will be fine in the normal case (most installs will have only one merchant). Even if it isn't and we leave providers global, I think introducing this is the right call from a web UI / permissions point of view. I'll play around with it in the next couple of diffs and figure out exactly where the line goes. Test Plan: Listed, created, edited, viewed merchants. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10648
2014-10-07 19:55:16 +02:00
'PhortuneMerchant' => 'applications/phortune/storage/PhortuneMerchant.php',
'PhortuneMerchantCapability' => 'applications/phortune/capability/PhortuneMerchantCapability.php',
'PhortuneMerchantController' => 'applications/phortune/controller/PhortuneMerchantController.php',
'PhortuneMerchantEditController' => 'applications/phortune/controller/PhortuneMerchantEditController.php',
'PhortuneMerchantEditor' => 'applications/phortune/editor/PhortuneMerchantEditor.php',
Give Phortune merchants explicit members Summary: Ref T2787. Make this a little more concrete with explicit membership instead of a general edit policy. In particular, we need to know who to email when orders happen, and can't reasonably do that with an edit policy. I imagine this might eventually get more nuanced (e.g., users who can only approve orders vs users who can manage the merchant itself) but that's a long ways away. Test Plan: {F216284} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10681
2014-10-13 20:13:50 +02:00
'PhortuneMerchantHasMemberEdgeType' => 'applications/phortune/edge/PhortuneMerchantHasMemberEdgeType.php',
Support basic ad-hoc invoices in Phortune Summary: This allows a merchant to send a user an invoice for something arbitrary, like services rendered. Two major missing parts: - These don't actually get marked as invoices. I'll fix that in the next diff, but it's not entirely trivial because `subscriptionPHID` is currently overloaded to also mean "is invoice". - We don't send email automatically. I don't plan to fix that for now, since all our invoicing needs are covered by personal email. Test Plan: Merchants have a new "new invoice" option: {F376999} This leads to selecting a user and account, and then you can generate the invoice (only one actual "purchase" / line item for the moment). You can add a longer-form remarkup description to contextualize the billable items: {F377001} This sends the invoice and takes you to the merchant order overview screen: {F377002} For now, you copy/paste that link into a nice personal enterprisey business-to-business email; the recipient sees this: {F377003} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D12478
2015-04-20 19:05:22 +02:00
'PhortuneMerchantInvoiceCreateController' => 'applications/phortune/controller/PhortuneMerchantInvoiceCreateController.php',
Add Merchants to Phortune Summary: Ref T2787. Currently, you add payment providers (Stripe, Paypal, etc) in global configuration. Generally, this approach is cumbersome, limiting, and often hard for users to figure out. It also doesn't provide a natural way to segment payment receivers or provide web access to administrative payment functions like issuing refunds, canceling orders, etc. I think that stuff definitely needs to be in the web UI, and the rule for access to it can't reasonably just be "all administrators" in a lot of reasonable cases. The only real advantage is that it prevents an attacker from adjusting settings and pointing something at an account they control. But this attack can be mitigated through notifications, some sort of CLI-only merchant lock, payment accounts being relatively identifiable, etc. So introduce "merchants", which are basically payable entities. An individual merchant will have attached Paypal, Stripe, etc., accounts, and access rules. When you buy something in an application, the merchant to pay is also specified. They also provide an umbrella for dealing with permissions down the line. This may get a //little// cumbersome because if there are several merchants your saved card information is not shared across them. I think that will be fine in the normal case (most installs will have only one merchant). Even if it isn't and we leave providers global, I think introducing this is the right call from a web UI / permissions point of view. I'll play around with it in the next couple of diffs and figure out exactly where the line goes. Test Plan: Listed, created, edited, viewed merchants. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10648
2014-10-07 19:55:16 +02:00
'PhortuneMerchantListController' => 'applications/phortune/controller/PhortuneMerchantListController.php',
'PhortuneMerchantPHIDType' => 'applications/phortune/phid/PhortuneMerchantPHIDType.php',
'PhortuneMerchantQuery' => 'applications/phortune/query/PhortuneMerchantQuery.php',
'PhortuneMerchantSearchEngine' => 'applications/phortune/query/PhortuneMerchantSearchEngine.php',
'PhortuneMerchantTransaction' => 'applications/phortune/storage/PhortuneMerchantTransaction.php',
'PhortuneMerchantTransactionQuery' => 'applications/phortune/query/PhortuneMerchantTransactionQuery.php',
'PhortuneMerchantViewController' => 'applications/phortune/controller/PhortuneMerchantViewController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhortuneMonthYearExpiryControl' => 'applications/phortune/control/PhortuneMonthYearExpiryControl.php',
Show only recent orders and charges on Phortune account profile page Summary: Ref T2787. Currently, we show all orders/charges, which won't scale well. Show the 10 most recent and link to full order/charge history. Test Plan: {F216325} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10685
2014-10-13 20:14:50 +02:00
'PhortuneOrderTableView' => 'applications/phortune/view/PhortuneOrderTableView.php',
Make payment providers a configurable property of Merchants in Phortune Summary: Ref T2787. Instead of making providers global configuration, make them a thing on merchants with web configuration. Payment methods and some of the pyament workflow needs to be retooled a bit after this, but this seemed like a reasonable cutoff point for this diff. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10649
2014-10-07 23:41:41 +02:00
'PhortunePayPalPaymentProvider' => 'applications/phortune/provider/PhortunePayPalPaymentProvider.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortunePaymentMethod' => 'applications/phortune/storage/PhortunePaymentMethod.php',
Make payment method management somewhat more reasonable in Phortune Summary: Ref T2787. Shows somewhat-useful information, allows payment methods to be disabled and renamed. Test Plan: Created, renamed, disabled payment methods. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10203
2014-08-11 21:07:35 +02:00
'PhortunePaymentMethodCreateController' => 'applications/phortune/controller/PhortunePaymentMethodCreateController.php',
'PhortunePaymentMethodDisableController' => 'applications/phortune/controller/PhortunePaymentMethodDisableController.php',
Phortune v0.1: add payment methods Summary: Hook @btrahan's Stripe form to the rest of Phortune. - Users can add payment methods. - They are saved to Stripe and associated with PhortunePaymentMethods on our side. - Payment methods appear on account overview. Test Plan: {F37548} {F37549} {F37550} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5438
2013-03-28 17:11:42 +01:00
'PhortunePaymentMethodEditController' => 'applications/phortune/controller/PhortunePaymentMethodEditController.php',
Modernize Phortune PHID constants Summary: Ref T2787. These were still stuck in the stone ages. (The handles are pretty skeletal but most aren't used anywehre.) Test Plan: Funded an initiative without anything breaking. Grepped for removed constants. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10647
2014-10-07 01:48:16 +02:00
'PhortunePaymentMethodPHIDType' => 'applications/phortune/phid/PhortunePaymentMethodPHIDType.php',
Phortune v0.1: add payment methods Summary: Hook @btrahan's Stripe form to the rest of Phortune. - Users can add payment methods. - They are saved to Stripe and associated with PhortunePaymentMethods on our side. - Payment methods appear on account overview. Test Plan: {F37548} {F37549} {F37550} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5438
2013-03-28 17:11:42 +01:00
'PhortunePaymentMethodQuery' => 'applications/phortune/query/PhortunePaymentMethodQuery.php',
Add basic payment providers to Phortune Summary: Abstract out the Stripiness of payment providers so we can add a Test provider (and maybe MtGox / Balanced / Paypal / etc). Ref T2787. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5752
2013-04-25 18:45:43 +02:00
'PhortunePaymentProvider' => 'applications/phortune/provider/PhortunePaymentProvider.php',
Make payment providers a configurable property of Merchants in Phortune Summary: Ref T2787. Instead of making providers global configuration, make them a thing on merchants with web configuration. Payment methods and some of the pyament workflow needs to be retooled a bit after this, but this seemed like a reasonable cutoff point for this diff. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10649
2014-10-07 23:41:41 +02:00
'PhortunePaymentProviderConfig' => 'applications/phortune/storage/PhortunePaymentProviderConfig.php',
'PhortunePaymentProviderConfigEditor' => 'applications/phortune/editor/PhortunePaymentProviderConfigEditor.php',
'PhortunePaymentProviderConfigQuery' => 'applications/phortune/query/PhortunePaymentProviderConfigQuery.php',
'PhortunePaymentProviderConfigTransaction' => 'applications/phortune/storage/PhortunePaymentProviderConfigTransaction.php',
'PhortunePaymentProviderConfigTransactionQuery' => 'applications/phortune/query/PhortunePaymentProviderConfigTransactionQuery.php',
'PhortunePaymentProviderPHIDType' => 'applications/phortune/phid/PhortunePaymentProviderPHIDType.php',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhortunePaymentProviderTestCase' => 'applications/phortune/provider/__tests__/PhortunePaymentProviderTestCase.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneProduct' => 'applications/phortune/storage/PhortuneProduct.php',
Move Phortune product logic into applications Summary: Ref T2787. `Product` is currently a fairly heavy object, but as Phortune develops it makes a lot of sense to make it a lighter object and put more product logic in applications. Convert it into a fairly lightweight reference to applications. The idea is that Phortune is mostly providing a cart flow, and applications manage the details of products. Test Plan: Funded an initiative for $1. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10634
2014-10-06 19:30:06 +02:00
'PhortuneProductImplementation' => 'applications/phortune/product/PhortuneProductImplementation.php',
Phortune v0.1: products Summary: Ref T2787. A product is the abstract representation of something you can buy or rent/subscribe to. Although the interface isn't locked down yet, this would ultimately be internal/administrative. Products likely have some user-facing skin on top of them: plans would have a purchasing/comparison flow, physical goods would have a storefront, etc., so products don't have any information like descriptions or images, just the data that Phortune needs to correctly bill accounts. Generally, this is very basic for the moment. Test Plan: {F37594} {F37595} {F37596} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5441
2013-03-28 17:13:07 +01:00
'PhortuneProductListController' => 'applications/phortune/controller/PhortuneProductListController.php',
Modernize Phortune PHID constants Summary: Ref T2787. These were still stuck in the stone ages. (The handles are pretty skeletal but most aren't used anywehre.) Test Plan: Funded an initiative without anything breaking. Grepped for removed constants. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10647
2014-10-07 01:48:16 +02:00
'PhortuneProductPHIDType' => 'applications/phortune/phid/PhortuneProductPHIDType.php',
Phortune v0.1: products Summary: Ref T2787. A product is the abstract representation of something you can buy or rent/subscribe to. Although the interface isn't locked down yet, this would ultimately be internal/administrative. Products likely have some user-facing skin on top of them: plans would have a purchasing/comparison flow, physical goods would have a storefront, etc., so products don't have any information like descriptions or images, just the data that Phortune needs to correctly bill accounts. Generally, this is very basic for the moment. Test Plan: {F37594} {F37595} {F37596} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5441
2013-03-28 17:13:07 +01:00
'PhortuneProductQuery' => 'applications/phortune/query/PhortuneProductQuery.php',
'PhortuneProductViewController' => 'applications/phortune/controller/PhortuneProductViewController.php',
Make payment providers a configurable property of Merchants in Phortune Summary: Ref T2787. Instead of making providers global configuration, make them a thing on merchants with web configuration. Payment methods and some of the pyament workflow needs to be retooled a bit after this, but this seemed like a reasonable cutoff point for this diff. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10649
2014-10-07 23:41:41 +02:00
'PhortuneProviderActionController' => 'applications/phortune/controller/PhortuneProviderActionController.php',
Allow merchants to disable payment providers and show more UI info Summary: Ref T2787. - Allow merchants to disable payment providers. - Show more useful information about providers on the payments page. - Make test vs live more clear. - Show merchant status. - Add a description to merchants to flesh them out a bit -- the merchant areas of responsibilities seem to be fitting well with accounts, etc. Test Plan: {F215109} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10662
2014-10-08 17:31:24 +02:00
'PhortuneProviderDisableController' => 'applications/phortune/controller/PhortuneProviderDisableController.php',
Make payment providers a configurable property of Merchants in Phortune Summary: Ref T2787. Instead of making providers global configuration, make them a thing on merchants with web configuration. Payment methods and some of the pyament workflow needs to be retooled a bit after this, but this seemed like a reasonable cutoff point for this diff. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10649
2014-10-07 23:41:41 +02:00
'PhortuneProviderEditController' => 'applications/phortune/controller/PhortuneProviderEditController.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortunePurchase' => 'applications/phortune/storage/PhortunePurchase.php',
Modernize Phortune PHID constants Summary: Ref T2787. These were still stuck in the stone ages. (The handles are pretty skeletal but most aren't used anywehre.) Test Plan: Funded an initiative without anything breaking. Grepped for removed constants. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10647
2014-10-07 01:48:16 +02:00
'PhortunePurchasePHIDType' => 'applications/phortune/phid/PhortunePurchasePHIDType.php',
Phortune Carts and Purchases Summary: Ref T2787. Make carts and purchases real objects, with storage, that kind-of work. Roughly, the idea here is that applications create "purchases" (like "1 large t-shirt") and add them to "carts" (a user can have a lot of different carts at the same time), then hand things off to Phortune to deal with actualy charging a card. Roughly this works like Paypal or other similar systems do, except Phortune is the thing the user gets handed off to. This doesn't do anything interesting/useful yet. Also fix some bugs and update some UI. Test Plan: Added a product to a cart, saw it in cart screen. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10001
2014-07-23 19:34:08 +02:00
'PhortunePurchaseQuery' => 'applications/phortune/query/PhortunePurchaseQuery.php',
Generate expected schemata for Pholio, Phortune, Phragment, Phriction and Policy Summary: Ref T1191. Nothing too out-of-the-ordinary here. Test Plan: Saw fewer than 500 remaining issues. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley, hach-que Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10587
2014-10-01 16:52:26 +02:00
'PhortuneSchemaSpec' => 'applications/phortune/storage/PhortuneSchemaSpec.php',
Add basic payment providers to Phortune Summary: Abstract out the Stripiness of payment providers so we can add a Test provider (and maybe MtGox / Balanced / Paypal / etc). Ref T2787. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5752
2013-04-25 18:45:43 +02:00
'PhortuneStripePaymentProvider' => 'applications/phortune/provider/PhortuneStripePaymentProvider.php',
Add boilerplate scaffolding for Phortune subscriptions Summary: Ref T6881. This roughs in the major objects, support classes, and controllers. - Show subscriptions on account detail. - Browse all account subscriptions. - Link to active subsciptions from merchant detail. Test Plan: Clicked around in the UI. There's no way to create subscriptions yet, so I basically just kicked the tires on this. I probably missed a few things that I'll clean up in followups. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11482
2015-01-27 23:50:20 +01:00
'PhortuneSubscription' => 'applications/phortune/storage/PhortuneSubscription.php',
Kind of generate a bill for users Summary: Ref T6881. This generates a product, purchase and invoice for users, and there's sort of some UI for them. Stuff it doesn't do yet: - Try to autobill when we have a CC; - actually tell the user they should pay it; - ask the application for anything like "how much should we charge", or tell the application anything like "the user paid". However, these work: - You can //technically// pay the invoices. - You can see the invoices you paid in the past. Test Plan: Used `bin/phriction invoice` to double-bill myself over and over again. Paid one of the invoices. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11580
2015-01-30 20:52:50 +01:00
'PhortuneSubscriptionCart' => 'applications/phortune/cart/PhortuneSubscriptionCart.php',
Automatically bill subscriptions when a payment method is available Summary: Ref T6881. - Allow users to set a default payment method for a subscription, which we'll try to autobill (not all payment methods are autobillable, so we can't require this in the general case, and a charge might fail anyway). - If a subscription has an autopay method, try to automatically bill it. - Otherwise, we'll send them an email like "hey here's a bill, it couldn't autopay for some reasons, go pay it and fix those if you want". - (That email doesn't exist yet but there's a comment about it.) - Also some UI cleanup. Test Plan: - Used `bin/phortune invoice` to autobill myself some fake test money. {F279416} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11596
2015-02-01 21:31:46 +01:00
'PhortuneSubscriptionEditController' => 'applications/phortune/controller/PhortuneSubscriptionEditController.php',
Add boilerplate scaffolding for Phortune subscriptions Summary: Ref T6881. This roughs in the major objects, support classes, and controllers. - Show subscriptions on account detail. - Browse all account subscriptions. - Link to active subsciptions from merchant detail. Test Plan: Clicked around in the UI. There's no way to create subscriptions yet, so I basically just kicked the tires on this. I probably missed a few things that I'll clean up in followups. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11482
2015-01-27 23:50:20 +01:00
'PhortuneSubscriptionImplementation' => 'applications/phortune/subscription/PhortuneSubscriptionImplementation.php',
'PhortuneSubscriptionListController' => 'applications/phortune/controller/PhortuneSubscriptionListController.php',
'PhortuneSubscriptionPHIDType' => 'applications/phortune/phid/PhortuneSubscriptionPHIDType.php',
Kind of generate a bill for users Summary: Ref T6881. This generates a product, purchase and invoice for users, and there's sort of some UI for them. Stuff it doesn't do yet: - Try to autobill when we have a CC; - actually tell the user they should pay it; - ask the application for anything like "how much should we charge", or tell the application anything like "the user paid". However, these work: - You can //technically// pay the invoices. - You can see the invoices you paid in the past. Test Plan: Used `bin/phriction invoice` to double-bill myself over and over again. Paid one of the invoices. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11580
2015-01-30 20:52:50 +01:00
'PhortuneSubscriptionProduct' => 'applications/phortune/product/PhortuneSubscriptionProduct.php',
Add boilerplate scaffolding for Phortune subscriptions Summary: Ref T6881. This roughs in the major objects, support classes, and controllers. - Show subscriptions on account detail. - Browse all account subscriptions. - Link to active subsciptions from merchant detail. Test Plan: Clicked around in the UI. There's no way to create subscriptions yet, so I basically just kicked the tires on this. I probably missed a few things that I'll clean up in followups. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11482
2015-01-27 23:50:20 +01:00
'PhortuneSubscriptionQuery' => 'applications/phortune/query/PhortuneSubscriptionQuery.php',
'PhortuneSubscriptionSearchEngine' => 'applications/phortune/query/PhortuneSubscriptionSearchEngine.php',
'PhortuneSubscriptionTableView' => 'applications/phortune/view/PhortuneSubscriptionTableView.php',
Build a very basic subscription detail page in Phortune Summary: Ref T6881. - Add a subscription detail page. Minor cosmetics: - Fix glyph, from "X" (old "X marks the spot" icon) to "diamond" (new gem icon). - Name the initial account "Default Account" instead of "Personal Account", since this seems more general. Test Plan: {F278623} And I got two full days to test that Jan 30/31 -> Feb 28 billing logic! Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11576
2015-01-30 20:28:49 +01:00
'PhortuneSubscriptionViewController' => 'applications/phortune/controller/PhortuneSubscriptionViewController.php',
Add some of a billing daemon skeleton Summary: Ref T6881. This adds the worker, and a script to make it easier to test. It doesn't actually invoice anything. I'm intentionally allowing the script to double-bill since it makes testing way easier (by letting you bill the same period over and over again), and provides a tool for recovery if billing screws up. (This diff isn't very interesting, just trying to avoid a 5K-line diff at the end.) Test Plan: Used `bin/phortune invoice ...` to get the worker to print out some date ranges which it would theoretically invoice. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11577
2015-01-30 20:29:05 +01:00
'PhortuneSubscriptionWorker' => 'applications/phortune/worker/PhortuneSubscriptionWorker.php',
Add basic payment providers to Phortune Summary: Abstract out the Stripiness of payment providers so we can add a Test provider (and maybe MtGox / Balanced / Paypal / etc). Ref T2787. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5752
2013-04-25 18:45:43 +02:00
'PhortuneTestPaymentProvider' => 'applications/phortune/provider/PhortuneTestPaymentProvider.php',
Add WePay as a one-time payment provider Summary: Ref T2787. I //think// we could also use WePay as a recurring payment provider, but this is somewhat messy (OAuth + requires account) -- basically it's "add a WePay account" instead of "add a credit card". The WePay checkout workflow is a bit upsell-y but basically reasonable. I like that their API just has a `request($method, $params)` method instead of 30,000 lines of methods for each request type. I did hit one bug; I'll send a pull for that. Test Plan: Got as far as the charge callback in testing; the rest isn't implemented for any provider yet. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5982
2013-05-22 00:34:46 +02:00
'PhortuneWePayPaymentProvider' => 'applications/phortune/provider/PhortuneWePayPaymentProvider.php',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhragmentBrowseController' => 'applications/phragment/controller/PhragmentBrowseController.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'PhragmentCanCreateCapability' => 'applications/phragment/capability/PhragmentCanCreateCapability.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhragmentConduitAPIMethod' => 'applications/phragment/conduit/PhragmentConduitAPIMethod.php',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhragmentController' => 'applications/phragment/controller/PhragmentController.php',
'PhragmentCreateController' => 'applications/phragment/controller/PhragmentCreateController.php',
'PhragmentDAO' => 'applications/phragment/storage/PhragmentDAO.php',
'PhragmentFragment' => 'applications/phragment/storage/PhragmentFragment.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhragmentFragmentPHIDType' => 'applications/phragment/phid/PhragmentFragmentPHIDType.php',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhragmentFragmentQuery' => 'applications/phragment/query/PhragmentFragmentQuery.php',
'PhragmentFragmentVersion' => 'applications/phragment/storage/PhragmentFragmentVersion.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhragmentFragmentVersionPHIDType' => 'applications/phragment/phid/PhragmentFragmentVersionPHIDType.php',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhragmentFragmentVersionQuery' => 'applications/phragment/query/PhragmentFragmentVersionQuery.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhragmentGetPatchConduitAPIMethod' => 'applications/phragment/conduit/PhragmentGetPatchConduitAPIMethod.php',
Implement update and history controllers in Phragment Summary: Depends on D7726. This adds a history controller (for viewing a list of patches associated with a fragment) and an update controller, for creating a new patch of a fragment. Test Plan: Updated and viewed history of fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7727
2013-12-07 02:56:55 +01:00
'PhragmentHistoryController' => 'applications/phragment/controller/PhragmentHistoryController.php',
Implement viewing versions and downloading patches in Phragment Summary: This adds support for viewing individual versions on a fragment as well as comparing versions and downloading diff_match_patch-based patches. It does not use the side-by-side diff format as while it works for small changes, it quickly becomes impossible to distingush what changes have been made due to the diff_match_patch format. Test Plan: Clicked on versions and downloaded patches. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7734
2013-12-08 02:14:34 +01:00
'PhragmentPatchController' => 'applications/phragment/controller/PhragmentPatchController.php',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhragmentPatchUtil' => 'applications/phragment/util/PhragmentPatchUtil.php',
Implement policies in Phragment Summary: This implements support for enforcing and setting policies in Phragment. Test Plan: Set policies and ensured they were enforced successfully. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7751
2013-12-13 04:42:12 +01:00
'PhragmentPolicyController' => 'applications/phragment/controller/PhragmentPolicyController.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhragmentQueryFragmentsConduitAPIMethod' => 'applications/phragment/conduit/PhragmentQueryFragmentsConduitAPIMethod.php',
Implement "Revert to Version" functionality in Phragment Summary: This functionality allows users to revert a fragment to a previous version from the history page. Reverting a version actually creates a new version pointing at the same file as the version being "reverted" to. In this sense it acts pretty much like Git and other distributed VCS where once you have published a commit the only way to undo your changes is to create a new commit that reverts those changes. Test Plan: Reverted a fragment to a version before it was deleted, then reverted it to when it was deleted and saw the new versions have the correct file PHIDs (including null for the deletion). Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7738
2013-12-08 21:57:53 +01:00
'PhragmentRevertController' => 'applications/phragment/controller/PhragmentRevertController.php',
Generate expected schemata for Pholio, Phortune, Phragment, Phriction and Policy Summary: Ref T1191. Nothing too out-of-the-ordinary here. Test Plan: Saw fewer than 500 remaining issues. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley, hach-que Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10587
2014-10-01 16:52:26 +02:00
'PhragmentSchemaSpec' => 'applications/phragment/storage/PhragmentSchemaSpec.php',
Implement snapshots in Phragment Summary: Ref T4212. This implements snapshots in Phragment, which allows you to take a snapshot of a fragment at a given point in time, and download a ZIP of the snapshot as it was in this state. There's also functionality for deleting and promoting snapshots. You can promote a snapshot to either the latest version or any other snapshot of the fragment. Test Plan: Clicked around, took some snapshots, promoted them to different points and deleted snapshots. Also downloaded ZIPs of the snapshots and saw the right versions coming through for all the files downloaded. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205, T4212 Differential Revision: https://secure.phabricator.com/D7741
2013-12-08 22:24:50 +01:00
'PhragmentSnapshot' => 'applications/phragment/storage/PhragmentSnapshot.php',
'PhragmentSnapshotChild' => 'applications/phragment/storage/PhragmentSnapshotChild.php',
'PhragmentSnapshotChildQuery' => 'applications/phragment/query/PhragmentSnapshotChildQuery.php',
'PhragmentSnapshotCreateController' => 'applications/phragment/controller/PhragmentSnapshotCreateController.php',
'PhragmentSnapshotDeleteController' => 'applications/phragment/controller/PhragmentSnapshotDeleteController.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhragmentSnapshotPHIDType' => 'applications/phragment/phid/PhragmentSnapshotPHIDType.php',
Implement snapshots in Phragment Summary: Ref T4212. This implements snapshots in Phragment, which allows you to take a snapshot of a fragment at a given point in time, and download a ZIP of the snapshot as it was in this state. There's also functionality for deleting and promoting snapshots. You can promote a snapshot to either the latest version or any other snapshot of the fragment. Test Plan: Clicked around, took some snapshots, promoted them to different points and deleted snapshots. Also downloaded ZIPs of the snapshots and saw the right versions coming through for all the files downloaded. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205, T4212 Differential Revision: https://secure.phabricator.com/D7741
2013-12-08 22:24:50 +01:00
'PhragmentSnapshotPromoteController' => 'applications/phragment/controller/PhragmentSnapshotPromoteController.php',
'PhragmentSnapshotQuery' => 'applications/phragment/query/PhragmentSnapshotQuery.php',
'PhragmentSnapshotViewController' => 'applications/phragment/controller/PhragmentSnapshotViewController.php',
Implement update and history controllers in Phragment Summary: Depends on D7726. This adds a history controller (for viewing a list of patches associated with a fragment) and an update controller, for creating a new patch of a fragment. Test Plan: Updated and viewed history of fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7727
2013-12-07 02:56:55 +01:00
'PhragmentUpdateController' => 'applications/phragment/controller/PhragmentUpdateController.php',
Implement viewing versions and downloading patches in Phragment Summary: This adds support for viewing individual versions on a fragment as well as comparing versions and downloading diff_match_patch-based patches. It does not use the side-by-side diff format as while it works for small changes, it quickly becomes impossible to distingush what changes have been made due to the diff_match_patch format. Test Plan: Clicked on versions and downloaded patches. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7734
2013-12-08 02:14:34 +01:00
'PhragmentVersionController' => 'applications/phragment/controller/PhragmentVersionController.php',
Implement "Download ZIP" controller for Phragment Summary: Depends on D7727. This adds support for downloading a fragment and all it's children as a ZIP file. Fragments that have children automatically become directories in the ZIP file. Test Plan: Downloaded a fragment as a ZIP and was able to extract the contents successfully. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7728
2013-12-07 03:25:22 +01:00
'PhragmentZIPController' => 'applications/phragment/controller/PhragmentZIPController.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhrequentConduitAPIMethod' => 'applications/phrequent/conduit/PhrequentConduitAPIMethod.php',
Implemented Phrequent time tracking functionality. Summary: This differential implements Phrequent's time tracking functionality for users and hooks it up to Maniphest. It also includes a basic "Time Tracked" list for the Phrequent application, where users can review what they've spent time working on. Test Plan: Apply the patch and track some things in Maniphest. They should appear in the "Time Tracked" view of Phrequent. There is also a `phrequent.show-prompt` option which toggles whether to display a prompt when tracking time. I'm unsure of whether the prompt is useful or is more likely to cause people to click "Track Time", go off and do the task and then come back to the prompt still waiting for them to confirm. A potential solution to the "accidentally clicking the button and recording 2 seconds of time" might be to show a prompt on stop if the total time is under 10 seconds, asking whether the user wants to keep or discard the tracked time. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2857 Differential Revision: https://secure.phabricator.com/D5479
2013-03-30 17:32:29 +01:00
'PhrequentController' => 'applications/phrequent/controller/PhrequentController.php',
Add a Phrequent curtain extension Summary: Fixes T10546. Some day, decades from now, we can revisit this when we iterate on Phrequent. Just don't regress for no real reason in the meantime, since it's easy enough to keep it working in reasonable shape. Test Plan: {F1169096} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10546 Differential Revision: https://secure.phabricator.com/D15461
2016-03-11 03:11:12 +01:00
'PhrequentCurtainExtension' => 'applications/phrequent/engineextension/PhrequentCurtainExtension.php',
Implemented Phrequent time tracking functionality. Summary: This differential implements Phrequent's time tracking functionality for users and hooks it up to Maniphest. It also includes a basic "Time Tracked" list for the Phrequent application, where users can review what they've spent time working on. Test Plan: Apply the patch and track some things in Maniphest. They should appear in the "Time Tracked" view of Phrequent. There is also a `phrequent.show-prompt` option which toggles whether to display a prompt when tracking time. I'm unsure of whether the prompt is useful or is more likely to cause people to click "Track Time", go off and do the task and then come back to the prompt still waiting for them to confirm. A potential solution to the "accidentally clicking the button and recording 2 seconds of time" might be to show a prompt on stop if the total time is under 10 seconds, asking whether the user wants to keep or discard the tracked time. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2857 Differential Revision: https://secure.phabricator.com/D5479
2013-03-30 17:32:29 +01:00
'PhrequentDAO' => 'applications/phrequent/storage/PhrequentDAO.php',
'PhrequentListController' => 'applications/phrequent/controller/PhrequentListController.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhrequentPopConduitAPIMethod' => 'applications/phrequent/conduit/PhrequentPopConduitAPIMethod.php',
'PhrequentPushConduitAPIMethod' => 'applications/phrequent/conduit/PhrequentPushConduitAPIMethod.php',
Update Phrequent to use new search infrastructure. Summary: This updates Phrequent to use new the search infrastructure. Now it looks like: {F60141} I've also added the policy infrastructure stubs, but it's probably not even close to being right in terms of enforcing policies (in particular being able to see time tracked against objects the user wouldn't normally be able to see). At some point I'd like to be able to filter on the objects that the time is tracked against, but I don't believe there's a tokenizer / readahead control that allows you to type any kind of object. Test Plan: Clicked around the new interface, created some custom queries and saved them. Reviewers: epriestley CC: Korvin, aran Maniphest Tasks: T3870 Differential Revision: https://secure.phabricator.com/D7163
2013-10-01 22:04:47 +02:00
'PhrequentSearchEngine' => 'applications/phrequent/query/PhrequentSearchEngine.php',
Make Phrequent time accounting aware of the stack Summary: Ref T3569. Fixes T3567. When figuring out how much time has been spent on an object, subtract "preemptive" events which interrupted the object. Also, make the UI look vaguely sane: {F72773} Test Plan: Added a bunch of unit tests, mucked around in the UI. Reviewers: btrahan Reviewed By: btrahan CC: hach-que, skyronic, aran Maniphest Tasks: T3567, T3569 Differential Revision: https://secure.phabricator.com/D7349
2013-10-18 21:47:36 +02:00
'PhrequentTimeBlock' => 'applications/phrequent/storage/PhrequentTimeBlock.php',
'PhrequentTimeBlockTestCase' => 'applications/phrequent/storage/__tests__/PhrequentTimeBlockTestCase.php',
Emit more usable results from phrequent.tracking Summary: I think this pretty much does what you would expect? The "active" item is always at the top of the stack. Test Plan: Called `phrequent.tracking` and got reasonable results. Reviewers: hach-que Reviewed By: hach-que Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9939
2014-07-17 02:12:38 +02:00
'PhrequentTimeSlices' => 'applications/phrequent/storage/PhrequentTimeSlices.php',
Implemented Phrequent time tracking functionality. Summary: This differential implements Phrequent's time tracking functionality for users and hooks it up to Maniphest. It also includes a basic "Time Tracked" list for the Phrequent application, where users can review what they've spent time working on. Test Plan: Apply the patch and track some things in Maniphest. They should appear in the "Time Tracked" view of Phrequent. There is also a `phrequent.show-prompt` option which toggles whether to display a prompt when tracking time. I'm unsure of whether the prompt is useful or is more likely to cause people to click "Track Time", go off and do the task and then come back to the prompt still waiting for them to confirm. A potential solution to the "accidentally clicking the button and recording 2 seconds of time" might be to show a prompt on stop if the total time is under 10 seconds, asking whether the user wants to keep or discard the tracked time. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2857 Differential Revision: https://secure.phabricator.com/D5479
2013-03-30 17:32:29 +01:00
'PhrequentTrackController' => 'applications/phrequent/controller/PhrequentTrackController.php',
'PhrequentTrackableInterface' => 'applications/phrequent/interface/PhrequentTrackableInterface.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhrequentTrackingConduitAPIMethod' => 'applications/phrequent/conduit/PhrequentTrackingConduitAPIMethod.php',
Conduit APIs to start and stop tracking time in phrequent Summary: This adds methods to start and stop tracking any arbitrary PHID in phrequent. Currently, this uses copy-pasted code from PhrequentTrackController. I had to do this because the code to start/stop was not abstracted into a common class. Once the code to start/stop working is extracted into a re-usable class, the conduit API can use this as well. Test Plan: I called the functions with a PHID of a task and ensured that the fields in the phrequent database table was being updated correctly. Reviewers: skyronic, #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: maxhodak, erik.fercak, aran, epriestley, Korvin Maniphest Tasks: T3569, T3970 Differential Revision: https://secure.phabricator.com/D7326
2014-07-12 03:42:32 +02:00
'PhrequentTrackingEditor' => 'applications/phrequent/editor/PhrequentTrackingEditor.php',
Implemented Phrequent time tracking functionality. Summary: This differential implements Phrequent's time tracking functionality for users and hooks it up to Maniphest. It also includes a basic "Time Tracked" list for the Phrequent application, where users can review what they've spent time working on. Test Plan: Apply the patch and track some things in Maniphest. They should appear in the "Time Tracked" view of Phrequent. There is also a `phrequent.show-prompt` option which toggles whether to display a prompt when tracking time. I'm unsure of whether the prompt is useful or is more likely to cause people to click "Track Time", go off and do the task and then come back to the prompt still waiting for them to confirm. A potential solution to the "accidentally clicking the button and recording 2 seconds of time" might be to show a prompt on stop if the total time is under 10 seconds, asking whether the user wants to keep or discard the tracked time. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2857 Differential Revision: https://secure.phabricator.com/D5479
2013-03-30 17:32:29 +01:00
'PhrequentUIEventListener' => 'applications/phrequent/event/PhrequentUIEventListener.php',
'PhrequentUserTime' => 'applications/phrequent/storage/PhrequentUserTime.php',
'PhrequentUserTimeQuery' => 'applications/phrequent/query/PhrequentUserTimeQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhrictionChangeType' => 'applications/phriction/constants/PhrictionChangeType.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhrictionConduitAPIMethod' => 'applications/phriction/conduit/PhrictionConduitAPIMethod.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhrictionConstants' => 'applications/phriction/constants/PhrictionConstants.php',
'PhrictionContent' => 'applications/phriction/storage/PhrictionContent.php',
'PhrictionController' => 'applications/phriction/controller/PhrictionController.php',
Phriction - add "create" conduit endpoint Summary: Fixes T6262. Ref T4029. Also gets us ready for T5873 for these end points. I can file something new about someday adding phriction.query, etc but I think we'll remember and can look at that post T5873. Test Plan: made a document via conduit and it worked! Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6262, T4029 Differential Revision: https://secure.phabricator.com/D10813
2014-11-07 20:46:25 +01:00
'PhrictionCreateConduitAPIMethod' => 'applications/phriction/conduit/PhrictionCreateConduitAPIMethod.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhrictionDAO' => 'applications/phriction/storage/PhrictionDAO.php',
'PhrictionDeleteController' => 'applications/phriction/controller/PhrictionDeleteController.php',
'PhrictionDiffController' => 'applications/phriction/controller/PhrictionDiffController.php',
'PhrictionDocument' => 'applications/phriction/storage/PhrictionDocument.php',
Modularize all remaining Phriction Herald fields Summary: Ref T8726. Test Plan: - Created a rule using all the fields. - Updated documents, saw rule apply, reviewed transcript. - Migrated stuff. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13514
2015-07-06 22:17:50 +02:00
'PhrictionDocumentAuthorHeraldField' => 'applications/phriction/herald/PhrictionDocumentAuthorHeraldField.php',
'PhrictionDocumentContentHeraldField' => 'applications/phriction/herald/PhrictionDocumentContentHeraldField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhrictionDocumentController' => 'applications/phriction/controller/PhrictionDocumentController.php',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhrictionDocumentFulltextEngine' => 'applications/phriction/search/PhrictionDocumentFulltextEngine.php',
T4666, Support Herald in Phriction Summary: Fixes T4666, add Herald rules to Phriction Documents Test Plan: add Herald rule to flag if title contains "xyz", create Phriction Document with title "xyz". Phriction Document should be flagged. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T4666 Differential Revision: https://secure.phabricator.com/D10830
2014-11-12 03:29:36 +01:00
'PhrictionDocumentHeraldAdapter' => 'applications/phriction/herald/PhrictionDocumentHeraldAdapter.php',
Modularize all remaining Phriction Herald fields Summary: Ref T8726. Test Plan: - Created a rule using all the fields. - Updated documents, saw rule apply, reviewed transcript. - Migrated stuff. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13514
2015-07-06 22:17:50 +02:00
'PhrictionDocumentHeraldField' => 'applications/phriction/herald/PhrictionDocumentHeraldField.php',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'PhrictionDocumentHeraldFieldGroup' => 'applications/phriction/herald/PhrictionDocumentHeraldFieldGroup.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhrictionDocumentPHIDType' => 'applications/phriction/phid/PhrictionDocumentPHIDType.php',
Modularize all remaining Phriction Herald fields Summary: Ref T8726. Test Plan: - Created a rule using all the fields. - Updated documents, saw rule apply, reviewed transcript. - Migrated stuff. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13514
2015-07-06 22:17:50 +02:00
'PhrictionDocumentPathHeraldField' => 'applications/phriction/herald/PhrictionDocumentPathHeraldField.php',
Implement PhrictionDocumentQuery Summary: Companion for D5284. Move all the query logic to a policy-aware query class. In particular: - Currently, anyone can view and edit a project's wiki documents. For callsites using this query class, you must be able to view or edit the project to view or edit its documents. - There's some very sketchy logic with the content/document joins. This cleans that up. - This cleans up loading projects by moving it inside the query. We need to do this anyway to perform policy checks. Test Plan: Viewed active/all/updated. Set page size to 2, verified pager works. Reviewers: AnhNhan, chad Reviewed By: AnhNhan CC: aran Differential Revision: https://secure.phabricator.com/D5285
2013-03-08 16:12:24 +01:00
'PhrictionDocumentQuery' => 'applications/phriction/query/PhrictionDocumentQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhrictionDocumentStatus' => 'applications/phriction/constants/PhrictionDocumentStatus.php',
Modularize all remaining Phriction Herald fields Summary: Ref T8726. Test Plan: - Created a rule using all the fields. - Updated documents, saw rule apply, reviewed transcript. - Migrated stuff. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13514
2015-07-06 22:17:50 +02:00
'PhrictionDocumentTitleHeraldField' => 'applications/phriction/herald/PhrictionDocumentTitleHeraldField.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhrictionEditConduitAPIMethod' => 'applications/phriction/conduit/PhrictionEditConduitAPIMethod.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhrictionEditController' => 'applications/phriction/controller/PhrictionEditController.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhrictionHistoryConduitAPIMethod' => 'applications/phriction/conduit/PhrictionHistoryConduitAPIMethod.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhrictionHistoryController' => 'applications/phriction/controller/PhrictionHistoryController.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhrictionInfoConduitAPIMethod' => 'applications/phriction/conduit/PhrictionInfoConduitAPIMethod.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhrictionListController' => 'applications/phriction/controller/PhrictionListController.php',
Support relative links in Phriction Summary: Resolves T7691. This turned out more complex than I really wanted, mainly because I needed to feed the slug information through to both the document renderer and the preview window that appears in the edit controller. After this change, you can now create relative links in Phriction by doing `[[ ./../some/relative/path ]]`. Relative paths aren't handled anywhere else (they'll still render, but the dots are turned into a literal 'dot' as per existing behaviour). Test Plan: Created some Phriction documents with relative links, saw them all link correctly. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Maniphest Tasks: T7691 Differential Revision: https://secure.phabricator.com/D15732
2016-04-16 04:07:03 +02:00
'PhrictionMarkupPreviewController' => 'applications/phriction/controller/PhrictionMarkupPreviewController.php',
Phriction Documents can be moved Summary: Refs T1575 Test Plan: created plenty of pages, did all kind of stuff with them, moved them around, verified expected behaviour. {F34453} {F34455} Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, epriestley, Korvin Maniphest Tasks: T1575 Differential Revision: https://secure.phabricator.com/D5198
2013-03-06 22:12:04 +01:00
'PhrictionMoveController' => 'applications/phriction/controller/PhrictionMoveController.php',
Create a "New Document" button in phriction Summary: gives user a dialogue and they can fill out what comes after /w/ Test Plan: made some new wiki docs. played with garbage data and edit scenarios as well as vanilla create -- good ish Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1360 Differential Revision: https://secure.phabricator.com/D3946
2012-11-10 00:08:37 +01:00
'PhrictionNewController' => 'applications/phriction/controller/PhrictionNewController.php',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhrictionRemarkupRule' => 'applications/phriction/markup/PhrictionRemarkupRule.php',
Phriction - start the move towards transactions and an editor Summary: This implements as little as possible to stick a working transactions + editor codepath in the basic create / edit flow. Aside from the transaction tables, this also required adding a mailKey to a phrictionDocument. Future work would include adding more transactions types for things like "move" and all the pertinent support. Even future work is to add things like policies which will work easily in the transaction framework. Ref T4029. Test Plan: - made a wiki doc - edit a wiki doc - had someone subscribe to a wiki doc and edited it For all three, the edits worked, a reasonable email was sent out, and feed stories were generated. - made a wiki doc at a /location/like/this document "stubs" were made as expected in /location and /location/like Reviewers: epriestley Reviewed By: epriestley Subscribers: chad, Korvin, epriestley Maniphest Tasks: T4029 Differential Revision: https://secure.phabricator.com/D10756
2014-10-30 16:59:21 +01:00
'PhrictionReplyHandler' => 'applications/phriction/mail/PhrictionReplyHandler.php',
Generate expected schemata for Pholio, Phortune, Phragment, Phriction and Policy Summary: Ref T1191. Nothing too out-of-the-ordinary here. Test Plan: Saw fewer than 500 remaining issues. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley, hach-que Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10587
2014-10-01 16:52:26 +02:00
'PhrictionSchemaSpec' => 'applications/phriction/storage/PhrictionSchemaSpec.php',
Add breadcrumbs and ApplicationSearch to Phriction Summary: Fixes T3631. Also adds ApplicationSearch. Test Plan: Viewed "New", "Edit"; saw breadcrumbs. Viewed "index", saw application search. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T3631 Differential Revision: https://secure.phabricator.com/D6593
2013-07-28 03:26:42 +02:00
'PhrictionSearchEngine' => 'applications/phriction/query/PhrictionSearchEngine.php',
Phriction - start the move towards transactions and an editor Summary: This implements as little as possible to stick a working transactions + editor codepath in the basic create / edit flow. Aside from the transaction tables, this also required adding a mailKey to a phrictionDocument. Future work would include adding more transactions types for things like "move" and all the pertinent support. Even future work is to add things like policies which will work easily in the transaction framework. Ref T4029. Test Plan: - made a wiki doc - edit a wiki doc - had someone subscribe to a wiki doc and edited it For all three, the edits worked, a reasonable email was sent out, and feed stories were generated. - made a wiki doc at a /location/like/this document "stubs" were made as expected in /location and /location/like Reviewers: epriestley Reviewed By: epriestley Subscribers: chad, Korvin, epriestley Maniphest Tasks: T4029 Differential Revision: https://secure.phabricator.com/D10756
2014-10-30 16:59:21 +01:00
'PhrictionTransaction' => 'applications/phriction/storage/PhrictionTransaction.php',
'PhrictionTransactionComment' => 'applications/phriction/storage/PhrictionTransactionComment.php',
'PhrictionTransactionEditor' => 'applications/phriction/editor/PhrictionTransactionEditor.php',
'PhrictionTransactionQuery' => 'applications/phriction/query/PhrictionTransactionQuery.php',
Config - add an option to lock policy settings Summary: Fixes T6947 Test Plan: locked people.create.user and noted the UI only showed a link to the existing policy with no way to edit it. tried to set the config to all the various bad things and saw helpful error messages telling me what I did wrong. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6947 Differential Revision: https://secure.phabricator.com/D11358
2015-01-13 20:46:29 +01:00
'PolicyLockOptionType' => 'applications/policy/config/PolicyLockOptionType.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderAddAnswerView' => 'applications/ponder/view/PonderAddAnswerView.php',
'PonderAnswer' => 'applications/ponder/storage/PonderAnswer.php',
Restore comments on Ponder answers Summary: Ref T3373. This is still pretty messy: - The JS bugs out a bit with multiple primary object PHIDs on a single page. I'll fix this in a followup. - The comment form itself is enormous, I'll restore some show/hide stuff in a followup. Test Plan: Added answer comments in Ponder. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6608
2013-07-29 02:40:11 +02:00
'PonderAnswerCommentController' => 'applications/ponder/controller/PonderAnswerCommentController.php',
Allow ponder answers to be edited Summary: Ref T3373. Use applicationtransactions to edit ponder answers. Also enable tokens and subscriptions. Test Plan: edited an answer Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6607
2013-07-29 02:23:04 +02:00
'PonderAnswerEditController' => 'applications/ponder/controller/PonderAnswerEditController.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderAnswerEditor' => 'applications/ponder/editor/PonderAnswerEditor.php',
Move non-comment transactions to a separate history view in Ponder Summary: Ref T3373. Most edits aren't too interesting, put them on a separate history page. Test Plan: Viewed question page; viewed history page for question and answer. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6612
2013-07-29 03:32:55 +02:00
'PonderAnswerHistoryController' => 'applications/ponder/controller/PonderAnswerHistoryController.php',
Add ability to reply to Ponder Answer emails Summary: Ref T9068, Ref T3846. Maybe fixes both, but I'm having issues testing email replies in a sandbox. Moves answer feed/mail generation to the AnswerEditor, hides it in QuestionEditor. Test Plan: Write an answer, see feed story, check /mail/ for mail generation. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T3846, T9068 Differential Revision: https://secure.phabricator.com/D13905
2015-08-17 19:22:54 +02:00
'PonderAnswerMailReceiver' => 'applications/ponder/mail/PonderAnswerMailReceiver.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PonderAnswerPHIDType' => 'applications/ponder/phid/PonderAnswerPHIDType.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderAnswerQuery' => 'applications/ponder/query/PonderAnswerQuery.php',
Add ability to reply to Ponder Answer emails Summary: Ref T9068, Ref T3846. Maybe fixes both, but I'm having issues testing email replies in a sandbox. Moves answer feed/mail generation to the AnswerEditor, hides it in QuestionEditor. Test Plan: Write an answer, see feed story, check /mail/ for mail generation. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T3846, T9068 Differential Revision: https://secure.phabricator.com/D13905
2015-08-17 19:22:54 +02:00
'PonderAnswerReplyHandler' => 'applications/ponder/mail/PonderAnswerReplyHandler.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderAnswerSaveController' => 'applications/ponder/controller/PonderAnswerSaveController.php',
Add ability to hide answers in Ponder Summary: Ref T9173, adds basic hide support for answers. Answer authors and Moderators can hide answers, unhide them. Test Plan: Hide answer, log into other account, see hidden message. Mark as visible, see answer again. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9173 Differential Revision: https://secure.phabricator.com/D13894
2015-08-14 18:25:02 +02:00
'PonderAnswerStatus' => 'applications/ponder/constants/PonderAnswerStatus.php',
Add question and answer transactions to Ponder Summary: Ref T3373. Test Plan: Ran this script, saw valid inserts: <?php $unguarded = AphrontWriteGuard::beginScopedUnguardedWrites(); id(new PonderQuestionTransaction()) ->setAuthorPHID('herp') ->setObjectPHID('derp') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setTransactionType('beep') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderAnswerTransaction()) ->setAuthorPHID('herp') ->setObjectPHID('derp') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setTransactionType('beep') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderQuestionTransactionComment()) ->setCommentVersion(1) ->setAuthorPHID('bloop') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setContent('blip') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderAnswerTransactionComment()) ->setCommentVersion(1) ->setAuthorPHID('bloop') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setContent('blip') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); unset($unguarded); echo "OK!\n"; Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6584
2013-07-26 22:52:57 +02:00
'PonderAnswerTransaction' => 'applications/ponder/storage/PonderAnswerTransaction.php',
'PonderAnswerTransactionComment' => 'applications/ponder/storage/PonderAnswerTransactionComment.php',
Make Ponder use ApplicationTransaction rendering for answers Summary: Ref T3373. This breaks some stuff, but future diffs will fix it. Test Plan: Viewed some questions, saw answer text. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6604
2013-07-29 01:17:51 +02:00
'PonderAnswerTransactionQuery' => 'applications/ponder/query/PonderAnswerTransactionQuery.php',
Update Ponder Answer layout Summary: Ref T9099, A step forward for the main Ponder UI. Mostly moving stuff into View classes and reducing clutter. Took a pass at keeping comments and helpfuls, but unclear what the 'final' UI will be (I'm just designing as I use the product). Test Plan: Review a number of questions and answers. {F702495} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9099 Differential Revision: https://secure.phabricator.com/D13872
2015-08-11 19:42:40 +02:00
'PonderAnswerView' => 'applications/ponder/view/PonderAnswerView.php',
Allowing Closing of questions Summary: Fixes T3579 As a basic overview, this enables the author of a question to open/close a question. Other bits; - Add "Open" filter to the builtin queries - Add "Status" to search form - Refactor ponder constants - Add coloured bars for different question statuses Test Plan: - Open/Close questions - Search for some bits - Use filters Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3579 Differential Revision: https://secure.phabricator.com/D6590 Conflicts: src/infrastructure/storage/patch/PhabricatorBuiltinPatchList.php
2013-07-28 03:37:17 +02:00
'PonderConstants' => 'applications/ponder/constants/PonderConstants.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderController' => 'applications/ponder/controller/PonderController.php',
'PonderDAO' => 'applications/ponder/storage/PonderDAO.php',
Add a default moderation policy to Ponder Summary: This allows installs to essentially set a "moderator" for Ponder, who can clean up answers. Fixes T9098 Test Plan: Edit an answer I don't own. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9098 Differential Revision: https://secure.phabricator.com/D13818
2015-08-08 21:20:01 +02:00
'PonderDefaultViewCapability' => 'applications/ponder/capability/PonderDefaultViewCapability.php',
Ponder - make feed stories and emails a bit better Summary: Also some random cleanup now and again. Note reply handler stuff is kind of bojangles bad right now. It didn't work before though either so hey. Test Plan: asked questions, answered questions, edited answers... the feed pleased my eye Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T3653 Differential Revision: https://secure.phabricator.com/D7027
2013-09-19 00:15:25 +02:00
'PonderEditor' => 'applications/ponder/editor/PonderEditor.php',
Update Ponder Answer layout Summary: Ref T9099, A step forward for the main Ponder UI. Mostly moving stuff into View classes and reducing clutter. Took a pass at keeping comments and helpfuls, but unclear what the 'final' UI will be (I'm just designing as I use the product). Test Plan: Review a number of questions and answers. {F702495} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9099 Differential Revision: https://secure.phabricator.com/D13872
2015-08-11 19:42:40 +02:00
'PonderFooterView' => 'applications/ponder/view/PonderFooterView.php',
Add a default moderation policy to Ponder Summary: This allows installs to essentially set a "moderator" for Ponder, who can clean up answers. Fixes T9098 Test Plan: Edit an answer I don't own. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9098 Differential Revision: https://secure.phabricator.com/D13818
2015-08-08 21:20:01 +02:00
'PonderModerateCapability' => 'applications/ponder/capability/PonderModerateCapability.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderQuestion' => 'applications/ponder/storage/PonderQuestion.php',
Restore Ponder question commenting Summary: Ref T3373. Same issues as the other commenting patch; it's huge and the JS is a bit buggy. Backend is fine, though. Test Plan: Made some comments on a question. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6610
2013-07-29 02:58:34 +02:00
'PonderQuestionCommentController' => 'applications/ponder/controller/PonderQuestionCommentController.php',
Make PonderQuestionEditor use ApplicationTransactions Summary: Ref T3373. Make PonderQuestions editable and use transactions. This temporarily disables some stuff: - email; - feed; - comments; - voting. I'll restore those in followups and wait to land this until they're at least mostly back online. The transactions themselves also need more string/color/icon work. Test Plan: Created and edited questions. Viewed transactions. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6601
2013-07-29 00:02:18 +02:00
'PonderQuestionEditController' => 'applications/ponder/controller/PonderQuestionEditController.php',
move ponder writes into editors; better search indexing Summary: * Moved the remaining `->save()` calls into editors * for the `PonderQuestion`, separate `attachRelated` (needed for indexing and viewing) from `attachVotes` (needed for viewing but not indexing) * Update the indexer to include comment and answer content in the search index. Test Plan: Stuff works as before. Also: add a comment or answer with some easily-identifiable text and search for it; observe that it gets indexed appropriately. Reviewers: epriestley, nh, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1869 Differential Revision: https://secure.phabricator.com/D3654
2012-10-07 23:35:01 +02:00
'PonderQuestionEditor' => 'applications/ponder/editor/PonderQuestionEditor.php',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PonderQuestionFulltextEngine' => 'applications/ponder/search/PonderQuestionFulltextEngine.php',
Move non-comment transactions to a separate history view in Ponder Summary: Ref T3373. Most edits aren't too interesting, put them on a separate history page. Test Plan: Viewed question page; viewed history page for question and answer. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6612
2013-07-29 03:32:55 +02:00
'PonderQuestionHistoryController' => 'applications/ponder/controller/PonderQuestionHistoryController.php',
Use ApplicationSearch in Ponder Summary: Ref T2625. Also modernize some other things: - Fix double-"subscribers". - Use byline and more standard date. - Modernize some of the use of crumbs and navigation. - Delete some dead / uncalled code. Test Plan: {F50669} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3578, T2625 Differential Revision: https://secure.phabricator.com/D6486
2013-07-18 21:40:51 +02:00
'PonderQuestionListController' => 'applications/ponder/controller/PonderQuestionListController.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PonderQuestionMailReceiver' => 'applications/ponder/mail/PonderQuestionMailReceiver.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PonderQuestionPHIDType' => 'applications/ponder/phid/PonderQuestionPHIDType.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderQuestionQuery' => 'applications/ponder/query/PonderQuestionQuery.php',
Restore mail to Ponder Summary: Ref T3578. Use ApplicationTransactions mail. Test Plan: {F52159} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3578 Differential Revision: https://secure.phabricator.com/D6620
2013-07-29 17:38:25 +02:00
'PonderQuestionReplyHandler' => 'applications/ponder/mail/PonderQuestionReplyHandler.php',
Use ApplicationSearch in Ponder Summary: Ref T2625. Also modernize some other things: - Fix double-"subscribers". - Use byline and more standard date. - Modernize some of the use of crumbs and navigation. - Delete some dead / uncalled code. Test Plan: {F50669} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3578, T2625 Differential Revision: https://secure.phabricator.com/D6486
2013-07-18 21:40:51 +02:00
'PonderQuestionSearchEngine' => 'applications/ponder/query/PonderQuestionSearchEngine.php',
Allowing Closing of questions Summary: Fixes T3579 As a basic overview, this enables the author of a question to open/close a question. Other bits; - Add "Open" filter to the builtin queries - Add "Status" to search form - Refactor ponder constants - Add coloured bars for different question statuses Test Plan: - Open/Close questions - Search for some bits - Use filters Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3579 Differential Revision: https://secure.phabricator.com/D6590 Conflicts: src/infrastructure/storage/patch/PhabricatorBuiltinPatchList.php
2013-07-28 03:37:17 +02:00
'PonderQuestionStatus' => 'applications/ponder/constants/PonderQuestionStatus.php',
'PonderQuestionStatusController' => 'applications/ponder/controller/PonderQuestionStatusController.php',
Add question and answer transactions to Ponder Summary: Ref T3373. Test Plan: Ran this script, saw valid inserts: <?php $unguarded = AphrontWriteGuard::beginScopedUnguardedWrites(); id(new PonderQuestionTransaction()) ->setAuthorPHID('herp') ->setObjectPHID('derp') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setTransactionType('beep') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderAnswerTransaction()) ->setAuthorPHID('herp') ->setObjectPHID('derp') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setTransactionType('beep') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderQuestionTransactionComment()) ->setCommentVersion(1) ->setAuthorPHID('bloop') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setContent('blip') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderAnswerTransactionComment()) ->setCommentVersion(1) ->setAuthorPHID('bloop') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setContent('blip') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); unset($unguarded); echo "OK!\n"; Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6584
2013-07-26 22:52:57 +02:00
'PonderQuestionTransaction' => 'applications/ponder/storage/PonderQuestionTransaction.php',
'PonderQuestionTransactionComment' => 'applications/ponder/storage/PonderQuestionTransactionComment.php',
Make PonderQuestionEditor use ApplicationTransactions Summary: Ref T3373. Make PonderQuestions editable and use transactions. This temporarily disables some stuff: - email; - feed; - comments; - voting. I'll restore those in followups and wait to land this until they're at least mostly back online. The transactions themselves also need more string/color/icon work. Test Plan: Created and edited questions. Viewed transactions. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6601
2013-07-29 00:02:18 +02:00
'PonderQuestionTransactionQuery' => 'applications/ponder/query/PonderQuestionTransactionQuery.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderQuestionViewController' => 'applications/ponder/controller/PonderQuestionViewController.php',
Pre-prepare for hovercards Summary: D5120 and followups refactor and generalize object references in Remarkup -- notably, they move remarkup rules from a central location to the implementing applications. Preserve blame by doing moves/renames only first. This change moves application remarkup rules into those applications, and renames the ones D5120 modifies. Test Plan: Typed some preview text into a textarea, got a valid Remarkup render. Reviewers: vrana, chad Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5123
2013-02-26 23:57:41 +01:00
'PonderRemarkupRule' => 'applications/ponder/remarkup/PonderRemarkupRule.php',
Generate expected Ponder schemata Summary: Ref T1191. - Removes ponder comment table. This was migrated a very long time ago. Test Plan: - Grepped for removed table. - Saw ~100 fewer issues in web UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10582
2014-10-01 16:37:14 +02:00
'PonderSchemaSpec' => 'applications/ponder/storage/PonderSchemaSpec.php',
Implement a "!projects" mail command Summary: Ref T7199. Implements `!projects` for all objects which implement `PhabricatorProjectInterface`. Test Plan: Added projects to a task via email. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12246
2015-04-01 18:40:12 +02:00
'ProjectAddProjectsEmailCommand' => 'applications/project/command/ProjectAddProjectsEmailCommand.php',
Project work boards - make editing tasks from workboards work Summary: This wasn't working. Create a little JS handler and server-side support for returning the Task in the "project card" format. Test Plan: Edited tasks from the board - they worked! Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D8392
2014-03-04 20:50:44 +01:00
'ProjectBoardTaskCard' => 'applications/project/view/ProjectBoardTaskCard.php',
Projects - add "lock membership", which prevents people from leaving Summary: Fixes T5603. Puts the toggling of locking membership into the editor so we get exceptions and all that. I think the dialogue when you try to leave a project that is locked could be a little better maybe? Right now it just says "You can't leave" and "The membership is locked" more or less; should I surface a link to the policy stuff there too? Test Plan: - made a project, toggled the "lock" setting, observed stickiness and good transactions being made - locked a project and tried to leave as a non-editor - got a dialogue letting me know i couldn't - locked a project and tried to leave as an editor - left successfully Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5603 Differential Revision: https://secure.phabricator.com/D10508
2014-09-18 20:00:50 +02:00
'ProjectCanLockProjectsCapability' => 'applications/project/capability/ProjectCanLockProjectsCapability.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ProjectConduitAPIMethod' => 'applications/project/conduit/ProjectConduitAPIMethod.php',
Workboards - add new "initialization" flow Summary: Currently, we just create a default "backlog" column if / when you visit a workboard for the first time. Post this patch, instead you see a blocking dialog that lets you either create the default backlog column or import columns from another project. In the case of the latter, the user gets another dialog which lets them select any project of which they are a member that also has columns in it. Note that only not hidden columns get imported. Fixes T4431. Test Plan: - made a new workboard and got my new dialog. made a default backlog and it worked! - made a new workboard again and tried the import flow - it also worked. - verified projects with no columns do not show up in import dialog - verified project with / without columns still all show up in maniphest project typeahead Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4431 Differential Revision: https://secure.phabricator.com/D10153
2014-08-05 22:40:41 +02:00
'ProjectCreateConduitAPIMethod' => 'applications/project/conduit/ProjectCreateConduitAPIMethod.php',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'ProjectCreateProjectsCapability' => 'applications/project/capability/ProjectCreateProjectsCapability.php',
Add default View, Edit, and Join Policies to Projects Summary: Fixes T6567, lets admins set a default policy for new Projects. Test Plan: Changed the default Policy, created a new Project. Project had correct defaults. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6567 Differential Revision: https://secure.phabricator.com/D10890
2014-11-21 20:22:17 +01:00
'ProjectDefaultEditCapability' => 'applications/project/capability/ProjectDefaultEditCapability.php',
'ProjectDefaultJoinCapability' => 'applications/project/capability/ProjectDefaultJoinCapability.php',
'ProjectDefaultViewCapability' => 'applications/project/capability/ProjectDefaultViewCapability.php',
Convert projects to EditEngine Summary: Ref T10010. This is pretty straightforward with a couple of very minor new behaviors, like the icon selector edit field. Test Plan: - Created projects. - Edited projects. - Saw "Create Project" in quick create menu. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14896
2015-12-27 15:45:53 +01:00
'ProjectEditConduitAPIMethod' => 'applications/project/conduit/ProjectEditConduitAPIMethod.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ProjectQueryConduitAPIMethod' => 'applications/project/conduit/ProjectQueryConduitAPIMethod.php',
Implement #yoloswag Summary: Ref T3190. #shipit Likely future work: - Extract project mentions from remarkup for ApplicationTransactions; this isn't relevant in any apps right now (but will be in Pholio before tooo long). Ref T3189. - Allow projects to have alternate short names. As written, this is fine for most projects ("Differential" is `#differential`) but not so great for other projects ("Phabricator Public & Media Relations" is `#phabricator_public_media_relations`). This also breaks refs when you rename a project. Better would be letting long project names have short aliases (`#pr`) as permitted alternatives. Since this mention uses `#` instead of a letter, I needed to do a small amount of regexp gymnastics. Test Plan: you only #yolo once {F43615} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3189, T3190 Differential Revision: https://secure.phabricator.com/D5954
2013-05-18 11:46:39 +02:00
'ProjectRemarkupRule' => 'applications/project/remarkup/ProjectRemarkupRule.php',
Fix project hashtag regexp to stop matching terminal periods Summary: Fixes T6416. The comment is consistent with intent, but the actual regexp doesn't quite work right. In particular, we incorrectly match `#security.` as `security.` (with a period) instead of `security` (with no period). Since this stuff is a pain to test and I evidently got it wrong in this case in D8703, make it unit testable. Test Plan: Added unit tests. Also: {F227181} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6416 Differential Revision: https://secure.phabricator.com/D10753
2014-10-29 16:13:38 +01:00
'ProjectRemarkupRuleTestCase' => 'applications/project/remarkup/__tests__/ProjectRemarkupRuleTestCase.php',
Projects - add mail to project updates Summary: ...which lets all the fancy settings for Email | Notify | Off be possible. Fixes T8164. Wasn't too sure the best way to break things up but members vs watchers felt meaningful to break out to me. Also fixes a small bug where we were generating bad slug updated stories by messing with the signature of the slug data. Perhaps this fix isn't even good enough (the array_keys()) call and instead we'll need to implement transaction has effect and do a sort? Test Plan: used ./bin/mail list-outbound and ./bin/mail show-outbound --id XX to verify reasonable emails were being generated. saw new preferences in settings. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T8164 Differential Revision: https://secure.phabricator.com/D12868
2015-05-16 01:33:31 +02:00
'ProjectReplyHandler' => 'applications/project/mail/ProjectReplyHandler.php',
Implement a basic project.search third-generation API method Summary: Ref T10010. This still needs support for attachments (to get members) and more constraints (like slugs), but mostly works. Test Plan: Ran query, saw basically sensible results. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14889
2015-12-27 11:44:07 +01:00
'ProjectSearchConduitAPIMethod' => 'applications/project/conduit/ProjectSearchConduitAPIMethod.php',
Move qsprintf() test cases from libphutil to Phabricator Summary: Also move the other tests up so they'll trigger when this stuff is touched. Test Plan: liberate Reviewers: nh, btrahan, vrana Reviewed By: nh CC: aran Maniphest Tasks: T1283 Differential Revision: https://secure.phabricator.com/D3074
2012-07-26 21:01:47 +02:00
'QueryFormattingTestCase' => 'infrastructure/storage/__tests__/QueryFormattingTestCase.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephAuthorFieldSpecification' => 'applications/releeph/field/specification/ReleephAuthorFieldSpecification.php',
'ReleephBranch' => 'applications/releeph/storage/ReleephBranch.php',
'ReleephBranchAccessController' => 'applications/releeph/controller/branch/ReleephBranchAccessController.php',
'ReleephBranchCommitFieldSpecification' => 'applications/releeph/field/specification/ReleephBranchCommitFieldSpecification.php',
Move Releeph branch controllers toward a modern/stable state Summary: Ref T3644. Ref T3657. Ref T3549. Basically: - Move these controllers to modern query/policy infrastructure. - Move them to consistent, ID-based URIs. - Rename "Project" to "Product"; "Pick Request" to "Pull Request". - Clean up a few UI things here and there. Test Plan: - Created and edited branches. - Opened and closed branches. - Viewed branch history. - Searched within a branch. - Browsed to branches from products. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3644, T3549, T3657 Differential Revision: https://secure.phabricator.com/D8646
2014-04-13 01:53:51 +02:00
'ReleephBranchController' => 'applications/releeph/controller/branch/ReleephBranchController.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephBranchCreateController' => 'applications/releeph/controller/branch/ReleephBranchCreateController.php',
'ReleephBranchEditController' => 'applications/releeph/controller/branch/ReleephBranchEditController.php',
'ReleephBranchEditor' => 'applications/releeph/editor/ReleephBranchEditor.php',
Provide a history controller for Releeph branches Summary: Ref T3663. Same as D6785, but for branches. No writes to this table yet. Test Plan: Clicked "View History", got a blank but non-broken page. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3663 Differential Revision: https://secure.phabricator.com/D6787
2013-08-20 19:11:52 +02:00
'ReleephBranchHistoryController' => 'applications/releeph/controller/branch/ReleephBranchHistoryController.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephBranchNamePreviewController' => 'applications/releeph/controller/branch/ReleephBranchNamePreviewController.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'ReleephBranchPHIDType' => 'applications/releeph/phid/ReleephBranchPHIDType.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephBranchPreviewView' => 'applications/releeph/view/branch/ReleephBranchPreviewView.php',
Use application PHIDs in Releeph, plus more Summary: Ref T2715. Ref T3551. Ref T603. This does a few things, but they're all sort of small: - We commonly use a `getX()` / `attachX()` pattern, but have very similar code in the `getX()` method every time. Provide a convenience method to make this pattern easier to write. - We use `willFilterPage()` in many queries, but it currently is called with zero or more results. This means we have a lot of "if no results, return nothing" boilerplate. Make it call only for one or more results. - Implement `PhabricatorPolicyInterface` on `ReleephBranch`. A branch has the same policy as its project. - Implement `ReleephBranchQuery`. - Move the branch PHID type to application PHID infrastructure. Test Plan: Browsed Releeph. Used `phid.query` to query branch PHIDs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2715, T3551 Differential Revision: https://secure.phabricator.com/D6512
2013-07-21 18:27:00 +02:00
'ReleephBranchQuery' => 'applications/releeph/query/ReleephBranchQuery.php',
Use ApplicationSearch for Releeph branch lists Summary: Releeph branch lists in project views have a bunch of custom UI right now; give them more standard UI and ApplicationSearch. This drops a small piece of functionality: we now show only a total open request count instead of a detailed enumeration of each request status. I assume this is reasonable (that is, the important piece is "is there something to do on this branch?"), but we can muck with it if the more detailed status is important. Test Plan: {F54344} Reviewers: btrahan Reviewed By: btrahan CC: LegNeato, aran Maniphest Tasks: T3656 Differential Revision: https://secure.phabricator.com/D6764
2013-08-17 03:55:35 +02:00
'ReleephBranchSearchEngine' => 'applications/releeph/query/ReleephBranchSearchEngine.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephBranchTemplate' => 'applications/releeph/view/branch/ReleephBranchTemplate.php',
Remove ReleephBranchBoxView Summary: Ref T3092. This was obsoleted recently and has no more call/use sites. Test Plan: `grep` Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3092 Differential Revision: https://secure.phabricator.com/D6779
2013-08-20 18:31:27 +02:00
'ReleephBranchTransaction' => 'applications/releeph/storage/ReleephBranchTransaction.php',
Provide a history controller for Releeph branches Summary: Ref T3663. Same as D6785, but for branches. No writes to this table yet. Test Plan: Clicked "View History", got a blank but non-broken page. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3663 Differential Revision: https://secure.phabricator.com/D6787
2013-08-20 19:11:52 +02:00
'ReleephBranchTransactionQuery' => 'applications/releeph/query/ReleephBranchTransactionQuery.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephBranchViewController' => 'applications/releeph/controller/branch/ReleephBranchViewController.php',
'ReleephCommitFinder' => 'applications/releeph/commitfinder/ReleephCommitFinder.php',
'ReleephCommitFinderException' => 'applications/releeph/commitfinder/ReleephCommitFinderException.php',
'ReleephCommitMessageFieldSpecification' => 'applications/releeph/field/specification/ReleephCommitMessageFieldSpecification.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ReleephConduitAPIMethod' => 'applications/releeph/conduit/ReleephConduitAPIMethod.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephController' => 'applications/releeph/controller/ReleephController.php',
'ReleephDAO' => 'applications/releeph/storage/ReleephDAO.php',
'ReleephDefaultFieldSelector' => 'applications/releeph/field/selector/ReleephDefaultFieldSelector.php',
Add dependencies to releeph Summary: Add the 'Depends On' field to releeph requests. This will help the release engineers to be aware of the dependencies and make sure pick them altogether. Test Plan: Check sandbox. This field shows up when a revision has some dependencies. Reviewers: JoelB, lifeihuang, epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7946
2014-01-14 03:18:26 +01:00
'ReleephDependsOnFieldSpecification' => 'applications/releeph/field/specification/ReleephDependsOnFieldSpecification.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephDiffChurnFieldSpecification' => 'applications/releeph/field/specification/ReleephDiffChurnFieldSpecification.php',
'ReleephDiffMessageFieldSpecification' => 'applications/releeph/field/specification/ReleephDiffMessageFieldSpecification.php',
'ReleephDiffSizeFieldSpecification' => 'applications/releeph/field/specification/ReleephDiffSizeFieldSpecification.php',
'ReleephFieldParseException' => 'applications/releeph/field/exception/ReleephFieldParseException.php',
'ReleephFieldSelector' => 'applications/releeph/field/selector/ReleephFieldSelector.php',
'ReleephFieldSpecification' => 'applications/releeph/field/specification/ReleephFieldSpecification.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ReleephGetBranchesConduitAPIMethod' => 'applications/releeph/conduit/ReleephGetBranchesConduitAPIMethod.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephIntentFieldSpecification' => 'applications/releeph/field/specification/ReleephIntentFieldSpecification.php',
'ReleephLevelFieldSpecification' => 'applications/releeph/field/specification/ReleephLevelFieldSpecification.php',
'ReleephOriginalCommitFieldSpecification' => 'applications/releeph/field/specification/ReleephOriginalCommitFieldSpecification.php',
Move /project/ controllers to /product/ Summary: Ref T3549. Move only, no extra changes. Test Plan: Loaded application. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8817
2014-04-20 20:54:37 +02:00
'ReleephProductActionController' => 'applications/releeph/controller/product/ReleephProductActionController.php',
'ReleephProductController' => 'applications/releeph/controller/product/ReleephProductController.php',
'ReleephProductCreateController' => 'applications/releeph/controller/product/ReleephProductCreateController.php',
'ReleephProductEditController' => 'applications/releeph/controller/product/ReleephProductEditController.php',
Use ApplicationTransactions for Releeph product activity Summary: Ref T3549. Ref T3663. - Use transactions for activate/deactivate. - Rename some "project" -> "product". Test Plan: - Activated products. - Deactivated products. {F135480} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3663, T3549 Differential Revision: https://secure.phabricator.com/D8634
2014-03-29 17:16:02 +01:00
'ReleephProductEditor' => 'applications/releeph/editor/ReleephProductEditor.php',
Move /project/ controllers to /product/ Summary: Ref T3549. Move only, no extra changes. Test Plan: Loaded application. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8817
2014-04-20 20:54:37 +02:00
'ReleephProductHistoryController' => 'applications/releeph/controller/product/ReleephProductHistoryController.php',
'ReleephProductListController' => 'applications/releeph/controller/product/ReleephProductListController.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'ReleephProductPHIDType' => 'applications/releeph/phid/ReleephProductPHIDType.php',
Rename ReleephProjectQuery to ReleephProductQuery Summary: Ref T3549. Test Plan: grep/lint Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8815
2014-04-20 20:51:02 +02:00
'ReleephProductQuery' => 'applications/releeph/query/ReleephProductQuery.php',
Rename more project -> product in Releeph Summary: Ref T3549. - Renames most "project" in view/list controllers. - Moves away from "ProjectController". - Modernizes some modern UI. Test Plan: - Viewed product lists. - Viewed product detail pages. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8635
2014-03-29 17:16:24 +01:00
'ReleephProductSearchEngine' => 'applications/releeph/query/ReleephProductSearchEngine.php',
Rename Releeph "Project" transactions to "Product" Summary: Ref T3549. This table isn't written to yet; rename it and the DAOs and modernize the history controller. Test Plan: Viewed history page for a product. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8633
2014-03-29 17:15:09 +01:00
'ReleephProductTransaction' => 'applications/releeph/storage/ReleephProductTransaction.php',
'ReleephProductTransactionQuery' => 'applications/releeph/query/ReleephProductTransactionQuery.php',
Move /project/ controllers to /product/ Summary: Ref T3549. Move only, no extra changes. Test Plan: Loaded application. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8817
2014-04-20 20:54:37 +02:00
'ReleephProductViewController' => 'applications/releeph/controller/product/ReleephProductViewController.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephProject' => 'applications/releeph/storage/ReleephProject.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ReleephQueryBranchesConduitAPIMethod' => 'applications/releeph/conduit/ReleephQueryBranchesConduitAPIMethod.php',
Fix a file misnaming Summary: This class was renamed in D9991 but the filename is incorrect. Test Plan: Eyeball it Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D10118
2014-08-02 09:36:34 +02:00
'ReleephQueryProductsConduitAPIMethod' => 'applications/releeph/conduit/ReleephQueryProductsConduitAPIMethod.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ReleephQueryRequestsConduitAPIMethod' => 'applications/releeph/conduit/ReleephQueryRequestsConduitAPIMethod.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephReasonFieldSpecification' => 'applications/releeph/field/specification/ReleephReasonFieldSpecification.php',
'ReleephRequest' => 'applications/releeph/storage/ReleephRequest.php',
'ReleephRequestActionController' => 'applications/releeph/controller/request/ReleephRequestActionController.php',
ReleephRequest xactions Summary: Migrate to `PhabricatorApplicationTransactions` (`ReleephRequestTransactions` applied by `ReleephRequestTransactionalEditor`, instead of `ReleephRequestEvents` created by `ReleephRequestEditor`) and migrate all the old events into transactions. Email is supported in the standard way (no more `ReleephRequestMail`) as well. This also collapses the Releeph request create and edit controllers into one class, as well as breaking everyone's subject-based mail rules by standardising them (but which should be more easily filtered by looking at headers.) Test Plan: * Make requests, then pick them. * Pick and revert the same request so that discovery happens way after `arc` has told Releeph about what's been happening. * Try to pick something that fails to pick in a project with pick instructions (and see the instructions are in the email.) * Load all of FB's Releeph data into my DB and run the `storage upgrade` script. * Request a commit via the "action" in a Differential revision. Reviewers: epriestley Reviewed By: epriestley CC: epriestley, aran, Korvin, wez Maniphest Tasks: T3092, T2720 Differential Revision: https://secure.phabricator.com/D5868
2013-04-08 17:34:21 +02:00
'ReleephRequestCommentController' => 'applications/releeph/controller/request/ReleephRequestCommentController.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ReleephRequestConduitAPIMethod' => 'applications/releeph/conduit/ReleephRequestConduitAPIMethod.php',
Remove ReleephProjectController Summary: Ref T3657. General changes here: - Removes `ReleephProjectController`, which is the source of T3657. - Mostly moves requests from "RQ" as a monogram to "Y" (looks like a merge, mnemonic for "yank"?, we don't have too many characters left). This should be essentially only cosmetic. This reduces ambiguity with "rQ" and "R123", which are current and future repository monograms. This will continue in the next few diffs. - Makes requests implement policies correctly. Test Plan: Created, edited, browsed requests. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3657 Differential Revision: https://secure.phabricator.com/D8766
2014-04-14 21:06:56 +02:00
'ReleephRequestController' => 'applications/releeph/controller/request/ReleephRequestController.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephRequestDifferentialCreateController' => 'applications/releeph/controller/request/ReleephRequestDifferentialCreateController.php',
'ReleephRequestEditController' => 'applications/releeph/controller/request/ReleephRequestEditController.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ReleephRequestMailReceiver' => 'applications/releeph/mail/ReleephRequestMailReceiver.php',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'ReleephRequestPHIDType' => 'applications/releeph/phid/ReleephRequestPHIDType.php',
Add unit tests to cover PhabricatorMailReceiver::matchAddresses() Summary: Ref T3183. We should accept addresses like `"New Bug" <bugs@example.com>` to match `bugs@example.com`. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3183 Differential Revision: https://secure.phabricator.com/D5923
2013-05-15 00:04:17 +02:00
'ReleephRequestQuery' => 'applications/releeph/query/ReleephRequestQuery.php',
ReleephRequest xactions Summary: Migrate to `PhabricatorApplicationTransactions` (`ReleephRequestTransactions` applied by `ReleephRequestTransactionalEditor`, instead of `ReleephRequestEvents` created by `ReleephRequestEditor`) and migrate all the old events into transactions. Email is supported in the standard way (no more `ReleephRequestMail`) as well. This also collapses the Releeph request create and edit controllers into one class, as well as breaking everyone's subject-based mail rules by standardising them (but which should be more easily filtered by looking at headers.) Test Plan: * Make requests, then pick them. * Pick and revert the same request so that discovery happens way after `arc` has told Releeph about what's been happening. * Try to pick something that fails to pick in a project with pick instructions (and see the instructions are in the email.) * Load all of FB's Releeph data into my DB and run the `storage upgrade` script. * Request a commit via the "action" in a Differential revision. Reviewers: epriestley Reviewed By: epriestley CC: epriestley, aran, Korvin, wez Maniphest Tasks: T3092, T2720 Differential Revision: https://secure.phabricator.com/D5868
2013-04-08 17:34:21 +02:00
'ReleephRequestReplyHandler' => 'applications/releeph/mail/ReleephRequestReplyHandler.php',
Use ApplicationSearch in ReleephBranchView Summary: Ref T3721. Releeph currently attempts to implement a flexible, field-driven search for branches, but it's building all of its own infrastructure and it ends up heading down some weird paths. In particular, it loads **every** request and then makes calls into fields to filter them. It also tries to be very very general, which isn't really necessary (for example, I think it's reasonable for us to assume that we won't let you disable the "requestor" field). ApplicationSearch and CustomField provide more scalable approaches to this problem; move search on top of them. The query still ends up doing some filtering in-process, but it's now far more limited in scope and can be denormalized later. Test Plan: {F54304} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T3721 Differential Revision: https://secure.phabricator.com/D6758
2013-08-15 00:38:52 +02:00
'ReleephRequestSearchEngine' => 'applications/releeph/query/ReleephRequestSearchEngine.php',
ReleephRequestStatus Summary: This is just a bit of gardening in order to make the responsive-UI diff easier; I'll be putting `getColorFor($status)` type things in this class, following the pattern in `ManiphestTaskStatus`. Test Plan: Poke around Releeph. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5893
2013-05-10 18:07:33 +02:00
'ReleephRequestStatus' => 'applications/releeph/constants/ReleephRequestStatus.php',
ReleephRequest xactions Summary: Migrate to `PhabricatorApplicationTransactions` (`ReleephRequestTransactions` applied by `ReleephRequestTransactionalEditor`, instead of `ReleephRequestEvents` created by `ReleephRequestEditor`) and migrate all the old events into transactions. Email is supported in the standard way (no more `ReleephRequestMail`) as well. This also collapses the Releeph request create and edit controllers into one class, as well as breaking everyone's subject-based mail rules by standardising them (but which should be more easily filtered by looking at headers.) Test Plan: * Make requests, then pick them. * Pick and revert the same request so that discovery happens way after `arc` has told Releeph about what's been happening. * Try to pick something that fails to pick in a project with pick instructions (and see the instructions are in the email.) * Load all of FB's Releeph data into my DB and run the `storage upgrade` script. * Request a commit via the "action" in a Differential revision. Reviewers: epriestley Reviewed By: epriestley CC: epriestley, aran, Korvin, wez Maniphest Tasks: T3092, T2720 Differential Revision: https://secure.phabricator.com/D5868
2013-04-08 17:34:21 +02:00
'ReleephRequestTransaction' => 'applications/releeph/storage/ReleephRequestTransaction.php',
'ReleephRequestTransactionComment' => 'applications/releeph/storage/ReleephRequestTransactionComment.php',
'ReleephRequestTransactionQuery' => 'applications/releeph/query/ReleephRequestTransactionQuery.php',
'ReleephRequestTransactionalEditor' => 'applications/releeph/editor/ReleephRequestTransactionalEditor.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephRequestTypeaheadControl' => 'applications/releeph/view/request/ReleephRequestTypeaheadControl.php',
'ReleephRequestTypeaheadController' => 'applications/releeph/controller/request/ReleephRequestTypeaheadController.php',
Use standard UI elements to render pull requests in Releeph Summary: Ref T3718. Ref T3644. Ref T3092. Switches from the Releeph UI elements to standard ones. I'll attach some screenshots. Also fixes CSRF against the request action endpoint. Test Plan: - Viewed request details. - Took actions on a request from detail page. - Viewed request list. - Took actions on a request from list page. - Used keyboard shortcuts to navigate list. - Used keyboard shortcuts to take actions. - Simulated errors. - Viewed on devices. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: grp, FacebookPOC, mattlqx, tala, beng, LegNeato, epriestley Maniphest Tasks: T3718, T3092, T3644 Differential Revision: https://secure.phabricator.com/D8771
2014-04-18 15:44:45 +02:00
'ReleephRequestView' => 'applications/releeph/view/ReleephRequestView.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephRequestViewController' => 'applications/releeph/controller/request/ReleephRequestViewController.php',
'ReleephRequestorFieldSpecification' => 'applications/releeph/field/specification/ReleephRequestorFieldSpecification.php',
'ReleephRevisionFieldSpecification' => 'applications/releeph/field/specification/ReleephRevisionFieldSpecification.php',
'ReleephSeverityFieldSpecification' => 'applications/releeph/field/specification/ReleephSeverityFieldSpecification.php',
'ReleephSummaryFieldSpecification' => 'applications/releeph/field/specification/ReleephSummaryFieldSpecification.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ReleephWorkCanPushConduitAPIMethod' => 'applications/releeph/conduit/work/ReleephWorkCanPushConduitAPIMethod.php',
'ReleephWorkGetAuthorInfoConduitAPIMethod' => 'applications/releeph/conduit/work/ReleephWorkGetAuthorInfoConduitAPIMethod.php',
'ReleephWorkGetBranchCommitMessageConduitAPIMethod' => 'applications/releeph/conduit/work/ReleephWorkGetBranchCommitMessageConduitAPIMethod.php',
'ReleephWorkGetBranchConduitAPIMethod' => 'applications/releeph/conduit/work/ReleephWorkGetBranchConduitAPIMethod.php',
'ReleephWorkGetCommitMessageConduitAPIMethod' => 'applications/releeph/conduit/work/ReleephWorkGetCommitMessageConduitAPIMethod.php',
'ReleephWorkNextRequestConduitAPIMethod' => 'applications/releeph/conduit/work/ReleephWorkNextRequestConduitAPIMethod.php',
'ReleephWorkRecordConduitAPIMethod' => 'applications/releeph/conduit/work/ReleephWorkRecordConduitAPIMethod.php',
'ReleephWorkRecordPickStatusConduitAPIMethod' => 'applications/releeph/conduit/work/ReleephWorkRecordPickStatusConduitAPIMethod.php',
'RemarkupProcessConduitAPIMethod' => 'applications/remarkup/conduit/RemarkupProcessConduitAPIMethod.php',
'RepositoryConduitAPIMethod' => 'applications/repository/conduit/RepositoryConduitAPIMethod.php',
'RepositoryQueryConduitAPIMethod' => 'applications/repository/conduit/RepositoryQueryConduitAPIMethod.php',
Implemented support for build logs Summary: Depends on D7519. This implements support for build logs in Harbormaster. This includes support for appending to a log from the "Run Remote Command" build step. It also adds the ability to cancel builds. Currently the build view page doesn't update the logs live; I'm sure this can be achieved with Javelin, but I don't have enough experience with Javelin to actually make it poll from updates to content in the background. {F79151} {F79153} {F79150} {F79152} Test Plan: Tested this by setting up SSH on a Windows machine and using a Remote Command configured with: ``` C:\Windows\system32\cmd.exe /C cd C:\Build && mkdir Build_${timestamp} && cd Build_${timestamp} && git clone --recursive https://github.com/hach-que/Tychaia.git && cd Tychaia && Protobuild.exe && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Tychaia.Windows.sln ``` and observed the output of the build stream from the Windows machine into Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7521
2013-11-09 03:09:03 +01:00
'ShellLogView' => 'applications/harbormaster/view/ShellLogView.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'SlowvoteConduitAPIMethod' => 'applications/slowvote/conduit/SlowvoteConduitAPIMethod.php',
v0 embedding slowvotes Summary: Slowvotes can now be embed using {V*} syntax. Nothing fancy there yet. Test Plan: {F40842} Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2883 Differential Revision: https://secure.phabricator.com/D5713
2013-04-16 17:18:52 +02:00
'SlowvoteEmbedView' => 'applications/slowvote/view/SlowvoteEmbedView.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'SlowvoteInfoConduitAPIMethod' => 'applications/slowvote/conduit/SlowvoteInfoConduitAPIMethod.php',
v0 embedding slowvotes Summary: Slowvotes can now be embed using {V*} syntax. Nothing fancy there yet. Test Plan: {F40842} Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2883 Differential Revision: https://secure.phabricator.com/D5713
2013-04-16 17:18:52 +02:00
'SlowvoteRemarkupRule' => 'applications/slowvote/remarkup/SlowvoteRemarkupRule.php',
Subscriptions - make a dialog for massive subscription lists Summary: Ref T4430. This just deploys it on the property lists. (Help on how to do translations better? I tried a more traditional pht('%s, %s, %s, and %d other(s)') but I think the string lookup assumes the %d comes as the second param or something?) Test Plan: Made a Maniphest Task with a hojillion subscribers and noted the working dialogue. Also made a Pholio Mock with lots of subscribers and it worked. Reviewers: epriestley Reviewed By: epriestley Subscribers: aran, epriestley, Korvin, chad Maniphest Tasks: T4430 Differential Revision: https://secure.phabricator.com/D8525
2014-03-14 19:22:00 +01:00
'SubscriptionListDialogBuilder' => 'applications/subscriptions/view/SubscriptionListDialogBuilder.php',
'SubscriptionListStringBuilder' => 'applications/subscriptions/view/SubscriptionListStringBuilder.php',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'TokenConduitAPIMethod' => 'applications/tokens/conduit/TokenConduitAPIMethod.php',
'TokenGiveConduitAPIMethod' => 'applications/tokens/conduit/TokenGiveConduitAPIMethod.php',
'TokenGivenConduitAPIMethod' => 'applications/tokens/conduit/TokenGivenConduitAPIMethod.php',
'TokenQueryConduitAPIMethod' => 'applications/tokens/conduit/TokenQueryConduitAPIMethod.php',
'UserConduitAPIMethod' => 'applications/people/conduit/UserConduitAPIMethod.php',
'UserDisableConduitAPIMethod' => 'applications/people/conduit/UserDisableConduitAPIMethod.php',
'UserEnableConduitAPIMethod' => 'applications/people/conduit/UserEnableConduitAPIMethod.php',
'UserFindConduitAPIMethod' => 'applications/people/conduit/UserFindConduitAPIMethod.php',
'UserQueryConduitAPIMethod' => 'applications/people/conduit/UserQueryConduitAPIMethod.php',
'UserWhoAmIConduitAPIMethod' => 'applications/people/conduit/UserWhoAmIConduitAPIMethod.php',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
),
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'function' => array(
Make Celerity a real application Summary: Ref T5702. This primarily gets URI routing out of Aphront and into an Application, for consistency. Test Plan: Loaded some pages, got static resources. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D10696
2014-10-13 20:17:23 +02:00
'celerity_generate_unique_node_id' => 'applications/celerity/api.php',
'celerity_get_resource_uri' => 'applications/celerity/api.php',
Merge branch 'master' into phutil_tag (Synchronizing.)
2013-01-29 20:05:02 +01:00
'javelin_tag' => 'infrastructure/javelin/markup.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'phabricator_date' => 'view/viewutils.php',
'phabricator_datetime' => 'view/viewutils.php',
render_tag -> tag: phabricator_form, differential inline comment Summary: Pretty straightforward. Test Plan: Viewed inline edit on left / right and new /edit. Reviewers: vrana Reviewed By: vrana CC: aran Maniphest Tasks: T2432 Differential Revision: https://secure.phabricator.com/D4724
2013-01-30 20:24:30 +01:00
'phabricator_form' => 'infrastructure/javelin/markup.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'phabricator_format_local_time' => 'view/viewutils.php',
'phabricator_relative_date' => 'view/viewutils.php',
'phabricator_time' => 'view/viewutils.php',
Add feed integration to generic transactions Summary: Publish feed stories, including from Pholio. Actual stories are somewhat garbage but it's all display-time; I'm going to do a pass on feed in general. Test Plan: {F26832} Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4140
2012-12-11 23:00:21 +01:00
'phid_get_subtype' => 'applications/phid/utils.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'phid_get_type' => 'applications/phid/utils.php',
'phid_group_by_type' => 'applications/phid/utils.php',
Make Celerity a real application Summary: Ref T5702. This primarily gets URI routing out of Aphront and into an Application, for consistency. Test Plan: Loaded some pages, got static resources. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D10696
2014-10-13 20:17:23 +02:00
'require_celerity_resource' => 'applications/celerity/api.php',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
),
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'xmap' => array(
Build AlmanacInterface Summary: Ref T5833. An interface is an IP (maybe v4, maybe v6) and port on a specified network (public internet, VPN, NAT block, etc). Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10718
2014-10-17 14:04:24 +02:00
'AlmanacAddress' => 'Phobject',
Add AlmanacBinding, to bind a service to an interface Summary: Ref T5833. Allows you to bind a service (like `db.example.com`) to one or more interfaces (for example, to specify a pool with one read/write host and two read-only hosts). You can't configure which hosts have which properties yet, but you can add all the relevant interfaces to the service. Next diff will start supporting service, binding, and device properties like "is writable", "is active", etc., so that Almanac will be able to express operations like "change which database is writable", "disable writes", "bring a device down", etc. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10745
2014-10-27 21:39:36 +01:00
'AlmanacBinding' => array(
'AlmanacDAO',
'PhabricatorPolicyInterface',
Allow Almanac Devices and Bindings to have properties Summary: Ref T5833. Adds support for arbitrary properites to Almanac devices and bindings. - For Devices, this allows you to maybe mark what `rack` a server is on, the `serial` number of a router, etc. - For Bindings, this allows you to maybe mark that a bound device is `active`, provide `credentials`, expose it as `readonly`, etc. Test Plan: Added properties to Devices and Bindings. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10781
2014-11-06 00:28:36 +01:00
'PhabricatorApplicationTransactionInterface',
'AlmanacPropertyInterface',
Allow device bindings to be destroyed Summary: Ref T9762. Currently it is not possible to destroy an Alamanac device because any associate bindings cannot be destroyed. Test Plan: Destroyed an Almanac device. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Maniphest Tasks: T9762 Differential Revision: https://secure.phabricator.com/D14461
2015-11-15 21:14:55 +01:00
'PhabricatorDestructibleInterface',
Library Map Update Summary: Our of date, failed harbormaster build Test Plan: run `arc liberate` Reviewers: epriestley, nickz Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15351
2016-02-26 18:42:23 +01:00
'PhabricatorExtendedPolicyInterface',
Add AlmanacBinding, to bind a service to an interface Summary: Ref T5833. Allows you to bind a service (like `db.example.com`) to one or more interfaces (for example, to specify a pool with one read/write host and two read-only hosts). You can't configure which hosts have which properties yet, but you can add all the relevant interfaces to the service. Next diff will start supporting service, binding, and device properties like "is writable", "is active", etc., so that Almanac will be able to express operations like "change which database is writable", "disable writes", "bring a device down", etc. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10745
2014-10-27 21:39:36 +01:00
),
Allow Almanac bindings to be disabled and unused interfaces to be removed Summary: Fixes T9762. Ref T10246. **Disabling Bindings**: Previously, there was no formal way to disable bindings. The internal callers sometimes check some informal property on the binding, but this is a common need and deserves first-class support in the UI. Allow bindings to be disabled. **Deleting Interfaces**: Previously, you could not delete interfaces. Now, you can delete unused interfaces. Also some minor cleanup and slightly less mysterious documentation. Test Plan: Disabled bindings and deleted interfaces. Reviewers: chad Reviewed By: chad Subscribers: yelirekim Maniphest Tasks: T9762, T10246 Differential Revision: https://secure.phabricator.com/D15345
2016-02-25 12:52:41 +01:00
'AlmanacBindingDisableController' => 'AlmanacServiceController',
Add AlmanacBinding, to bind a service to an interface Summary: Ref T5833. Allows you to bind a service (like `db.example.com`) to one or more interfaces (for example, to specify a pool with one read/write host and two read-only hosts). You can't configure which hosts have which properties yet, but you can add all the relevant interfaces to the service. Next diff will start supporting service, binding, and device properties like "is writable", "is active", etc., so that Almanac will be able to express operations like "change which database is writable", "disable writes", "bring a device down", etc. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10745
2014-10-27 21:39:36 +01:00
'AlmanacBindingEditController' => 'AlmanacServiceController',
Allow Almanac properties to be deleted, use EditEngine instead of CustomField Summary: Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings. The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff). Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks. This also makes the internal storage for properties JSON instead of raw text. Test Plan: - Created, edited and deleted properties on services, devices and bindings. - Edited and reset builtin properties on repository services. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10410 Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 15:35:30 +01:00
'AlmanacBindingEditor' => 'AlmanacEditor',
Add AlmanacBinding, to bind a service to an interface Summary: Ref T5833. Allows you to bind a service (like `db.example.com`) to one or more interfaces (for example, to specify a pool with one read/write host and two read-only hosts). You can't configure which hosts have which properties yet, but you can add all the relevant interfaces to the service. Next diff will start supporting service, binding, and device properties like "is writable", "is active", etc., so that Almanac will be able to express operations like "change which database is writable", "disable writes", "bring a device down", etc. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10745
2014-10-27 21:39:36 +01:00
'AlmanacBindingPHIDType' => 'PhabricatorPHIDType',
Allow Almanac properties to be deleted, use EditEngine instead of CustomField Summary: Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings. The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff). Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks. This also makes the internal storage for properties JSON instead of raw text. Test Plan: - Created, edited and deleted properties on services, devices and bindings. - Edited and reset builtin properties on repository services. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10410 Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 15:35:30 +01:00
'AlmanacBindingPropertyEditEngine' => 'AlmanacPropertyEditEngine',
Allow Almanac Devices and Bindings to have properties Summary: Ref T5833. Adds support for arbitrary properites to Almanac devices and bindings. - For Devices, this allows you to maybe mark what `rack` a server is on, the `serial` number of a router, etc. - For Bindings, this allows you to maybe mark that a bound device is `active`, provide `credentials`, expose it as `readonly`, etc. Test Plan: Added properties to Devices and Bindings. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10781
2014-11-06 00:28:36 +01:00
'AlmanacBindingQuery' => 'AlmanacQuery',
Add AlmanacBinding, to bind a service to an interface Summary: Ref T5833. Allows you to bind a service (like `db.example.com`) to one or more interfaces (for example, to specify a pool with one read/write host and two read-only hosts). You can't configure which hosts have which properties yet, but you can add all the relevant interfaces to the service. Next diff will start supporting service, binding, and device properties like "is writable", "is active", etc., so that Almanac will be able to express operations like "change which database is writable", "disable writes", "bring a device down", etc. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10745
2014-10-27 21:39:36 +01:00
'AlmanacBindingTableView' => 'AphrontView',
Allow Almanac properties to be deleted, use EditEngine instead of CustomField Summary: Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings. The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff). Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks. This also makes the internal storage for properties JSON instead of raw text. Test Plan: - Created, edited and deleted properties on services, devices and bindings. - Edited and reset builtin properties on repository services. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10410 Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 15:35:30 +01:00
'AlmanacBindingTransaction' => 'AlmanacTransaction',
Add AlmanacBinding, to bind a service to an interface Summary: Ref T5833. Allows you to bind a service (like `db.example.com`) to one or more interfaces (for example, to specify a pool with one read/write host and two read-only hosts). You can't configure which hosts have which properties yet, but you can add all the relevant interfaces to the service. Next diff will start supporting service, binding, and device properties like "is writable", "is active", etc., so that Almanac will be able to express operations like "change which database is writable", "disable writes", "bring a device down", etc. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10745
2014-10-27 21:39:36 +01:00
'AlmanacBindingTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'AlmanacBindingViewController' => 'AlmanacServiceController',
Expose modern `*.search` Conduit endpoints in Almanac Summary: Fixes T10411. Ref T10246. There are probably still some rough edges with this, but replace the old-school endpoints with modern ones so we don't unprototype with deprecated stuff. Test Plan: - Made a bunch of calls to the new endpoints with various constraints/attachments. - Created and edited services, devices, interfaces, bindings, and properties on everything. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10246, T10411 Differential Revision: https://secure.phabricator.com/D15329
2016-02-22 21:53:40 +01:00
'AlmanacBindingsSearchEngineAttachment' => 'AlmanacSearchEngineAttachment',
Add a "ClusterDatabase" Almanac service type Summary: Ref T5833. This doesn't do anything yet, but will allow new instances to automaticaly bind to an open database without anything too hacky. Test Plan: Created a service of this type. {F267059} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D11372
2015-01-13 20:59:23 +01:00
'AlmanacClusterDatabaseServiceType' => 'AlmanacClusterServiceType',
Give AlmanacServices a service type Summary: Ref T5833. This allows services to be typed, to distinguish between different kinds of services. This makes a few things easier: - It's easier for clients to select the services they're interested in (see note in T5873 about Phacility). This isn't a full-power solution, but gets is some of the way there. - It's easier to set appropriate permissions around when modifications to the Phabricator cluster are allowed. These service nodes need to be demarcated as special in some way no matter what (see T6741). This also defines a new policy for users who are permitted to create services. - It's easier to browse/review/understand services. - Future diffs will allow ServiceTypes to specify more service structure (for example, default properties) to make it easier to configure services correctly. Instead of a free-for-all, you'll get a useful list of things that consumers of the service expect to read. The "custom" service type allows unstructured/freeform services to be created. Test Plan: - Created a new service (and hit error cases). - Edited an existing service. - Saw service types on list and detail views. - Poked around new permission stuff. - Ran `almanac.queryservices` with service class specification. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10995
2014-12-17 20:10:27 +01:00
'AlmanacClusterRepositoryServiceType' => 'AlmanacClusterServiceType',
'AlmanacClusterServiceType' => 'AlmanacServiceType',
Build AlmanacService Summary: Ref T5833. See that task for functional goals and some discussion of design. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 14:01:57 +02:00
'AlmanacConsoleController' => 'AlmanacController',
'AlmanacController' => 'PhabricatorController',
Build AlmanacDevice UI Summary: Ref T5833. The "uninteresting" part of this object is virtually identical to AlmanacService. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10714
2014-10-17 14:02:14 +02:00
'AlmanacCreateDevicesCapability' => 'PhabricatorPolicyCapability',
Rough-in Almanac namespaces Summary: Ref T6741. Ref T10246. Root problem: to provide Drydock in the cluster, we need to expose Almanac, and doing so would let users accidentally or intentionally create a bunch of `repo006.phacility.net` devices/services which could conflict with the real ones we manage. There's currently no way to say "you can't create anything named `*.blah.net`". This adds "namespaces", which let you do that (well, not yet, but they will after the next diff). After the next diff, if you try to create `repo003.phacility.net`, but the namespace `phacility.net` already exists and you don't have permission to edit it, you'll be asked to choose a different name. Also various modernizations and some new docs. Test Plan: - Created cool namespaces like `this.computer`. - Almanac namespaces don't actually enforce policies yet. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6741, T10246 Differential Revision: https://secure.phabricator.com/D15324
2016-02-21 21:15:57 +01:00
'AlmanacCreateNamespacesCapability' => 'PhabricatorPolicyCapability',
Build AlmanacNetwork Summary: Ref T5833. This differentiates address spaces like the public internet from VPNs, so when a service is available at `192.168.0.1`, we'll know it's on some specific NAT block or whatever. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10715
2014-10-17 14:04:02 +02:00
'AlmanacCreateNetworksCapability' => 'PhabricatorPolicyCapability',
Build AlmanacService Summary: Ref T5833. See that task for functional goals and some discussion of design. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 14:01:57 +02:00
'AlmanacCreateServicesCapability' => 'PhabricatorPolicyCapability',
Give AlmanacServices a service type Summary: Ref T5833. This allows services to be typed, to distinguish between different kinds of services. This makes a few things easier: - It's easier for clients to select the services they're interested in (see note in T5873 about Phacility). This isn't a full-power solution, but gets is some of the way there. - It's easier to set appropriate permissions around when modifications to the Phabricator cluster are allowed. These service nodes need to be demarcated as special in some way no matter what (see T6741). This also defines a new policy for users who are permitted to create services. - It's easier to browse/review/understand services. - Future diffs will allow ServiceTypes to specify more service structure (for example, default properties) to make it easier to configure services correctly. Instead of a free-for-all, you'll get a useful list of things that consumers of the service expect to read. The "custom" service type allows unstructured/freeform services to be created. Test Plan: - Created a new service (and hit error cases). - Edited an existing service. - Saw service types on list and detail views. - Poked around new permission stuff. - Ran `almanac.queryservices` with service class specification. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10995
2014-12-17 20:10:27 +01:00
'AlmanacCustomServiceType' => 'AlmanacServiceType',
Implement storage of a host ID and a public key for authorizing Conduit between servers Summary: Ref T4209. This creates storage for public keys against authorized hosts, such that servers can be authorized to make Conduit calls as the omnipotent user. Servers are registered into this system by running the following command once: ``` bin/almanac register ``` NOTE: This doesn't implement authorization between servers, just the storage of public keys. Placing this against Almanac seemed like the most sensible place, since I'm imagining in future that the `register` command will accept more information (like the hostname of the server so it can be found in the service directory). Test Plan: Ran `bin/almanac register` and saw the host (and public key information) appear in the database. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4209 Differential Revision: https://secure.phabricator.com/D10400
2014-10-03 14:52:41 +02:00
'AlmanacDAO' => 'PhabricatorLiskDAO',
'AlmanacDevice' => array(
'AlmanacDAO',
'PhabricatorPolicyInterface',
Allow Almanac Devices and Bindings to have properties Summary: Ref T5833. Adds support for arbitrary properites to Almanac devices and bindings. - For Devices, this allows you to maybe mark what `rack` a server is on, the `serial` number of a router, etc. - For Bindings, this allows you to maybe mark that a bound device is `active`, provide `credentials`, expose it as `readonly`, etc. Test Plan: Added properties to Devices and Bindings. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10781
2014-11-06 00:28:36 +01:00
'PhabricatorApplicationTransactionInterface',
Implement PhabricatorProjectInterface on Almanac Services and Devices Summary: Ref T5833. Allow services and devices to be tagged with projects. (These fluff apply implementations are a good example of the issue discussed in T6403.) Test Plan: {F229569} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10782
2014-11-06 00:30:00 +01:00
'PhabricatorProjectInterface',
Allow Almanac devices to have SSH keys Summary: Ref T5833. Expose a key management interface for Almanac devices. Test Plan: {F231962} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10825
2014-11-11 17:20:08 +01:00
'PhabricatorSSHPublicKeyInterface',
Allow Almanac Devices and Bindings to have properties Summary: Ref T5833. Adds support for arbitrary properites to Almanac devices and bindings. - For Devices, this allows you to maybe mark what `rack` a server is on, the `serial` number of a router, etc. - For Bindings, this allows you to maybe mark that a bound device is `active`, provide `credentials`, expose it as `readonly`, etc. Test Plan: Added properties to Devices and Bindings. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10781
2014-11-06 00:28:36 +01:00
'AlmanacPropertyInterface',
Almanac: forced interface PHIDs, prefix/suffix device query, DestructibleInterface Summary: Ref T5833. Ref T6238. These are general capabilities which are particularly useful for synchronizing cluster specifications to instances. Test Plan: - Synchronized networks, devices, interfaces, services, bindings and properties to a managed instance. - Used typeahead. - Destroyed networks, devices, and services. Saw interfaces and bindings destroyed. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6238, T5833 Differential Revision: https://secure.phabricator.com/D11024
2014-12-22 21:50:44 +01:00
'PhabricatorDestructibleInterface',
Allow Almanac devices to be queried and sorted by name Summary: Ref T10205. Ref T10246. This is general modernization, but also supports fixing the interface datasource in T10205. - Update Query. - Update SearchEngine. - Use an ngrams index for searching names efficiently. Test Plan: - Ran migrations. - Searched Almanac devices by name. - Created a new device, searched for it by name. {F1121303} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10205, T10246 Differential Revision: https://secure.phabricator.com/D15319
2016-02-21 11:48:10 +01:00
'PhabricatorNgramsInterface',
Expose modern `*.search` Conduit endpoints in Almanac Summary: Fixes T10411. Ref T10246. There are probably still some rough edges with this, but replace the old-school endpoints with modern ones so we don't unprototype with deprecated stuff. Test Plan: - Made a bunch of calls to the new endpoints with various constraints/attachments. - Created and edited services, devices, interfaces, bindings, and properties on everything. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10246, T10411 Differential Revision: https://secure.phabricator.com/D15329
2016-02-22 21:53:40 +01:00
'PhabricatorConduitResultInterface',
Library Map Update Summary: Our of date, failed harbormaster build Test Plan: run `arc liberate` Reviewers: epriestley, nickz Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15351
2016-02-26 18:42:23 +01:00
'PhabricatorExtendedPolicyInterface',
Implement storage of a host ID and a public key for authorizing Conduit between servers Summary: Ref T4209. This creates storage for public keys against authorized hosts, such that servers can be authorized to make Conduit calls as the omnipotent user. Servers are registered into this system by running the following command once: ``` bin/almanac register ``` NOTE: This doesn't implement authorization between servers, just the storage of public keys. Placing this against Almanac seemed like the most sensible place, since I'm imagining in future that the `register` command will accept more information (like the hostname of the server so it can be found in the service directory). Test Plan: Ran `bin/almanac register` and saw the host (and public key information) appear in the database. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4209 Differential Revision: https://secure.phabricator.com/D10400
2014-10-03 14:52:41 +02:00
),
Build AlmanacDevice UI Summary: Ref T5833. The "uninteresting" part of this object is virtually identical to AlmanacService. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10714
2014-10-17 14:02:14 +02:00
'AlmanacDeviceController' => 'AlmanacController',
'AlmanacDeviceEditController' => 'AlmanacDeviceController',
Use EditEngine for AlmanacDevice Summary: Ref T10449. Modernize the AlmanacDevice code a bit. Test Plan: - Created a device. - Edited a device. - Listed devices. - Viewed a device. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10449 Differential Revision: https://secure.phabricator.com/D15399
2016-03-05 01:14:27 +01:00
'AlmanacDeviceEditEngine' => 'PhabricatorEditEngine',
Allow Almanac properties to be deleted, use EditEngine instead of CustomField Summary: Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings. The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff). Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks. This also makes the internal storage for properties JSON instead of raw text. Test Plan: - Created, edited and deleted properties on services, devices and bindings. - Edited and reset builtin properties on repository services. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10410 Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 15:35:30 +01:00
'AlmanacDeviceEditor' => 'AlmanacEditor',
Build AlmanacDevice UI Summary: Ref T5833. The "uninteresting" part of this object is virtually identical to AlmanacService. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10714
2014-10-17 14:02:14 +02:00
'AlmanacDeviceListController' => 'AlmanacDeviceController',
Allow Almanac devices to be queried and sorted by name Summary: Ref T10205. Ref T10246. This is general modernization, but also supports fixing the interface datasource in T10205. - Update Query. - Update SearchEngine. - Use an ngrams index for searching names efficiently. Test Plan: - Ran migrations. - Searched Almanac devices by name. - Created a new device, searched for it by name. {F1121303} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10205, T10246 Differential Revision: https://secure.phabricator.com/D15319
2016-02-21 11:48:10 +01:00
'AlmanacDeviceNameNgrams' => 'PhabricatorSearchNgrams',
Implement storage of a host ID and a public key for authorizing Conduit between servers Summary: Ref T4209. This creates storage for public keys against authorized hosts, such that servers can be authorized to make Conduit calls as the omnipotent user. Servers are registered into this system by running the following command once: ``` bin/almanac register ``` NOTE: This doesn't implement authorization between servers, just the storage of public keys. Placing this against Almanac seemed like the most sensible place, since I'm imagining in future that the `register` command will accept more information (like the hostname of the server so it can be found in the service directory). Test Plan: Ran `bin/almanac register` and saw the host (and public key information) appear in the database. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4209 Differential Revision: https://secure.phabricator.com/D10400
2014-10-03 14:52:41 +02:00
'AlmanacDevicePHIDType' => 'PhabricatorPHIDType',
Allow Almanac properties to be deleted, use EditEngine instead of CustomField Summary: Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings. The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff). Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks. This also makes the internal storage for properties JSON instead of raw text. Test Plan: - Created, edited and deleted properties on services, devices and bindings. - Edited and reset builtin properties on repository services. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10410 Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 15:35:30 +01:00
'AlmanacDevicePropertyEditEngine' => 'AlmanacPropertyEditEngine',
Allow Almanac Devices and Bindings to have properties Summary: Ref T5833. Adds support for arbitrary properites to Almanac devices and bindings. - For Devices, this allows you to maybe mark what `rack` a server is on, the `serial` number of a router, etc. - For Bindings, this allows you to maybe mark that a bound device is `active`, provide `credentials`, expose it as `readonly`, etc. Test Plan: Added properties to Devices and Bindings. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10781
2014-11-06 00:28:36 +01:00
'AlmanacDeviceQuery' => 'AlmanacQuery',
Expose modern `*.search` Conduit endpoints in Almanac Summary: Fixes T10411. Ref T10246. There are probably still some rough edges with this, but replace the old-school endpoints with modern ones so we don't unprototype with deprecated stuff. Test Plan: - Made a bunch of calls to the new endpoints with various constraints/attachments. - Created and edited services, devices, interfaces, bindings, and properties on everything. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10246, T10411 Differential Revision: https://secure.phabricator.com/D15329
2016-02-22 21:53:40 +01:00
'AlmanacDeviceSearchConduitAPIMethod' => 'PhabricatorSearchEngineAPIMethod',
Build AlmanacDevice UI Summary: Ref T5833. The "uninteresting" part of this object is virtually identical to AlmanacService. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10714
2014-10-17 14:02:14 +02:00
'AlmanacDeviceSearchEngine' => 'PhabricatorApplicationSearchEngine',
Allow Almanac properties to be deleted, use EditEngine instead of CustomField Summary: Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings. The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff). Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks. This also makes the internal storage for properties JSON instead of raw text. Test Plan: - Created, edited and deleted properties on services, devices and bindings. - Edited and reset builtin properties on repository services. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10410 Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 15:35:30 +01:00
'AlmanacDeviceTransaction' => 'AlmanacTransaction',
Build AlmanacDevice UI Summary: Ref T5833. The "uninteresting" part of this object is virtually identical to AlmanacService. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10714
2014-10-17 14:02:14 +02:00
'AlmanacDeviceTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'AlmanacDeviceViewController' => 'AlmanacDeviceController',
Add an Almanac service type for Drydock to lease against Summary: Ref T9253. See D13843 for some discussion. This is very bare-bones for now since I believe that almost all interesting configuration (e.g., credentials) should live in Drydock, although I imagine it getting some configuration eventually. Test Plan: Used {nav Almanac > Services > Create Service} to create a new service of this type. Reviewers: hach-que, chad Reviewed By: hach-que, chad Maniphest Tasks: T9253 Differential Revision: https://secure.phabricator.com/D14109
2015-09-21 13:41:23 +02:00
'AlmanacDrydockPoolServiceType' => 'AlmanacServiceType',
Allow Almanac properties to be deleted, use EditEngine instead of CustomField Summary: Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings. The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff). Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks. This also makes the internal storage for properties JSON instead of raw text. Test Plan: - Created, edited and deleted properties on services, devices and bindings. - Edited and reset builtin properties on repository services. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10410 Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 15:35:30 +01:00
'AlmanacEditor' => 'PhabricatorApplicationTransactionEditor',
Build AlmanacInterface Summary: Ref T5833. An interface is an IP (maybe v4, maybe v6) and port on a specified network (public internet, VPN, NAT block, etc). Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10718
2014-10-17 14:04:24 +02:00
'AlmanacInterface' => array(
'AlmanacDAO',
'PhabricatorPolicyInterface',
Almanac: forced interface PHIDs, prefix/suffix device query, DestructibleInterface Summary: Ref T5833. Ref T6238. These are general capabilities which are particularly useful for synchronizing cluster specifications to instances. Test Plan: - Synchronized networks, devices, interfaces, services, bindings and properties to a managed instance. - Used typeahead. - Destroyed networks, devices, and services. Saw interfaces and bindings destroyed. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6238, T5833 Differential Revision: https://secure.phabricator.com/D11024
2014-12-22 21:50:44 +01:00
'PhabricatorDestructibleInterface',
Allow Almanac bindings to be disabled and unused interfaces to be removed Summary: Fixes T9762. Ref T10246. **Disabling Bindings**: Previously, there was no formal way to disable bindings. The internal callers sometimes check some informal property on the binding, but this is a common need and deserves first-class support in the UI. Allow bindings to be disabled. **Deleting Interfaces**: Previously, you could not delete interfaces. Now, you can delete unused interfaces. Also some minor cleanup and slightly less mysterious documentation. Test Plan: Disabled bindings and deleted interfaces. Reviewers: chad Reviewed By: chad Subscribers: yelirekim Maniphest Tasks: T9762, T10246 Differential Revision: https://secure.phabricator.com/D15345
2016-02-25 12:52:41 +01:00
'PhabricatorExtendedPolicyInterface',
Build AlmanacInterface Summary: Ref T5833. An interface is an IP (maybe v4, maybe v6) and port on a specified network (public internet, VPN, NAT block, etc). Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10718
2014-10-17 14:04:24 +02:00
),
Add AlmanacBinding, to bind a service to an interface Summary: Ref T5833. Allows you to bind a service (like `db.example.com`) to one or more interfaces (for example, to specify a pool with one read/write host and two read-only hosts). You can't configure which hosts have which properties yet, but you can add all the relevant interfaces to the service. Next diff will start supporting service, binding, and device properties like "is writable", "is active", etc., so that Almanac will be able to express operations like "change which database is writable", "disable writes", "bring a device down", etc. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10745
2014-10-27 21:39:36 +01:00
'AlmanacInterfaceDatasource' => 'PhabricatorTypeaheadDatasource',
Allow Almanac bindings to be disabled and unused interfaces to be removed Summary: Fixes T9762. Ref T10246. **Disabling Bindings**: Previously, there was no formal way to disable bindings. The internal callers sometimes check some informal property on the binding, but this is a common need and deserves first-class support in the UI. Allow bindings to be disabled. **Deleting Interfaces**: Previously, you could not delete interfaces. Now, you can delete unused interfaces. Also some minor cleanup and slightly less mysterious documentation. Test Plan: Disabled bindings and deleted interfaces. Reviewers: chad Reviewed By: chad Subscribers: yelirekim Maniphest Tasks: T9762, T10246 Differential Revision: https://secure.phabricator.com/D15345
2016-02-25 12:52:41 +01:00
'AlmanacInterfaceDeleteController' => 'AlmanacDeviceController',
Build AlmanacInterface Summary: Ref T5833. An interface is an IP (maybe v4, maybe v6) and port on a specified network (public internet, VPN, NAT block, etc). Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10718
2014-10-17 14:04:24 +02:00
'AlmanacInterfaceEditController' => 'AlmanacDeviceController',
'AlmanacInterfacePHIDType' => 'PhabricatorPHIDType',
Expose modern `*.search` Conduit endpoints in Almanac Summary: Fixes T10411. Ref T10246. There are probably still some rough edges with this, but replace the old-school endpoints with modern ones so we don't unprototype with deprecated stuff. Test Plan: - Made a bunch of calls to the new endpoints with various constraints/attachments. - Created and edited services, devices, interfaces, bindings, and properties on everything. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10246, T10411 Differential Revision: https://secure.phabricator.com/D15329
2016-02-22 21:53:40 +01:00
'AlmanacInterfaceQuery' => 'AlmanacQuery',
Build AlmanacInterface Summary: Ref T5833. An interface is an IP (maybe v4, maybe v6) and port on a specified network (public internet, VPN, NAT block, etc). Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10718
2014-10-17 14:04:24 +02:00
'AlmanacInterfaceTableView' => 'AphrontView',
Add `bin/almanac register` to associate a host with an Almanac device and trust it Summary: Ref T2783. This is basically a more refined version of D10400, which churned a bit on things like SSH key storage, the actual way the signing protocol shook out, etc. - When Phabricator tries to make an intra-cluster service call as the omnipotent user, sign it with the host's device key. - Add `bin/almanac register` to say "this host is X device, identified by private key Y". This stores the keypair locally, adds the public key to Almanac, and trusts it. Net effect is that once a host has been registered, the daemons can make calls to other nodes as the omnipotent user. This is primarily necessary so they can access repository API methods on remote hosts. Test Plan: - Ran `bin/almanac register` with various valid and invalid inputs. - Verified keys get generated/added/stored properly. - Made a device-signed cluster Conduit call. - Made a normal old user-signed cluster Conduit call. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2783 Differential Revision: https://secure.phabricator.com/D11158
2015-01-03 00:13:30 +01:00
'AlmanacKeys' => 'Phobject',
Library Map Update Summary: Our of date, failed harbormaster build Test Plan: run `arc liberate` Reviewers: epriestley, nickz Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15351
2016-02-26 18:42:23 +01:00
'AlmanacManageClusterServicesCapability' => 'PhabricatorPolicyCapability',
Add `bin/almanac register` to associate a host with an Almanac device and trust it Summary: Ref T2783. This is basically a more refined version of D10400, which churned a bit on things like SSH key storage, the actual way the signing protocol shook out, etc. - When Phabricator tries to make an intra-cluster service call as the omnipotent user, sign it with the host's device key. - Add `bin/almanac register` to say "this host is X device, identified by private key Y". This stores the keypair locally, adds the public key to Almanac, and trusts it. Net effect is that once a host has been registered, the daemons can make calls to other nodes as the omnipotent user. This is primarily necessary so they can access repository API methods on remote hosts. Test Plan: - Ran `bin/almanac register` with various valid and invalid inputs. - Verified keys get generated/added/stored properly. - Made a device-signed cluster Conduit call. - Made a normal old user-signed cluster Conduit call. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2783 Differential Revision: https://secure.phabricator.com/D11158
2015-01-03 00:13:30 +01:00
'AlmanacManagementRegisterWorkflow' => 'AlmanacManagementWorkflow',
Allow device SSH keys to be trusted Summary: Ref T6240. Some discussion in that task. In instance/cluster environments, daemons need to make Conduit calls that bypass policy checks. We can't just let anyone add SSH keys with this capability to the web directly, because then an adminstrator could just add a key they own and start signing requests with it, bypassing policy checks. Add a `bin/almanac trust-key --id <x>` workflow for trusting keys. Only trusted keys can sign requests. Test Plan: - Generated a user key. - Generated a device key. - Trusted a device key. - Untrusted a device key. - Hit the various errors on trust/untrust. - Tried to edit a trusted key. {F236010} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6240 Differential Revision: https://secure.phabricator.com/D10878
2014-11-21 02:33:30 +01:00
'AlmanacManagementTrustKeyWorkflow' => 'AlmanacManagementWorkflow',
'AlmanacManagementUntrustKeyWorkflow' => 'AlmanacManagementWorkflow',
Implement storage of a host ID and a public key for authorizing Conduit between servers Summary: Ref T4209. This creates storage for public keys against authorized hosts, such that servers can be authorized to make Conduit calls as the omnipotent user. Servers are registered into this system by running the following command once: ``` bin/almanac register ``` NOTE: This doesn't implement authorization between servers, just the storage of public keys. Placing this against Almanac seemed like the most sensible place, since I'm imagining in future that the `register` command will accept more information (like the hostname of the server so it can be found in the service directory). Test Plan: Ran `bin/almanac register` and saw the host (and public key information) appear in the database. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4209 Differential Revision: https://secure.phabricator.com/D10400
2014-10-03 14:52:41 +02:00
'AlmanacManagementWorkflow' => 'PhabricatorManagementWorkflow',
Build AlmanacDevice UI Summary: Ref T5833. The "uninteresting" part of this object is virtually identical to AlmanacService. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10714
2014-10-17 14:02:14 +02:00
'AlmanacNames' => 'Phobject',
'AlmanacNamesTestCase' => 'PhabricatorTestCase',
Rough-in Almanac namespaces Summary: Ref T6741. Ref T10246. Root problem: to provide Drydock in the cluster, we need to expose Almanac, and doing so would let users accidentally or intentionally create a bunch of `repo006.phacility.net` devices/services which could conflict with the real ones we manage. There's currently no way to say "you can't create anything named `*.blah.net`". This adds "namespaces", which let you do that (well, not yet, but they will after the next diff). After the next diff, if you try to create `repo003.phacility.net`, but the namespace `phacility.net` already exists and you don't have permission to edit it, you'll be asked to choose a different name. Also various modernizations and some new docs. Test Plan: - Created cool namespaces like `this.computer`. - Almanac namespaces don't actually enforce policies yet. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6741, T10246 Differential Revision: https://secure.phabricator.com/D15324
2016-02-21 21:15:57 +01:00
'AlmanacNamespace' => array(
'AlmanacDAO',
'PhabricatorPolicyInterface',
'PhabricatorApplicationTransactionInterface',
'PhabricatorProjectInterface',
'AlmanacPropertyInterface',
'PhabricatorDestructibleInterface',
'PhabricatorNgramsInterface',
),
'AlmanacNamespaceController' => 'AlmanacController',
Use EditEngine for Almanac Services, Devices, and Networks Summary: Ref T10411. This cleans up / modernizes things and lets me get an `almanac.network.edit` API in the future. This is mostly straightforward, except that Services have an extra "choose type" screen in front of them. Test Plan: - Created and edited Almanac networks, services, and devices. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10411 Differential Revision: https://secure.phabricator.com/D15326
2016-02-22 14:11:02 +01:00
'AlmanacNamespaceEditController' => 'AlmanacNamespaceController',
Rough-in Almanac namespaces Summary: Ref T6741. Ref T10246. Root problem: to provide Drydock in the cluster, we need to expose Almanac, and doing so would let users accidentally or intentionally create a bunch of `repo006.phacility.net` devices/services which could conflict with the real ones we manage. There's currently no way to say "you can't create anything named `*.blah.net`". This adds "namespaces", which let you do that (well, not yet, but they will after the next diff). After the next diff, if you try to create `repo003.phacility.net`, but the namespace `phacility.net` already exists and you don't have permission to edit it, you'll be asked to choose a different name. Also various modernizations and some new docs. Test Plan: - Created cool namespaces like `this.computer`. - Almanac namespaces don't actually enforce policies yet. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6741, T10246 Differential Revision: https://secure.phabricator.com/D15324
2016-02-21 21:15:57 +01:00
'AlmanacNamespaceEditEngine' => 'PhabricatorEditEngine',
'AlmanacNamespaceEditor' => 'PhabricatorApplicationTransactionEditor',
'AlmanacNamespaceListController' => 'AlmanacNamespaceController',
'AlmanacNamespaceNameNgrams' => 'PhabricatorSearchNgrams',
'AlmanacNamespacePHIDType' => 'PhabricatorPHIDType',
Apply namespace locking rules in Almanac Summary: Ref T10246. Ref T6741. When you have a namespace like "phacility.net", require users creating services and devices within it to have edit permission on the namespace. This primarily allows us to lock down future device names in the cluster, so instances can't break themselves once they get access to Almanac. Test Plan: - Configured a `phacility.net` namespace, locked myself out of it. - Could not create new `stuff.phacility.net` services/devices. - Could still edit existing devices I had permission for. - Configured a `free.phacility.net` namespace with more liberal policies. - Could create `me.free.phacility.net`. - Still could not create `other.phacility.net`. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6741, T10246 Differential Revision: https://secure.phabricator.com/D15325
2016-02-21 23:34:03 +01:00
'AlmanacNamespaceQuery' => 'AlmanacQuery',
Rough-in Almanac namespaces Summary: Ref T6741. Ref T10246. Root problem: to provide Drydock in the cluster, we need to expose Almanac, and doing so would let users accidentally or intentionally create a bunch of `repo006.phacility.net` devices/services which could conflict with the real ones we manage. There's currently no way to say "you can't create anything named `*.blah.net`". This adds "namespaces", which let you do that (well, not yet, but they will after the next diff). After the next diff, if you try to create `repo003.phacility.net`, but the namespace `phacility.net` already exists and you don't have permission to edit it, you'll be asked to choose a different name. Also various modernizations and some new docs. Test Plan: - Created cool namespaces like `this.computer`. - Almanac namespaces don't actually enforce policies yet. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6741, T10246 Differential Revision: https://secure.phabricator.com/D15324
2016-02-21 21:15:57 +01:00
'AlmanacNamespaceSearchEngine' => 'PhabricatorApplicationSearchEngine',
'AlmanacNamespaceTransaction' => 'PhabricatorApplicationTransaction',
'AlmanacNamespaceTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'AlmanacNamespaceViewController' => 'AlmanacNamespaceController',
Build AlmanacNetwork Summary: Ref T5833. This differentiates address spaces like the public internet from VPNs, so when a service is available at `192.168.0.1`, we'll know it's on some specific NAT block or whatever. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10715
2014-10-17 14:04:02 +02:00
'AlmanacNetwork' => array(
'AlmanacDAO',
Transactions - deploy buildTransactionTimeline against a few more applications Summary: Ref T4712. Thus far, it seems that most "non-standard" things can be done pretty easily in the controller. Aside from deploying, this diff had to fix a few bugs / missing implementations of stuff. (Notably, PhabricatorAuthProviderConfig, HeraldRule, PhabricatorSlowvotePoll, and AlmanacNetwork needed to implement PhabricatorApplicationTransactionInterface, PhabricatorAuthAuthProviderPHIDType had to be added, and a rendering bug in transactions of type PhabricatorOAuth2AuthProvider had to be fixed.) Test Plan: Almanac - looked at binding, device, network, and service view controllers and verified timeline displayed properly. Herald - looked at a rule and verified timeline. Slowvote - looked at a vote and verified timeline. Auth - looked at an auth provider (Facebook) and verified proper display of transactions within timeline. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10921
2014-12-02 23:33:59 +01:00
'PhabricatorApplicationTransactionInterface',
Build AlmanacNetwork Summary: Ref T5833. This differentiates address spaces like the public internet from VPNs, so when a service is available at `192.168.0.1`, we'll know it's on some specific NAT block or whatever. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10715
2014-10-17 14:04:02 +02:00
'PhabricatorPolicyInterface',
Almanac: forced interface PHIDs, prefix/suffix device query, DestructibleInterface Summary: Ref T5833. Ref T6238. These are general capabilities which are particularly useful for synchronizing cluster specifications to instances. Test Plan: - Synchronized networks, devices, interfaces, services, bindings and properties to a managed instance. - Used typeahead. - Destroyed networks, devices, and services. Saw interfaces and bindings destroyed. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6238, T5833 Differential Revision: https://secure.phabricator.com/D11024
2014-12-22 21:50:44 +01:00
'PhabricatorDestructibleInterface',
Allow Almanac namespaces to be searched by ngram index Summary: Ref T6741. Ref T10246. This is largely modernization, but will partially support namespace locking in Almanac. Test Plan: Searched for Almanac networks by name substring. {F1121740} Reviewers: chad Reviewed By: chad Maniphest Tasks: T6741, T10246 Differential Revision: https://secure.phabricator.com/D15322
2016-02-21 20:13:08 +01:00
'PhabricatorNgramsInterface',
Build AlmanacNetwork Summary: Ref T5833. This differentiates address spaces like the public internet from VPNs, so when a service is available at `192.168.0.1`, we'll know it's on some specific NAT block or whatever. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10715
2014-10-17 14:04:02 +02:00
),
'AlmanacNetworkController' => 'AlmanacController',
'AlmanacNetworkEditController' => 'AlmanacNetworkController',
Use EditEngine for Almanac Services, Devices, and Networks Summary: Ref T10411. This cleans up / modernizes things and lets me get an `almanac.network.edit` API in the future. This is mostly straightforward, except that Services have an extra "choose type" screen in front of them. Test Plan: - Created and edited Almanac networks, services, and devices. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10411 Differential Revision: https://secure.phabricator.com/D15326
2016-02-22 14:11:02 +01:00
'AlmanacNetworkEditEngine' => 'PhabricatorEditEngine',
Build AlmanacNetwork Summary: Ref T5833. This differentiates address spaces like the public internet from VPNs, so when a service is available at `192.168.0.1`, we'll know it's on some specific NAT block or whatever. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10715
2014-10-17 14:04:02 +02:00
'AlmanacNetworkEditor' => 'PhabricatorApplicationTransactionEditor',
'AlmanacNetworkListController' => 'AlmanacNetworkController',
Allow Almanac namespaces to be searched by ngram index Summary: Ref T6741. Ref T10246. This is largely modernization, but will partially support namespace locking in Almanac. Test Plan: Searched for Almanac networks by name substring. {F1121740} Reviewers: chad Reviewed By: chad Maniphest Tasks: T6741, T10246 Differential Revision: https://secure.phabricator.com/D15322
2016-02-21 20:13:08 +01:00
'AlmanacNetworkNameNgrams' => 'PhabricatorSearchNgrams',
Build AlmanacNetwork Summary: Ref T5833. This differentiates address spaces like the public internet from VPNs, so when a service is available at `192.168.0.1`, we'll know it's on some specific NAT block or whatever. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10715
2014-10-17 14:04:02 +02:00
'AlmanacNetworkPHIDType' => 'PhabricatorPHIDType',
Expose modern `*.search` Conduit endpoints in Almanac Summary: Fixes T10411. Ref T10246. There are probably still some rough edges with this, but replace the old-school endpoints with modern ones so we don't unprototype with deprecated stuff. Test Plan: - Made a bunch of calls to the new endpoints with various constraints/attachments. - Created and edited services, devices, interfaces, bindings, and properties on everything. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10246, T10411 Differential Revision: https://secure.phabricator.com/D15329
2016-02-22 21:53:40 +01:00
'AlmanacNetworkQuery' => 'AlmanacQuery',
Build AlmanacNetwork Summary: Ref T5833. This differentiates address spaces like the public internet from VPNs, so when a service is available at `192.168.0.1`, we'll know it's on some specific NAT block or whatever. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10715
2014-10-17 14:04:02 +02:00
'AlmanacNetworkSearchEngine' => 'PhabricatorApplicationSearchEngine',
'AlmanacNetworkTransaction' => 'PhabricatorApplicationTransaction',
'AlmanacNetworkTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'AlmanacNetworkViewController' => 'AlmanacNetworkController',
Prepare DestructionEngine to be modularized Summary: Ref T9979. The general shape of "engine" code feels pretty good, and I plan to move indexing to be more in line with other modern engines, with the ultimate goal of supporting subprojects (T10010) and several intermediate goals. Before moving indexing, clean up Destruction, since some of the new indexes will need destruction hooks and destruction currently has a lot of `instanceof` stuff that should be easy to fix by applying more modern approaches. Test Plan: - Used `bin/remove destroy` to destory an Almanac device. - Verified that properties for the device were destroyed. - Viewed module panel in UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14831
2015-12-20 16:44:03 +01:00
'AlmanacPropertiesDestructionEngineExtension' => 'PhabricatorDestructionEngineExtension',
Expose modern `*.search` Conduit endpoints in Almanac Summary: Fixes T10411. Ref T10246. There are probably still some rough edges with this, but replace the old-school endpoints with modern ones so we don't unprototype with deprecated stuff. Test Plan: - Made a bunch of calls to the new endpoints with various constraints/attachments. - Created and edited services, devices, interfaces, bindings, and properties on everything. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10246, T10411 Differential Revision: https://secure.phabricator.com/D15329
2016-02-22 21:53:40 +01:00
'AlmanacPropertiesSearchEngineAttachment' => 'AlmanacSearchEngineAttachment',
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
'AlmanacProperty' => array(
Allow Almanac properties to be deleted, use EditEngine instead of CustomField Summary: Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings. The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff). Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks. This also makes the internal storage for properties JSON instead of raw text. Test Plan: - Created, edited and deleted properties on services, devices and bindings. - Edited and reset builtin properties on repository services. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10410 Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 15:35:30 +01:00
'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
'PhabricatorPolicyInterface',
),
'AlmanacPropertyController' => 'AlmanacController',
Expose modern `*.search` Conduit endpoints in Almanac Summary: Fixes T10411. Ref T10246. There are probably still some rough edges with this, but replace the old-school endpoints with modern ones so we don't unprototype with deprecated stuff. Test Plan: - Made a bunch of calls to the new endpoints with various constraints/attachments. - Created and edited services, devices, interfaces, bindings, and properties on everything. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10246, T10411 Differential Revision: https://secure.phabricator.com/D15329
2016-02-22 21:53:40 +01:00
'AlmanacPropertyDeleteController' => 'AlmanacPropertyController',
'AlmanacPropertyEditController' => 'AlmanacPropertyController',
Allow Almanac properties to be deleted, use EditEngine instead of CustomField Summary: Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings. The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff). Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks. This also makes the internal storage for properties JSON instead of raw text. Test Plan: - Created, edited and deleted properties on services, devices and bindings. - Edited and reset builtin properties on repository services. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10410 Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 15:35:30 +01:00
'AlmanacPropertyEditEngine' => 'PhabricatorEditEngine',
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
'AlmanacPropertyQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Allow Almanac Devices and Bindings to have properties Summary: Ref T5833. Adds support for arbitrary properites to Almanac devices and bindings. - For Devices, this allows you to maybe mark what `rack` a server is on, the `serial` number of a router, etc. - For Bindings, this allows you to maybe mark that a bound device is `active`, provide `credentials`, expose it as `readonly`, etc. Test Plan: Added properties to Devices and Bindings. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10781
2014-11-06 00:28:36 +01:00
'AlmanacQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Implement PhabricatorProjectInterface on Almanac Services and Devices Summary: Ref T5833. Allow services and devices to be tagged with projects. (These fluff apply implementations are a good example of the issue discussed in T6403.) Test Plan: {F229569} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10782
2014-11-06 00:30:00 +01:00
'AlmanacSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Expose modern `*.search` Conduit endpoints in Almanac Summary: Fixes T10411. Ref T10246. There are probably still some rough edges with this, but replace the old-school endpoints with modern ones so we don't unprototype with deprecated stuff. Test Plan: - Made a bunch of calls to the new endpoints with various constraints/attachments. - Created and edited services, devices, interfaces, bindings, and properties on everything. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10246, T10411 Differential Revision: https://secure.phabricator.com/D15329
2016-02-22 21:53:40 +01:00
'AlmanacSearchEngineAttachment' => 'PhabricatorSearchEngineAttachment',
Build AlmanacService Summary: Ref T5833. See that task for functional goals and some discussion of design. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 14:01:57 +02:00
'AlmanacService' => array(
'AlmanacDAO',
'PhabricatorPolicyInterface',
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
'PhabricatorApplicationTransactionInterface',
Implement PhabricatorProjectInterface on Almanac Services and Devices Summary: Ref T5833. Allow services and devices to be tagged with projects. (These fluff apply implementations are a good example of the issue discussed in T6403.) Test Plan: {F229569} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10782
2014-11-06 00:30:00 +01:00
'PhabricatorProjectInterface',
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
'AlmanacPropertyInterface',
Almanac: forced interface PHIDs, prefix/suffix device query, DestructibleInterface Summary: Ref T5833. Ref T6238. These are general capabilities which are particularly useful for synchronizing cluster specifications to instances. Test Plan: - Synchronized networks, devices, interfaces, services, bindings and properties to a managed instance. - Used typeahead. - Destroyed networks, devices, and services. Saw interfaces and bindings destroyed. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6238, T5833 Differential Revision: https://secure.phabricator.com/D11024
2014-12-22 21:50:44 +01:00
'PhabricatorDestructibleInterface',
Allow Almanac services to be searched by substring Summary: Ref T10246. Build an ngram index for Almanac services, and use it to support improved search. Test Plan: {F1121725} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10246 Differential Revision: https://secure.phabricator.com/D15321
2016-02-21 19:52:19 +01:00
'PhabricatorNgramsInterface',
Expose modern `*.search` Conduit endpoints in Almanac Summary: Fixes T10411. Ref T10246. There are probably still some rough edges with this, but replace the old-school endpoints with modern ones so we don't unprototype with deprecated stuff. Test Plan: - Made a bunch of calls to the new endpoints with various constraints/attachments. - Created and edited services, devices, interfaces, bindings, and properties on everything. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10246, T10411 Differential Revision: https://secure.phabricator.com/D15329
2016-02-22 21:53:40 +01:00
'PhabricatorConduitResultInterface',
Library Map Update Summary: Our of date, failed harbormaster build Test Plan: run `arc liberate` Reviewers: epriestley, nickz Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15351
2016-02-26 18:42:23 +01:00
'PhabricatorExtendedPolicyInterface',
Build AlmanacService Summary: Ref T5833. See that task for functional goals and some discussion of design. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 14:01:57 +02:00
),
'AlmanacServiceController' => 'AlmanacController',
Add an Almanac service typeahead datasource Summary: Ref T5833. Ref T6238. This will probably be useful somewhere in the upstream eventually, and is materially useful in the Instances application right now. Test Plan: tippy typey typey Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6238, T5833 Differential Revision: https://secure.phabricator.com/D11016
2014-12-19 21:36:14 +01:00
'AlmanacServiceDatasource' => 'PhabricatorTypeaheadDatasource',
Build AlmanacService Summary: Ref T5833. See that task for functional goals and some discussion of design. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 14:01:57 +02:00
'AlmanacServiceEditController' => 'AlmanacServiceController',
Move Almanac Services to EditEngine Summary: Ref T10449. This modernizes the service creation/editing flow and updates the list view code a little bit. Test Plan: - Created a service. - Edited a service. - Browsed services. - Hit policy exception for editing cluster services with no permission. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10449 Differential Revision: https://secure.phabricator.com/D15398
2016-03-05 01:08:38 +01:00
'AlmanacServiceEditEngine' => 'PhabricatorEditEngine',
Allow Almanac properties to be deleted, use EditEngine instead of CustomField Summary: Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings. The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff). Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks. This also makes the internal storage for properties JSON instead of raw text. Test Plan: - Created, edited and deleted properties on services, devices and bindings. - Edited and reset builtin properties on repository services. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10410 Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 15:35:30 +01:00
'AlmanacServiceEditor' => 'AlmanacEditor',
Build AlmanacService Summary: Ref T5833. See that task for functional goals and some discussion of design. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 14:01:57 +02:00
'AlmanacServiceListController' => 'AlmanacServiceController',
Allow Almanac services to be searched by substring Summary: Ref T10246. Build an ngram index for Almanac services, and use it to support improved search. Test Plan: {F1121725} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10246 Differential Revision: https://secure.phabricator.com/D15321
2016-02-21 19:52:19 +01:00
'AlmanacServiceNameNgrams' => 'PhabricatorSearchNgrams',
Build AlmanacService Summary: Ref T5833. See that task for functional goals and some discussion of design. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 14:01:57 +02:00
'AlmanacServicePHIDType' => 'PhabricatorPHIDType',
Allow Almanac properties to be deleted, use EditEngine instead of CustomField Summary: Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings. The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff). Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks. This also makes the internal storage for properties JSON instead of raw text. Test Plan: - Created, edited and deleted properties on services, devices and bindings. - Edited and reset builtin properties on repository services. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10410 Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 15:35:30 +01:00
'AlmanacServicePropertyEditEngine' => 'AlmanacPropertyEditEngine',
Allow Almanac Devices and Bindings to have properties Summary: Ref T5833. Adds support for arbitrary properites to Almanac devices and bindings. - For Devices, this allows you to maybe mark what `rack` a server is on, the `serial` number of a router, etc. - For Bindings, this allows you to maybe mark that a bound device is `active`, provide `credentials`, expose it as `readonly`, etc. Test Plan: Added properties to Devices and Bindings. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10781
2014-11-06 00:28:36 +01:00
'AlmanacServiceQuery' => 'AlmanacQuery',
Expose modern `*.search` Conduit endpoints in Almanac Summary: Fixes T10411. Ref T10246. There are probably still some rough edges with this, but replace the old-school endpoints with modern ones so we don't unprototype with deprecated stuff. Test Plan: - Made a bunch of calls to the new endpoints with various constraints/attachments. - Created and edited services, devices, interfaces, bindings, and properties on everything. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10246, T10411 Differential Revision: https://secure.phabricator.com/D15329
2016-02-22 21:53:40 +01:00
'AlmanacServiceSearchConduitAPIMethod' => 'PhabricatorSearchEngineAPIMethod',
Build AlmanacService Summary: Ref T5833. See that task for functional goals and some discussion of design. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 14:01:57 +02:00
'AlmanacServiceSearchEngine' => 'PhabricatorApplicationSearchEngine',
Allow Almanac properties to be deleted, use EditEngine instead of CustomField Summary: Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings. The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff). Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks. This also makes the internal storage for properties JSON instead of raw text. Test Plan: - Created, edited and deleted properties on services, devices and bindings. - Edited and reset builtin properties on repository services. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10410 Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 15:35:30 +01:00
'AlmanacServiceTransaction' => 'AlmanacTransaction',
Build AlmanacService Summary: Ref T5833. See that task for functional goals and some discussion of design. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 14:01:57 +02:00
'AlmanacServiceTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Give AlmanacServices a service type Summary: Ref T5833. This allows services to be typed, to distinguish between different kinds of services. This makes a few things easier: - It's easier for clients to select the services they're interested in (see note in T5873 about Phacility). This isn't a full-power solution, but gets is some of the way there. - It's easier to set appropriate permissions around when modifications to the Phabricator cluster are allowed. These service nodes need to be demarcated as special in some way no matter what (see T6741). This also defines a new policy for users who are permitted to create services. - It's easier to browse/review/understand services. - Future diffs will allow ServiceTypes to specify more service structure (for example, default properties) to make it easier to configure services correctly. Instead of a free-for-all, you'll get a useful list of things that consumers of the service expect to read. The "custom" service type allows unstructured/freeform services to be created. Test Plan: - Created a new service (and hit error cases). - Edited an existing service. - Saw service types on list and detail views. - Poked around new permission stuff. - Ran `almanac.queryservices` with service class specification. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10995
2014-12-17 20:10:27 +01:00
'AlmanacServiceType' => 'Phobject',
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
'AlmanacServiceTypeDatasource' => 'PhabricatorTypeaheadDatasource',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'AlmanacServiceTypeTestCase' => 'PhabricatorTestCase',
Build AlmanacService Summary: Ref T5833. See that task for functional goals and some discussion of design. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 14:01:57 +02:00
'AlmanacServiceViewController' => 'AlmanacServiceController',
Allow Almanac properties to be deleted, use EditEngine instead of CustomField Summary: Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings. The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff). Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks. This also makes the internal storage for properties JSON instead of raw text. Test Plan: - Created, edited and deleted properties on services, devices and bindings. - Edited and reset builtin properties on repository services. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10410 Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 15:35:30 +01:00
'AlmanacTransaction' => 'PhabricatorApplicationTransaction',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'AphlictDropdownDataQuery' => 'Phobject',
Allow Celerity to return "304 Not Modified" responses Summary: We always return HTTP 200 right now and don't send a "Last-Modified" header, so browsers download more data then necessary if you sit on a page mashing reload (for example). Test Plan: Used Charles to verify HTTP response codes from 400, 404 and 304 responses. Mashed reload a bunch and saw that the server sent back 304s. Changed the resource hash seed and saw 200s, then 304s on reload. Reviewed By: tuomaspelkonen Reviewers: tuomaspelkonen, jungejason, aran CC: bmaurer, aran, tuomaspelkonen Differential Revision: 253
2011-05-09 10:10:40 +02:00
'Aphront304Response' => 'AphrontResponse',
Write pathway for Differential Comments
2011-01-30 21:08:40 +01:00
'Aphront400Response' => 'AphrontResponse',
Make webpage response final
2012-11-29 08:57:13 +01:00
'Aphront403Response' => 'AphrontHTMLResponse',
'Aphront404Response' => 'AphrontHTMLResponse',
Javelin integration.
2011-01-25 20:57:47 +01:00
'AphrontAjaxResponse' => 'AphrontResponse',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'AphrontApplicationConfiguration' => 'Phobject',
AphrontBars Summary: Aphront widgets that render the either a discrete or continuous value as a horizontal shape. Like a progress bar, or a five-star rating bar. Test Plan: `/uiexample/view/PhabricatorAphrontBarExample/` ...which shows this, amongst other things: {F33898} Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5122
2013-03-05 17:46:09 +01:00
'AphrontBarView' => 'AphrontView',
Support HTTP parameter prefilling in EditEngine forms for CustomFields Summary: Ref T9132. This allows you to prefill custom fields with `?custom.x.y=value`, for most types of custom fields. Dates (which are substantially more complicated) aren't supported. I'll just do those once the dust settles. Other types should work, I think. Test Plan: - Verified custom fields appear on "HTTP Parameters" help UI. - Used `?x=y` to prefill custom fields on edit form. - Performed various normal edits. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14634
2015-12-02 14:55:31 +01:00
'AphrontBoolHTTPParameterType' => 'AphrontHTTPParameterType',
Fix conservative CSRF token cycling limit Summary: We currently cycle CSRF tokens every hour and check for the last two valid ones. This means that a form could go stale in as little as an hour, and is certainly stale after two. When a stale form is submitted, you basically get a terrible heisen-state where some of your data might persist if you're lucky but more likely it all just vanishes. The .js file below outlines some more details. This is a pretty terrible UX and we don't need to be as conservative about CSRF validation as we're being. Remedy this problem by: - Accepting the last 6 CSRF tokens instead of the last 1 (i.e., pages are valid for at least 6 hours, and for as long as 7). - Using JS to refresh the CSRF token every 55 minutes (i.e., pages connected to the internet are valid indefinitely). - Showing the user an explicit message about what went wrong when CSRF validation fails so the experience is less bewildering. They should now only be able to submit with a bad CSRF token if: - They load a page, disconnect from the internet for 7 hours, reconnect, and submit the form within 55 minutes; or - They are actually the victim of a CSRF attack. We could eventually fix the first one by tracking reconnects, which might be "free" once the notification server gets built. It will probably never be an issue in practice. Test Plan: - Reduced CSRF cycle frequency to 2 seconds, submitted a form after 15 seconds, got the CSRF exception. - Reduced csrf-refresh cycle frequency to 3 seconds, submitted a form after 15 seconds, got a clean form post. - Added debugging code the the csrf refresh to make sure it was doing sensible things (pulling different tokens, finding all the inputs). Reviewed By: aran Reviewers: tuomaspelkonen, jungejason, aran CC: aran, epriestley Differential Revision: 660
2011-07-13 23:05:18 +02:00
'AphrontCSRFException' => 'AphrontException',
Show user status on calendar Summary: This is a rough cut, but gets some of the basics at least. Here's what it looks like: {F11690} Some things that would be nice for future diffs: - Different colors for different event types (tasks? MEETINGS?!) - When events span across multiple days, keep them in the same row. - Switch which month you're looking at. - Show specific users instead of all. - etc etc etc Test Plan: See screenshot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2514
2012-05-21 19:24:23 +02:00
'AphrontCalendarEventView' => 'AphrontView',
Throw instead of log for invalid properties Summary: Continue work started at D3601. Test Plan: Commented declaration `AphrontController::$request`, saw exception. Brought it back, didn't see exception. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4233
2012-12-19 01:11:07 +01:00
'AphrontController' => 'Phobject',
Rename "IDPaged" to "CursorPaged", "executeWithPager" to "executeWith[Cursor|Offset]Pager" Summary: I'm trying to make progress on the policy/visibility stuff since it's a blocker for Wikimedia. First, I want to improve Projects so they can serve as policy groups (e.g., an object can have a visibility policy like "Visible to: members of project 'security'"). However, doing this without breaking anything or snowballing into a bigger change is a bit awkward because Projects are name-ordered and we have a Conduit API which does offset paging. Rather than breaking or rewriting this stuff, I want to just continue offset paging them for now. So I'm going to make PhabricatorPolicyQuery extend PhabricatorOffsetPagedQuery, but can't currently since the `executeWithPager` methods would clash. These methods do different things anyway and are probably better with different names. This also generally improves the names of these classes, since cursors are not necessarily IDs (in the feed case, they're "chronlogicalKeys", for example). I did leave some of the interals as "ID" since calling them "Cursor"s (e.g., `setAfterCursor()`) seemed a little wrong -- it should maybe be `setAfterCursorPosition()`. These APIs have very limited use and can easily be made more consistent later. Test Plan: Browsed around various affected tools; any issues here should throw/fail in a loud/obvious way. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3177
2012-08-07 20:54:06 +02:00
'AphrontCursorPagerView' => 'AphrontView',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontDefaultApplicationConfiguration' => 'AphrontApplicationConfiguration',
'AphrontDialogResponse' => 'AphrontResponse',
Allow Controllers to return a wider range of "response-like" objects Summary: Ref T1806. Ref T5752. Currently, `handleRequest()` needs to return an `AphrontResponse`, but sometimes it's really convenient to return some other object, like a Dialog, and let that convert into a response elsewhere. Formalize this and clean up some of the existing hacks for it so there's less custom/magical code in Phabricator-specific classes and more general code in Aphront classes. More broadly, I want to clean up T5752 before pursuing T9132, since I'm generally happy with how `SearchEngine` works except for how it interacts with side navs / application menus. I want to fix that first so a new Editor (which will have a lot in common with SearchEngine in terms of how controllers interact with it) doesn't make the problem twice as bad. Test Plan: - Loaded a bunch of normal pages. - Loaded dialogs. - Loaded proxy responses (submitted empty comments in Maniphest). Reviewers: chad Reviewed By: chad Subscribers: joshuaspence Maniphest Tasks: T1806, T5752 Differential Revision: https://secure.phabricator.com/D14032
2015-09-02 00:52:52 +02:00
'AphrontDialogView' => array(
'AphrontView',
'AphrontResponseProducerInterface',
),
Convert Countdown to EditEngine Summary: Fixes T10684. Fixes T10520. This primarily implements a date/epoch field, and then does a bunch of standard plumbing. Test Plan: - Created countdowns. - Edited countdowns. - Used HTTP prefilling. - Created a countdown ending on "Christmas Morning", etc. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10520, T10684 Differential Revision: https://secure.phabricator.com/D15655
2016-04-07 20:06:26 +02:00
'AphrontEpochHTTPParameterType' => 'AphrontHTTPParameterType',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'AphrontException' => 'Exception',
Phabricator file upload application.
2011-01-23 03:33:00 +01:00
'AphrontFileResponse' => 'AphrontResponse',
MetaMTA
2011-01-26 02:40:21 +01:00
'AphrontFormCheckboxControl' => 'AphrontFormControl',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontFormControl' => 'AphrontView',
Add a datepicker control Summary: I looooove JS! It makes me giddy with glee! Test Plan: Picked dates. See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2086
2012-04-04 21:14:10 +02:00
'AphrontFormDateControl' => 'AphrontFormControl',
Fix datepicker to show correct error messages on Calendar event edit view Summary: Ref T8024, Fix datepicker to show correct error messages on Calendar event edit view. Test Plan: Edit Calendar event, set blank title, and valid new end time, error page should correctly point out invalid title, but reflec the updated time. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T8024 Differential Revision: https://secure.phabricator.com/D12647
2015-05-02 01:07:57 +02:00
'AphrontFormDateControlValue' => 'Phobject',
Various fixes, particularly on the revision update workflow.
2011-02-05 02:53:14 +01:00
'AphrontFormDividerControl' => 'AphrontFormControl',
Phabricator file upload application.
2011-01-23 03:33:00 +01:00
'AphrontFormFileControl' => 'AphrontFormControl',
Make "Create Subtask" work properly in EditEngine Summary: Ref T9908. This fixes "Create Subtask" so it works with the new stuff. Mostly straightforward. Test Plan: Created some subtasks. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9908 Differential Revision: https://secure.phabricator.com/D14706
2015-12-08 16:54:01 +01:00
'AphrontFormHandlesControl' => 'AphrontFormControl',
Conduit: user.find
2011-01-24 20:36:53 +01:00
'AphrontFormMarkupControl' => 'AphrontFormControl',
PhabricatorEnv 'infratructure' -> 'infrastructure' (rofl) Recaptcha Email Login / Forgot Password Password Reset
2011-01-31 20:55:26 +01:00
'AphrontFormPasswordControl' => 'AphrontFormControl',
Add basic per-object privacy policies Summary: Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change. Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request. The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens. We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can. Test Plan: Unit tests, played around in the UI with various policy settings. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
'AphrontFormPolicyControl' => 'AphrontFormControl',
Improve Herald personal/global UI/UX Summary: - Default "personal" vs "global" choice to "personal". - Don't show global rules under "My Rules". - After editing or creating a global rule, redirect back to global rule list. - Use radio buttons for "personal" vs "global" and add captions explaining the difference. - For "global" rules, don't show the owner/author in the rule detail view -- they effectively have no owner (see also D1387). - For "global" rules, don't show the owner/author in the rule list view, as above. - For admin views, show rule type (global vs personal). Test Plan: - Created and edited new global and personal rules. - Viewed "my", "global" and "admin" views. Reviewers: btrahan, jungejason, nh, xela Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1518
2012-01-31 21:09:29 +01:00
'AphrontFormRadioButtonControl' => 'AphrontFormControl',
PhabricatorEnv 'infratructure' -> 'infrastructure' (rofl) Recaptcha Email Login / Forgot Password Password Reset
2011-01-31 20:55:26 +01:00
'AphrontFormRecaptchaControl' => 'AphrontFormControl',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontFormSelectControl' => 'AphrontFormControl',
Phabricator file upload application.
2011-01-23 03:33:00 +01:00
'AphrontFormStaticControl' => 'AphrontFormControl',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontFormSubmitControl' => 'AphrontFormControl',
'AphrontFormTextAreaControl' => 'AphrontFormControl',
'AphrontFormTextControl' => 'AphrontFormControl',
Clean up the Diffusion search UI a little bit Summary: Ref T156. @vlada recently implemented filename search in Diffusion, this cleans up the UI a little bit: - Instead of showing one search box with two different buttons, let the submit buttons appear to the right of the text boxes and separate the search modes. - Clean up the results a little bit (don't show columns which don't exist). Test Plan: {F107260} Reviewers: vlada, btrahan, chad Reviewed By: chad CC: vlada, chad, aran Maniphest Tasks: T156 Differential Revision: https://secure.phabricator.com/D8125
2014-02-01 20:48:28 +01:00
'AphrontFormTextWithSubmitControl' => 'AphrontFormControl',
Typeaheads
2011-01-25 22:48:05 +01:00
'AphrontFormTokenizerControl' => 'AphrontFormControl',
Add a SublimeText-style repository typeahead Summary: Allows you to quickly search for files within a repository. Roughly: - We build a big tree of everything and ship it to the client. - The client implements a bunch of Sublime-ish magic to find paths. Test Plan: {F154007} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley, zeeg Differential Revision: https://secure.phabricator.com/D9087
2014-05-13 23:08:21 +02:00
'AphrontFormTypeaheadControl' => 'AphrontFormControl',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontFormView' => 'AphrontView',
AphrontBars Summary: Aphront widgets that render the either a discrete or continuous value as a horizontal shape. Like a progress bar, or a five-star rating bar. Test Plan: `/uiexample/view/PhabricatorAphrontBarExample/` ...which shows this, amongst other things: {F33898} Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5122
2013-03-05 17:46:09 +01:00
'AphrontGlyphBarView' => 'AphrontBarView',
Make webpage response final
2012-11-29 08:57:13 +01:00
'AphrontHTMLResponse' => 'AphrontResponse',
Modularize complex HTTP parameter types Summary: Ref T9132. We have several places in the code that sometimes need to parse complex types. For example, we accept all of these in ApplicationSearch and now in ApplicationEditor: > /?subscribers=cat,dog > /?subscribers=PHID-USER-1111 > /?subscribers[]=cat&subscribers[]=PHID-USER-2222 ..etc. The logic to parse this stuff isn't too complex, but it isn't trivial either. Right now it lives in some odd places. Notably, `PhabricatorApplicationSearchEngine` has some weird helper methods for this stuff. Rather than give `EditEngine` the same set of weird helper methods, pull all this stuff out into "HTTPParameterTypes". Future diffs will add "Projects" and "Users" types where all the custom parsing/lookup logic can live. Then eventually the Search stuff can reuse these. Generally, this just breaks the code up into smaller pieces that have more specific responsibilities. Test Plan: {F944142} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14402
2015-11-04 14:05:10 +01:00
'AphrontHTTPParameterType' => 'Phobject',
Add an AphrontHTTPProxyResponse Summary: Ref T7019. Adds a new response which can proxy an HTTP request and pass the result through. This is grossly inefficient for the same reasons as HTTP hosting is generally inefficient right now (T4369). This stuff is fixable but not trivial. Test Plan: Replaced home page with a proxy to `example.org`, used Charles to view headers, saw the page headers and content proxy with an X-Phabricator-Proxied header. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7019 Differential Revision: https://secure.phabricator.com/D11492
2015-01-27 23:50:52 +01:00
'AphrontHTTPProxyResponse' => 'AphrontResponse',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'AphrontHTTPSink' => 'Phobject',
Provide software protections for HTTP response splitting Summary: This addresses a few things: - Provide a software HTTP response spliting guard as an extra layer of security, see http://news.php.net/php.internals/57655 and who knows what HPHP/i does. - Cleans up webroot/index.php a little bit, I want to get that file under control eventually. - Eventually I want to collect bytes in/out metrics and this allows us to do that easily. - We may eventually want to write to a socket or do something else like that, ala Litespawn. Test Plan: - Ran unit tests. - Browsed around, checked headers and HTTP status codes. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1564
2012-02-06 18:59:34 +01:00
'AphrontHTTPSinkTestCase' => 'PhabricatorTestCase',
Support HTTP parameter prefilling in EditEngine forms for CustomFields Summary: Ref T9132. This allows you to prefill custom fields with `?custom.x.y=value`, for most types of custom fields. Dates (which are substantially more complicated) aren't supported. I'll just do those once the dust settles. Other types should work, I think. Test Plan: - Verified custom fields appear on "HTTP Parameters" help UI. - Used `?x=y` to prefill custom fields on edit form. - Performed various normal edits. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14634
2015-12-02 14:55:31 +01:00
'AphrontIntHTTPParameterType' => 'AphrontHTTPParameterType',
Provide an "isolated" database connection for testing Summary: This provides a new connection which doesn't connect to anything, so effects can be isolated to the current process (for unit testing). Test Plan: Ran unit tests. Reviewed By: aran Reviewers: aran, tuomaspelkonen, jungejason CC: aran, epriestley Differential Revision: 193
2011-04-30 19:11:41 +02:00
'AphrontIsolatedDatabaseConnectionTestCase' => 'PhabricatorTestCase',
Provide software protections for HTTP response splitting Summary: This addresses a few things: - Provide a software HTTP response spliting guard as an extra layer of security, see http://news.php.net/php.internals/57655 and who knows what HPHP/i does. - Cleans up webroot/index.php a little bit, I want to get that file under control eventually. - Eventually I want to collect bytes in/out metrics and this allows us to do that easily. - We may eventually want to write to a socket or do something else like that, ala Litespawn. Test Plan: - Ran unit tests. - Browsed around, checked headers and HTTP status codes. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1564
2012-02-06 18:59:34 +01:00
'AphrontIsolatedHTTPSink' => 'AphrontHTTPSink',
Encode "<" and ">" in JSON/Ajax responses to prevent content-sniffing attacks Summary: Some browsers will still sniff content types even with "Content-Type" and "X-Content-Type-Options: nosniff". Encode "<" and ">" to prevent them from sniffing the content as HTML. See T865. Also unified some of the code on this pathway. Test Plan: Verified Opera no longer sniffs the Conduit response into HTML for the test case in T865. Unit tests pass. Reviewers: cbg, btrahan Reviewed By: cbg CC: aran, epriestley Maniphest Tasks: T139, T865 Differential Revision: https://secure.phabricator.com/D1606
2012-02-14 23:51:51 +01:00
'AphrontJSONResponse' => 'AphrontResponse',
Examples using JX.View Summary: Provide a dirt-simple working example of client-side templating and reactive programming. Test Plan: Load the examples Reviewers: epriestley, mroch, tomo Reviewed By: epriestley CC: ide, schrockn, aran, rzadorozny, epriestley Differential Revision: 908
2011-09-07 23:01:13 +02:00
'AphrontJavelinView' => 'AphrontView',
Provide basic keyboard navigation support for Differential. Summary: ReviewBoard has a fancier version of this feature that's more granular -- the keyboard can focus on individual changes. I think that's good and intend to implement something similar, but this gets us a step closer and gets rid of some of the bookkeeping stuff like making shortcuts discoverable. (I have another brnach with Maniphest merging which also uses fatcow icons, which is why the README seems a little out of context.) Test Plan: Used "j" and "k" to jump between changesets. Pressed "?" and got a list of available shortcuts. Reviewed By: tuomaspelkonen Reviewers: aran, jungejason, tuomaspelkonen CC: moskov, aran, epriestley, tuomaspelkonen Differential Revision: 412
2011-06-08 20:53:10 +02:00
'AphrontKeyboardShortcutsAvailableView' => 'AphrontView',
AphrontListFilterView, for list filtering.
2011-04-04 00:50:06 +02:00
'AphrontListFilterView' => 'AphrontView',
Improve code structure of PHID fields in EditEngine Summary: Ref T9132. I had some hacks in place for dealing with Edge/Subscribers stuff. Clean that up so it's structured a little better. Test Plan: - Edited subscribers and projects. - Verified things still show up in Conduit. - Made concurrent edits (added a project in one window, removed it in another window, got a clean result with a correct merge of the two edits). Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14601
2015-11-29 22:24:47 +01:00
'AphrontListHTTPParameterType' => 'AphrontHTTPParameterType',
Replace AphrontUsageException with AphrontMalformedRequestException Summary: Ref T1806. Ref T7173. Context here is that I want to fix "you can not log in to this instance" being a confusing mess with an opaque error. To do this without hacks, I want to: - clean up some exception handling behavior (this diff); - modularize exception handling (next diff); - replace confusing, over-general exceptions with tailored ones in the Phacility cluster, using the new modular stuff. This cleans up an awkward "AphrontUsageException" which does some weird stuff right now. In particular, it is extensible and extended in one place in Diffusion, but that extension is meaningless. Realign this as "AphrontMalformedRequestException", which is a better description of what it is and does: raises errors before we can get as far as normal routing and site handling. Test Plan: Hit some of these exceptions, saw the expected "abandon all hope" error page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14047
2015-09-03 19:04:17 +02:00
'AphrontMalformedRequestException' => 'AphrontException',
Show "show more..." link in "Local Commits" view in Differential Summary: Javascript! Depends on D2437 to do anything useful. Test Plan: Clicked "show more", saw more. Reviewers: csilvers, btrahan Reviewed By: csilvers CC: aran Maniphest Tasks: T1189 Differential Revision: https://secure.phabricator.com/D2438
2012-05-10 00:56:37 +02:00
'AphrontMoreView' => 'AphrontView',
Build an AphrontMultiColumnView, use on workboards. Summary: Abstract out the multi-column code from workboards and have it be available separately. I feel like there will be some benefit here especially for custom developers in how they present infromation (like releeph). It also scales back to tablet and mobile fairly well, so they get those things for free. Test Plan: Tested mobile, tablet and chrome layouts. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5529
2013-04-02 20:23:24 +02:00
'AphrontMultiColumnView' => 'AphrontView',
Simplify Aphront transaction code Summary: In D1515, I introduced some excessively-complicated semantics for detecting connections that are lost while transactional. These semantics cause us to reenter establishConnection() and establish twice as many connections as we need in the common case. We don't need a hook there at all -- it's sufficient to throw the exception rather than retrying the query when we encounter it. This doesn't have reentrancy problems. Test Plan: - Added some encapsulation-violating hooks and a unit test for them - Verified we no longer double-connect. Reviewers: btrahan, nh Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T835 Differential Revision: https://secure.phabricator.com/D1576
2012-02-07 23:58:37 +01:00
'AphrontMySQLDatabaseConnectionTestCase' => 'PhabricatorTestCase',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontNullView' => 'AphrontView',
Modularize complex HTTP parameter types Summary: Ref T9132. We have several places in the code that sometimes need to parse complex types. For example, we accept all of these in ApplicationSearch and now in ApplicationEditor: > /?subscribers=cat,dog > /?subscribers=PHID-USER-1111 > /?subscribers[]=cat&subscribers[]=PHID-USER-2222 ..etc. The logic to parse this stuff isn't too complex, but it isn't trivial either. Right now it lives in some odd places. Notably, `PhabricatorApplicationSearchEngine` has some weird helper methods for this stuff. Rather than give `EditEngine` the same set of weird helper methods, pull all this stuff out into "HTTPParameterTypes". Future diffs will add "Projects" and "Users" types where all the custom parsing/lookup logic can live. Then eventually the Search stuff can reuse these. Generally, this just breaks the code up into smaller pieces that have more specific responsibilities. Test Plan: {F944142} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14402
2015-11-04 14:05:10 +01:00
'AphrontPHIDHTTPParameterType' => 'AphrontHTTPParameterType',
Improve code structure of PHID fields in EditEngine Summary: Ref T9132. I had some hacks in place for dealing with Edge/Subscribers stuff. Clean that up so it's structured a little better. Test Plan: - Edited subscribers and projects. - Verified things still show up in Conduit. - Made concurrent edits (added a project in one window, removed it in another window, got a clean result with a correct merge of the two edits). Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14601
2015-11-29 22:24:47 +01:00
'AphrontPHIDListHTTPParameterType' => 'AphrontListHTTPParameterType',
Provide software protections for HTTP response splitting Summary: This addresses a few things: - Provide a software HTTP response spliting guard as an extra layer of security, see http://news.php.net/php.internals/57655 and who knows what HPHP/i does. - Cleans up webroot/index.php a little bit, I want to get that file under control eventually. - Eventually I want to collect bytes in/out metrics and this allows us to do that easily. - We may eventually want to write to a socket or do something else like that, ala Litespawn. Test Plan: - Ran unit tests. - Browsed around, checked headers and HTTP status codes. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1564
2012-02-06 18:59:34 +01:00
'AphrontPHPHTTPSink' => 'AphrontHTTPSink',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontPageView' => 'AphrontView',
Improve error message for Conduit path problems Summary: A few people in IRC have been having issues here recently. If you misconfigure the IRC bot, e.g., you get a 200 response back with a bunch of login HTML in it. This is unhelpful. Try to detect that a conduit request is going to the wrong path and raise a concise, explicit error which is comprehensible from the CLI. Also created a "PlainText" response and moved the IE nosniff header to the base response object. Test Plan: As a logged-out user, hit various nonsense with "?__conduit__=true" in the URI. Got good error messages. Hit nonsense without it, got login screens. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T775 Differential Revision: https://secure.phabricator.com/D1407
2012-01-15 20:06:13 +01:00
'AphrontPlainTextResponse' => 'AphrontResponse',
AphrontBars Summary: Aphront widgets that render the either a discrete or continuous value as a horizontal shape. Like a progress bar, or a five-star rating bar. Test Plan: `/uiexample/view/PhabricatorAphrontBarExample/` ...which shows this, amongst other things: {F33898} Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5122
2013-03-05 17:46:09 +01:00
'AphrontProgressBarView' => 'AphrontBarView',
Improve code structure of PHID fields in EditEngine Summary: Ref T9132. I had some hacks in place for dealing with Edge/Subscribers stuff. Clean that up so it's structured a little better. Test Plan: - Edited subscribers and projects. - Verified things still show up in Conduit. - Made concurrent edits (added a project in one window, removed it in another window, got a clean result with a correct merge of the two edits). Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14601
2015-11-29 22:24:47 +01:00
'AphrontProjectListHTTPParameterType' => 'AphrontListHTTPParameterType',
Allow Controllers to return a wider range of "response-like" objects Summary: Ref T1806. Ref T5752. Currently, `handleRequest()` needs to return an `AphrontResponse`, but sometimes it's really convenient to return some other object, like a Dialog, and let that convert into a response elsewhere. Formalize this and clean up some of the existing hacks for it so there's less custom/magical code in Phabricator-specific classes and more general code in Aphront classes. More broadly, I want to clean up T5752 before pursuing T9132, since I'm generally happy with how `SearchEngine` works except for how it interacts with side navs / application menus. I want to fix that first so a new Editor (which will have a lot in common with SearchEngine in terms of how controllers interact with it) doesn't make the problem twice as bad. Test Plan: - Loaded a bunch of normal pages. - Loaded dialogs. - Loaded proxy responses (submitted empty comments in Maniphest). Reviewers: chad Reviewed By: chad Subscribers: joshuaspence Maniphest Tasks: T1806, T5752 Differential Revision: https://secure.phabricator.com/D14032
2015-09-02 00:52:52 +02:00
'AphrontProxyResponse' => array(
'AphrontResponse',
'AphrontResponseProducerInterface',
),
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontRedirectResponse' => 'AphrontResponse',
Be more strict about "Location:" redirects Summary: Via HackerOne. Chrome (at least) interprets backslashes like forward slashes, so a redirect to "/\evil.com" is the same as a redirect to "//evil.com". - Reject local URIs with backslashes (we never generate these). - Fully-qualify all "Location:" redirects. - Require external redirects to be marked explicitly. Test Plan: - Expanded existing test coverage. - Verified that neither Diffusion nor Phriction can generate URIs with backslashes (they are escaped in Diffusion, and removed by slugging in Phriction). - Logged in with Facebook (OAuth2 submits a form to the external site, and isn't affected) and Twitter (OAuth1 redirects, and is affected). - Went through some local redirects (login, save-an-object). - Verified file still work. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D10291
2014-08-18 23:11:06 +02:00
'AphrontRedirectResponseTestCase' => 'PhabricatorTestCase',
Allow revisions to be edited from Maniphest Summary: You can currently attach tasks to revisions from Differential, but not revisions to tasks from Maniphest. Allow editing from either side. This logic is kind of tricky but the alternative was massive code duplication. Test Plan: Added and removed revisions from maniphest. Added and removed tasks from differential. This should have no impact on the Facebook install since none of this is used there. Reviewed By: aran Reviewers: tomo, tuomaspelkonen, jungejason, aran CC: aran, epriestley Differential Revision: 288
2011-05-16 20:43:39 +02:00
'AphrontReloadResponse' => 'AphrontRedirectResponse',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'AphrontRequest' => 'Phobject',
Modularize Aphront exception handling Summary: Ref T1806. Ref T7173. Depends on D14047. Currently, all exception handling is in this big messy clump in `AphrontDefaultApplicationConfiguration`. Split it out into modular classes. This will let a future change add new classes in the Phacility cluster which intercept particular exceptions we care about and replaces the default, generic responses with more useful, tailored responses. Test Plan: {F777391} - Hit a Conduit error (made a method throw). - Hit an Ajax error (made comment preview throw). - Hit a high security error (tried to edit TOTP). - Hit a rate limiting error (added a bunch of email addresses). - Hit a policy error (tried to look at something with no permission). - Hit an arbitrary exception (made a randomc ontroller throw). Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14049
2015-09-03 19:04:42 +02:00
'AphrontRequestExceptionHandler' => 'Phobject',
Add getStrList() to AphrontRequest Summary: - We have a few places where we do some kind of ad-hoc comma list tokenizing, and I'm adding another one in D1290. Add a helper to the request object. - Add some unit tests. Test Plan: - Ran unit tests. - Used PHID manager, Maniphest custom view, and Repository project editor. Reviewers: btrahan, fratrik, jungejason Reviewed By: btrahan CC: aran, btrahan, epriestley Differential Revision: https://secure.phabricator.com/D1302
2012-01-04 06:57:45 +01:00
'AphrontRequestTestCase' => 'PhabricatorTestCase',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'AphrontResponse' => 'Phobject',
Push construction of routing maps into Sites Summary: This enables CORGI. Currently, `AphrontSite` subclasses can't really have their own routes. They can do this sort of hacky rewriting of paths, but that's a mess and not desirable in the long run. Instead, let subclasses build their own routing maps. This will let CORP and ORG have their own routing maps. I was able to get rid of the `PhameBlogResourcesSite` since it can really just share the standard resources site. Test Plan: - With no base URI set, and a base URI set, loaded main page and resources (from main site). - With file domain set, loaded resources from main site and file site. - Loaded a skinned blog from a domain. - Loaded a skinned blog from the main site. - Viewed "Request" tab of DarkConsole to see site/controller info. Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D14008
2015-08-31 13:01:01 +02:00
'AphrontRoutingMap' => 'Phobject',
'AphrontRoutingResult' => 'Phobject',
Modularize complex HTTP parameter types Summary: Ref T9132. We have several places in the code that sometimes need to parse complex types. For example, we accept all of these in ApplicationSearch and now in ApplicationEditor: > /?subscribers=cat,dog > /?subscribers=PHID-USER-1111 > /?subscribers[]=cat&subscribers[]=PHID-USER-2222 ..etc. The logic to parse this stuff isn't too complex, but it isn't trivial either. Right now it lives in some odd places. Notably, `PhabricatorApplicationSearchEngine` has some weird helper methods for this stuff. Rather than give `EditEngine` the same set of weird helper methods, pull all this stuff out into "HTTPParameterTypes". Future diffs will add "Projects" and "Users" types where all the custom parsing/lookup logic can live. Then eventually the Search stuff can reuse these. Generally, this just breaks the code up into smaller pieces that have more specific responsibilities. Test Plan: {F944142} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14402
2015-11-04 14:05:10 +01:00
'AphrontSelectHTTPParameterType' => 'AphrontHTTPParameterType',
Take the first step on the long journey of fixing "Projects" Summary: - Allow more than the 100 most recent projects to be viewed. - Provide some useful filters. - Default the view to your projects, not all projects. - Put query logic in a query object. - Put filter view logic in a view object. We can port more stuff to it later. Test Plan: Looked at active/owned/all projects. Set page size to 5 and paged through projects. Reviewers: btrahan, jungejason, zeeg Reviewed By: btrahan CC: aran, btrahan Differential Revision: 1227
2011-12-17 02:08:18 +01:00
'AphrontSideNavFilterView' => 'AphrontView',
Modularize Aphront "sites" Summary: Fixes T5702. The path here is long and windy: - I want to move `blog.phacility.com` to the new `secure` host. - That host has `security.require-https` set, which I want to keep set (before, this was handled in a sort of hacky way at the nginx/preamble level, but I've cleaned up everything else now). - Currently, that setting forces blogs to HTTPS too, which won't work. - To let blogs be individually configurable, we need to either modularize site config or make things hackier. - Modularize rather than increasing hackiness. - Also add a little "modules" panel in Config. See T6859. This feels like a reasonable middle ground between putting this stuff in Applications and burying it in `bin/somewhere`. Test Plan: - Visited normal site. - Visited phame on-domain site. - Visited phame off-domain site. - Viewed static resources. {F561897} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D13474
2015-06-29 23:04:48 +02:00
'AphrontSite' => 'Phobject',
When stopping on redirect, show a full stack trace Summary: Ref T4140. Provide more debugging information so we can figure out what's going on with redirect loops. Test Plan: {F83868} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4140 Differential Revision: https://secure.phabricator.com/D7620
2013-11-21 23:38:29 +01:00
'AphrontStackTraceView' => 'AphrontView',
Improve top-level exception handling Summary: Fixes T6692. Addresses two main issues: - The write guard would sometimes not get disposed of on exception pathways, generating an unnecessary secondary error which was just a symptom of the original root error. - This was generally confusing and reduced the quality of reports we received because users would report the symptomatic error sometimes instead of the real error. - Instead, reflow the handling so that we always dispose of the write guard if we create one. - If we missed the Controller-level error page generation (normally, a nice page with full CSS, etc), we'd jump straight to Startup-level error page generation (very basic plain text). - A large class of errors occur too early or too late to be handled by Controller-level pages, but many of these errors are not fundamental, and the plain text page is excessively severe. - Provide a mid-level simple HTML error page for errors which can't get full CSS, but also aren't so fundamental that we have no recourse but plain text. Test Plan: Mid-level errors now produce an intentional-looking error page: {F259885} Verified that setup errors still render properly. @chad, feel free to tweak the exception page -- I just did a rough pass on it. Like the setup error stuff, it doesn't have Celerity, so we can't use `{$colors}` and no other CSS will be loaded. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley, chad Maniphest Tasks: T6692 Differential Revision: https://secure.phabricator.com/D11126
2015-01-02 19:49:27 +01:00
'AphrontStandaloneHTMLResponse' => 'AphrontHTMLResponse',
Modularize complex HTTP parameter types Summary: Ref T9132. We have several places in the code that sometimes need to parse complex types. For example, we accept all of these in ApplicationSearch and now in ApplicationEditor: > /?subscribers=cat,dog > /?subscribers=PHID-USER-1111 > /?subscribers[]=cat&subscribers[]=PHID-USER-2222 ..etc. The logic to parse this stuff isn't too complex, but it isn't trivial either. Right now it lives in some odd places. Notably, `PhabricatorApplicationSearchEngine` has some weird helper methods for this stuff. Rather than give `EditEngine` the same set of weird helper methods, pull all this stuff out into "HTTPParameterTypes". Future diffs will add "Projects" and "Users" types where all the custom parsing/lookup logic can live. Then eventually the Search stuff can reuse these. Generally, this just breaks the code up into smaller pieces that have more specific responsibilities. Test Plan: {F944142} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14402
2015-11-04 14:05:10 +01:00
'AphrontStringHTTPParameterType' => 'AphrontHTTPParameterType',
Improve code structure of PHID fields in EditEngine Summary: Ref T9132. I had some hacks in place for dealing with Edge/Subscribers stuff. Clean that up so it's structured a little better. Test Plan: - Edited subscribers and projects. - Verified things still show up in Conduit. - Made concurrent edits (added a project in one window, removed it in another window, got a clean result with a correct merge of the two edits). Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14601
2015-11-29 22:24:47 +01:00
'AphrontStringListHTTPParameterType' => 'AphrontListHTTPParameterType',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontTableView' => 'AphrontView',
Genericize implementing views which expose common attributes Summary: Some views expose some/most/all of the basics (id, class, sigil, metadata, etc); let them extend a dedicated view to get it for free. Test Plan: Viewed home page, paste, mobile dropdown, etc. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D4440
2013-01-16 19:50:41 +01:00
'AphrontTagView' => 'AphrontView',
Some herald improvements.
2011-03-23 04:41:02 +01:00
'AphrontTokenizerTemplateView' => 'AphrontView',
Some owners read workflows.
2011-04-04 04:20:47 +02:00
'AphrontTypeaheadTemplateView' => 'AphrontView',
Improve top-level exception handling Summary: Fixes T6692. Addresses two main issues: - The write guard would sometimes not get disposed of on exception pathways, generating an unnecessary secondary error which was just a symptom of the original root error. - This was generally confusing and reduced the quality of reports we received because users would report the symptomatic error sometimes instead of the real error. - Instead, reflow the handling so that we always dispose of the write guard if we create one. - If we missed the Controller-level error page generation (normally, a nice page with full CSS, etc), we'd jump straight to Startup-level error page generation (very basic plain text). - A large class of errors occur too early or too late to be handled by Controller-level pages, but many of these errors are not fundamental, and the plain text page is excessively severe. - Provide a mid-level simple HTML error page for errors which can't get full CSS, but also aren't so fundamental that we have no recourse but plain text. Test Plan: Mid-level errors now produce an intentional-looking error page: {F259885} Verified that setup errors still render properly. @chad, feel free to tweak the exception page -- I just did a rough pass on it. Like the setup error stuff, it doesn't have Celerity, so we can't use `{$colors}` and no other CSS will be loaded. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley, chad Maniphest Tasks: T6692 Differential Revision: https://secure.phabricator.com/D11126
2015-01-02 19:49:27 +01:00
'AphrontUnhandledExceptionResponse' => 'AphrontStandaloneHTMLResponse',
Improve code structure of PHID fields in EditEngine Summary: Ref T9132. I had some hacks in place for dealing with Edge/Subscribers stuff. Clean that up so it's structured a little better. Test Plan: - Edited subscribers and projects. - Verified things still show up in Conduit. - Made concurrent edits (added a project in one window, removed it in another window, got a clean result with a correct merge of the two edits). Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14601
2015-11-29 22:24:47 +01:00
'AphrontUserListHTTPParameterType' => 'AphrontListHTTPParameterType',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'AphrontView' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'Phobject',
'PhutilSafeHTMLProducerInterface',
Have AphrontView implement PhutilSafeHTMLProducerInterface Summary: Allows views to work like tags. Test Plan: Implemented a few completely arbitrary render() / singleView simplifications. I just picked some that were easy to test. I'll do a more thorough pass on this in a followup; these calls don't really hurt anything. Reviewers: chad, vrana Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D5306
2013-03-09 22:52:21 +01:00
),
Make webpage response final
2012-11-29 08:57:13 +01:00
'AphrontWebpageResponse' => 'AphrontHTMLResponse',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ArcanistConduitAPIMethod' => 'ConduitAPIMethod',
'AuditConduitAPIMethod' => 'ConduitAPIMethod',
'AuditQueryConduitAPIMethod' => 'AuditConduitAPIMethod',
Auth - add "manage providers" capability Summary: Ref T6947. Test Plan: toggled setting in application settings and changes stuck. set policy to admin user a only and could not add a provider as a admin user b. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6947 Differential Revision: https://secure.phabricator.com/D11356
2015-01-12 23:37:58 +01:00
'AuthManageProvidersCapability' => 'PhabricatorPolicyCapability',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'CalendarTimeUtil' => 'Phobject',
Fix calendar display on profile. Summary: ...maybe anyway because I can't reproduce it live. This diff does two things that should help with bugginess though - uses $viewer rather than $user (...$user is who we are looking at...) *AND* upgrades a Conpherence util class to Calendar, and said util class has unit tests and came about from fixing a similar bug in Conpherence back in the day. Wrote some comments in the util class because I think it has a tendency to trip people up. These comments are not partciularly good however. Test Plan: viewed user profile - looked good. viewed conpherence - looked good. ran unit tests - they passed. (note I would also like to push this live and verify Chad's profile is fixed on secure.phabricator.com) Reviewers: epriestley, chad Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D8341
2014-02-25 22:43:31 +01:00
'CalendarTimeUtilTestCase' => 'PhabricatorTestCase',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'CelerityAPI' => 'Phobject',
Modularize Celerity postprocessors Summary: Not sure if we want this, but it seems to work fine. Test Plan: {F516736} Reviewers: joshuaspence, chad Reviewed By: joshuaspence, chad Subscribers: joshuaspence, epriestley Differential Revision: https://secure.phabricator.com/D13363
2015-06-20 15:10:42 +02:00
'CelerityDefaultPostprocessor' => 'CelerityPostprocessor',
'CelerityHighContrastPostprocessor' => 'CelerityPostprocessor',
[Redesign] Larger Font PostProcessor Summary: Ref T8099, Ref T8614. Reasonable attempt at a larger font size PostProcessor, will need additional UI cleanup (places where we fix height) but overall very decent. Test Plan: Use lots of the UI elements with new font sizes. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T8099, T8614 Differential Revision: https://secure.phabricator.com/D13457
2015-06-26 18:33:03 +02:00
'CelerityLargeFontPostprocessor' => 'CelerityPostprocessor',
Begin construction of `bin/celerity map` Summary: Ref T4222. Moves us toward a more modern Celerity CLI, and moves map discovery into the classtree. This is a little bit bulky (and means you can't ship completely standalone celerity maps) but has the advantage of being completely standard, and we could subclass maps into an auto-discovering map later if we have a need for it. This doesn't affect the existing Celerity stuff. I'm going to build the new stuff in parallel, and then swap us over at the end. Test Plan: Ran `bin/celerity map`, got reasonable-looking output. Reviewers: btrahan, hach-que Reviewed By: hach-que CC: aran Maniphest Tasks: T4222 Differential Revision: https://secure.phabricator.com/D7864
2014-01-01 03:02:41 +01:00
'CelerityManagementMapWorkflow' => 'CelerityManagementWorkflow',
Generate syntax highlighting CSS from a reusable map Summary: Ref T9790. This prepares the syntax color rules to be reused in mail. This goes about halfway toward T5701 by sort-of supporting different styles but not really. Test Plan: - Ran `bin/celerity syntax` to regenerate syntax map. - Viewed some highlighted code, didn't see any differences. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9790 Differential Revision: https://secure.phabricator.com/D15846
2016-05-05 03:24:59 +02:00
'CelerityManagementSyntaxWorkflow' => 'CelerityManagementWorkflow',
Begin construction of `bin/celerity map` Summary: Ref T4222. Moves us toward a more modern Celerity CLI, and moves map discovery into the classtree. This is a little bit bulky (and means you can't ship completely standalone celerity maps) but has the advantage of being completely standard, and we could subclass maps into an auto-discovering map later if we have a need for it. This doesn't affect the existing Celerity stuff. I'm going to build the new stuff in parallel, and then swap us over at the end. Test Plan: Ran `bin/celerity map`, got reasonable-looking output. Reviewers: btrahan, hach-que Reviewed By: hach-que CC: aran Maniphest Tasks: T4222 Differential Revision: https://secure.phabricator.com/D7864
2014-01-01 03:02:41 +01:00
'CelerityManagementWorkflow' => 'PhabricatorManagementWorkflow',
Allow blog resources to be served without Celerity Summary: Allow skins to serve arbitrary resources without needing to be mapped, so we can have a vibrant community of amateur skinners. For "basic" skins, just put all the "css/" on the page always. Includes an image to prove that works. @vrana, pretty sure this has no impact outside of Phame but it does change Celerity so it might be to blame if there's any weirdness with static resources. Test Plan: {F21341} {F21340} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3719
2012-10-17 17:37:05 +02:00
'CelerityPhabricatorResourceController' => 'CelerityResourceController',
Begin construction of `bin/celerity map` Summary: Ref T4222. Moves us toward a more modern Celerity CLI, and moves map discovery into the classtree. This is a little bit bulky (and means you can't ship completely standalone celerity maps) but has the advantage of being completely standard, and we could subclass maps into an auto-discovering map later if we have a need for it. This doesn't affect the existing Celerity stuff. I'm going to build the new stuff in parallel, and then swap us over at the end. Test Plan: Ran `bin/celerity map`, got reasonable-looking output. Reviewers: btrahan, hach-que Reviewed By: hach-que CC: aran Maniphest Tasks: T4222 Differential Revision: https://secure.phabricator.com/D7864
2014-01-01 03:02:41 +01:00
'CelerityPhabricatorResources' => 'CelerityResourcesOnDisk',
Move build-time resources to "CelerityPhysicalResources" to fix Phame Summary: Ref T4222. This fixes some issues with Phame's resource construction. Phame requires a fully virtual resource source, and since I want to run wordpress templates unmodified some day I don't want to build resource maps for skins. Move all the stuff that depends on resource lists being discoverable at build time to `CelerityPhysicalResources`, and only generate maps for subclasses. The root `CelerityResources` can now construct virtual resources; construct a virtual resource for Phame and use it. Test Plan: Off-domain blogs work correctly now. On-domain blogs with custom skins work correctly now. Reviewers: btrahan, hach-que Reviewed By: hach-que CC: aran Maniphest Tasks: T4222 Differential Revision: https://secure.phabricator.com/D7873
2014-01-01 04:21:56 +01:00
'CelerityPhysicalResources' => 'CelerityResources',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'CelerityPhysicalResourcesTestCase' => 'PhabricatorTestCase',
Modularize Celerity postprocessors Summary: Not sure if we want this, but it seems to work fine. Test Plan: {F516736} Reviewers: joshuaspence, chad Reviewed By: joshuaspence, chad Subscribers: joshuaspence, epriestley Differential Revision: https://secure.phabricator.com/D13363
2015-06-20 15:10:42 +02:00
'CelerityPostprocessor' => 'Phobject',
'CelerityPostprocessorTestCase' => 'PhabricatorTestCase',
Make CelerityController extend PhabricatorController Summary: Currently, CelerityController extends AphrontController, not PhabricatorController. (I think I imagined Celerity being somewhat stand-alone and didn't want to create a dependency.) This creates a concrete problem if a static resource is missing, since we throw an exception, but the higher-level exception handlers depend on the User existing in order to show an appropriate response page. This is the only controller which doesn't extend PhabricatorController, and it doesn't seem worthwhile to make a weird edge case out of it. Specific repro case is: - Remove `externals/javelin/` (or forget to run `git submodule update --init`). - Load a static resource. - Get "[Rendering Exception] Argument 1 passed to PhabricatorMainMenuView::setUser() must be an instance of PhabricatorUser, null given, called in /services/apache/phabricator/phabricator/src/view/page/PhabricatorStandardPageView.php on line 435 and defined" Test Plan: - Followed above steps, no more fataling. - Verified this is the only weird controller. Reviewers: voldern, vrana, btrahan Reviewed By: voldern CC: aran Differential Revision: https://secure.phabricator.com/D3389
2012-08-28 22:46:35 +02:00
'CelerityResourceController' => 'PhabricatorController',
Add cycle detection to celerity mapper Summary: create CelerityResourceGraph, which extends AbstractDirectedGraph. since we've done a bunch of work already to load the resource graph into memory CelerityResourceGraph simply stores a copy and makes loadEdges work off that stored copy. Test Plan: made phabricator-prefab require herald-rule-editor ~/code/phabricator> ./scripts/celerity_mapper.php webroot Finding static resources... Processing 154 files.......................................................................................................................................................... [2011-11-22 11:28:29] EXCEPTION: (Exception) Cycle detected in resource graph: phabricator-prefab => herald-rule-editor => phabricator-prefab at [/Users/btrahan/Dropbox/code/phabricator/scripts/celerity_mapper.php:173] fixed phabricator-prefab requiring herald-rule-editor. re-ran celerity_mapper and no errors! Reviewers: epriestley Reviewed By: epriestley CC: aran, btrahan, epriestley Differential Revision: 1132
2011-11-22 20:36:57 +01:00
'CelerityResourceGraph' => 'AbstractDirectedGraph',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'CelerityResourceMap' => 'Phobject',
'CelerityResourceMapGenerator' => 'Phobject',
'CelerityResourceTransformer' => 'Phobject',
Use Celerity to version all static resources Summary: We don't use versioned URIs for images, so when they change users may get old versions. This was a particular issue with the recent logo change, which several users reported cache-related issues from. Instead, use Celerity to manage image URI versions in addition to CSS/JS. This is complicated, because we need to rewrite image URIs inside of CSS, which means the hash of a CSS file has to be derived from the current image data. Otherwise, when we updated an image the CSS wouldn't update, so we wouldn't be any better off. So basically we: - Find all the "raw" files, and put them into the map. - Find all the CSS/JS, perform content-altering transformations on it (i.e., not minification) based on the partial map, and then put it into the map based on transformed hashes. (If we wanted, we could now do CSS variables or whatever for "free", more or less.) Test Plan: - Regenerated celerity map, browsed site, verified images generated with versioned URIs. - Moved "blue" flag image over "green" flag image, regenerated map, verified "green" flag image and the associated CSS changed hashes. - Added transformation unit tests; ran unit tests. Reviewers: btrahan, vrana, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1073 Differential Revision: https://secure.phabricator.com/D2146
2012-04-08 19:07:51 +02:00
'CelerityResourceTransformerTestCase' => 'PhabricatorTestCase',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'CelerityResources' => 'Phobject',
Move build-time resources to "CelerityPhysicalResources" to fix Phame Summary: Ref T4222. This fixes some issues with Phame's resource construction. Phame requires a fully virtual resource source, and since I want to run wordpress templates unmodified some day I don't want to build resource maps for skins. Move all the stuff that depends on resource lists being discoverable at build time to `CelerityPhysicalResources`, and only generate maps for subclasses. The root `CelerityResources` can now construct virtual resources; construct a virtual resource for Phame and use it. Test Plan: Off-domain blogs work correctly now. On-domain blogs with custom skins work correctly now. Reviewers: btrahan, hach-que Reviewed By: hach-que CC: aran Maniphest Tasks: T4222 Differential Revision: https://secure.phabricator.com/D7873
2014-01-01 04:21:56 +01:00
'CelerityResourcesOnDisk' => 'CelerityPhysicalResources',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'CeleritySpriteGenerator' => 'Phobject',
'CelerityStaticResourceResponse' => 'Phobject',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ChatLogConduitAPIMethod' => 'ConduitAPIMethod',
'ChatLogQueryConduitAPIMethod' => 'ChatLogConduitAPIMethod',
'ChatLogRecordConduitAPIMethod' => 'ChatLogConduitAPIMethod',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'ConduitAPIMethod' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'Phobject',
'PhabricatorPolicyInterface',
Modernize most Conduit console interfaces Summary: Ref T603. Ref T2625. Long chain of "doing the right thing" here: I want to clean this up, so I can clean up the Conduit logs, so I can add a setup issue for deprecated method calls, so I can remove deprecated methods, so I can get rid of `DifferentialRevisionListData`, so I can make Differntial policy-aware. Adds modern infrastructure and UI to all of the Conduit interfaces (except only partially for the logs, that will be the next diff). Test Plan: {F48201} {F48202} {F48203} {F48204} {F48206} This will get further updates in the next diff: {F48205} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6331
2013-07-01 21:36:34 +02:00
),
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'ConduitAPIMethodTestCase' => 'PhabricatorTestCase',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'ConduitAPIRequest' => 'Phobject',
'ConduitAPIResponse' => 'Phobject',
Don't log Conduit 404s as errors Summary: Fixes T5695. A Conduit "method does not exist" exception is somewhat expected... there is no need to `phlog` the exception. Test Plan: Called a non-existent Conduit method. Saw no exceptions in the error logs. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5695 Differential Revision: https://secure.phabricator.com/D10042
2014-07-25 03:24:31 +02:00
'ConduitApplicationNotInstalledException' => 'ConduitMethodNotFoundException',
Port "Allow Dangerous Changes" to new Manage UI Summary: Ref T10748. Brings this forward in the UI and EditEngine. Test Plan: - Edited via Conduit. - Viewed via Manage UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15805
2016-04-27 01:02:57 +02:00
'ConduitBoolParameterType' => 'ConduitParameterType',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'ConduitCall' => 'Phobject',
Allow applications to call Conduit directly Summary: Sorry this took so long, had a bunch of stuff going on today. Separate the actual core part of making conduit calls from the controller, so the application can make conduit calls without needing to invoke HTTP or redo auth. Generally, this lets us build more parts of the application on top of Conduit, as appropriate. This diff can be simplified, but I wanted to unblock you guys first. I'll followup with a cleanup patch once I have a chance. Test Plan: Ran unit tests, ran calls from the conduit API console, and ran calls over arc. Reviewers: nodren, 20after4, btrahan, vrana Reviewed By: 20after4 CC: aran, svemir Maniphest Tasks: T945 Differential Revision: https://secure.phabricator.com/D2718
2012-06-17 17:47:09 +02:00
'ConduitCallTestCase' => 'PhabricatorTestCase',
Expose column positions via maniphest.edit Summary: Ref T5214. Fixes T10486. Ref T6027. This exposes the `TYPE_COLUMNS` transaction in a usable way via API, and fixes the interactions via prefilling. Test Plan: - Created tasks directly into columns via API. - Moved tasks between columns via API. - Used `?column=...` to try to create a template task with valid and bogus column PHIDs. Reviewers: chad Reviewed By: chad Subscribers: AmyLewis Maniphest Tasks: T5214, T6027, T10486 Differential Revision: https://secure.phabricator.com/D15636
2016-04-06 13:37:01 +02:00
'ConduitColumnsParameterType' => 'ConduitParameterType',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ConduitConnectConduitAPIMethod' => 'ConduitAPIMethod',
Flesh out Conduit types for Paste search fields Summary: Ref T9964. This fills in types and descriptions for ApplicationSearch fields in Paste. Test Plan: Got this nice table now: {F1023999} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14765
2015-12-13 15:52:37 +01:00
'ConduitEpochParameterType' => 'ConduitListParameterType',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'ConduitException' => 'Exception',
Add conduit.getcapabilities and a modern CLI handshake workflow Summary: Ref T5955. - Add `conduit.getcapabilities` to help arc (and other clients) determine formats, protocols, etc., the server supports. - Fixes T3117. Add a more modern version of the handshake workflow that allows all generated tokens to remain valid for an hour. - Generally, add a CLI token type. This token type expires after an hour when generated, then becomes permanent if used. Test Plan: - See D10988. - Ran `conduit.getcapabilities` and inspected output. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3117, T5955 Differential Revision: https://secure.phabricator.com/D10989
2014-12-15 20:14:53 +01:00
'ConduitGetCapabilitiesConduitAPIMethod' => 'ConduitAPIMethod',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ConduitGetCertificateConduitAPIMethod' => 'ConduitAPIMethod',
Flesh out Conduit parmeter types for maniphest.search Summary: Ref T9964. I left a couple of these unsupported for now since they're weird in some way. Test Plan: {F1024031} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14767
2015-12-13 16:43:02 +01:00
'ConduitIntListParameterType' => 'ConduitListParameterType',
Support enabling a formal points field in Maniphest Summary: Ref T4427. - New config option for labels, enabling, etc., but no UI/niceness yet. - When enabled, add a field. - Allow nonnegative values, including fractional values. - EditEngine is nice and Conduit / actions basically just work with a tiny bit of extra support code. Test Plan: - Edited points via "Edit". - Edited points via Conduit. - Edited points via stacked actions. - Tried to set "zebra" points. - Tried to set -1 points. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4427 Differential Revision: https://secure.phabricator.com/D15220
2016-02-09 00:24:52 +01:00
'ConduitIntParameterType' => 'ConduitParameterType',
Add basic typechecking support to Conduit Summary: Ref T9964. I want to show users what we're expecting in "constraints", and let constraints like "authors=epriestley" work to make things easier. I'm generally very happy with the "HTTPParameterType" stuff from EditEngine, so add a parallel set of "ConduitParameterType" classes. These are a little simpler than the HTTP ones, but have a little more validation logic. Test Plan: This is really just a proof of concept; some of these fields are now filled in: {F1023845} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14763
2015-12-13 12:53:15 +01:00
'ConduitListParameterType' => 'ConduitParameterType',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'ConduitLogGarbageCollector' => 'PhabricatorGarbageCollector',
Fix string construction in Conduit exceptions Summary: Fixes T5838. - We currently try to use a `ConduitAPIMethod` object as a string. - We then pass that string to the parent's `__construct()` method as `$message`. Test Plan: Uninstalled Maniphest, then tried to execute `maniphest.createtask`. Got a useful exception message instead of an error during message construction. Reviewers: joshuaspence, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5838 Differential Revision: https://secure.phabricator.com/D10211
2014-08-11 21:08:06 +02:00
'ConduitMethodDoesNotExistException' => 'ConduitMethodNotFoundException',
Don't log Conduit 404s as errors Summary: Fixes T5695. A Conduit "method does not exist" exception is somewhat expected... there is no need to `phlog` the exception. Test Plan: Called a non-existent Conduit method. Saw no exceptions in the error logs. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5695 Differential Revision: https://secure.phabricator.com/D10042
2014-07-25 03:24:31 +02:00
'ConduitMethodNotFoundException' => 'ConduitException',
Flesh out Conduit types for Paste search fields Summary: Ref T9964. This fills in types and descriptions for ApplicationSearch fields in Paste. Test Plan: Got this nice table now: {F1023999} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14765
2015-12-13 15:52:37 +01:00
'ConduitPHIDListParameterType' => 'ConduitListParameterType',
Provide phame.post.edit Conduit API method Summary: Ref T9897. This one is a little more involved because of how getting a post on a blog works. I also changed moving posts to be a real transaction (which shows up in history, now). Test Plan: Created posts from web UI and conduit. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14902
2015-12-28 14:46:22 +01:00
'ConduitPHIDParameterType' => 'ConduitParameterType',
Add basic typechecking support to Conduit Summary: Ref T9964. I want to show users what we're expecting in "constraints", and let constraints like "authors=epriestley" work to make things easier. I'm generally very happy with the "HTTPParameterType" stuff from EditEngine, so add a parallel set of "ConduitParameterType" classes. These are a little simpler than the HTTP ones, but have a little more validation logic. Test Plan: This is really just a proof of concept; some of these fields are now filled in: {F1023845} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14763
2015-12-13 12:53:15 +01:00
'ConduitParameterType' => 'Phobject',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ConduitPingConduitAPIMethod' => 'ConduitAPIMethod',
Support enabling a formal points field in Maniphest Summary: Ref T4427. - New config option for labels, enabling, etc., but no UI/niceness yet. - When enabled, add a field. - Allow nonnegative values, including fractional values. - EditEngine is nice and Conduit / actions basically just work with a tiny bit of extra support code. Test Plan: - Edited points via "Edit". - Edited points via Conduit. - Edited points via stacked actions. - Tried to set "zebra" points. - Tried to set -1 points. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4427 Differential Revision: https://secure.phabricator.com/D15220
2016-02-09 00:24:52 +01:00
'ConduitPointsParameterType' => 'ConduitParameterType',
Flesh out Conduit types for Paste search fields Summary: Ref T9964. This fills in types and descriptions for ApplicationSearch fields in Paste. Test Plan: Got this nice table now: {F1023999} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14765
2015-12-13 15:52:37 +01:00
'ConduitProjectListParameterType' => 'ConduitListParameterType',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ConduitQueryConduitAPIMethod' => 'ConduitAPIMethod',
Implement a rough initial version of ApplicationSearch-driven Conduit read endpoints Summary: Ref T9964. See that task for some context and discussion. Ref T7715, which has the bigger picture here. Basically, I want Conduit read endpoints to be full-power, ApplicationSearch-driven endpoints, so that applications can: - Write one EditEngine and get web + conduit writes for free. - Write one SearchEngine and get web + conduit reads for free. I previously made some steps toward this, but this puts more of the structure in place. Test Plan: Viewed API console endpoint and read 20 pages of docs: {F1021961} Made various calls: with query keys, constraints, pagination, and limits. Viewed new {nav Config > Modules} page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7715, T9964 Differential Revision: https://secure.phabricator.com/D14743
2015-12-11 17:45:56 +01:00
'ConduitResultSearchEngineExtension' => 'PhabricatorSearchEngineExtension',
Implement SSHD glue and Conduit SSH endpoint Summary: - Build "sshd-auth" (for authentication) and "sshd-exec" (for command execution) binaries. These are callable by "sshd-vcs", located [[https://github.com/epriestley/sshd-vcs | in my account on GitHub]]. They are based on precursors [[https://github.com/epriestley/sshd-vcs-glue | here on GitHub]] which I deployed for TenXer about a year ago, so I have some confidence they at least basically work. - The problem this solves is that normally every user would need an account on a machine to connect to it, and/or their public keys would all need to be listed in `~/.authorized_keys`. This is a big pain in most installs. Software like Gitosis/Gitolite solve this problem by giving you an easy way to add public keys to `~/.authorized_keys`, but this is pretty gross. - Roughly, instead of looking in `~/.authorized_keys` when a user connects, the patched sshd instead runs `echo <public key> | sshd-auth`. The `sshd-auth` script looks up the public key and authorizes the matching user, if they exist. It also forces sshd to run `sshd-exec` instead of a normal shell. - `sshd-exec` receives the authenticated user and any command which was passed to ssh (like `git receive-pack`) and can route them appropriately. - Overall, this permits a single account to be set up on a server which all Phabricator users can connect to without any extra work, and which can safely execute commands and apply appropriate permissions, and disable users when they are disabled in Phabricator and all that stuff. - Build out "sshd-exec" to do more thorough checks and setup, and delegate command execution to Workflows (they now exist, and did not when I originally built this stuff). - Convert @btrahan's conduit API script into a workflow and slightly simplify it (ConduitCall did not exist at the time it was written). The next steps here on the Repository side are to implement Workflows for Git, SVN and HG wire protocols. These will mostly just proxy the protocols, but also need to enforce permissions. So the approach will basically be: - Implement workflows for stuff like `git receive-pack`. - These workflows will implement enough of the underlying protocol to determine what resource the user is trying to access, and whether they want to read or write it. - They'll then do a permissons check, and kick the user out if they don't have permission to do whatever they are trying to do. - If the user does have permission, we just proxy the rest of the transaction. Next steps on the Conduit side are more simple: - Make ConduitClient understand "ssh://" URLs. Test Plan: Ran `sshd-exec --phabricator-ssh-user epriestley conduit differential.query`, etc. This will get a more comprehensive test once I set up sshd-vcs. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T550 Differential Revision: https://secure.phabricator.com/D4229
2012-12-19 20:08:07 +01:00
'ConduitSSHWorkflow' => 'PhabricatorSSHWorkflow',
Add basic typechecking support to Conduit Summary: Ref T9964. I want to show users what we're expecting in "constraints", and let constraints like "authors=epriestley" work to make things easier. I'm generally very happy with the "HTTPParameterType" stuff from EditEngine, so add a parallel set of "ConduitParameterType" classes. These are a little simpler than the HTTP ones, but have a little more validation logic. Test Plan: This is really just a proof of concept; some of these fields are now filled in: {F1023845} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14763
2015-12-13 12:53:15 +01:00
'ConduitStringListParameterType' => 'ConduitListParameterType',
Add a phame.blog.edit Conduit API endpoint Summary: Ref T9897. Test Plan: Used API to make a few changes to a blog. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14899
2015-12-28 12:57:03 +01:00
'ConduitStringParameterType' => 'ConduitParameterType',
Add Conduit Tokens to make authentication in Conduit somewhat more sane Summary: Ref T5955. Summary of intended changes: **Improve Granularity of Authorization**: Currently, users have one Conduit Certificate. This isn't very flexible, and means that you can't ever generate an API token with limited permissions or IP block controls (see T6706). This moves toward a world where you can generate multiple tokens, revoke them individually, and assign disparate privileges to them. **Standardize Token Management**: This moves Conduit to work the same way that sessions, OAuth authorizations, and temporary tokens already work, instead of being this crazy bizarre mess. **Make Authentication Faster**: Authentication currently requires a handshake (conduit.connect) to establish a session, like the web UI. This is unnecessary from a security point of view and puts an extra round trip in front of all Conduit activity. Essentially no other API anywhere works like this. **Make Authentication Simpler**: The handshake is complex, and involves deriving hashes. The session is also complex, and creates issues like T4377. Handshake and session management require different inputs. **Make Token Management Simpler**: The certificate is this huge long thing right now, which is not necessary from a security perspective. There are separate Arcanist handshake tokens, but they have a different set of issues. We can move forward to a token management world where neither of these problems exist. **Lower Protocol Barrier**: The simplest possible API client is very complex right now. It should be `curl`. Simplifying authentication is a necessary step toward this. **Unblock T2783**: T2783 is blocked on nodes in the cluster making authenticated API calls to other nodes. This provides a simpler way forward than the handshake mess (or enormous-hack-mess) which would currently be required. Test Plan: - Generated tokens. - Generated tokens for a bot account. - Terminated tokens (and for a bot account). - Terminated all tokens (and for a bot account). - Ran GC and saw it reap all the expired tokens. NOTE: These tokens can not actually be used to authenticate yet! {F249658} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5955 Differential Revision: https://secure.phabricator.com/D10985
2014-12-15 20:14:23 +01:00
'ConduitTokenGarbageCollector' => 'PhabricatorGarbageCollector',
Add basic typechecking support to Conduit Summary: Ref T9964. I want to show users what we're expecting in "constraints", and let constraints like "authors=epriestley" work to make things easier. I'm generally very happy with the "HTTPParameterType" stuff from EditEngine, so add a parallel set of "ConduitParameterType" classes. These are a little simpler than the HTTP ones, but have a little more validation logic. Test Plan: This is really just a proof of concept; some of these fields are now filled in: {F1023845} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14763
2015-12-13 12:53:15 +01:00
'ConduitUserListParameterType' => 'ConduitListParameterType',
Improve behavior of "owner" transaction in "maniphest.edit" endpoint Summary: Fixes T10117. - I accidentally broke setting `null` to unassign tasks at some point when I added richer validation. - Raise a better error if the user passes junk. Test Plan: - Unassigned a task via API and web UI. - Reassigned a task via API and web UI. - Tried to do an invalid assign via API, got a sensible error. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10117 Differential Revision: https://secure.phabricator.com/D14992
2016-01-11 12:24:03 +01:00
'ConduitUserParameterType' => 'ConduitParameterType',
Improve Conduit type handling for `*.edit` endpoints Summary: Ref T9964. Three goals here: - Make it easier to supply Conduit documentation. - Make automatic documentation for `*.edit` endpoints more complete, particularly for custom fields. - Allow type resolution via Conduit types, so you can pass `["alincoln"]` to "subscribers" instead of needing to use PHIDs. Test Plan: - Viewed and used all search and edit endpoints, including custom fields. - Used parameter type resolution to set subscribers to user "dog" instead of "PHID-USER-whatever". - Viewed HTTP parameter documentation. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14796
2015-12-16 14:09:21 +01:00
'ConduitWildParameterType' => 'ConduitListParameterType',
Conpherence - make the durable column kind of work and stuff Summary: Ref T7014. This hooks up the durable column such that when you open it up it loads your most recent Conpherence. You can then switch amongst the various widgets and stuff and everything works nicely. Except... - scroll bar does not work - also doesn't work at HEAD when I add a ton of text to the UI with no changes? (wrapped $copy in array_fill(0, 1000, $copy)) - "widget selector" does not collapse when you select something else - this part wasn't really specified so I used the aphlict dropdown stuff. didn't want to keep working on that if this was the wrong UI choice - can not edit title - do we still want that to be done by clicking on the title, which pops a dialogue? - can not add participants or calendar events - what should this UI be? maybe just a button on the top for "participants" and a button on the bottom for calendar? both on top? - this is not pixel perfect to the mock or two I've seen around. Aside from generally being bad at that, I definitely didn't get the name + timestamps formatting correctly, because the standard DOM of that has timestamp FIRST which appears second due to a "float right". Seemed like a lot of special-casing for what might not even be that important in the UI so I punted. (And again, there's likely many unknown ways in which this isn't pixel perfect) There's also code quality issues - `ConpherenceWidgetConfigConstants` is hopefully temporary or at least gets more sleek as we keep progressing here - copied some CSS from main Conpherence app - DOM structure is pretty different - there's some minor CSS tweaks too given the different width (not to mention the DOM structure being different) - copied some JS from behavior-pontificate.js to sync threads relative to aphlict updates - JS in general is like a better version of existing JS; these should collapse I'd hope? - maybe the aphlict-behavior-dropdown change was badsauce? ...but all that said, this definitely feels really nice and I feel like adding stuff is going to be really easy compared to how normal Conpherence is. Also includes a bonus bug fix - we now correctly update participation. The user would encounter this issue if they were in a conpherence that got some updates and then they went to a different page; they would have unread status for the messages that were ajax'd in. This patch fixes that by making sure we mark participation up to date with the proper transaction in all cases. Test Plan: hit "\" to invoke the column and saw nice loading UI and my latest conpherence load. sent messages and verified they received A-OK by looking in DOM console. toggled various widges and verified they rendered correctly. opened up a second browser with a second user on the thread, sent a message, and it was received in a nice asynchronous fashion Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7014 Differential Revision: https://secure.phabricator.com/D11968
2015-03-05 19:33:39 +01:00
'ConpherenceColumnViewController' => 'ConpherenceController',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ConpherenceConduitAPIMethod' => 'ConduitAPIMethod',
Conpherence - reply handler integration Summary: Added a reply handler. A few problems -- first, I can't seem to get this to actually send me email so I haven't been able to reply (which I would have done by generating a reply, then copying the raw email into scripts/mail_handler.php). Second, the subject is often terrible on these emails -- unless the conpherence is named its something gross like "E4:" Third, on create I am noticing an error on array_combine() which I think is related to the need to write array_combine_not_broken or what have you I saw go by... (PhabricatorTransactionEditor does array_combine(xaction->getOldValue(), xaction->getOldValue()) and complains that the arrays are empty) Test Plan: noted that /mail/ said mails were being sent Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2399 Differential Revision: https://secure.phabricator.com/D4656
2013-01-26 01:03:54 +01:00
'ConpherenceConfigOptions' => 'PhabricatorApplicationConfigOptions',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'ConpherenceConstants' => 'Phobject',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceController' => 'PhabricatorController',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ConpherenceCreateThreadConduitAPIMethod' => 'ConpherenceConduitAPIMethod',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceDAO' => 'PhabricatorLiskDAO',
Shrink side-nav on home when durable column is open Summary: This still needs some fine tuning, but wanted to get opinions. Using it on a laptop feels pretty good. This also moves `durable-column.css` into its own file since it'll likely continue to grow. Minor CSS tweaks to the near perfect rendition of durable column from pixel based mockups. Test Plan: Press \ on my laptop. Having issues with Chrome however, but FF and Safari work as expected. {F322506} Reviewers: epriestley, btrahan Reviewed By: btrahan Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11901
2015-02-27 20:38:33 +01:00
'ConpherenceDurableColumnView' => 'AphrontTagView',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceEditor' => 'PhabricatorApplicationTransactionEditor',
Conpherence - add back in custom images Summary: Fixes T7254. This reverts the previous functionality, but makes pertinent updates like scaling the images to 35 x 35. Codebase had moved on quite a bit so far from a straight revert but nothing too tricky relative to the code that was here before. This does not allow for changing the images from the conpherence durable column view -- that would require some JS trickery, but also doesn't fit into the current notion of the column being "light". Can always modify this later. Test Plan: - from full conpherence, uploaded a square pic and things looked nice - from full conpherence, uploaded a rectangular pic and wasnt happy, so reinvoked edit dialog and used crop control to make it better - noted could not update picture from conpherence durable column - used different user and noted could see custom picture Reviewers: epriestley Reviewed By: epriestley Subscribers: CodeMouse92, Korvin, epriestley Maniphest Tasks: T7254 Differential Revision: https://secure.phabricator.com/D12648
2015-05-04 22:52:22 +02:00
'ConpherenceFormDragAndDropUploadControl' => 'AphrontFormControl',
Build a Conpherence thread index Summary: Ref T3165. Builds a dedicated index for Conpherence to avoid scale/policy filtering concerns. - This is pretty one-off but I think it's generally OK. - There's no UI for it. - `ConpherenceFulltextQuery` is very low-level. You would need to do another query on the PHIDs it returns to actually show anything to the user. - The `previousTransactionPHID` is so you can load chat context efficiently. Specifically, if you want to show results like this: > previous line of context > **line of chat that matches the query** > next line of context ...you can read the previous lines out of `previousTransactionPHID` directly, and the next lines by issuing one query with `WHERE previousTransactionPHID IN (...)`. I'm not 100% sure this is useful, but it seemed like a reasonable thing to provide, since there's no way to query this efficiently otherwise and I figure a lot of chat might make way more sense with a couple of lines of context. Test Plan: - Indexed a thread manually (whole thing indexed). - Indexed a thread by updating it (just the new comment indexed). - Wrote a hacky test script and got reasonable-looking query results. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3165 Differential Revision: https://secure.phabricator.com/D11234
2015-01-06 19:24:30 +01:00
'ConpherenceFulltextQuery' => 'PhabricatorOffsetPagedQuery',
Conpherence - add back in custom images Summary: Fixes T7254. This reverts the previous functionality, but makes pertinent updates like scaling the images to 35 x 35. Codebase had moved on quite a bit so far from a straight revert but nothing too tricky relative to the code that was here before. This does not allow for changing the images from the conpherence durable column view -- that would require some JS trickery, but also doesn't fit into the current notion of the column being "light". Can always modify this later. Test Plan: - from full conpherence, uploaded a square pic and things looked nice - from full conpherence, uploaded a rectangular pic and wasnt happy, so reinvoked edit dialog and used crop control to make it better - noted could not update picture from conpherence durable column - used different user and noted could see custom picture Reviewers: epriestley Reviewed By: epriestley Subscribers: CodeMouse92, Korvin, epriestley Maniphest Tasks: T7254 Differential Revision: https://secure.phabricator.com/D12648
2015-05-04 22:52:22 +02:00
'ConpherenceImageData' => 'ConpherenceConstants',
Build a Conpherence thread index Summary: Ref T3165. Builds a dedicated index for Conpherence to avoid scale/policy filtering concerns. - This is pretty one-off but I think it's generally OK. - There's no UI for it. - `ConpherenceFulltextQuery` is very low-level. You would need to do another query on the PHIDs it returns to actually show anything to the user. - The `previousTransactionPHID` is so you can load chat context efficiently. Specifically, if you want to show results like this: > previous line of context > **line of chat that matches the query** > next line of context ...you can read the previous lines out of `previousTransactionPHID` directly, and the next lines by issuing one query with `WHERE previousTransactionPHID IN (...)`. I'm not 100% sure this is useful, but it seemed like a reasonable thing to provide, since there's no way to query this efficiently otherwise and I figure a lot of chat might make way more sense with a couple of lines of context. Test Plan: - Indexed a thread manually (whole thing indexed). - Indexed a thread by updating it (just the new comment indexed). - Wrote a hacky test script and got reasonable-looking query results. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3165 Differential Revision: https://secure.phabricator.com/D11234
2015-01-06 19:24:30 +01:00
'ConpherenceIndex' => 'ConpherenceDAO',
Consolidate Conpherence frame rendering Summary: Conpherence frame rendering is spread out a bit across ConpherenceController, ConpherenceListController, and previously ConpherenceNewController. I want to let the Thread and Widget controllers render the frame for mobile. Ref T2421. Test Plan: Viewed conpherences, switched between conpherences. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2421 Differential Revision: https://secure.phabricator.com/D5501
2013-04-01 21:43:07 +02:00
'ConpherenceLayoutView' => 'AphrontView',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceListController' => 'ConpherenceController',
'ConpherenceMenuItemView' => 'AphrontTagView',
Conpherence - add "room" search UI and create UI Summary: Ref T7584. This hits all the major bullets there. Next step on T7584 is figuring out how it integrates into the full UI and column UI. That said, this is a bit buggy feeling right now since Conpherence as is assumes you are a participant all over the place and rooms make no such assumption. I'll probably this bit up next. Test Plan: viewed /conpherence/room/ and saw stuff. viewed the "participant" query as two different users and saw different correct result sets. made a room via the button and it worked. tried to view a room I wasn't a participant in and it failed horribly, which is something to fix in a future diff created a thread via "send message" on a user profile and it worked Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7584 Differential Revision: https://secure.phabricator.com/D12113
2015-03-24 21:04:33 +01:00
'ConpherenceNewRoomController' => 'ConpherenceController',
Conpherence - add dropdown menu Summary: Fixes T3641. Probably needs some @chad love though on colors and what have you. Technique was to jam this into the existing notifications stuff as much as possible. I think its "okay" but if we were to add more stuff here (like a 3rd application) this could get a quality pass to consolidate even more code. Test Plan: played with it in Chrome and Safari - looks reasonable Reviewers: chad, epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3641 Differential Revision: https://secure.phabricator.com/D6708
2013-08-08 22:43:33 +02:00
'ConpherenceNotificationPanelController' => 'ConpherenceController',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceParticipant' => 'ConpherenceDAO',
Conpherence - paginate thread list Summary: this is D5750 but just the conpherence part. fixes a few random conpherence bugs / quirks as well. Also messes with ApplicationTransactionEditor to expose the xactions so Conpherence doesn't over-update participation rows. Fixes T2429. Test Plan: set LIMIT to 3. verified I could scroll down all conpherences. next, picked a conpherence "in the middle" to load. verified I could page up and down. next, picked a conpherence in the middle then had another user update that conpherence. verified as I paged up the conpherence re-loaded properly selected Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin, vrana Maniphest Tasks: T2429 Differential Revision: https://secure.phabricator.com/D5783
2013-04-26 19:30:41 +02:00
'ConpherenceParticipantCountQuery' => 'PhabricatorOffsetPagedQuery',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceParticipantQuery' => 'PhabricatorOffsetPagedQuery',
'ConpherenceParticipationStatus' => 'ConpherenceConstants',
Conpherence - people widget Summary: adds ye olde people widget. Features include - handle-based display, so we get status for free. (Note less pretty than M14 would have it!) - can add a person - can remove a person - can see the people already in the conpherence Test Plan: added and removed people and noted they joined / re-added as appropriate. Tried to add someone already in the conpherence and got a "transaction has no effect" message Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2399 Differential Revision: https://secure.phabricator.com/D5466
2013-04-02 18:32:40 +02:00
'ConpherencePeopleWidgetView' => 'ConpherenceWidgetView',
Conpherence - add back in custom images Summary: Fixes T7254. This reverts the previous functionality, but makes pertinent updates like scaling the images to 35 x 35. Codebase had moved on quite a bit so far from a straight revert but nothing too tricky relative to the code that was here before. This does not allow for changing the images from the conpherence durable column view -- that would require some JS trickery, but also doesn't fit into the current notion of the column being "light". Can always modify this later. Test Plan: - from full conpherence, uploaded a square pic and things looked nice - from full conpherence, uploaded a rectangular pic and wasnt happy, so reinvoked edit dialog and used crop control to make it better - noted could not update picture from conpherence durable column - used different user and noted could see custom picture Reviewers: epriestley Reviewed By: epriestley Subscribers: CodeMouse92, Korvin, epriestley Maniphest Tasks: T7254 Differential Revision: https://secure.phabricator.com/D12648
2015-05-04 22:52:22 +02:00
'ConpherencePicCropControl' => 'AphrontFormControl',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ConpherenceQueryThreadConduitAPIMethod' => 'ConpherenceConduitAPIMethod',
'ConpherenceQueryTransactionConduitAPIMethod' => 'ConpherenceConduitAPIMethod',
Conpherence - reply handler integration Summary: Added a reply handler. A few problems -- first, I can't seem to get this to actually send me email so I haven't been able to reply (which I would have done by generating a reply, then copying the raw email into scripts/mail_handler.php). Second, the subject is often terrible on these emails -- unless the conpherence is named its something gross like "E4:" Third, on create I am noticing an error on array_combine() which I think is related to the need to write array_combine_not_broken or what have you I saw go by... (PhabricatorTransactionEditor does array_combine(xaction->getOldValue(), xaction->getOldValue()) and complains that the arrays are empty) Test Plan: noted that /mail/ said mails were being sent Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2399 Differential Revision: https://secure.phabricator.com/D4656
2013-01-26 01:03:54 +01:00
'ConpherenceReplyHandler' => 'PhabricatorMailReplyHandler',
Conpherence - add "room" search UI and create UI Summary: Ref T7584. This hits all the major bullets there. Next step on T7584 is figuring out how it integrates into the full UI and column UI. That said, this is a bit buggy feeling right now since Conpherence as is assumes you are a participant all over the place and rooms make no such assumption. I'll probably this bit up next. Test Plan: viewed /conpherence/room/ and saw stuff. viewed the "participant" query as two different users and saw different correct result sets. made a room via the button and it worked. tried to view a room I wasn't a participant in and it failed horribly, which is something to fix in a future diff created a thread via "send message" on a user profile and it worked Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7584 Differential Revision: https://secure.phabricator.com/D12113
2015-03-24 21:04:33 +01:00
'ConpherenceRoomListController' => 'ConpherenceController',
Conpherence - Differentiate audience of Threads/Rooms with icon Summary: Fixes T7629 plus an un filed bug that's breaking creating new threads since we need to add participants EVEN EARLIER than we were doing it now that policy is actually enforced. Back to the main thrust of this, there is one UI corner case - in the main view if you go from 1:1 to 1:1:1 (i.e. add a 3rd recipient, or Nth in a row) the icon only updates on page reload. I figure this will get sorted out at a later refactor as we make the client better / share more code with durable column. One other small behavioral oddity is in the main view sometime we start loading with no conpherence. in that case, rather than show some incorrect icon, we show no icon (and "no title") and then things change at load. Seems okay-ish. Finally, @chad - the CSS is a very work-man-like "use the built in stuff you can specify from PHP" so I'm sure it needs some love. Test Plan: made all sorts of rooms and threads and liked the icons. noted smooth loading action as i switched around Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: Korvin, chad, epriestley Maniphest Tasks: T7629 Differential Revision: https://secure.phabricator.com/D12163
2015-03-26 20:24:29 +01:00
'ConpherenceRoomTestCase' => 'ConpherenceTestCase',
Generate expected schemata for Dashboards and Conpherence Summary: Ref T1191. - Add edge schemata generation. - Hit a couple of mostly-minor issues (T6128, T6129, T6130). Test Plan: Viewed schema in web UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10518
2014-09-18 20:15:38 +02:00
'ConpherenceSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Conpherence - add per thread notification setting Summary: Introduces a new settings panel for Conpherence specific settings. Test Plan: started a thread with a test user, thus two participants total. Replied to conpherence, toggling notification settings in between. Verified 1 or 2 emails were sent as appropos to the current toggle. Toggled global setting and verified setting was updated in conpherences where nothing was specified. Verified setting conpherence setting overrides global setting. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2521 Differential Revision: https://secure.phabricator.com/D5391
2013-03-26 21:30:35 +01:00
'ConpherenceSettings' => 'ConpherenceConstants',
Conpherence - Differentiate audience of Threads/Rooms with icon Summary: Fixes T7629 plus an un filed bug that's breaking creating new threads since we need to add participants EVEN EARLIER than we were doing it now that policy is actually enforced. Back to the main thrust of this, there is one UI corner case - in the main view if you go from 1:1 to 1:1:1 (i.e. add a 3rd recipient, or Nth in a row) the icon only updates on page reload. I figure this will get sorted out at a later refactor as we make the client better / share more code with durable column. One other small behavioral oddity is in the main view sometime we start loading with no conpherence. in that case, rather than show some incorrect icon, we show no icon (and "no title") and then things change at load. Seems okay-ish. Finally, @chad - the CSS is a very work-man-like "use the built in stuff you can specify from PHP" so I'm sure it needs some love. Test Plan: made all sorts of rooms and threads and liked the icons. noted smooth loading action as i switched around Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: Korvin, chad, epriestley Maniphest Tasks: T7629 Differential Revision: https://secure.phabricator.com/D12163
2015-03-26 20:24:29 +01:00
'ConpherenceTestCase' => 'PhabricatorTestCase',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'ConpherenceThread' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'ConpherenceDAO',
'PhabricatorPolicyInterface',
Expose all application mail receivers Summary: Fixes T7199. This still isn't a shining example of perfect code, but the raw amount of copy/paste is much lower than it used to be. - Reduce code duplication between existing receivers. - Expose receiving objects in help menus where appropriate. - Connect some "TODO" receivers. Test Plan: - Sent mail to every supported object type. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12249
2015-04-01 20:01:21 +02:00
'PhabricatorApplicationTransactionInterface',
Conpherence - refactor display classes a bit Summary: D12409 made me realize this was a bit janky. `PhabricatorTransactionView` was only being used by Conpherence, so move and rename that class to `ConpherenceTransactionView`. Also, rename the existing `ConpherenceTransactionView` to `ConpherenceTransactionRenderer`, moving the actual view bits into the new `ConpherenceTransactionView`. Resulting code is a bit cleaner IMO. Diff 1 of 2 (second diff has to be written. =D). Diff 2 will take care of the CSS and possibly clean things up further. Test Plan: played around in conpherence full and conpherence column and things looked nice Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D12410
2015-04-14 21:25:35 +02:00
'PhabricatorMentionableInterface',
Conpherence - implement PhabricatorDestructibleInterface so threads can be deleted Summary: Fixes T7694. I had to complicate the `ConpherenceThreadQuery` code slightly so that if we specify id(s) or phid(s) then we don't bother with all that join stuff we need to make sure we have a reasonable query in production. Test Plan: `bin/remove destroy ZXX` worked! tried to visit `ZXX` and got a nice 404. Clicked around and couldn't find anything broken because of the deletion Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7756, T7694 Differential Revision: https://secure.phabricator.com/D12304
2015-04-08 21:19:40 +02:00
'PhabricatorDestructibleInterface',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
),
Lift Conpherence indexing up out of the Fulltext index Summary: Ref T9979. There are currently some hacks around Conpherence indexing: it does not really use the fulltext index, but its own specialized index. However, it's kind of hacked up so it can get reindexed by the normal indexing pipeline. Lift it up into IndexEngine, instead of FulltextEngine. Specifically, the new stuff is going to look like this: - IndexEngine: Rebuild all indexes. - ConpherenceIndexExtension: Rebuild thread indexes. - ProjectMemberIndexExtension: Rebuild project membership views. - NgramIndexExtension: Rebuild ngram indexes. - FulltextIndexExtension / FulltextEngine: Rebuild fulltext indexes, a special type of index. - FulltextCommentExtension: Rebuild comment fulltext indexes. - FulltextProjectExtension: Rebuild project fulltext indexes. - etc. Most of this is at least sort-of-in-place as of this diff, although some of the part in the middle is still pretty rough. Test Plan: - Made a unique comment in a Conpherence thread. - Used `bin/search index --force` to rebuild the index. - Searched for the comment. - Found the thread. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14841
2015-12-21 15:07:41 +01:00
'ConpherenceThreadIndexEngineExtension' => 'PhabricatorIndexEngineExtension',
Render Conpherence threads as a separate menu inside the layout, not a side nav Summary: Currently, the thread list is in a standard side nav, but that makes it awkward to render (rendering logic needs to live in the base controller) and gives it some bad beahviors (like autohiding on mobile). Instead, move it into its own view and make it a little more custom. Ref T2421. Test Plan: {F38098} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T2421 Differential Revision: https://secure.phabricator.com/D5504
2013-04-01 21:50:39 +02:00
'ConpherenceThreadListView' => 'AphrontView',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ConpherenceThreadMailReceiver' => 'PhabricatorObjectMailReceiver',
Add a "Thread Members" object policy and some unit tests Summary: Ref T8488. Ref T5681. Now you can just use `id(new ConpherenceThreadMembersPolicyRule())->getObjectPolicyFullKey()` as a policy. Added tests for TaskAuthor + ThreadMembers. Test Plan: - Ran tests. - Set a thread policy to "Members of thread'. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5681, T8488 Differential Revision: https://secure.phabricator.com/D13258
2015-06-14 00:44:56 +02:00
'ConpherenceThreadMembersPolicyRule' => 'PhabricatorPolicyRule',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceThreadQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Conpherence - make `ZXXX` monograms a bit more useful. Summary: Ref T7756. Now viewing individual threads in Conpherence is `ZXXX` driven. Also adds remarkup support. Test Plan: clicked around on list of conpherences in full view and it worked. selected 'view in conpherence' action from column and loaded correct `ZXXX` uri. Typed `ZXXX` in Maniphest and saw it link to Conpherence room. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7756 Differential Revision: https://secure.phabricator.com/D12397
2015-04-13 21:45:55 +02:00
'ConpherenceThreadRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Conpherence - add "room" search UI and create UI Summary: Ref T7584. This hits all the major bullets there. Next step on T7584 is figuring out how it integrates into the full UI and column UI. That said, this is a bit buggy feeling right now since Conpherence as is assumes you are a participant all over the place and rooms make no such assumption. I'll probably this bit up next. Test Plan: viewed /conpherence/room/ and saw stuff. viewed the "participant" query as two different users and saw different correct result sets. made a room via the button and it worked. tried to view a room I wasn't a participant in and it failed horribly, which is something to fix in a future diff created a thread via "send message" on a user profile and it worked Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7584 Differential Revision: https://secure.phabricator.com/D12113
2015-03-24 21:04:33 +01:00
'ConpherenceThreadSearchEngine' => 'PhabricatorApplicationSearchEngine',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceTransaction' => 'PhabricatorApplicationTransaction',
'ConpherenceTransactionComment' => 'PhabricatorApplicationTransactionComment',
'ConpherenceTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'ConpherenceTransactionRenderer' => 'Phobject',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceTransactionView' => 'AphrontView',
Conpherence - continue the load less quest Summary: basically makes it so we only really load what we need from the server for any particular update action. the javascript thus then has some things deleted from it. made a spot or two ready for when the pertinent UI won't be there as well. also added a feature in javascript -- updating the document title to the current conpherence title. Ref T2867 T2399 Test Plan: played with conpherence for quite a bit. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2867 Differential Revision: https://secure.phabricator.com/D5625
2013-04-10 20:37:04 +02:00
'ConpherenceUpdateActions' => 'ConpherenceConstants',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceUpdateController' => 'ConpherenceController',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ConpherenceUpdateThreadConduitAPIMethod' => 'ConpherenceConduitAPIMethod',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceViewController' => 'ConpherenceController',
Conpherence - make the durable column kind of work and stuff Summary: Ref T7014. This hooks up the durable column such that when you open it up it loads your most recent Conpherence. You can then switch amongst the various widgets and stuff and everything works nicely. Except... - scroll bar does not work - also doesn't work at HEAD when I add a ton of text to the UI with no changes? (wrapped $copy in array_fill(0, 1000, $copy)) - "widget selector" does not collapse when you select something else - this part wasn't really specified so I used the aphlict dropdown stuff. didn't want to keep working on that if this was the wrong UI choice - can not edit title - do we still want that to be done by clicking on the title, which pops a dialogue? - can not add participants or calendar events - what should this UI be? maybe just a button on the top for "participants" and a button on the bottom for calendar? both on top? - this is not pixel perfect to the mock or two I've seen around. Aside from generally being bad at that, I definitely didn't get the name + timestamps formatting correctly, because the standard DOM of that has timestamp FIRST which appears second due to a "float right". Seemed like a lot of special-casing for what might not even be that important in the UI so I punted. (And again, there's likely many unknown ways in which this isn't pixel perfect) There's also code quality issues - `ConpherenceWidgetConfigConstants` is hopefully temporary or at least gets more sleek as we keep progressing here - copied some CSS from main Conpherence app - DOM structure is pretty different - there's some minor CSS tweaks too given the different width (not to mention the DOM structure being different) - copied some JS from behavior-pontificate.js to sync threads relative to aphlict updates - JS in general is like a better version of existing JS; these should collapse I'd hope? - maybe the aphlict-behavior-dropdown change was badsauce? ...but all that said, this definitely feels really nice and I feel like adding stuff is going to be really easy compared to how normal Conpherence is. Also includes a bonus bug fix - we now correctly update participation. The user would encounter this issue if they were in a conpherence that got some updates and then they went to a different page; they would have unread status for the messages that were ajax'd in. This patch fixes that by making sure we mark participation up to date with the proper transaction in all cases. Test Plan: hit "\" to invoke the column and saw nice loading UI and my latest conpherence load. sent messages and verified they received A-OK by looking in DOM console. toggled various widges and verified they rendered correctly. opened up a second browser with a second user on the thread, sent a message, and it was received in a nice asynchronous fashion Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7014 Differential Revision: https://secure.phabricator.com/D11968
2015-03-05 19:33:39 +01:00
'ConpherenceWidgetConfigConstants' => 'ConpherenceConstants',
Renders the last 100 conpherence transactions only Summary: Fixed T2428 a little bit Test Plan: On trial, only the last n transactions loaded as hardcoded in ConpherenceViewController.php. Button was rendered. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2428 Differential Revision: https://secure.phabricator.com/D4898
2013-02-15 23:01:27 +01:00
'ConpherenceWidgetController' => 'ConpherenceController',
Conpherence - people widget Summary: adds ye olde people widget. Features include - handle-based display, so we get status for free. (Note less pretty than M14 would have it!) - can add a person - can remove a person - can see the people already in the conpherence Test Plan: added and removed people and noted they joined / re-added as appropriate. Tried to add someone already in the conpherence and got a "transaction has no effect" message Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2399 Differential Revision: https://secure.phabricator.com/D5466
2013-04-02 18:32:40 +02:00
'ConpherenceWidgetView' => 'AphrontView',
Flesh out some DarkConsole stuff.
2011-02-03 07:38:42 +01:00
'DarkConsoleController' => 'PhabricatorController',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DarkConsoleCore' => 'Phobject',
DarkConsole: fix rendering, move request log, load over ajax Summary: This accomplishes three major goals: # Fixes phutil_render_tag -> phutil_tag callsites in DarkConsole. # Moves the Ajax request log to a new panel on the left. This panel (and the tabs panel) get scrollbars when they get large, instead of making the page constantly scroll down. # Loads the panel content over ajax, instead of dumping it into the page body / ajax response body. I've been planning to do this for about 3 years, which is why the plugins are architected the way they are. This should make debugging easier by making response bodies not be 50%+ darkconsole stuff. Additionally, load the plugins dynamically (the old method predates library maps and PhutilSymbolLoader). Test Plan: {F30675} - Switched between requests and tabs, reloaded page, saw same tab. - Used "analyze queries", "profile page", triggered errors. - Verified page does not load anything by default if dark console is closed with Charles. - Generally banged on it a bit. Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2432 Differential Revision: https://secure.phabricator.com/D4692
2013-01-29 03:45:32 +01:00
'DarkConsoleDataController' => 'PhabricatorController',
Very rough cut of DarkConsole + XHProf
2011-02-02 22:48:52 +01:00
'DarkConsoleErrorLogPlugin' => 'DarkConsolePlugin',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DarkConsoleErrorLogPluginAPI' => 'Phobject',
Add an "Event" plugin to DarkConsole for event inspection Summary: Shows events which a page dispatched, plus all the registered listeners. Test Plan: Pretty basic for now, but works OK: https://secure.phabricator.com/file/view/PHID-FILE-49fcd23081ce55cf9369/ (I also made it dispatch some dummy events to verify they show up.) Reviewers: aran Reviewed By: aran CC: aran Differential Revision: 973
2011-09-30 21:54:17 +02:00
'DarkConsoleEventPlugin' => 'DarkConsolePlugin',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'DarkConsoleEventPluginAPI' => 'PhabricatorEventListener',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DarkConsolePlugin' => 'Phobject',
Very rough cut of DarkConsole + XHProf
2011-02-02 22:48:52 +01:00
'DarkConsoleRequestPlugin' => 'DarkConsolePlugin',
'DarkConsoleServicesPlugin' => 'DarkConsolePlugin',
Add a "Startup" to DarkConsole Summary: Ref T8588. It looks like something slow is happening //before// we start DarkConsole. Add some crude reporting to try to narrow it down. Test Plan: {F743050} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8588 Differential Revision: https://secure.phabricator.com/D13956
2015-08-21 23:53:29 +02:00
'DarkConsoleStartupPlugin' => 'DarkConsolePlugin',
Very rough cut of DarkConsole + XHProf
2011-02-02 22:48:52 +01:00
'DarkConsoleXHProfPlugin' => 'DarkConsolePlugin',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DarkConsoleXHProfPluginAPI' => 'Phobject',
'DefaultDatabaseConfigurationProvider' => array(
'Phobject',
'DatabaseConfigurationProvider',
),
'DifferentialAction' => 'Phobject',
Move Differential to modular mail commands Summary: Ref T7199. Convert Differential to modern modular commands. Test Plan: Used `bin/mail receive-test` to send command and comment mail to Differential. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12239
2015-04-01 17:40:12 +02:00
'DifferentialActionEmailCommand' => 'MetaMTAEmailTransactionCommand',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'DifferentialActionMenuEventListener' => 'PhabricatorEventListener',
AddCommentView
2011-01-30 20:02:22 +01:00
'DifferentialAddCommentView' => 'AphrontView',
Replace ArcanistPhutilTestCase refs with PhutilTestCase Summary: Ref T7977. Remove the `PhabricatorTestCase::getLink` method. Depends on D12665. Test Plan: `arc unit`. Reviewers: avivey, #blessed_reviewers, epriestley Reviewed By: avivey, #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7977 Differential Revision: https://secure.phabricator.com/D12667
2015-05-20 01:37:39 +02:00
'DifferentialAdjustmentMapTestCase' => 'PhutilTestCase',
Build an "affected path" index when attaching diffs to revisions Summary: See T262. This creates the index on the Differential side which we need in order to execute this query efficiently on the Diffusion side. Also renames "DiffusionGitPathIDQuery" to "DiffusionPathIDQuery", this query object has nothing to do with git. Test Plan: Attached top-level and sub-level diffs to revisions and verified they populated the table with sensible data. Reviewers: bmaurer, aravindn, fmoo, jungejason, nh, tuomaspelkonen, aran CC: Differential Revision: 931
2011-09-14 19:59:52 +02:00
'DifferentialAffectedPath' => 'DifferentialDAO',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialApplyPatchField' => 'DifferentialCustomField',
'DifferentialAsanaRepresentationField' => 'DifferentialCustomField',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialAuditorsField' => 'DifferentialStoredCustomField',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialAuthorField' => 'DifferentialCustomField',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialBlameRevisionField' => 'DifferentialStoredCustomField',
Modularize the Diffusion/Differential "Block" Herald actions Also removes HeraldCustomAction. This completes action modularization. Ref T8726.
2015-08-03 21:54:40 +02:00
'DifferentialBlockHeraldAction' => 'HeraldAction',
Add Branch and Arcanist Project CustomFields Summary: Ref T2222. These are pretty straightforward. For these fields and a few others, the existing code shows the value for the "current/manual" diff (i.e., the diff selected in the diff selection table), not the "active" diff (i.e., the most recent diff attached to the revision). I'm going to drop that for now (always showing the most recent diff instead) and then reevaluate it once we're switched over. In 95% of cases these are the same, anyway. Test Plan: Looked at fields; this diff changes nothing on its own. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8359
2014-02-27 20:05:48 +01:00
'DifferentialBranchField' => 'DifferentialCustomField',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'DifferentialChangeHeraldFieldGroup' => 'HeraldFieldGroup',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DifferentialChangeType' => 'Phobject',
Restore "Branch" and "changes since last update" fields to Differential mail Summary: Ref T418. Fixes T4642. The "changes since last update" and "branch" fields got dropped; restore them in a general, field-driven way. Test Plan: - Created a revision, got relevant sections in mail. - Commented on a revision, got relevant sections in mail. - Updated a revision, got relevant sections in mail. Reviewers: btrahan Reviewed By: btrahan Subscribers: spicyj, epriestley Maniphest Tasks: T418, T4642 Differential Revision: https://secure.phabricator.com/D8657
2014-04-01 17:23:34 +02:00
'DifferentialChangesSinceLastUpdateField' => 'DifferentialCustomField',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'DifferentialChangeset' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'DifferentialDAO',
'PhabricatorPolicyInterface',
Move more hunk loads into DifferentialHunkQuery Summary: Ref T5179. Ref T4045. I want to move all hunk loads into DifferentialHunkQuery so I can make it do magical things where hunks come from multiple places, handle non-utf8 encodings properly, handle compression, archive into Files, and so on. Test Plan: Viewed some revisions. Called `differential.getrawdiff`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4045, T5179 Differential Revision: https://secure.phabricator.com/D9287
2014-05-25 17:09:01 +02:00
),
DifferentialDiffView
2011-01-24 22:18:41 +01:00
'DifferentialChangesetDetailView' => 'AphrontView',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DifferentialChangesetFileTreeSideNavBuilder' => 'Phobject',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialChangesetHTMLRenderer' => 'DifferentialChangesetRenderer',
make differential use fluid width for code layout Summary: assume at least 360px for a given code pane. that's about when the comment box starts fighting back anyway. we'll use the yet-to-be-built one page render for the narrow viewport cases. This address the cases as laid out in T2005. It fails the "MMMMM" case pretty horribly. However, if there is a space it works just fine and presumably folks are stretching out their windows on big glorious monitors at 160 characters wide or whatever. Re-factored things just a tad but figure I'll take a nice big chunk of "renderer" to move forward T2009 Test Plan: looked at all sorts of funky diffs Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2005 Differential Revision: https://secure.phabricator.com/D4083
2012-12-06 20:33:04 +01:00
'DifferentialChangesetListView' => 'AphrontView',
Highlight inline diff context in HTML mail Summary: Ref T10694. Ref T9790. When generating inline diff context, highlight it and then mangle the highlighted output into `style="..."` so it works in HTML. Also try to tighten up some spacing/formatting stuff. Test Plan: Got some output in this vein: {F1259937} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9790, T10694 Differential Revision: https://secure.phabricator.com/D15852
2016-05-05 18:46:44 +02:00
'DifferentialChangesetOneUpMailRenderer' => 'DifferentialChangesetRenderer',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialChangesetOneUpRenderer' => 'DifferentialChangesetHTMLRenderer',
'DifferentialChangesetOneUpTestRenderer' => 'DifferentialChangesetTestRenderer',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DifferentialChangesetParser' => 'Phobject',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialChangesetParserTestCase' => 'PhabricatorTestCase',
Introduce DifferentialChangesetQuery and remove loadHunks() Summary: Ref T4045. Ref T5179. This removes all non-Query hunk loads. Test Plan: - Viewed revisions. - Viewed standalone changesets. - Viewed raw old/new files. - Viewed vs diffs. - Enabled inline comments in mail and sent some transactions with inlines. - Called `differential.getrawdiff`. - Grepped for `loadHunks()`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4045, T5179 Differential Revision: https://secure.phabricator.com/D9289
2014-05-25 17:59:31 +02:00
'DifferentialChangesetQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DifferentialChangesetRenderer' => 'Phobject',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialChangesetTestRenderer' => 'DifferentialChangesetRenderer',
'DifferentialChangesetTwoUpRenderer' => 'DifferentialChangesetHTMLRenderer',
'DifferentialChangesetTwoUpTestRenderer' => 'DifferentialChangesetTestRenderer',
DifferentialChangesetView
2011-01-25 00:52:35 +01:00
'DifferentialChangesetViewController' => 'DifferentialController',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DifferentialCloseConduitAPIMethod' => 'DifferentialConduitAPIMethod',
Differential comment previews.
2011-02-01 03:05:20 +01:00
'DifferentialCommentPreviewController' => 'DifferentialController',
Write pathway for Differential Comments
2011-01-30 21:08:40 +01:00
'DifferentialCommentSaveController' => 'DifferentialController',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DifferentialCommitMessageParser' => 'Phobject',
Move Differential commit message parsing to a separate, tested class Summary: Ref T2222. We have a hunk of logic that purely does text parsing here; separate it and get coverage on it. Test Plan: - Ran new unit tests. - Used `differential.parsecommitmessage`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8444
2014-03-08 02:44:35 +01:00
'DifferentialCommitMessageParserTestCase' => 'PhabricatorTestCase',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialCommitsField' => 'DifferentialCustomField',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DifferentialConduitAPIMethod' => 'ConduitAPIMethod',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialConflictsField' => 'DifferentialCustomField',
DifferentialDiffView
2011-01-24 22:18:41 +01:00
'DifferentialController' => 'PhabricatorController',
Implement new-style "Summary" field Summary: Ref T3886. - Adds "Summary" field. - Adds "CoreField" for fields stored on the actual object, to reduce code duplication a bit for the main fields. Test Plan: {F115902} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8283
2014-02-21 20:52:52 +01:00
'DifferentialCoreCustomField' => 'DifferentialCustomField',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DifferentialCreateCommentConduitAPIMethod' => 'DifferentialConduitAPIMethod',
'DifferentialCreateDiffConduitAPIMethod' => 'DifferentialConduitAPIMethod',
'DifferentialCreateInlineConduitAPIMethod' => 'DifferentialConduitAPIMethod',
Differential - add ability to setup "create" addresses for revisions Summary: Fixes T1476. The body of the email should be just the output of some diff command. Test Plan: git diff master > text.txt; ./bin/mail receive-test --to <configured-diff-create-address> < text.txt; a diff was successfully created...! email generated had a working link to the diff. ./bin/mail receive-test --to <configured-diff-create-address> < README.md; a diff was not created as expected...! email generated had a sensical error message, telling me that the mail body should have been generated via a diff command Reviewers: epriestley Reviewed By: epriestley Subscribers: johnny-bit, Korvin, epriestley Maniphest Tasks: T1476 Differential Revision: https://secure.phabricator.com/D11574
2015-01-30 19:31:39 +01:00
'DifferentialCreateMailReceiver' => 'PhabricatorMailReceiver',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DifferentialCreateRawDiffConduitAPIMethod' => 'DifferentialConduitAPIMethod',
'DifferentialCreateRevisionConduitAPIMethod' => 'DifferentialConduitAPIMethod',
Implement "Pro" version of revision editor, with one field Summary: Ref T3886. I spent a few hours trying to make `DifferentialFieldSpecification` extend `PhabricatorCustomField` so I could be more blunt in my approach here and just swap the whole thing over in one go (more or less like I did with Maniphest) but we have a ton of custom fields and things felt really shaky and the change was enormous and hard to keep track of. Instead, I'm going to do this more gradually and go field-by-field. This implements a CustomField version of the "Title" field. (There are no links to this in the UI.) Test Plan: {F115353} {F115354} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8276
2014-02-19 01:32:55 +01:00
'DifferentialCustomField' => 'PhabricatorCustomField',
Modularize parser for "Closes task X as Y" Summary: Ref T3886. Ref T3872. Ref T1812. We have several parsers which look for textual references to other objects, like: Closes Tx. Depends on Dy. Reverts Dz. Currently, these are pretty hard coded, don't get all the edge cases right, and don't generalize well. They're also implemented in the middle of Differential's field code. So I want to: - Share more code so that, e.g., "Tx, Ty" always works (only some rules support it right now); - fix bugs in the parser, like T3872; - make this a modular, extensible process which runs against custom fields, not a builtin part of fields; - make the internals more flexible to accommodate custom stuff like T1812. This implements the "Verbs optional-noun Object, Optional Other Objects optional-as-something." grammar in a general way so subclasses can just plug in their keywords. Runtime code doesn't touch this yet. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3872, T1812, T3886 Differential Revision: https://secure.phabricator.com/D8261
2014-02-18 00:53:47 +01:00
'DifferentialCustomFieldDependsOnParser' => 'PhabricatorCustomFieldMonogramParser',
'DifferentialCustomFieldDependsOnParserTestCase' => 'PhabricatorTestCase',
Adjust keys for new Differential inline comment table Summary: Ref T2222. This sequences //before// D7139 and sorts out keys on the table. In particular: - There was a fairly silly `draft` key modeled after Pholio; drop it. - Add a `revisionPHID` key. This is queried mostly-transitionally on the revision view screen. - Add a `changesetID` key. This is queried by a bunch of interfaces that want more surgical results than `revisionPHID` provides. - Add an `authorPHID, transactionPHID` key. This is queried on the list interface to find pending drafts. - Add a `legacy` key. This is queried by the feed publisher. Test Plan: Used the query analyzer to hit all (I think?) of the pages, saw keyed queries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D7140
2013-09-26 22:48:36 +02:00
'DifferentialCustomFieldNumericIndex' => 'PhabricatorCustomFieldNumericIndexStorage',
Bring "Reverts X" to more general infrastructure and port unit tests Summary: Ref T3886. See D8261. This brings the "reverts x" phrase to modern infrastructure. It isn't actually called by the real parser yet, I'm going to do that in one go at the end so I can test everything more easily. This had unit tests; port most of them forward. Test Plan: Added and executed unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8262
2014-02-18 00:58:59 +01:00
'DifferentialCustomFieldRevertsParser' => 'PhabricatorCustomFieldMonogramParser',
'DifferentialCustomFieldRevertsParserTestCase' => 'PhabricatorTestCase',
Adjust keys for new Differential inline comment table Summary: Ref T2222. This sequences //before// D7139 and sorts out keys on the table. In particular: - There was a fairly silly `draft` key modeled after Pholio; drop it. - Add a `revisionPHID` key. This is queried mostly-transitionally on the revision view screen. - Add a `changesetID` key. This is queried by a bunch of interfaces that want more surgical results than `revisionPHID` provides. - Add an `authorPHID, transactionPHID` key. This is queried on the list interface to find pending drafts. - Add a `legacy` key. This is queried by the feed publisher. Test Plan: Used the query analyzer to hit all (I think?) of the pages, saw keyed queries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D7140
2013-09-26 22:48:36 +02:00
'DifferentialCustomFieldStorage' => 'PhabricatorCustomFieldStorage',
'DifferentialCustomFieldStringIndex' => 'PhabricatorCustomFieldStringIndexStorage',
Conduit: differential.creatediff
2011-01-24 20:01:53 +01:00
'DifferentialDAO' => 'PhabricatorLiskDAO',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'DifferentialDefaultViewCapability' => 'PhabricatorPolicyCapability',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialDependenciesField' => 'DifferentialCustomField',
'DifferentialDependsOnField' => 'DifferentialCustomField',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'DifferentialDiff' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'DifferentialDAO',
'PhabricatorPolicyInterface',
'HarbormasterBuildableInterface',
Add a "Build with CircleCI" build step Summary: Ref T9456. Some rough edges and we can't complete the build yet since I haven't written a webhook, but this mostly seems to be working. Test Plan: - Ran this build on some stuff. - Ran a normal HTTP step build to make sure I didn't break that. {F880301} {F880302} {F880303} Reviewers: chad Reviewed By: chad Subscribers: JustinTulloss, joshma Maniphest Tasks: T9456 Differential Revision: https://secure.phabricator.com/D14286
2015-10-15 05:01:22 +02:00
'HarbormasterCircleCIBuildableInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorApplicationTransactionInterface',
'PhabricatorDestructibleInterface',
Add DifferentialDiffQuery and change most callsites Summary: Ref T603. This introduces a policy-aware DifferentialDiffQuery and converts most callsites. I've left unusual callsites (mostly: hard to get the viewer, unusual query, queries related to active diffs) alone for now, so this isn't exhaustive but hits 60-80% of sites. Test Plan: Created diff; created revision; viewed diffs and revisions; made additional conduit calls. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D6338
2013-07-01 21:38:42 +02:00
),
Modernize all Herald DifferentialDiff fields Summary: Ref T8726. This deals with all the Differential diff fields, same deal as previous changes. Test Plan: - Wrote a rule with every field. - Migrated it. - Saw the same rule working. - Rigged the hell out of transcripts (diffs normally do not generate transcripts, because the only action is "block" and they don't exist yet when Herald runs). - Verified that all fields looked sensible in the transcript. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13590
2015-07-08 21:25:38 +02:00
'DifferentialDiffAffectedFilesHeraldField' => 'DifferentialDiffHeraldField',
'DifferentialDiffAuthorHeraldField' => 'DifferentialDiffHeraldField',
'DifferentialDiffAuthorProjectsHeraldField' => 'DifferentialDiffHeraldField',
'DifferentialDiffContentAddedHeraldField' => 'DifferentialDiffHeraldField',
'DifferentialDiffContentHeraldField' => 'DifferentialDiffHeraldField',
'DifferentialDiffContentRemovedHeraldField' => 'DifferentialDiffHeraldField',
Differential lazyweb diff create workflow.
2011-02-05 21:20:18 +01:00
'DifferentialDiffCreateController' => 'DifferentialController',
Differential - make DifferentialDiffEditor into a real transaction editor. Summary: Ref T6237. This sets us up for some future work like T6152, T6200 and generally cleaning up this workflow a bit. Tried to do as little as possible so not exposing transaction view yet. (Though that timeline is going to be a little funky in the common case of just the lone create transaction.) Test Plan: made a diff from web ui and it worked. made a herald rule to block certain diffs then tried to make such a diff and saw UI letting me know i was blocked Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6237 Differential Revision: https://secure.phabricator.com/D10869
2014-11-19 00:32:23 +01:00
'DifferentialDiffEditor' => 'PhabricatorApplicationTransactionEditor',
Move diff extraction from commits to a separate test with a CLI command Summary: Ref T9319. When we discover a commit, we sometimes update the corresponding revision with a "this is the actual committed change" diff and send out a link to the changes between review and commit. This is currently very difficult to test, because it only happens the first time and you have to either go set up a bunch of objects or add a bunch of special casing to the parser to hit the workflow. I'm making some changes to how it pulls file content. To make those changes easier to test, first start extracting this stuff so the code can be run with `bin/differential extract ...` instead of needing to do a bunch of more complicated setup steps. Test Plan: - Ran `bin/differential extract ...` to extract diffs from commits. - Forced my way through the daemon workflow by faking out a bunch of flags, got a clean extract + attach + update. After this patch, this should rarely be necessary. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9319 Differential Revision: https://secure.phabricator.com/D14967
2016-01-08 13:35:17 +01:00
'DifferentialDiffExtractionEngine' => 'Phobject',
Modernize all Herald DifferentialDiff fields Summary: Ref T8726. This deals with all the Differential diff fields, same deal as previous changes. Test Plan: - Wrote a rule with every field. - Migrated it. - Saw the same rule working. - Rigged the hell out of transcripts (diffs normally do not generate transcripts, because the only action is "block" and they don't exist yet when Herald runs). - Verified that all fields looked sensible in the transcript. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13590
2015-07-08 21:25:38 +02:00
'DifferentialDiffHeraldField' => 'HeraldField',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'DifferentialDiffHeraldFieldGroup' => 'HeraldFieldGroup',
Extend TransactionCommentQuery for Differential Summary: Ref T2009. Ref T1460. Replace hard-coded garbage with a real Query-layer query. Test Plan: Submitted inline comments in Differential. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2009, T1460 Differential Revision: https://secure.phabricator.com/D12027
2015-03-09 20:40:29 +01:00
'DifferentialDiffInlineCommentQuery' => 'PhabricatorDiffInlineCommentQuery',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'DifferentialDiffPHIDType' => 'PhabricatorPHIDType',
Conduit: differential.setdiffproperty
2011-01-24 21:07:34 +01:00
'DifferentialDiffProperty' => 'DifferentialDAO',
Add DifferentialDiffQuery and change most callsites Summary: Ref T603. This introduces a policy-aware DifferentialDiffQuery and converts most callsites. I've left unusual callsites (mostly: hard to get the viewer, unusual query, queries related to active diffs) alone for now, so this isn't exhaustive but hits 60-80% of sites. Test Plan: Created diff; created revision; viewed diffs and revisions; made additional conduit calls. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D6338
2013-07-01 21:38:42 +02:00
'DifferentialDiffQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Modernize all Herald DifferentialDiff fields Summary: Ref T8726. This deals with all the Differential diff fields, same deal as previous changes. Test Plan: - Wrote a rule with every field. - Migrated it. - Saw the same rule working. - Rigged the hell out of transcripts (diffs normally do not generate transcripts, because the only action is "block" and they don't exist yet when Herald runs). - Verified that all fields looked sensible in the transcript. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13590
2015-07-08 21:25:38 +02:00
'DifferentialDiffRepositoryHeraldField' => 'DifferentialDiffHeraldField',
'DifferentialDiffRepositoryProjectsHeraldField' => 'DifferentialDiffHeraldField',
Replace ArcanistPhutilTestCase refs with PhutilTestCase Summary: Ref T7977. Remove the `PhabricatorTestCase::getLink` method. Depends on D12665. Test Plan: `arc unit`. Reviewers: avivey, #blessed_reviewers, epriestley Reviewed By: avivey, #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7977 Differential Revision: https://secure.phabricator.com/D12667
2015-05-20 01:37:39 +02:00
'DifferentialDiffTestCase' => 'PhutilTestCase',
Differential - make DifferentialDiffEditor into a real transaction editor. Summary: Ref T6237. This sets us up for some future work like T6152, T6200 and generally cleaning up this workflow a bit. Tried to do as little as possible so not exposing transaction view yet. (Though that timeline is going to be a little funky in the common case of just the lone create transaction.) Test Plan: made a diff from web ui and it worked. made a herald rule to block certain diffs then tried to make such a diff and saw UI letting me know i was blocked Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6237 Differential Revision: https://secure.phabricator.com/D10869
2014-11-19 00:32:23 +01:00
'DifferentialDiffTransaction' => 'PhabricatorApplicationTransaction',
Add "Autoplans" to Harbormaster Summary: Ref T8095. Two general problems: - I want Harbormaster to own all lint and unit test results. - I don't want users to have to configure anything for `arc` to keep working automatically. These are in conflict because generic lint/unit test ownership in Harbormaster requires that build targets exist which we can attach build results to. However, we can't currently create build targets on demand: Harbormaster assumes it is responsible for creating targets, then running code or making third-party service calls to actually run the builds. I considered two broad approaches to let `arc` push results into Harbormaster without requiring administrators to configure some kind of "arc results" build plan: # Add magic target PHIDs like `PHID-MAGIC-this-is-really-arc-unit`. # Add new code to build real targets with real PHIDs. (1) is probably a bit less work to get off the ground, but I think it's worse overall and very likely to create more problems in the long run. I particularly worry that it will lead to a small amount of special casing in a very large number of places, which seems more fragile. (2) is more work upfront but I think does a better job of putting all the special casing in one place that we can, e.g., more reasonably unit test, and letting the rest of the code rarely/never care about this case since it's just dealing with normal plans/steps/targets as far as it can tell. This diff introduces "autoplans", which are source templates for plans/steps. This let us "push" these targets into Harbormaster. Hypthetically, any process "like" arc can use autoplans to upload test/lint/etc results. In practice, probably only `arc` will ever use this, but I think it's still quite a bit cleaner than the alternative despite all the generality. Workflow is basically: - `arc` creates a diff. - `arc` calls `harbormaster.queryautotargets`, passing the diff PHID and saying "I have some lint and unit results I want to stick on this thing". - Harbormaster builds the plan, steps, and targets (if any of them don't already exist), and hands back the target PHIDs so `arc` has a completely standard-looking place to put results. - `arc` uploads the test results to the right targets, as though Harbormaster had asked it to run unit/lint in the first place. (This doesn't actually do any of that yet, just sets things up.) I'll maybe doc turn that ^^^^^^ into a doc for posterity since I think it's hard to guess what an "autotarget" is, but I'm going to grab some lunch first. Test Plan: - Added unit tests to make sure we can build these things properly. - Used `harbormaster.queryautotargets` to build autotargets for a bunch of diffs. - Verified targets come up in "waiting for message" state. - Verified plans and steps are not editable. Reviewers: btrahan Reviewed By: btrahan Subscribers: hach-que, epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13345
2015-06-21 18:04:21 +02:00
'DifferentialDiffTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
DifferentialDiffView
2011-01-24 22:18:41 +01:00
'DifferentialDiffViewController' => 'DifferentialController',
Generalize Asana-publishable feed story objects Summary: Ref T2852. Pulls the Differential-specific aspects of the Asana sync out of the worker. Next diff will add a publisher for Audit/Diffusion. Test Plan: Published events, including state changes. Saw them reflected correctly in Asana. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6569
2013-07-26 17:56:35 +02:00
'DifferentialDoorkeeperRevisionFeedStoryPublisher' => 'DoorkeeperFeedStoryPublisher',
Differential - add DifferentialDraft to track whether revisions have draft feedback or not Summary: ...do it somewhat generically, so we could fairly easily add this to other applications. Fixes T3496. I got a wee bit lazy and decided not to migrate existing drafts. My excuses aside from laziness are doing it this way will let us see if anyone complains, we can always do a migration later if people do complain, and there's likely to be a lot of garbage data for older / bigger installs, and the migration didn't seem worth itgiven it would also likely be expensive in these cases. Test Plan: made a draft inline comment on DX and observed DX had a note icon on Differential home page. made a draft comment on DX and observed DX had a note icon on Differential home page. deleted a draft inline comment and noted icon disappeared from Differential homepage. Submitted a draft comment + inline comment and noted icon disappeared. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T3496 Differential Revision: https://secure.phabricator.com/D8275
2014-02-19 01:25:16 +01:00
'DifferentialDraft' => 'DifferentialDAO',
Implement view and edit policies in Differential CustomFields Summary: Ref T3886. Ref T418. - Adds "View Policy" and "Edit Policy" fields. - Allows CustomFields to produce arbitrary types of transactions, so these fields can produce standard view/edit policy transactions and get all the strings and validation associated with them. Test Plan: {F116001} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T3886 Differential Revision: https://secure.phabricator.com/D8287
2014-02-21 20:53:48 +01:00
'DifferentialEditPolicyField' => 'DifferentialCoreCustomField',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'DifferentialFieldParseException' => 'Exception',
'DifferentialFieldValidationException' => 'Exception',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DifferentialFindConduitAPIMethod' => 'DifferentialConduitAPIMethod',
'DifferentialGetAllDiffsConduitAPIMethod' => 'DifferentialConduitAPIMethod',
'DifferentialGetCommitMessageConduitAPIMethod' => 'DifferentialConduitAPIMethod',
'DifferentialGetCommitPathsConduitAPIMethod' => 'DifferentialConduitAPIMethod',
'DifferentialGetDiffConduitAPIMethod' => 'DifferentialConduitAPIMethod',
'DifferentialGetRawDiffConduitAPIMethod' => 'DifferentialConduitAPIMethod',
'DifferentialGetRevisionCommentsConduitAPIMethod' => 'DifferentialConduitAPIMethod',
'DifferentialGetRevisionConduitAPIMethod' => 'DifferentialConduitAPIMethod',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DifferentialGetWorkingCopy' => 'Phobject',
Rename `DifferentialLandingStrategy` subclasses for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: avivey, Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11186
2015-01-04 20:33:42 +01:00
'DifferentialGitHubLandingStrategy' => 'DifferentialLandingStrategy',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialGitSVNIDField' => 'DifferentialCustomField',
Reduce Lint/Unit rendering duplication Summary: Ref T8096. No functional changes, just a bit less code. Test Plan: Viewed some revisions, saw the same stuff as before. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8096 Differential Revision: https://secure.phabricator.com/D13404
2015-06-23 22:33:09 +02:00
'DifferentialHarbormasterField' => 'DifferentialCustomField',
Allow inline comments to be individually hidden Summary: Ref T7447. Implements per-viewer comment hiding. Once a comment is obsolete or uninteresting, you can hide it completely. This is sticky per-user. My hope is that this will strike a better balance between concerns than some of the other approaches (conservative porting, summarization, hide-all). Specifically, this adds a new action here: {F435621} Clicking it completely collapses the comment into a small icon on the previous line, and saves the comment state as hidden for you: {F435626} You can click the icon to reveal all hidden comments below the line. Test Plan: - Hid comments. - Showed comments. - Created, edited, deleted and submitted comments. - Used Diffusion comments (hiding is not implemented there yet, but I'd plan to bring it there eventually if it works out in Differential). Reviewers: btrahan, chad Reviewed By: btrahan Subscribers: jparise, yelirekim, epriestley Maniphest Tasks: T7447 Differential Revision: https://secure.phabricator.com/D13009
2015-05-27 19:28:38 +02:00
'DifferentialHiddenComment' => 'DifferentialDAO',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialHostField' => 'DifferentialCustomField',
Rename `DifferentialLandingStrategy` subclasses for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: avivey, Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11186
2015-01-04 20:33:42 +01:00
'DifferentialHostedGitLandingStrategy' => 'DifferentialLandingStrategy',
'DifferentialHostedMercurialLandingStrategy' => 'DifferentialLandingStrategy',
Modernize Hovercard implementation Summary: Ref T8980. Move away from events to EngineExtensions. This also simplifies hovercards a bit: - Removes tasks from revision cards. - Removes blockers/blocked from task cards. - Removes "Send Message" from user cards. These mostly felt cluttery to me. Open to arguments to retain them. I think we can make better use of the space, though (e.g., flags, projects + board columns). Test Plan: - Viewed people, task, revision, commit and project hovercards. {F1043256} {F1043257} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8980 Differential Revision: https://secure.phabricator.com/D14878
2015-12-24 20:20:18 +01:00
'DifferentialHovercardEngineExtension' => 'PhabricatorHovercardEngineExtension',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'DifferentialHunk' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'DifferentialDAO',
'PhabricatorPolicyInterface',
Add DifferentialHunkQuery to start hiding hunk storage details Summary: Ref T4045. We have a lot of direct queries against the hunk table right now. These are messy, not really policy-aware, and limit our options on T4045. This query is unusual (it requires changesets, and does not accept IDs). This keeps us from having to load changeset -> diff -> revision in order to do policy checks. We could also fix this with smarter policy checks and caching, but I'd rather not open that can of worms for now. This object is very low level and relatively unusual, and this small deviation from convention seems like the cleanest cut to make to keep this from snowballing. Test Plan: Used Herald dry runs to verify that the affected rules still output the same data. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4045 Differential Revision: https://secure.phabricator.com/D8765
2014-04-14 21:06:26 +02:00
),
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DifferentialHunkParser' => 'Phobject',
re-factor DifferentialChangesetParser pass 3 / N Summary: introducing a new friend called DifferentialHunkParser. Sort of like the DifferentialChangesetParser but works with hunks only. tried to grab hunk parsing type things from across the code base and move them into this new class. Test Plan: unit tests and played around in Differential a bit. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4351
2013-01-09 22:11:17 +01:00
'DifferentialHunkParserTestCase' => 'PhabricatorTestCase',
Add DifferentialHunkQuery to start hiding hunk storage details Summary: Ref T4045. We have a lot of direct queries against the hunk table right now. These are messy, not really policy-aware, and limit our options on T4045. This query is unusual (it requires changesets, and does not accept IDs). This keeps us from having to load changeset -> diff -> revision in order to do policy checks. We could also fix this with smarter policy checks and caching, but I'd rather not open that can of worms for now. This object is very low level and relatively unusual, and this small deviation from convention seems like the cleanest cut to make to keep this from snowballing. Test Plan: Used Herald dry runs to verify that the affected rules still output the same data. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4045 Differential Revision: https://secure.phabricator.com/D8765
2014-04-14 21:06:26 +02:00
'DifferentialHunkQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Replace ArcanistPhutilTestCase refs with PhutilTestCase Summary: Ref T7977. Remove the `PhabricatorTestCase::getLink` method. Depends on D12665. Test Plan: `arc unit`. Reviewers: avivey, #blessed_reviewers, epriestley Reviewed By: avivey, #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7977 Differential Revision: https://secure.phabricator.com/D12667
2015-05-20 01:37:39 +02:00
'DifferentialHunkTestCase' => 'PhutilTestCase',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DifferentialInlineComment' => array(
'Phobject',
'PhabricatorInlineCommentInterface',
),
Add inline comments to Diffusion/Audit Summary: - Add inline comments to Audits, like Differential. - Creates new storage for the comments in the Audits database. - Creates a new PhabricatorAuditInlineComment class, similar to DifferentialInlineComment. - Defines an Interface which Differential and Audit comments conform to. - Makes consumers of DifferentialInlineComments consume objects which implement that interface instead. - Adds save NOTE: Some features are still missing! Wanted to cut this off before it got crazy: - Inline comments aren't shown in the main comment list. - Inline comments aren't shown in the emails. - Inline comments aren't previewed. I'll followup with those but this was getting pretty big. @vrana, does the SQL change look correct? Test Plan: - Created, edited, deleted, replied to, reloaded and saved inline comments in Diffusion, on the left and right side of diffs. - Created, edited, deleted, replied to, reloaded and saved inline comments in Differentila, on the left and right side of primary and diff-versus-diff diffs. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1898
2012-03-14 20:56:01 +01:00
'DifferentialInlineCommentEditController' => 'PhabricatorInlineCommentController',
Rough cut of inline comment context Summary: Ref T10694. This is still missing some pieces, but seems to get most of the data into the mail in a plausible format: - When an inline remarks on code, show the patch inline in the mail body. - When an inline replies to another inline, show that other inline in the mail body. - Apply remarkup rendering to inline content. - Apply basic styling to mail body blocks. Not covered yet: - Syntax highlighting. - Diff highlighting. - Maybe clearer style/layout hints to connect comments to what they reply to? Current approach might get messy with inlines that have blockquotes and code blocks inside them, for example. - I probably want to cap the amount of diff context we ever show to ~7 lines, even if you drag over 200 lines of code. - CSS is a generally a bit rough still. - The `unified-comment-context` option is effectively always on now, and should be removed. - Text section is getting indented right now but probably shouldn't be. - Spacing, etc., might be a bit off. Test Plan: Rigged Home to render these things, got a plausible-looking render (top is text, bottom is HTML): {F1259052} Sent myself some inline comment mail, got a plausible result. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10694 Differential Revision: https://secure.phabricator.com/D15850
2016-05-05 13:42:29 +02:00
'DifferentialInlineCommentMailView' => 'Phobject',
Make inline comment preview work in Diffusion Summary: created a PhabricatorInlineCommentPreviewController so controllers in Diffusion and Differential respectively just have to handle the URI mapping and data loading like good little controllers. Test Plan: left inline comments on commits, deleted inline commits, submitted inline comments -- all worked well did the same on some diffs Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1176 Differential Revision: https://secure.phabricator.com/D3034
2012-07-23 20:01:28 +02:00
'DifferentialInlineCommentPreviewController' => 'PhabricatorInlineCommentPreviewController',
Abstract access to DifferentialInlineComment behind a Query Summary: Ref T2222. See D6260. Push all this junk behind a Query so I can move the storage out from underneath it. Test Plan: Viewed home page, list view, revision. Made draft, looked at preview, submitted draft, viewed inline, replied to inline. Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D6262
2013-06-21 21:54:56 +02:00
'DifferentialInlineCommentQuery' => 'PhabricatorOffsetPagedQuery',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialJIRAIssuesField' => 'DifferentialStoredCustomField',
Land Revision button for hosted git repos Summary: ref T182. Simple approach of clone, patch, push. While waiting for drydock, implement a hackish mutex setup for the workspace, which should work ok as long as there's only one committer who is carefull about theses things. Less obvious note: This is taking the both author and commiter's 'primary email' for the commit - which might rub some people wrong. Test Plan: With a hosted repo, created some diffs and landed them. Also clicked button for some error cases, got the right error message. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: hach-que, Korvin, epriestley, aran Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D7486
2013-11-05 22:00:12 +01:00
'DifferentialLandingActionMenuEventListener' => 'PhabricatorEventListener',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DifferentialLandingStrategy' => 'Phobject',
Rename `DifferentialHunk` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11470
2015-01-22 21:17:04 +01:00
'DifferentialLegacyHunk' => 'DifferentialHunk',
Implement rough content-aware inline adjustment rules for ghosts Summary: Ref T7447. Fixes T7600. This likely needs significant adjustment, but implements content-aware comment porting for line changes. Specifically, this moves lines around to adjust their position considering added and removed lines between the diffs and across rebases. It does not try to do any actual content (line against line) matching. Test Plan: - Unit tests. - Poking around in the web UI seems to generate mostly reasonable-ish results? - This may be a huge step backward in some cases that I just haven't hit. Reviewers: btrahan Reviewed By: btrahan Subscribers: yelirekim, epriestley Maniphest Tasks: T7600, T7447 Differential Revision: https://secure.phabricator.com/D12741
2015-05-07 23:09:41 +02:00
'DifferentialLineAdjustmentMap' => 'Phobject',
Reduce Lint/Unit rendering duplication Summary: Ref T8096. No functional changes, just a bit less code. Test Plan: Viewed some revisions, saw the same stuff as before. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8096 Differential Revision: https://secure.phabricator.com/D13404
2015-06-23 22:33:09 +02:00
'DifferentialLintField' => 'DifferentialHarbormasterField',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DifferentialLintStatus' => 'Phobject',
Display local commit information in Differential Summary: After D857, we try to attach local commit information to revisions. If this information is available, display it on the revision. Design on this is a little rough, I might try to combine this into the revision update view or something like that since we're starting to take up a lot of real estate for metadata. Test Plan: Local diffed this and got some commit info. Reviewers: jungejason, tuomaspelkonen, aran Reviewed By: jungejason CC: aran, epriestley, jungejason Differential Revision: 872
2011-08-30 20:34:07 +02:00
'DifferentialLocalCommitsView' => 'AphrontView',
Remove DifferentialRevisionEditor Summary: Ref T2222. This has no callsites and no functionality not present in the TransactionEditor. Test Plan: awwyiss Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8456
2014-03-08 21:15:29 +01:00
'DifferentialManiphestTasksField' => 'DifferentialCoreCustomField',
Rename `DifferentialHunk` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11470
2015-01-22 21:17:04 +01:00
'DifferentialModernHunk' => 'DifferentialHunk',
Move "Next Step" to a custom field in Differential Summary: Fixes T9672. This was never turned into a custom field, for no particular reason. Convert it into one. This is substantially similar to the existing "Apply Patch" field, which does the same thing (only shows a command). We might rethink or remove this eventually (e.g., in a post-"Land Revision" world) but this makes it easier, at the very least. Test Plan: - Viewed a non-accepted revision (no hint). - Viewed an accepted revision from a raw diff source (no hint). - Viewed an accepted revision from Git (`arc land` hint). Reviewers: chad Reviewed By: chad Maniphest Tasks: T9672 Differential Revision: https://secure.phabricator.com/D14367
2015-10-30 17:00:53 +01:00
'DifferentialNextStepField' => 'DifferentialCustomField',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'DifferentialParseCacheGarbageCollector' => 'PhabricatorGarbageCollector',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DifferentialParseCommitMessageConduitAPIMethod' => 'DifferentialConduitAPIMethod',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialParseRenderTestCase' => 'PhabricatorTestCase',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialPathField' => 'DifferentialCustomField',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialProjectReviewersField' => 'DifferentialCustomField',
Projects for DifferentialRevision Summary: T2628, Adding project tags to revisions Test Plan: Edit revision, verify projects can be tagged. Add project hashtag to comments or commit templates, verify revision is tagged with project Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D9686
2014-06-23 18:49:52 +02:00
'DifferentialProjectsField' => 'DifferentialCoreCustomField',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DifferentialQueryConduitAPIMethod' => 'DifferentialConduitAPIMethod',
'DifferentialQueryDiffsConduitAPIMethod' => 'DifferentialConduitAPIMethod',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DifferentialRawDiffRenderer' => 'Phobject',
'DifferentialReleephRequestFieldSpecification' => 'Phobject',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'DifferentialRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Move Differential to modular mail commands Summary: Ref T7199. Convert Differential to modern modular commands. Test Plan: Used `bin/mail receive-test` to send command and comment mail to Differential. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12239
2015-04-01 17:40:12 +02:00
'DifferentialReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Implement "Repository" as a new-style CustomField in Differential Summary: Ref T3886. Ref T418. - Adds new capabilities for CustomField: - Controls can now bulk-load PHIDs (e.g., for tokenizers). - Transactions can now bulk-load PHIDs (e.g., for relationship changes). - Implements "Repository" control. - Improves tokenizer StandardCustomField controls. Test Plan: {F115942} {F115943} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T3886 Differential Revision: https://secure.phabricator.com/D8286
2014-02-21 20:53:37 +01:00
'DifferentialRepositoryField' => 'DifferentialCoreCustomField',
When creating or updating a revision, infer the repository from the diff Summary: Ref T603. When a diff is attached to a revision, try to guess the repository if possible. In cases where we succeed, this automatically gives us intuitive policy behavior (i.e., you can see a revision if you can see the repository the change is against). I pulled this into a funky little "Lookup" class for two reasons: - It's used in two places; - I anticipate that we might need to add some sort of `explainWhy()` method if users find the heuristics confusing. Test Plan: Created and updated revisions, saw them pick up the correct repository association. Ran Herald dry run against associable and nonassociable revisions, saw correct values populate. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7147
2013-09-27 00:28:42 +02:00
'DifferentialRepositoryLookup' => 'Phobject',
Allow Herald to "Require legal signatures" for reviews Summary: Ref T3116. Add a Herald action "Require legal signatures" which requires revision authors to accept legal agreements before their revisions can be accepted. - Herald will check which documents the author has signed, and trigger a "you have to sign X, Y, Z" for other documents. - If the author has already signed everything, we don't spam the revision -- basically, this only triggers when signatures are missing. - The UI will show which documents must be signed and warn that the revision can't be accepted until they're completed. - Users aren't allowed to "Accept" the revision until documents are cleared. Fixes T1157. The original install making the request (Hive) no longer uses Phabricator, and this satisfies our requirements. Test Plan: - Added a Herald rule. - Created a revision, saw the rule trigger. - Viewed as author and non-author, saw field UI (generic for non-author, specific for author), transaction UI, and accept-warning UI. - Tried to accept revision. - Signed document, saw UI update. Note that signatures don't currently //push// an update to the revision, but could eventually (like blocking tasks work). - Accepted revision. - Created another revision, saw rules not add the document (since it's already signed, this is the "no spam" case). Reviewers: btrahan, chad Reviewed By: chad Subscribers: asherkin, epriestley Maniphest Tasks: T1157, T3116 Differential Revision: https://secure.phabricator.com/D9771
2014-06-29 16:53:53 +02:00
'DifferentialRequiredSignaturesField' => 'DifferentialCoreCustomField',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialRevertPlanField' => 'DifferentialStoredCustomField',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialReviewedByField' => 'DifferentialCoreCustomField',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DifferentialReviewer' => 'Phobject',
Migrate Differential revision edges to use modern `EdgeType` subclasses Summary: Modernize Differential edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: From previous experience, these changes are fairly trivial and safe. I poked around a little to make sure things looked reasonably okay. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, Krenair, epriestley Differential Revision: https://secure.phabricator.com/D11074
2015-01-01 04:43:26 +01:00
'DifferentialReviewerForRevisionEdgeType' => 'PhabricatorEdgeType',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DifferentialReviewerStatus' => 'Phobject',
Modularize Differential Reviewer actions in Herald Ref T8726. Modularizes the "Add Reviewers" and "Add Blocking Reviewers" Herald actions.
2015-07-30 20:39:35 +02:00
'DifferentialReviewersAddBlockingReviewersHeraldAction' => 'DifferentialReviewersHeraldAction',
'DifferentialReviewersAddBlockingSelfHeraldAction' => 'DifferentialReviewersHeraldAction',
'DifferentialReviewersAddReviewersHeraldAction' => 'DifferentialReviewersHeraldAction',
'DifferentialReviewersAddSelfHeraldAction' => 'DifferentialReviewersHeraldAction',
Implement a "Reviewers" CustomField Summary: Ref T3886: - Adds a "Reviewers" field as a modern CustomField. Ref T418: - Allows CustomFields to emit transaction metadata. Test Plan: {F116254} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T3886 Differential Revision: https://secure.phabricator.com/D8291
2014-02-21 20:54:32 +01:00
'DifferentialReviewersField' => 'DifferentialCoreCustomField',
Modularize Differential Reviewer actions in Herald Ref T8726. Modularizes the "Add Reviewers" and "Add Blocking Reviewers" Herald actions.
2015-07-30 20:39:35 +02:00
'DifferentialReviewersHeraldAction' => 'HeraldAction',
Split users apart from projects/packages in reviewer and audit UIs Summary: Ref T1279. Show separate sections for "Reviewers" and "Project Reviewers" (Differential) and for "Auditors" and "Package/Project Auditors" (Diffusion/Audit). Test Plan: - Looked at a commit. Saw separation. - Looked at a revision. Saw separation. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1279 Differential Revision: https://secure.phabricator.com/D7233
2013-10-05 16:54:42 +02:00
'DifferentialReviewersView' => 'AphrontView',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'DifferentialRevision' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'DifferentialDAO',
'PhabricatorTokenReceiverInterface',
'PhabricatorPolicyInterface',
Add support for "Extended Policies" Summary: Ref T7703. See that task and inline for a bunch of discussion. Briefly, when we run implicit policy rules ("to see a revision, you must also be able to see its repository") at query time, they don't apply to other viewers we might check later. We do this very rarely, but when we do we're often doing it for a bunch of different viewers (for example, in Herald) so I don't want to just reload the object a million times. Test Plan: - Added and executed unit tests. - Wrote a "flag everything" Herald rule, as in the original report in T7703, and no longer got "Unknown Object" flags on revisions. - Rigged up a lot of cases in the web UI and couldn't find any inconsistencies, although this case is normally very hard to hit. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7703 Differential Revision: https://secure.phabricator.com/D13104
2015-05-11 23:23:35 +02:00
'PhabricatorExtendedPolicyInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorFlaggableInterface',
'PhrequentTrackableInterface',
'HarbormasterBuildableInterface',
'PhabricatorSubscribableInterface',
'PhabricatorCustomFieldInterface',
'PhabricatorApplicationTransactionInterface',
Transactions - add infrastructure for "mentions" Summary: Fixes T4036. Now if you say something on diff X like "This reminds me of Tx and Dy and commitHashFoo and Px." each of those objects gets a little visible transaction that the mention occurred. No feed, email, or notifications. Test Plan: made a comment like above and verified transactions. also submitted a diff that "Fixes Tx" and Tx did not get the transaction as expected. Reviewers: epriestley Reviewed By: epriestley Subscribers: joshuaspence, epriestley, Korvin Maniphest Tasks: T4036 Differential Revision: https://secure.phabricator.com/D10451
2014-09-09 23:21:13 +02:00
'PhabricatorMentionableInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorDestructibleInterface',
'PhabricatorProjectInterface',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorFulltextInterface',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
),
Modularize all DifferentialRevision fields Summary: Ref T8726. Make all the DifferentialRevision stuff modular. Test Plan: - Created a rule with all fields. - Ran upgrade. - Saw all fields preserved with new modular versions. - Used test console to run rule with all fields, verified field values as broadly sensible. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13598
2015-07-08 21:25:48 +02:00
'DifferentialRevisionAffectedFilesHeraldField' => 'DifferentialRevisionHeraldField',
'DifferentialRevisionAuthorHeraldField' => 'DifferentialRevisionHeraldField',
'DifferentialRevisionAuthorProjectsHeraldField' => 'DifferentialRevisionHeraldField',
Increase clarity when closing a revision in response to a commit Summary: I am not sure how valuable this is *as is* - I think it needs different explanations for what happened in mercurial or subversion? I do not know what those explanations are. Made an error in D10485 - the $hashes that were saved is an array of objects, so it ends up turning into garbage via the wonders of serialization and de-serialization. Fix that by explicitly saving the tree hash. I would like to make this work for the other VCS types we support, add the "undo / nope" button and call it fixed. Ref T3686. Test Plan: clicked "explan why" and saw why Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5693, T3686 Differential Revision: https://secure.phabricator.com/D10489
2014-10-14 01:55:26 +02:00
'DifferentialRevisionCloseDetailsController' => 'DifferentialController',
Modularize all DifferentialRevision fields Summary: Ref T8726. Make all the DifferentialRevision stuff modular. Test Plan: - Created a rule with all fields. - Ran upgrade. - Saw all fields preserved with new modular versions. - Used test console to run rule with all fields, verified field values as broadly sensible. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13598
2015-07-08 21:25:48 +02:00
'DifferentialRevisionContentAddedHeraldField' => 'DifferentialRevisionHeraldField',
'DifferentialRevisionContentHeraldField' => 'DifferentialRevisionHeraldField',
'DifferentialRevisionContentRemovedHeraldField' => 'DifferentialRevisionHeraldField',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DifferentialRevisionControlSystem' => 'Phobject',
Migrate Differential revision edges to use modern `EdgeType` subclasses Summary: Modernize Differential edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: From previous experience, these changes are fairly trivial and safe. I poked around a little to make sure things looked reasonably okay. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, Krenair, epriestley Differential Revision: https://secure.phabricator.com/D11074
2015-01-01 04:43:26 +01:00
'DifferentialRevisionDependedOnByRevisionEdgeType' => 'PhabricatorEdgeType',
'DifferentialRevisionDependsOnRevisionEdgeType' => 'PhabricatorEdgeType',
RevisionEdit
2011-01-25 22:26:09 +01:00
'DifferentialRevisionEditController' => 'DifferentialController',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'DifferentialRevisionFulltextEngine' => 'PhabricatorFulltextEngine',
Migrate Differential revision edges to use modern `EdgeType` subclasses Summary: Modernize Differential edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: From previous experience, these changes are fairly trivial and safe. I poked around a little to make sure things looked reasonably okay. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, Krenair, epriestley Differential Revision: https://secure.phabricator.com/D11074
2015-01-01 04:43:26 +01:00
'DifferentialRevisionHasCommitEdgeType' => 'PhabricatorEdgeType',
'DifferentialRevisionHasReviewerEdgeType' => 'PhabricatorEdgeType',
Modernize task/revision edges and write inverse transactions Summary: Ref T5245. See some discussion in D9838. When we attach object A to object B, we'd like to write transactions on both sides but only write the actual edges once. To do this, allow edge types to `shouldWriteInverseTransactions()`. When an edge type opts into this, have editors apply the inverse transactions before writing the edge. These inverse transactions don't actually apply effects, they just show up in the transaction log. Test Plan: Attached and detached revisions from tasks, saw transactions appear on both sides of the operation. Reviewers: chad, btrahan, joshuaspence Reviewed By: btrahan, joshuaspence Subscribers: epriestley Maniphest Tasks: T5245 Differential Revision: https://secure.phabricator.com/D9839
2014-07-18 00:41:08 +02:00
'DifferentialRevisionHasTaskEdgeType' => 'PhabricatorEdgeType',
Modularize all DifferentialRevision fields Summary: Ref T8726. Make all the DifferentialRevision stuff modular. Test Plan: - Created a rule with all fields. - Ran upgrade. - Saw all fields preserved with new modular versions. - Used test console to run rule with all fields, verified field values as broadly sensible. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13598
2015-07-08 21:25:48 +02:00
'DifferentialRevisionHeraldField' => 'HeraldField',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'DifferentialRevisionHeraldFieldGroup' => 'HeraldFieldGroup',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialRevisionIDField' => 'DifferentialCustomField',
Land Revision button for hosted git repos Summary: ref T182. Simple approach of clone, patch, push. While waiting for drydock, implement a hackish mutex setup for the workspace, which should work ok as long as there's only one committer who is carefull about theses things. Less obvious note: This is taking the both author and commiter's 'primary email' for the commit - which might rub some people wrong. Test Plan: With a hosted repo, created some diffs and landed them. Also clicked button for some error cases, got the right error message. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: hach-que, Korvin, epriestley, aran Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D7486
2013-11-05 22:00:12 +01:00
'DifferentialRevisionLandController' => 'DifferentialController',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'DifferentialRevisionListController' => 'DifferentialController',
Separate revision list rendering logic into a RevisionListView Summary: I want to throw this in Diffusion as part of T262, but it's embedded in the controller right now. Split it out. Test Plan: Looked at various revision list views, no changes. Reviewers: jungejason, nh, tuomaspelkonen, aran Reviewed By: jungejason CC: aran, jungejason Differential Revision: 977
2011-10-02 20:42:41 +02:00
'DifferentialRevisionListView' => 'AphrontView',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'DifferentialRevisionMailReceiver' => 'PhabricatorObjectMailReceiver',
Rough cut of DrydockRepositoryOperation Summary: Ref T182. This doesn't do anything interesting yet and is mostly scaffolding, but here's roughly the workflow. From previous revision, you can configure "Repository Automation" for a repository: {F875741} If it's configured, a new "Land Revision" button shows up: {F875743} Once you click it you get a big warning dialog that it won't work, and then this shows up at the top of the revision (completely temporary/placeholder UI, some day a nice progress bar or whatever): {F875747} If you're lucky, the operation eventually sort of works: {F875750} It only runs `git show` right now, doesn't actually do any writes or anything. Test Plan: - Clicked "Land Revision". - Watched `phd debug task`. - Saw it log `git show` to output. - Verified operation success in UI (by fiddling URL, no way to get there normally yet). Reviewers: chad Reviewed By: chad Subscribers: revi Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D14266
2015-10-14 00:46:12 +02:00
'DifferentialRevisionOperationController' => 'DifferentialController',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'DifferentialRevisionPHIDType' => 'PhabricatorPHIDType',
Modularize all DifferentialRevision fields Summary: Ref T8726. Make all the DifferentialRevision stuff modular. Test Plan: - Created a rule with all fields. - Ran upgrade. - Saw all fields preserved with new modular versions. - Used test console to run rule with all fields, verified field values as broadly sensible. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13598
2015-07-08 21:25:48 +02:00
'DifferentialRevisionPackageHeraldField' => 'DifferentialRevisionHeraldField',
'DifferentialRevisionPackageOwnerHeraldField' => 'DifferentialRevisionHeraldField',
[Rough Sketch] Differential ObjectItemView Smexyness Summary: Tried out `PhabricatorObjectItemView` for Differential. It looks smexy and smooth. Refs T2014 - Title and Date as Maniphest - Author in the handle icon - Bar color reflects revision status (Needs Review, Accepted, Abandoned etc.) @chad looking for non-blue is faster than keeping watch for everything that's not "Closed" in old table form - Some status information are in footer icons; currently only stale/old status display as well as saved drafts, maybe more in future; these come into my mind: - No reviewer warning - Push Blocking Priority (T2730) - Trivial, fast review guaranteed - Sketch / Just looking for advice/help - Arcanist Project (T2614) - Denote "Public Send-in" (T1476) {F37662} {F37663} {F37664} {F37665} Some flaws: - Date and reviewers on every entry the same? - No respect for Differential fields (for some reason, every entry appeared the same, so broke it to parts) - Plenty of (potential) increase in height - advise reducing paging length from 100 to 50 - or just ignore me Suggestions for the future: - Expand the meta information regarding revisions; e.g. the various status displays above - Uh... T2543, T1279, T793, T731 and what else I want for Differential, because they are awesome! - T793 should be in particular easy appearance-wise, just copy-paste from Maniphest Test Plan: By looking at it, of course. Verified there are no errors or crashed Reviewers: epriestley, chad, btrahan, liguobig Reviewed By: chad CC: aran, Korvin, edward, nh Maniphest Tasks: T2014 Differential Revision: https://secure.phabricator.com/D5451 Conflicts: src/__celerity_resource_map__.php
2013-07-02 21:14:33 +02:00
'DifferentialRevisionQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Modularize all DifferentialRevision fields Summary: Ref T8726. Make all the DifferentialRevision stuff modular. Test Plan: - Created a rule with all fields. - Ran upgrade. - Saw all fields preserved with new modular versions. - Used test console to run rule with all fields, verified field values as broadly sensible. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13598
2015-07-08 21:25:48 +02:00
'DifferentialRevisionRepositoryHeraldField' => 'DifferentialRevisionHeraldField',
'DifferentialRevisionRepositoryProjectsHeraldField' => 'DifferentialRevisionHeraldField',
'DifferentialRevisionReviewersHeraldField' => 'DifferentialRevisionHeraldField',
Use ApplicationSearch in Differential Summary: Ref T603. Ref T2625. Fixes T3241. Depends on D5451. Depends on D6346. @wez, this changes the Differential revision list UI substantially and may generate a lot of bikeshedding / who-moved-my-cheese churn. See T3417 for context, for example. The motivations for this change are: - The list now works on devices, like phones and tablets. This is a requirement to make the rest of Differential work on devices. - Although ApplicationSearch intentionally presents a simpler interface initially and some options which were one click away before aren't now, it is much more powerful than the search it replaces and allows users to build, save, share, fork, edit, and customize a much wider range of queries. Users who used the old filters frequently can use Advanced Search -> Save Custom Query to create new versions of them, and of any other query. "Edit Queries.." allows users to remove and reorder queries, including builtin queries. Basically, there are like three things which have gone from "1-click" to "a few clicks", and ten trillion things which have gone from "hard/impossible" to "relatively easy". The local screenshots look a bit iffy, but I think a lot of this is the fakenesss of my test data. If they still feel iffy in production we can tweak them until they feel good, like we did for Maniphest. Test Plan: {F48477} {F48478} Reviewers: btrahan, chad, wez Reviewed By: btrahan CC: aran, s Maniphest Tasks: T603, T2625, T3241 Differential Revision: https://secure.phabricator.com/D6347
2013-07-03 15:11:07 +02:00
'DifferentialRevisionSearchEngine' => 'PhabricatorApplicationSearchEngine',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DifferentialRevisionStatus' => 'Phobject',
Modularize all DifferentialRevision fields Summary: Ref T8726. Make all the DifferentialRevision stuff modular. Test Plan: - Created a rule with all fields. - Ran upgrade. - Saw all fields preserved with new modular versions. - Used test console to run rule with all fields, verified field values as broadly sensible. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13598
2015-07-08 21:25:48 +02:00
'DifferentialRevisionSummaryHeraldField' => 'DifferentialRevisionHeraldField',
'DifferentialRevisionTitleHeraldField' => 'DifferentialRevisionHeraldField',
DifferentialRevisionView
2011-01-27 23:55:52 +01:00
'DifferentialRevisionUpdateHistoryView' => 'AphrontView',
'DifferentialRevisionViewController' => 'DifferentialController',
Begin generating meaningful expected schemata Summary: Ref T1191. This lays some groundwork for generating the expected schemata, so we can compare them to the actual schemata and produce a meaningful diff. - In general, each application will subclass `PhabricatorConfigSchemaSpec` and provide a definition of the tables it expects. - This class has helper methods to mostly-automatically build table definitions for Lisk and (in the future) edges. - When building expected schema, we specify a "data type", like "epoch". This is the type of data the application stores in the column, from the application's point of view. The SchemaSpec converts this into the best avilable storage type: for example, "text" will translate to `utf8mb4` if it's availalbe, or `binary` if not. This gives us a layer of indirection to insulate us from craziness. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10497
2014-09-18 17:25:34 +02:00
'DifferentialSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DifferentialSetDiffPropertyConduitAPIMethod' => 'DifferentialConduitAPIMethod',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialStoredCustomField' => 'DifferentialCustomField',
Implement Differential subscribers as a CustomField Summary: Ref T3886. Now that a custom field can emit a core transaction, just emit a subscribers transaction. Test Plan: {F116014} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8289
2014-02-21 20:54:08 +01:00
'DifferentialSubscribersField' => 'DifferentialCoreCustomField',
Implement new-style "Summary" field Summary: Ref T3886. - Adds "Summary" field. - Adds "CoreField" for fields stored on the actual object, to reduce code duplication a bit for the main fields. Test Plan: {F115902} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8283
2014-02-21 20:52:52 +01:00
'DifferentialSummaryField' => 'DifferentialCoreCustomField',
Implement "Test Plan" as a CustomField Summary: Ref T3886. Moves some of the "required" logic to the base class ("DifferentialCoreField") so Title and Test Plan can share it. Test Plan: Edited revisions using "pro" editor, saw test plan transactions. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8285
2014-02-21 20:53:27 +01:00
'DifferentialTestPlanField' => 'DifferentialCoreCustomField',
Implement new-style "Summary" field Summary: Ref T3886. - Adds "Summary" field. - Adds "CoreField" for fields stored on the actual object, to reduce code duplication a bit for the main fields. Test Plan: {F115902} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8283
2014-02-21 20:52:52 +01:00
'DifferentialTitleField' => 'DifferentialCoreCustomField',
Add storage for new Differential transactions and transaction comments Summary: Ref T2222. Ref T1460. Depends on D6260. This creates the new tables, but doesn't start using them. I added three new fields for {T1460}, to represent fixed/done/replied states. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T1460, T2222 Differential Revision: https://secure.phabricator.com/D6261
2013-06-21 21:54:29 +02:00
'DifferentialTransaction' => 'PhabricatorApplicationTransaction',
'DifferentialTransactionComment' => 'PhabricatorApplicationTransactionComment',
Implement "Pro" version of revision editor, with one field Summary: Ref T3886. I spent a few hours trying to make `DifferentialFieldSpecification` extend `PhabricatorCustomField` so I could be more blunt in my approach here and just swap the whole thing over in one go (more or less like I did with Maniphest) but we have a ton of custom fields and things felt really shaky and the change was enormous and hard to keep track of. Instead, I'm going to do this more gradually and go field-by-field. This implements a CustomField version of the "Title" field. (There are no links to this in the UI.) Test Plan: {F115353} {F115354} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8276
2014-02-19 01:32:55 +01:00
'DifferentialTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
Migrate Differential comments to ApplicationTransactions Summary: Ref T2222. This is the big one. This migrates each `DifferentialComment` to one or more ApplicationTransactions (action, cc, reviewers, update, comment, inlines), and makes `DifferentialComment` a double-reader for ApplicationTransactions. The migration is pretty straightforward: - If a comment took an action not otherwise covered, it gets an "action" transaction. This is something like "epriestley abandoned this revision.". - If a comment updated the diff, it gets an "updated diff" transaction. Very old transactions of this type may not have a diff ID (probably only at Facebook). - If a comment added or removed reviewers, it gets a "changed reviewers" transaction. - If a comment added CCs, it gets a "subscribers" transaction. - If a comment added comment text, it gets a "comment" transaction. - For each inline attached to a comment, we generate an "inline" transaction. Most comments generate a small number of transactions, but a few generate a significant number. At HEAD, the code is basically already doing this, so comments in the last day or two already obey these rules, roughly, and will all generate only one transaction (except inlines). Because we've already preallocated PHIDs in the comment text table, we only need to write to the transaction table. NOTE: This significantly degrades Differential, making inline comments pretty much useless (they each get their own transaction, and don't show line numbers or files). The data is all fine, but the UI is garbage now. This needs to be fixed before we can deploy this to users, but it's easily separable since it's all just display code. Specifically, they look like this: {F112270} Test Plan: I've migrated locally and put things through their paces, but it's hard to catch sketchy stuff locally because most of my test data is nonsense and bad migrations wouldn't necessarily look out of place. IMPORTANT: I'm planning to push this to a branch and then shift production over to the branch, and run it for a day or two before bringing it to master. I generally feel good about this change: it's not that big since we were able to separate a lot of pieces out of it, and it's pretty straightforward. That said, it's still one of the most scary/dangerous changes we've ever made. Reviewers: btrahan CC: chad, aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8210
2014-02-12 00:36:58 +01:00
'DifferentialTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Use timeline view in Differential and make inlines somewhat usable again Summary: Ref T2222. This gets rid of Differential's custom view and uses a standard view instead. This also mostly fixes the rendering logic for inlines. This is headed to the `tmp.differential` branch. Test Plan: {F112696} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T1790, T2222 Differential Revision: https://secure.phabricator.com/D8215
2014-02-12 23:05:40 +01:00
'DifferentialTransactionView' => 'PhabricatorApplicationTransactionView',
Give unit test results their own table in Differential Summary: Ref T10457. This gives unit test results a more first-class treatment in the Differential UI, and consolidates some rendering code. Test Plan: Before: {F1135536} After: {F1135537} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15365
2016-02-29 18:53:46 +01:00
'DifferentialUnitField' => 'DifferentialCustomField',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DifferentialUnitStatus' => 'Phobject',
'DifferentialUnitTestResult' => 'Phobject',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DifferentialUpdateRevisionConduitAPIMethod' => 'DifferentialConduitAPIMethod',
Implement view and edit policies in Differential CustomFields Summary: Ref T3886. Ref T418. - Adds "View Policy" and "Edit Policy" fields. - Allows CustomFields to produce arbitrary types of transactions, so these fields can produce standard view/edit policy transactions and get all the strings and validation associated with them. Test Plan: {F116001} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T3886 Differential Revision: https://secure.phabricator.com/D8287
2014-02-21 20:53:48 +01:00
'DifferentialViewPolicyField' => 'DifferentialCoreCustomField',
Modernize "user, project or package" typeahead datasource Summary: Ref T4420. Call this "auditor" since that's what it is. Test Plan: - Edited auditors in auditor search. - Edited auditors in "add auditors" in Diffusion. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9888
2014-07-18 00:45:21 +02:00
'DiffusionAuditorDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Modernize Audit search engine Summary: Fixes T9279. Modernizes the SearchEngine and Query classes. User-facing changes: - Added order by commit date, default to order by commit date with newest commits first. - Added explicit "Needs Audit by". - Added new `packages(...)` typeahead function. - Picked up automatic subscribers, projects, and order fields. This changes behavior a little bit: we previously attempted to exclude, e.g., commits which a package you own needs to audit, but which you have resigned from. This is difficult in general and I think it needs a more comprehensive solution. This shouldn't impact users much, anyway. Test Plan: {F767628} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9279 Differential Revision: https://secure.phabricator.com/D14013
2015-08-31 19:17:54 +02:00
'DiffusionAuditorFunctionDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Modularize the Diffusion "Add Auditors" Herald action Ref T8726.
2015-08-03 15:01:24 +02:00
'DiffusionAuditorsAddAuditorsHeraldAction' => 'DiffusionAuditorsHeraldAction',
'DiffusionAuditorsAddSelfHeraldAction' => 'DiffusionAuditorsHeraldAction',
'DiffusionAuditorsHeraldAction' => 'HeraldAction',
Implement a dedicated "diffusion.blame" API method Summary: Fixes T2451. Several motivations here, from strongest to weakest: - Currently, getting blame and file content are closely entwined. This makes fixing T9319 more difficult, and I want to fix it. I want to separate blame from content so there's more flexibility in how we approach this issue. - This makes pursuing T2450 easier, if it turns out to be a meaningful win. - If we can get a win on blame performance, we can do `arc blame` eventually if we want. Test Plan: - Blamed in SVN, Git and Mercurial. Reviewers: chad Reviewed By: chad Maniphest Tasks: T2451 Differential Revision: https://secure.phabricator.com/D14957
2016-01-06 13:56:27 +01:00
'DiffusionBlameConduitAPIMethod' => 'DiffusionQueryConduitAPIMethod',
'DiffusionBlameQuery' => 'DiffusionQuery',
Modularize the Diffusion/Differential "Block" Herald actions Also removes HeraldCustomAction. This completes action modularization. Ref T8726.
2015-08-03 21:54:40 +02:00
'DiffusionBlockHeraldAction' => 'HeraldAction',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionBranchQueryConduitAPIMethod' => 'DiffusionQueryConduitAPIMethod',
Branch view improvements. Summary: Sorting by last commit date Branch view limit to 25 branches All branches table page with pagination on Git Test Plan: * Check repository view for expected behavior on branch table view * Check all branches page & test pagination Reviewers: epriestley Reviewed By: epriestley CC: aran, Koolvin Maniphest Tasks: T1200 Differential Revision: https://secure.phabricator.com/D2442
2012-05-10 09:28:19 +02:00
'DiffusionBranchTableController' => 'DiffusionController',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionBranchTableView' => 'DiffusionView',
Diffusion: basic browse view Summary: Synthesizes elements of Diffusion's browse view, Confusion's git support and Phabricator's repository infrastructure to provide a basic browse view for Phabricator Diffusion. This is basically a straight port of Confusion but uses Phabricator's Repository object and uses a real data object instead of arrays. Test Plan: Browsed Javelin in Phabricator at a very basic level. Reviewed By: jwilson Reviewers: aran, jwilson CC: jwilson, epriestley Differential Revision: 58
2011-03-08 02:25:47 +01:00
'DiffusionBrowseController' => 'DiffusionController',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionBrowseQueryConduitAPIMethod' => 'DiffusionQueryConduitAPIMethod',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DiffusionBrowseResultSet' => 'Phobject',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionBrowseTableView' => 'DiffusionView',
Provide a fast path for resolving repository refs Summary: Ref T2783. With service-oriented calls, we take a larger performacne hit than necessary resolving refs. Instead of resolving refs over the wire, try to resolve them from the database first. This can resolve almost all refs (commit hashes, branch and tag names). This can't resolve weird refs like `master~50`, and obviously can't resolve invalid refs. In those cases we'll go back to the old logic, call `diffusion.resolverefs`, and end up with the right result. Test Plan: - Browsed repositories in Diffusion. - Verified that service repositories no longer make unnecessary `diffusion.resolverefs` calls for common refs (branch names, commit hashes). - Resolved refs like `master~50`, saw call to underlying VCS and correct result. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2783 Differential Revision: https://secure.phabricator.com/D11476
2015-01-23 22:31:17 +01:00
'DiffusionCachedResolveRefsQuery' => 'DiffusionLowLevelQuery',
Browse / git improvements.
2011-03-14 06:03:30 +01:00
'DiffusionChangeController' => 'DiffusionController',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'DiffusionChangeHeraldFieldGroup' => 'HeraldFieldGroup',
Extract repository command construction from Repositories Summary: Ref T4292. Ref T10366. Depends on D15751. Today, generating repository commands is purely a function of the repository, so they use protocols and credentials based on the repository configuration. For example, a repository with an SSH "remote URI" always generate SSH "remote commands". This needs to change in the future: - After T10366, repositories won't necessarily just have one type of remote URI. They can only have one at a time still, but the repository itself won't change based on which one is currently active. - For T4292, I need to generate intracluster commands, regardless of repository configuration. These will have different protocols and credentials. Prepare for these cases by separating out command construction, so they'll be able to generate commands in a more flexible way. Test Plan: - Added unit tests. - Browsed diffusion. - Ran `bin/phd debug pull` to pull a bunch of repos. - Ran daemons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4292, T10366 Differential Revision: https://secure.phabricator.com/D15752
2016-04-19 00:22:52 +02:00
'DiffusionCommandEngine' => 'Phobject',
'DiffusionCommandEngineTestCase' => 'PhabricatorTestCase',
Modularize all Diffusion commit Herald fields Summary: Ref T8726. Test Plan: Created a giant rule with every commit field: {F594686} Ran the upgrade, got the same rule with new fields: {F594688} Used "Test Console" to run transcripts, saw all the fields populate correctly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13567
2015-07-07 20:53:17 +02:00
'DiffusionCommitAffectedFilesHeraldField' => 'DiffusionCommitHeraldField',
'DiffusionCommitAuthorHeraldField' => 'DiffusionCommitHeraldField',
'DiffusionCommitAutocloseHeraldField' => 'DiffusionCommitHeraldField',
Load commit branches and tags by AJAX Summary: Each query takes over 2 seconds in FBCODE. I didn't find a way how to speed them up. There's also no easy way how to parallelize them at least. So AJAX is the last instance. Test Plan: Loaded commit with one branch and no tag. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3112
2012-08-01 01:27:48 +02:00
'DiffusionCommitBranchesController' => 'DiffusionController',
Modularize all Diffusion commit Herald fields Summary: Ref T8726. Test Plan: Created a giant rule with every commit field: {F594686} Ran the upgrade, got the same rule with new fields: {F594688} Used "Test Console" to run transcripts, saw all the fields populate correctly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13567
2015-07-07 20:53:17 +02:00
'DiffusionCommitBranchesHeraldField' => 'DiffusionCommitHeraldField',
'DiffusionCommitCommitterHeraldField' => 'DiffusionCommitHeraldField',
Increase parseriness of some parsery things. Summary: None of these are parsnips. Test Plan: Reviewers: CC:
2011-03-11 18:34:22 +01:00
'DiffusionCommitController' => 'DiffusionController',
Modularize all Diffusion commit Herald fields Summary: Ref T8726. Test Plan: Created a giant rule with every commit field: {F594686} Ran the upgrade, got the same rule with new fields: {F594688} Used "Test Console" to run transcripts, saw all the fields populate correctly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13567
2015-07-07 20:53:17 +02:00
'DiffusionCommitDiffContentAddedHeraldField' => 'DiffusionCommitHeraldField',
'DiffusionCommitDiffContentHeraldField' => 'DiffusionCommitHeraldField',
'DiffusionCommitDiffContentRemovedHeraldField' => 'DiffusionCommitHeraldField',
'DiffusionCommitDiffEnormousHeraldField' => 'DiffusionCommitHeraldField',
Allow commits to be associated with projects and associated goodies Summary: - Commit detail view - List of projects - "edit" action which takes the user to a simple form where they can only add / remove projects. - Integrated the project relationship into the commit search indexer - fixed a bug from D790; it seems you must select the column if you're going to join against it later. Without this change searching for author or projectfails 100% for me. Test Plan: added and removed projects. verified appropriate projects showed up in detail and edit view. searched for commits by project and found the ones I was supposed to...! Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1614 Differential Revision: https://secure.phabricator.com/D3189
2012-08-08 19:03:41 +02:00
'DiffusionCommitEditController' => 'DiffusionController',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'DiffusionCommitFulltextEngine' => 'PhabricatorFulltextEngine',
Migrate Differential revision edges to use modern `EdgeType` subclasses Summary: Modernize Differential edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: From previous experience, these changes are fairly trivial and safe. I poked around a little to make sure things looked reasonably okay. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, Krenair, epriestley Differential Revision: https://secure.phabricator.com/D11074
2015-01-01 04:43:26 +01:00
'DiffusionCommitHasRevisionEdgeType' => 'PhabricatorEdgeType',
Modernize commit/edge transaction when parsing commit messages Summary: Ref T5245. With work elsewhere (notably, D9839) we can remove this TODO and use real transactions. Test Plan: Pushed a `closes Txxx` commit and got a close + transaction. Reviewers: chad, btrahan, joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5245 Differential Revision: https://secure.phabricator.com/D9848
2014-07-18 00:42:06 +02:00
'DiffusionCommitHasTaskEdgeType' => 'PhabricatorEdgeType',
Move commit hash querying to DiffusionLowLevelCommitQuery Summary: Ref T4195. I need this for the Herald pre-commit rules, and it generally simplifies things. Test Plan: Used `reparse.php` plus `var_dump()` to inspect refs in Git, Mercurial and SVN repos. They all looked correct and reparsed correctly. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7804
2013-12-20 21:38:15 +01:00
'DiffusionCommitHash' => 'Phobject',
Modularize all Diffusion commit Herald fields Summary: Ref T8726. Test Plan: Created a giant rule with every commit field: {F594686} Ran the upgrade, got the same rule with new fields: {F594688} Used "Test Console" to run transcripts, saw all the fields populate correctly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13567
2015-07-07 20:53:17 +02:00
'DiffusionCommitHeraldField' => 'HeraldField',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'DiffusionCommitHeraldFieldGroup' => 'HeraldFieldGroup',
Install pre-commit hooks in Git repositories Summary: Ref T4189. T4189 describes most of the intent here: - When updating hosted repositories, sync a pre-commit hook into them instead of doing a `git fetch`. - The hook calls into Phabricator. The acting Phabricator user is sent via PHABRICATOR_USER in the environment. The active repository is sent via CLI. - The hook doesn't do anything useful yet; it just veifies basic parameters, does a little parsing, and exits 0 to allow the commit. Test Plan: - Performed Git pushes and pulls over SSH and HTTP. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4189 Differential Revision: https://secure.phabricator.com/D7682
2013-12-03 00:45:36 +01:00
'DiffusionCommitHookEngine' => 'Phobject',
Reject dangerous changes in Git repositories by default Summary: Ref T4189. This adds a per-repository "dangerous changes" flag, which defaults to off. This flag must be enabled to do non-appending branch mutation (delete branches / rewrite history). Test Plan: With flag on and off, performed various safe and dangerous pushes. >>> orbital ~/repos/POEMS $ git push origin :blarp remote: +---------------------------------------------------------------+ remote: | * * * PUSH REJECTED BY EVIL DRAGON BUREAUCRATS * * * | remote: +---------------------------------------------------------------+ remote: \ remote: \ ^ /^ remote: \ / \ // \ remote: \ |\___/| / \// .\ remote: \ /V V \__ / // | \ \ *----* remote: / / \/_/ // | \ \ \ | remote: @___@` \/_ // | \ \ \/\ \ remote: 0/0/| \/_ // | \ \ \ \ remote: 0/0/0/0/| \/// | \ \ | | remote: 0/0/0/0/0/_|_ / ( // | \ _\ | / remote: 0/0/0/0/0/0/`/,_ _ _/ ) ; -. | _ _\.-~ / / remote: ,-} _ *-.|.-~-. .~ ~ remote: \ \__/ `/\ / ~-. _ .-~ / remote: \____(Oo) *. } { / remote: ( (--) .----~-.\ \-` .~ remote: //__\\ \ DENIED! ///.----..< \ _ -~ remote: // \\ ///-._ _ _ _ _ _ _{^ - - - - ~ remote: remote: remote: DANGEROUS CHANGE: The change you're attempting to push deletes the branch 'blarp'. remote: Dangerous change protection is enabled for this repository. remote: Edit the repository configuration before making dangerous changes. remote: To ssh://dweller@localhost/diffusion/POEMS/ ! [remote rejected] blarp (pre-receive hook declined) error: failed to push some refs to 'ssh://dweller@localhost/diffusion/POEMS/' Reviewers: btrahan Reviewed By: btrahan CC: aran, chad, richardvanvelzen Maniphest Tasks: T4189 Differential Revision: https://secure.phabricator.com/D7689
2013-12-03 19:28:39 +01:00
'DiffusionCommitHookRejectException' => 'Exception',
Add "Is merge commit?" to commit fields in Herald Summary: Fixes T5788. We already have this as a pre-commit field, add it as a post-commit field too. Test Plan: Ran this rule on a merge commit. Also ran it on a non-merge commit. Both got the correct value. Reviewers: avivey, chad Reviewed By: avivey, chad Subscribers: avivey Maniphest Tasks: T5788 Differential Revision: https://secure.phabricator.com/D14685
2015-12-05 21:54:51 +01:00
'DiffusionCommitMergeHeraldField' => 'DiffusionCommitHeraldField',
Modularize all Diffusion commit Herald fields Summary: Ref T8726. Test Plan: Created a giant rule with every commit field: {F594686} Ran the upgrade, got the same rule with new fields: {F594688} Used "Test Console" to run transcripts, saw all the fields populate correctly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13567
2015-07-07 20:53:17 +02:00
'DiffusionCommitMessageHeraldField' => 'DiffusionCommitHeraldField',
'DiffusionCommitPackageAuditHeraldField' => 'DiffusionCommitHeraldField',
'DiffusionCommitPackageHeraldField' => 'DiffusionCommitHeraldField',
'DiffusionCommitPackageOwnerHeraldField' => 'DiffusionCommitHeraldField',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionCommitParentsQueryConduitAPIMethod' => 'DiffusionQueryConduitAPIMethod',
Prepare Diffusion for hovercards Summary: Move Diffusion to be hovercard-ready, and expand our ability to resolve commit references. - Link unqualified hashes of 7 characters or more which match a commit. - Link qualified hashes of 5 characters or more which match a commit. - Support `{...}` syntax. Test Plan: {F33896} Reviewers: chad, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5121
2013-02-27 17:04:54 +01:00
'DiffusionCommitQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Move git commit metadata parsing into a LowLevelQuery Summary: Ref T4195. I need to issue this command from the pre-commit hook to get commit bodies for hooks. Test Plan: Ran `reparse.php --message --trace` and dumped the $ref, which looked correct. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7793
2013-12-19 02:48:06 +01:00
'DiffusionCommitRef' => 'Phobject',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'DiffusionCommitRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Fix an issue with tail parsing in object embeds in remarkup Summary: Fixes T6619. In `{Xnnn key=value, key=value}` we did not require a separator between the object and the key-value part. This could lead to `{rX11aaa}` being parsed as `{rX11 aaa}`, i.e. a reference to `rX11` with parameter `aaa` set. Instead, require a space or comma before we'll parse key-value parts of embedded objects. Test Plan: Added and executed unit tests. {F242002} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6619 Differential Revision: https://secure.phabricator.com/D10915
2014-12-02 03:48:20 +01:00
'DiffusionCommitRemarkupRuleTestCase' => 'PhabricatorTestCase',
Modularize all Diffusion commit Herald fields Summary: Ref T8726. Test Plan: Created a giant rule with every commit field: {F594686} Ran the upgrade, got the same rule with new fields: {F594688} Used "Test Console" to run transcripts, saw all the fields populate correctly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13567
2015-07-07 20:53:17 +02:00
'DiffusionCommitRepositoryHeraldField' => 'DiffusionCommitHeraldField',
'DiffusionCommitRepositoryProjectsHeraldField' => 'DiffusionCommitHeraldField',
Write edges for commit reverts Summary: Ref T1751. When a commit reverts another commit: - Add an edge linking them; - Show the edge in Diffusion. Next steps are: - If the reverted commit is associated with a Differential revision, leave a comment; - Also leave a comment on the commit (no API yet); - Also trigger an audit by the original commit's author. Test Plan: Used `scripts/repository/reparse.php --message ...` to parse commits with revert language. Verified they appear correctly in Diffusion, and update Differential. Reviewers: btrahan, epriestley Reviewed By: btrahan, epriestley Subscribers: Korvin, epriestley, cburroughs, joshuaspence, sascha-egerer, aran Maniphest Tasks: T4896, T1751 Differential Revision: https://secure.phabricator.com/D5846
2015-01-04 20:52:38 +01:00
'DiffusionCommitRevertedByCommitEdgeType' => 'PhabricatorEdgeType',
'DiffusionCommitRevertsCommitEdgeType' => 'PhabricatorEdgeType',
Modularize all Diffusion commit Herald fields Summary: Ref T8726. Test Plan: Created a giant rule with every commit field: {F594686} Ran the upgrade, got the same rule with new fields: {F594688} Used "Test Console" to run transcripts, saw all the fields populate correctly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13567
2015-07-07 20:53:17 +02:00
'DiffusionCommitReviewerHeraldField' => 'DiffusionCommitHeraldField',
'DiffusionCommitRevisionAcceptedHeraldField' => 'DiffusionCommitHeraldField',
'DiffusionCommitRevisionHeraldField' => 'DiffusionCommitHeraldField',
'DiffusionCommitRevisionReviewersHeraldField' => 'DiffusionCommitHeraldField',
'DiffusionCommitRevisionSubscribersHeraldField' => 'DiffusionCommitHeraldField',
Load commit branches and tags by AJAX Summary: Each query takes over 2 seconds in FBCODE. I didn't find a way how to speed them up. There's also no easy way how to parallelize them at least. So AJAX is the last instance. Test Plan: Loaded commit with one branch and no tag. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3112
2012-08-01 01:27:48 +02:00
'DiffusionCommitTagsController' => 'DiffusionController',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionConduitAPIMethod' => 'ConduitAPIMethod',
Rough version of DiffusionHomeController Summary: My strategy here is to synthesize Diffusion + Confusion (jwilson's git support for Diffusion) + Repository/Commit stuff into Phabricator and kill all birds with one stone. This probably involves the least total work since we have to do this port step anyway and a lot of the Phabricator primitives are in better shape than the trunk primitives. Test Plan: Looked at it in my sandbox, which has some parsed commits. Reviewers: jwilson, aran, jungejason CC: Differential Revision: 57
2011-03-08 00:13:36 +01:00
'DiffusionController' => 'PhabricatorController',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionCreateCommentConduitAPIMethod' => 'DiffusionConduitAPIMethod',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'DiffusionCreateRepositoriesCapability' => 'PhabricatorPolicyCapability',
'DiffusionDefaultEditCapability' => 'PhabricatorPolicyCapability',
'DiffusionDefaultPushCapability' => 'PhabricatorPolicyCapability',
'DiffusionDefaultViewCapability' => 'PhabricatorPolicyCapability',
Rough cut of Diffusion change view.
2011-03-31 02:36:16 +02:00
'DiffusionDiffController' => 'DiffusionController',
Extend TransactionCommentQuery for Diffusion Summary: Ref T2009. Ref T1460. Reduces the amount of garbage involved in loading inline comments and routes more pathways through the proper Query layer. Test Plan: Viewed, edited, previewed, submitted inline comments in Diffusion. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2009, T1460 Differential Revision: https://secure.phabricator.com/D12028
2015-03-09 20:50:33 +01:00
'DiffusionDiffInlineCommentQuery' => 'PhabricatorDiffInlineCommentQuery',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionDiffQueryConduitAPIMethod' => 'DiffusionQueryConduitAPIMethod',
Add commits/audits to Asana bridge Summary: Ref T2852. Adds sync for commits/audits. Test Plan: {F51660} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6573
2013-07-26 19:31:35 +02:00
'DiffusionDoorkeeperCommitFeedStoryPublisher' => 'DoorkeeperFeedStoryPublisher',
Add remarkup.process conduit method Summary: This exposes a few remarkup engines over conduit. Test Plan: Local conduit console, and playing with 'cat example.json | arc call-conduit remarkup.process' Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1551
2012-02-03 01:42:29 +01:00
'DiffusionEmptyResultView' => 'DiffusionView',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionExistsQueryConduitAPIMethod' => 'DiffusionQueryConduitAPIMethod',
Improve Diffusion behavior for externals Summary: - Feature request from Airtime that I missed in the feedback notes, came up yesterday. - Identify git submodules as "FILE_SUBMODULE", not "FILE_NORMAL". - Link git submodules to an external resolver endpoint, which tries to find commits in tracked repositories. - Identify git symlinks as "FILE_SYMLINK", not "FILE_NORMAL". - Add folder, file, symlink and externals icons. Test Plan: - externals/javelin is now identified as a submoudule and links to Javelin, not identified as a file and links to error. - bin/phd is now identified as a symlink. - Interfaces have pretty icons. Reviewers: btrahan, cpiro, ddfisher, keebuhm, allenjohnashton Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1975
2012-03-21 22:01:20 +01:00
'DiffusionExternalController' => 'DiffusionController',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DiffusionExternalSymbolQuery' => 'Phobject',
'DiffusionExternalSymbolsSource' => 'Phobject',
More Drydock Stuff Summary: - Still really really rough. - Adds a full synchronous mode for debugging. - Adds some logging. - It can now allocate EC2 machines and put webroots on them in a hacky, terrible way. - Adds a base query class. Test Plan: oh hey look a test page? http://ec2-50-18-65-151.us-west-1.compute.amazonaws.com:2011/ Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D2026
2012-03-27 05:54:26 +02:00
'DiffusionFileContentQuery' => 'DiffusionQuery',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionFileContentQueryConduitAPIMethod' => 'DiffusionQueryConduitAPIMethod',
'DiffusionFindSymbolsConduitAPIMethod' => 'DiffusionConduitAPIMethod',
'DiffusionGetLintMessagesConduitAPIMethod' => 'DiffusionConduitAPIMethod',
'DiffusionGetRecentCommitsByPathConduitAPIMethod' => 'DiffusionConduitAPIMethod',
Implement a dedicated "diffusion.blame" API method Summary: Fixes T2451. Several motivations here, from strongest to weakest: - Currently, getting blame and file content are closely entwined. This makes fixing T9319 more difficult, and I want to fix it. I want to separate blame from content so there's more flexibility in how we approach this issue. - This makes pursuing T2450 easier, if it turns out to be a meaningful win. - If we can get a win on blame performance, we can do `arc blame` eventually if we want. Test Plan: - Blamed in SVN, Git and Mercurial. Reviewers: chad Reviewed By: chad Maniphest Tasks: T2451 Differential Revision: https://secure.phabricator.com/D14957
2016-01-06 13:56:27 +01:00
'DiffusionGitBlameQuery' => 'DiffusionBlameQuery',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DiffusionGitBranch' => 'Phobject',
DiffusionBranchQuery => Conduit Summary: ref T2784. This one had a few fun spots where I had to move data around. Also, is there some common object (or should I add it?) that can do this toDictionary newFromConduit stuff? Also, this assumes D5803 is largely correct at the time of this diff. Test Plan: browsed mercurial and git repository page. saw the branches i expected. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5810
2013-05-01 23:56:36 +02:00
'DiffusionGitBranchTestCase' => 'PhabricatorTestCase',
Extract repository command construction from Repositories Summary: Ref T4292. Ref T10366. Depends on D15751. Today, generating repository commands is purely a function of the repository, so they use protocols and credentials based on the repository configuration. For example, a repository with an SSH "remote URI" always generate SSH "remote commands". This needs to change in the future: - After T10366, repositories won't necessarily just have one type of remote URI. They can only have one at a time still, but the repository itself won't change based on which one is currently active. - For T4292, I need to generate intracluster commands, regardless of repository configuration. These will have different protocols and credentials. Prepare for these cases by separating out command construction, so they'll be able to generate commands in a more flexible way. Test Plan: - Added unit tests. - Browsed diffusion. - Ran `bin/phd debug pull` to pull a bunch of repos. - Ran daemons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4292, T10366 Differential Revision: https://secure.phabricator.com/D15752
2016-04-19 00:22:52 +02:00
'DiffusionGitCommandEngine' => 'DiffusionCommandEngine',
Diffusion: basic file browse capability Summary: Very rough cut of file browsing. Not terribly useful yet, but it does cause file data to appear in the browser window. Test Plan: viewed a file from a git repo Reviewed By: jwilson Reviewers: aran, jwilson CC: jwilson Differential Revision: 64
2011-03-08 18:54:55 +01:00
'DiffusionGitFileContentQuery' => 'DiffusionFileContentQuery',
Implement "git-lfs-authenticate" over SSH Summary: Ref T7789. This implements a (probably) usable "git-lfs-authenticate" on top of the new temporary token infrastructure. This won't actually do anything yet, since nothing reads the tokens. Test Plan: ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate' phabricator-ssh-exec: Expected `git-lfs-authenticate <path> <operation>`, but received too few arguments. ``` ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate x' phabricator-ssh-exec: Unrecognized repository path "x". Expected a path like "/diffusion/X/" or "/diffusion/123/". ``` ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate diffusion/22' Exception: Expected `git-lfs-authenticate <path> <operation>`, but received too few arguments. ``` ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate diffusion/22 y' Exception: Git LFS operation "y" is not supported by this server. ``` ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate diffusion/22 upload' {"header":{"Authorization":"Basic QGdpdC1sZnM6NmR2bDVreWVsaXNuMmtnNXBtbnZwM3VlaWhubmI1bmI="},"href":"http:\/\/local.phacility.com\/diffusion\/22\/new-callsign-free-repository.git\/info\/lfs"} ``` Reviewers: chad Reviewed By: chad Maniphest Tasks: T7789 Differential Revision: https://secure.phabricator.com/D15482
2016-03-16 15:44:25 +01:00
'DiffusionGitLFSAuthenticateWorkflow' => 'DiffusionGitSSHWorkflow',
Implement a Git LFS server which supports no operations Summary: Ref T7789. This builds on top of `git-lfs-authenticate` to detect LFS requests, read LFS tokens, and route them to a handler which can do useful things. This handler promptly drops them on the floor with an error message. Test Plan: Here's a transcript showing the parts working together so far: - `git-lfs` connects to the server with SSH, and gets told how to connect with HTTP to do uploads. - `git-lfs` uses HTTP, and authenticates with the tokens properly. - But the server tells it to go away, and that it doesn't support anything, so the operation ultimately fails. ``` $ GIT_TRACE=1 git lfs push origin master 12:45:56.153913 git.c:558 trace: exec: 'git-lfs' 'push' 'origin' 'master' 12:45:56.154376 run-command.c:335 trace: run_command: 'git-lfs' 'push' 'origin' 'master' trace git-lfs: Upload refs origin to remote [master] trace git-lfs: run_command: git rev-list --objects master --not --remotes=origin trace git-lfs: run_command: git cat-file --batch-check trace git-lfs: run_command: git cat-file --batch trace git-lfs: run_command: 'git' config -l trace git-lfs: tq: starting 3 transfer workers trace git-lfs: tq: running as batched queue, batch size of 100 trace git-lfs: prepare upload: b7e0aeb82a03d627c6aa5fc1bbfd454b6789d9d9affc8607d40168fa18cf6c69 lfs/dog1.jpg 1/1 trace git-lfs: tq: sending batch of size 1 trace git-lfs: ssh: local@localvault.phacility.com git-lfs-authenticate diffusion/18/poems.git upload trace git-lfs: api: batch 1 files trace git-lfs: HTTP: POST http://local.phacility.com/diffusion/POEMS/poems.git/info/lfs/objects/batch trace git-lfs: HTTP: 404 trace git-lfs: HTTP: {"message":"Git LFS operation \"objects\/batch\" is not supported by this server."} trace git-lfs: HTTP: trace git-lfs: api: batch not implemented: 404 trace git-lfs: run_command: 'git' config lfs.batch false trace git-lfs: tq: batch api not implemented, falling back to individual trace git-lfs: ssh: local@localvault.phacility.com git-lfs-authenticate diffusion/18/poems.git upload b7e0aeb82a03d627c6aa5fc1bbfd454b6789d9d9affc8607d40168fa18cf6c69 trace git-lfs: api: uploading (b7e0aeb82a03d627c6aa5fc1bbfd454b6789d9d9affc8607d40168fa18cf6c69) trace git-lfs: HTTP: POST http://local.phacility.com/diffusion/POEMS/poems.git/info/lfs/objects trace git-lfs: HTTP: 404 trace git-lfs: HTTP: {"message":"Git LFS operation \"objects\" is not supported by this server."} trace git-lfs: HTTP: trace git-lfs: tq: retrying 1 failed transfers trace git-lfs: ssh: local@localvault.phacility.com git-lfs-authenticate diffusion/18/poems.git upload b7e0aeb82a03d627c6aa5fc1bbfd454b6789d9d9affc8607d40168fa18cf6c69 trace git-lfs: api: uploading (b7e0aeb82a03d627c6aa5fc1bbfd454b6789d9d9affc8607d40168fa18cf6c69) trace git-lfs: HTTP: POST http://local.phacility.com/diffusion/POEMS/poems.git/info/lfs/objects trace git-lfs: HTTP: 404 trace git-lfs: HTTP: {"message":"Git LFS operation \"objects\" is not supported by this server."} trace git-lfs: HTTP: Git LFS: (0 of 1 files) 0 B / 87.12 KB Git LFS operation "objects" is not supported by this server. Git LFS operation "objects" is not supported by this server. ``` Reviewers: chad Reviewed By: chad Subscribers: eadler Maniphest Tasks: T7789 Differential Revision: https://secure.phabricator.com/D15485
2016-03-16 20:42:21 +01:00
'DiffusionGitLFSResponse' => 'AphrontResponse',
Implement "git-lfs-authenticate" over SSH Summary: Ref T7789. This implements a (probably) usable "git-lfs-authenticate" on top of the new temporary token infrastructure. This won't actually do anything yet, since nothing reads the tokens. Test Plan: ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate' phabricator-ssh-exec: Expected `git-lfs-authenticate <path> <operation>`, but received too few arguments. ``` ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate x' phabricator-ssh-exec: Unrecognized repository path "x". Expected a path like "/diffusion/X/" or "/diffusion/123/". ``` ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate diffusion/22' Exception: Expected `git-lfs-authenticate <path> <operation>`, but received too few arguments. ``` ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate diffusion/22 y' Exception: Git LFS operation "y" is not supported by this server. ``` ``` $ ./bin/ssh-exec --phabricator-ssh-user admin --ssh-command 'git-lfs-authenticate diffusion/22 upload' {"header":{"Authorization":"Basic QGdpdC1sZnM6NmR2bDVreWVsaXNuMmtnNXBtbnZwM3VlaWhubmI1bmI="},"href":"http:\/\/local.phacility.com\/diffusion\/22\/new-callsign-free-repository.git\/info\/lfs"} ``` Reviewers: chad Reviewed By: chad Maniphest Tasks: T7789 Differential Revision: https://secure.phabricator.com/D15482
2016-03-16 15:44:25 +01:00
'DiffusionGitLFSTemporaryTokenType' => 'PhabricatorAuthTemporaryTokenType',
Add "DiffusionRawDiffQuery" Summary: - This is only slightly useful for updating Differential, since DiffQuery (vs RawDiffQuery) already gets you most of what you need. The only thing is that DiffQuery returns the diff for one path only right now(and the SVN version is very "special"). Should be easy to fix in the Git/HG cases at least, though (or maybe just use RawDiffQuery to avoid the SVN mess). - Added a "download raw diff" link. Test Plan: Viewed Diffusion and raw commits for SVN, Mercurial and Git repositories. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2350
2012-05-02 22:43:45 +02:00
'DiffusionGitRawDiffQuery' => 'DiffusionRawDiffQuery',
Rename `DiffusionSSHWorkflow` subclasses for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11185
2015-01-04 20:33:18 +01:00
'DiffusionGitReceivePackSSHWorkflow' => 'DiffusionGitSSHWorkflow',
Diffusion: encapsulate request in DiffusionRequest Summary: Put an indirection layer between controllers and URI management, adding branches to git repositories. Test Plan: Looked at browse, history browse, file browse views, bad branches, bad commits Reviewed By: jwilson Reviewers: aran, jwilson CC: jwilson, epriestley Differential Revision: 65
2011-03-08 23:29:02 +01:00
'DiffusionGitRequest' => 'DiffusionRequest',
Serve Git reads over HTTP Summary: Mostly ripped from D7391. No writes yet. Test Plan: Ran `git clone` against a local over HTTP, got a clone. Reviewers: btrahan, hach-que Reviewed By: hach-que CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7423
2013-10-26 21:10:52 +02:00
'DiffusionGitResponse' => 'AphrontResponse',
Make cluster repositories more chatty Summary: Ref T10860. At least in Git over SSH, we can freely echo a bunch of stuff to stderr and Git will print it to the console, so we can tell users what's going on. This should make debugging, etc., easier. We could tone this down a little bit once things are more stable if it's a little too chatty. Test Plan: ``` $ echo D >> record && git commit -am D && git push [master ca5efff] D 1 file changed, 1 insertion(+) # Push received by "local001.phacility.net", forwarding to cluster host. # Waiting up to 120 second(s) for a cluster write lock... # Acquired write lock immediately. # Waiting up to 120 second(s) for a cluster read lock on "local001.phacility.net"... # Acquired read lock immediately. # Device "local001.phacility.net" is already a cluster leader and does not need to be synchronized. # Ready to receive on cluster host "local001.phacility.net". Counting objects: 3, done. Delta compression using up to 8 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 256 bytes | 0 bytes/s, done. Total 3 (delta 1), reused 0 (delta 0) To ssh://local@localvault.phacility.com/diffusion/26/locktopia.git 8616189..ca5efff master -> master ``` Reviewers: chad Reviewed By: chad Maniphest Tasks: T10860 Differential Revision: https://secure.phabricator.com/D15791
2016-04-24 18:49:18 +02:00
'DiffusionGitSSHWorkflow' => array(
'DiffusionSSHWorkflow',
'DiffusionRepositoryClusterEngineLogInterface',
),
Rename `DiffusionSSHWorkflow` subclasses for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11185
2015-01-04 20:33:18 +01:00
'DiffusionGitUploadPackSSHWorkflow' => 'DiffusionGitSSHWorkflow',
Diffusion: rough cut of history view Summary: Very very rough approximation of history view. I left out all the log parsing stuff for now since we should be able to just look it up in a Repository table and I think that'll be a bit faster, although we can muck around and see. Test Plan: Looked at history of a path Reviewed By: jwilson Reviewers: aran, jwilson CC: epriestley, jwilson Differential Revision: 66
2011-03-09 02:31:44 +01:00
'DiffusionHistoryController' => 'DiffusionController',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionHistoryQueryConduitAPIMethod' => 'DiffusionQueryConduitAPIMethod',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionHistoryTableView' => 'DiffusionView',
Modernize Hovercard implementation Summary: Ref T8980. Move away from events to EngineExtensions. This also simplifies hovercards a bit: - Removes tasks from revision cards. - Removes blockers/blocked from task cards. - Removes "Send Message" from user cards. These mostly felt cluttery to me. Open to arguments to retain them. I think we can make better use of the space, though (e.g., flags, projects + board columns). Test Plan: - Viewed people, task, revision, commit and project hovercards. {F1043256} {F1043257} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8980 Differential Revision: https://secure.phabricator.com/D14878
2015-12-24 20:20:18 +01:00
'DiffusionHovercardEngineExtension' => 'PhabricatorHovercardEngineExtension',
Add inline comments to Diffusion/Audit Summary: - Add inline comments to Audits, like Differential. - Creates new storage for the comments in the Audits database. - Creates a new PhabricatorAuditInlineComment class, similar to DifferentialInlineComment. - Defines an Interface which Differential and Audit comments conform to. - Makes consumers of DifferentialInlineComments consume objects which implement that interface instead. - Adds save NOTE: Some features are still missing! Wanted to cut this off before it got crazy: - Inline comments aren't shown in the main comment list. - Inline comments aren't shown in the emails. - Inline comments aren't previewed. I'll followup with those but this was getting pretty big. @vrana, does the SQL change look correct? Test Plan: - Created, edited, deleted, replied to, reloaded and saved inline comments in Diffusion, on the left and right side of diffs. - Created, edited, deleted, replied to, reloaded and saved inline comments in Differentila, on the left and right side of primary and diff-versus-diff diffs. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1898
2012-03-14 20:56:01 +01:00
'DiffusionInlineCommentController' => 'PhabricatorInlineCommentController',
Make inline comment preview work in Diffusion Summary: created a PhabricatorInlineCommentPreviewController so controllers in Diffusion and Differential respectively just have to handle the URI mapping and data loading like good little controllers. Test Plan: left inline comments on commits, deleted inline commits, submitted inline comments -- all worked well did the same on some diffs Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1176 Differential Revision: https://secure.phabricator.com/D3034
2012-07-23 20:01:28 +02:00
'DiffusionInlineCommentPreviewController' => 'PhabricatorInlineCommentPreviewController',
Use Conduit in PhabricatorRepositoryGitCommitChangeParserWorker Summary: Ref T2783. This allows this worker to run on a machine different to the one that stores the repository, by routing the execution of Git over Conduit calls. This API method is super gross, but fixing it isn't straightforward and it runs into other complicated considerations. We can fix it later; for now, just define it as "internal" to limit how much mess this creates. "Internal" methods do not appear on the console. Test Plan: Ran `bin/repository reparse --change <commit> --trace` on several commits, saw daemons make a Conduit call instead of running a `git` command. Reviewers: hach-que, chad Reviewed By: chad Subscribers: joshuaspence, Korvin, epriestley Maniphest Tasks: T2783 Differential Revision: https://secure.phabricator.com/D11874
2016-04-08 22:08:56 +02:00
'DiffusionInternalGitRawDiffQueryConduitAPIMethod' => 'DiffusionQueryConduitAPIMethod',
Add more change metadata to SVN and git.
2011-03-31 08:27:06 +02:00
'DiffusionLastModifiedController' => 'DiffusionController',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionLastModifiedQueryConduitAPIMethod' => 'DiffusionQueryConduitAPIMethod',
Display lint overview in Diffusion Summary: I will add links from /diffusion/ARC/lint/ in future diff. Test Plan: /diffusion/ - clicked on lint messages link. /diffusion/ARC/ - clicked on lint messages link. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3926
2012-11-08 20:11:44 +01:00
'DiffusionLintController' => 'DiffusionController',
Implement a lint count query Summary: Ref T2683. This query is currently unbatched and happens inside a view. Leave it inside the view for now, but separate it and make it batchable. Test Plan: {F34848} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley, vrana, aran Maniphest Tasks: T2683 Differential Revision: https://secure.phabricator.com/D5252
2014-05-11 00:21:05 +02:00
'DiffusionLintCountQuery' => 'PhabricatorQuery',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DiffusionLintSaveRunner' => 'Phobject',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionLookSoonConduitAPIMethod' => 'DiffusionConduitAPIMethod',
Move commit message/metadata field query to a separate class Summary: Ref T4195. I need to query commit metadata to figure out which revision a commit is associated with. Move this out of the MessageParser so the code can be called from the HookEngine. Test Plan: Used `reparse.php` to reparse a variety of SVN, Mercurial and Git commits. Used `var_dump()` to verify sensible fields were returned. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7805
2013-12-20 21:38:44 +01:00
'DiffusionLowLevelCommitFieldsQuery' => 'DiffusionLowLevelQuery',
Provide a low-level SVN commit query, and merge the VCS query types Summary: Ref T4195. Even though we use `svnlook` in the hook itself, I need this query elsewhere, so provide it and merge the classes into one which does the right thing. Test Plan: - Used `reparse.php` to reparse messages for Git, SVN and Mercurial commits, using `var_dump()` to examine the commit refs for sanity. - Used `reparse.php` to reparse changes for an SVN commit. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7800
2013-12-19 20:05:06 +01:00
'DiffusionLowLevelCommitQuery' => 'DiffusionLowLevelQuery',
Consolidate querying of things which we can use `git for-each-ref` for Summary: Ref T2230. This cleans up D7442, by using `git for-each-ref` everywhere we can, in a basically reasonable way. Test Plan: In bare and non-bare repositories: - Ran discovery with `bin/repository discover`; - listed branches on `/diffusion/X/`; - listed tags on `/diffusion/X/`; - listed tags, branches and refs on `/diffusion/rXnnnn`. Reviewers: btrahan, avivey Reviewed By: avivey CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7447
2013-10-30 21:06:09 +01:00
'DiffusionLowLevelGitRefQuery' => 'DiffusionLowLevelQuery',
Clean up `hg --debug branches` calls Summary: Ref T1493. Consolidate these a bit; they might need some more magic once we do `--noupdate` checkouts. Mostly just trying to clean up and centralize this code a bit. Test Plan: Viewed and `bin/repository discover`'d Mercurial repos with and without any branches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1493 Differential Revision: https://secure.phabricator.com/D7480
2013-11-04 21:15:32 +01:00
'DiffusionLowLevelMercurialBranchesQuery' => 'DiffusionLowLevelQuery',
Diffusion - replace last `hg manifest` call with `hg locate` Summary: Fixes T4387. Test Plan: Setup a mercurial repository for rabbitmq-server. Browsed around it and things looked good. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4387 Differential Revision: https://secure.phabricator.com/D10380
2014-08-28 22:08:42 +02:00
'DiffusionLowLevelMercurialPathsQuery' => 'DiffusionLowLevelQuery',
Conditionally use `hg files` vs. `hg locate` depending on version of Mercurial Summary: In Mercurial 3.2 the `locate` command was deprecated in favor of `files` command. This change updates the DiffusionLowLevelMercurialPathsQuery command to conditionally use `locate` or `files` based on the version of Mercurial used. Closes T7375 Test Plan: My test/develop Phabricator instance is setup to run Mercurial 3.5.1. The test procedure to verify valid file listings are being returned: 1. I navigated to `http://192.168.0.133/conduit/method/diffusion.querypaths/` 2. I populated the following fields: - path: `"/"` - commit: `"d721d5b57fc9ef72e47ff9d4e0c583d74a46590c"` - callsign: `"HGTEST"` 3. I submitted request and verified that result contained all files in the repository: ``` { "0": "README", "1": "alpha/beta/trifle", "2": "test/Chupacabra.cow", "3": "test/socket.ks" } ``` I repeated the above steps after setting up Mercurial 2.6.2, which I installed in the following manner: 1. I downloaded Mercurial 2.6.2 source and run `make local` which will only compile it to work from its own directory (`/opt/mercurial-2.6.2`) 2. I linked `/usr/local/bin/hg -> /opt/mercurial-2.6.2/hg` (there's also a `/usr/bin/hg` which is a link to `/usr/local/bin/hg`) 3. I navigated to my home directory and verify that `hg --version` returns 2.6.2. 4. I restarted phabricator services (probably unnecessary). With the Multimeter application active 1. I verified that `/usr/local/bin/hg` referred to version 2.6 2. I ran the same conduit call from the conduit application 3. I verified that `http://192.168.0.133/multimeter/?type=2&group=label` incremented values for `bin.hg locate`. 4. I swapped out mercurial versions for 3.5.1 5. I ran the same conduit call from the conduit application 6. I verified that `http://192.168.0.133/multimeter/?type=2&group=label` incremented values for `bin.hg files` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T7375 Differential Revision: https://secure.phabricator.com/D14253
2015-10-13 02:50:26 +02:00
'DiffusionLowLevelMercurialPathsQueryTests' => 'PhabricatorTestCase',
Modernize Diffusion `commitparentsquery` Summary: Ref T4195. Ref T2783. We have an old-school implementation of this; move it into a LowLevel query and make callers all run through Conduit. I need the LowLevel query for hooks, to implement an "is merge commit" Herald rule. Test Plan: - Ran query via Conduit for SVN, Mercurial, Git. - Parsed a commit which closed a revision, attach/closed worked correctly. - Browsed Diffusion. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195, T2783 Differential Revision: https://secure.phabricator.com/D7808
2013-12-20 21:39:21 +01:00
'DiffusionLowLevelParentsQuery' => 'DiffusionLowLevelQuery',
Consolidate querying of things which we can use `git for-each-ref` for Summary: Ref T2230. This cleans up D7442, by using `git for-each-ref` everywhere we can, in a basically reasonable way. Test Plan: In bare and non-bare repositories: - Ran discovery with `bin/repository discover`; - listed branches on `/diffusion/X/`; - listed tags on `/diffusion/X/`; - listed tags, branches and refs on `/diffusion/rXnnnn`. Reviewers: btrahan, avivey Reviewed By: avivey CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7447
2013-10-30 21:06:09 +01:00
'DiffusionLowLevelQuery' => 'Phobject',
Merge "expandshortcommitquery" and "stablecommitnamequery" into "resolverefs" Summary: Ref T1493. Diffusion has some garbagey behavior for things we can't resolve. Common cases are: - Looking at a branch that doesn't exist. - Looking at a repository with no branches. - Looking at a commit that doesn't exist. - Looking at an empty repository. In these cases, we generally fatal unhelpfully. I want to untangle this mess. This doesn't help much, but does clean things up a bit. We currently have two separate query paths, "stablecommitname" and "expandshortcommit". These are pretty much doing the same thing -- taking some ref like "master" or "default" or a tag name or part of a commit name, and turning it into a full commit name. Merge them into a single "resolverefs" method. This simplifies the code a fair bit, and gives us better error messages. They still aren't great, but they're like this now: Ref "7498aec194ecf2d333e0e2baddd9d5cdf922d7f1" is ambiguous or does not exist. ...instead of just: ERR-INVALID-COMMIT Test Plan: Looked at Git, Mercurial and Subversion repositories that were empty and non-empty. Looked at branches/heads. Tried to look at invalid commits. Looked at tags. All of this still works, and some behaviors are a bit better than they used to be. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1493 Differential Revision: https://secure.phabricator.com/D7484
2013-11-04 23:13:07 +01:00
'DiffusionLowLevelResolveRefsQuery' => 'DiffusionLowLevelQuery',
Implement a dedicated "diffusion.blame" API method Summary: Fixes T2451. Several motivations here, from strongest to weakest: - Currently, getting blame and file content are closely entwined. This makes fixing T9319 more difficult, and I want to fix it. I want to separate blame from content so there's more flexibility in how we approach this issue. - This makes pursuing T2450 easier, if it turns out to be a meaningful win. - If we can get a win on blame performance, we can do `arc blame` eventually if we want. Test Plan: - Blamed in SVN, Git and Mercurial. Reviewers: chad Reviewed By: chad Maniphest Tasks: T2451 Differential Revision: https://secure.phabricator.com/D14957
2016-01-06 13:56:27 +01:00
'DiffusionMercurialBlameQuery' => 'DiffusionBlameQuery',
Extract repository command construction from Repositories Summary: Ref T4292. Ref T10366. Depends on D15751. Today, generating repository commands is purely a function of the repository, so they use protocols and credentials based on the repository configuration. For example, a repository with an SSH "remote URI" always generate SSH "remote commands". This needs to change in the future: - After T10366, repositories won't necessarily just have one type of remote URI. They can only have one at a time still, but the repository itself won't change based on which one is currently active. - For T4292, I need to generate intracluster commands, regardless of repository configuration. These will have different protocols and credentials. Prepare for these cases by separating out command construction, so they'll be able to generate commands in a more flexible way. Test Plan: - Added unit tests. - Browsed diffusion. - Ran `bin/phd debug pull` to pull a bunch of repos. - Ran daemons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4292, T10366 Differential Revision: https://secure.phabricator.com/D15752
2016-04-19 00:22:52 +02:00
'DiffusionMercurialCommandEngine' => 'DiffusionCommandEngine',
Basic support for Mercurial in Diffusion Summary: Change import script plus almost all the view stuff. Still some rough edges but this seems to mostly work. Blame is currently unsupported but I think everything else works properly. Test Plan: Imported the hg repository itself. It doesn't immediately seem completely broken. Here are some screens: https://secure.phabricator.com/file/view/PHID-FILE-1438b71cc7c4a2eb4569/ https://secure.phabricator.com/file/view/PHID-FILE-3cec4f72f39e7de2d041/ https://secure.phabricator.com/file/view/PHID-FILE-2ea4883f160e8e5098f9/ https://secure.phabricator.com/file/view/PHID-FILE-35f751a36ebf65399ade/ All the parsers were able to churn through it without errors. Ran the new "reparse.php" script in various one-commit and repository modes. Browsed/imported some git repos for good measure. NOTE: The hg repository is only 15,000 commits and around 1,000 files. Performance is okay but hg doesn't provide performant, native APIs to get some data efficiently so we have to do some dumb stuff. If some of these interfaces are cripplingly slow or whatever, let me know and we can start bundling some Mercurial extensions with Arcanist. Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran Reviewed By: Makinde CC: aran, Makinde, epriestley Differential Revision: 960
2011-09-26 20:07:38 +02:00
'DiffusionMercurialFileContentQuery' => 'DiffusionFileContentQuery',
Add "DiffusionRawDiffQuery" Summary: - This is only slightly useful for updating Differential, since DiffQuery (vs RawDiffQuery) already gets you most of what you need. The only thing is that DiffQuery returns the diff for one path only right now(and the SVN version is very "special"). Should be easy to fix in the Git/HG cases at least, though (or maybe just use RawDiffQuery to avoid the SVN mess). - Added a "download raw diff" link. Test Plan: Viewed Diffusion and raw commits for SVN, Mercurial and Git repositories. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2350
2012-05-02 22:43:45 +02:00
'DiffusionMercurialRawDiffQuery' => 'DiffusionRawDiffQuery',
Basic support for Mercurial in Diffusion Summary: Change import script plus almost all the view stuff. Still some rough edges but this seems to mostly work. Blame is currently unsupported but I think everything else works properly. Test Plan: Imported the hg repository itself. It doesn't immediately seem completely broken. Here are some screens: https://secure.phabricator.com/file/view/PHID-FILE-1438b71cc7c4a2eb4569/ https://secure.phabricator.com/file/view/PHID-FILE-3cec4f72f39e7de2d041/ https://secure.phabricator.com/file/view/PHID-FILE-2ea4883f160e8e5098f9/ https://secure.phabricator.com/file/view/PHID-FILE-35f751a36ebf65399ade/ All the parsers were able to churn through it without errors. Ran the new "reparse.php" script in various one-commit and repository modes. Browsed/imported some git repos for good measure. NOTE: The hg repository is only 15,000 commits and around 1,000 files. Performance is okay but hg doesn't provide performant, native APIs to get some data efficiently so we have to do some dumb stuff. If some of these interfaces are cripplingly slow or whatever, let me know and we can start bundling some Mercurial extensions with Arcanist. Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran Reviewed By: Makinde CC: aran, Makinde, epriestley Differential Revision: 960
2011-09-26 20:07:38 +02:00
'DiffusionMercurialRequest' => 'DiffusionRequest',
Allow Phabricator to serve Mercurial repositories over HTTP Summary: Ref T2230. This is easily the worst thing I've had to write in a while. I'll leave some notes inline. Test Plan: Ran `hg clone http://...` on a hosted repo. Ran `hg push` on the same. Changed sync'd both ways. Reviewers: asherkin, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7520
2013-11-07 03:00:42 +01:00
'DiffusionMercurialResponse' => 'AphrontResponse',
Rename `DiffusionSSHWorkflow` subclasses for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11185
2015-01-04 20:33:18 +01:00
'DiffusionMercurialSSHWorkflow' => 'DiffusionSSHWorkflow',
'DiffusionMercurialServeSSHWorkflow' => 'DiffusionMercurialSSHWorkflow',
'DiffusionMercurialWireClientSSHProtocolChannel' => 'PhutilProtocolChannel',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DiffusionMercurialWireProtocol' => 'Phobject',
Added an intercept to Mercurial's `capabilities` command to remove bundle2. Summary: If Mercurial 3.4+ is used to host repositories in Phabricator, any clients using 3.5+ will receive an exception after the bundle is pushed up. Clients will also fail to update phases for changesets pushed up. Before directly responding to mercurial clients with all capabilities, this change filters out the 'bundle2' capability so the client negotiates using a legacy bundle wire format instead. Test Plan: Server: Mercurial 3.5 Client: Mercurial 3.4 Test with both HTTP and SSH protocols: 1. Create a local commit on client 2. Push commit to server 3. Verify the client emits something like: ``` searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files ``` Closes T9450 Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T9450 Differential Revision: https://secure.phabricator.com/D14241
2015-10-10 16:14:48 +02:00
'DiffusionMercurialWireProtocolTests' => 'PhabricatorTestCase',
Rename `DiffusionSSHWorkflow` subclasses for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11185
2015-01-04 20:33:18 +01:00
'DiffusionMercurialWireSSHTestCase' => 'PhabricatorTestCase',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionMergedCommitsQueryConduitAPIMethod' => 'DiffusionQueryConduitAPIMethod',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DiffusionPathChange' => 'Phobject',
'DiffusionPathChangeQuery' => 'Phobject',
Some owners read workflows.
2011-04-04 04:20:47 +02:00
'DiffusionPathCompleteController' => 'DiffusionController',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DiffusionPathIDQuery' => 'Phobject',
'DiffusionPathQuery' => 'Phobject',
Fix a dirname() edge case in Diffusion Summary: dirname('x') returns '.', not '/'; this caused some issues for repositories with files at the root. There are some cases in the parsers where I should probably swap this out too but I'll wait until I'm doing some more rigorous testing since that stuff is a bit fragile and this fixes an immediate issue. Test Plan: Ran unit tests. Viewed a file at root level in a test repository. Reviewers: jungejason, nh, tuomaspelkonen, aran Reviewed By: nh CC: aran, nh Differential Revision: 932
2011-09-14 20:23:39 +02:00
'DiffusionPathQueryTestCase' => 'PhabricatorTestCase',
Add a SublimeText-style repository typeahead Summary: Allows you to quickly search for files within a repository. Roughly: - We build a big tree of everything and ship it to the client. - The client implements a bunch of Sublime-ish magic to find paths. Test Plan: {F154007} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley, zeeg Differential Revision: https://secure.phabricator.com/D9087
2014-05-13 23:08:21 +02:00
'DiffusionPathTreeController' => 'DiffusionController',
Some owners read workflows.
2011-04-04 04:20:47 +02:00
'DiffusionPathValidateController' => 'DiffusionController',
Framework for external symbol search Summary: Ref T7984. With this, an install can add an ExternalSymbolsSource to src/extensions, which will include whatever source they have. Test Plan: search for php and python builtins. Reviewers: joshuaspence, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7984 Differential Revision: https://secure.phabricator.com/D13036
2015-05-31 16:36:54 +02:00
'DiffusionPhpExternalSymbolsSource' => 'DiffusionExternalSymbolsSource',
Modularize Herald Diffusion pre-commit content fields Summary: Ref T8726. The gruntwork part of this is finally over. Test Plan: - Made a huge rule with every field. - Applied migration. - Verified the rule was still the same. - Pushed a bunch of commits and verified transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13601
2015-07-08 21:26:57 +02:00
'DiffusionPreCommitContentAffectedFilesHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentAuthorHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentAuthorRawHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentBranchesHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentCommitterHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentCommitterRawHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentDiffContentAddedHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentDiffContentHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentDiffContentRemovedHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentDiffEnormousHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentHeraldField' => 'HeraldField',
'DiffusionPreCommitContentMergeHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentMessageHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentPusherHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentPusherIsCommitterHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentPusherProjectsHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentRepositoryHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentRepositoryProjectsHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentRevisionAcceptedHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentRevisionHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentRevisionReviewersHeraldField' => 'DiffusionPreCommitContentHeraldField',
'DiffusionPreCommitContentRevisionSubscribersHeraldField' => 'DiffusionPreCommitContentHeraldField',
Modularize all Herald pre-commit ref fields Summary: Ref T8726. Just (pre-commit content) one more left. Test Plan: - Created a big rule with every field. - Migrated it. - Verified the rule was still the same. - Pushed a bunch of changes and reviewed the transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13600
2015-07-08 21:26:00 +02:00
'DiffusionPreCommitRefChangeHeraldField' => 'DiffusionPreCommitRefHeraldField',
'DiffusionPreCommitRefHeraldField' => 'HeraldField',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'DiffusionPreCommitRefHeraldFieldGroup' => 'HeraldFieldGroup',
Modularize all Herald pre-commit ref fields Summary: Ref T8726. Just (pre-commit content) one more left. Test Plan: - Created a big rule with every field. - Migrated it. - Verified the rule was still the same. - Pushed a bunch of changes and reviewed the transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13600
2015-07-08 21:26:00 +02:00
'DiffusionPreCommitRefNameHeraldField' => 'DiffusionPreCommitRefHeraldField',
'DiffusionPreCommitRefPusherHeraldField' => 'DiffusionPreCommitRefHeraldField',
'DiffusionPreCommitRefPusherProjectsHeraldField' => 'DiffusionPreCommitRefHeraldField',
'DiffusionPreCommitRefRepositoryHeraldField' => 'DiffusionPreCommitRefHeraldField',
'DiffusionPreCommitRefRepositoryProjectsHeraldField' => 'DiffusionPreCommitRefHeraldField',
'DiffusionPreCommitRefTypeHeraldField' => 'DiffusionPreCommitRefHeraldField',
Add a basic pull event log for debugging repository cloning Summary: Ref T10228. This is currently quite limited: - No UI. - No SSH support. My primary goal is to debug the issue in T10228. In the long run we can expand this to be a bit fancier. Test Plan: Made various valid and invalid clones, got sucess responses and not-so-successful responses, viewed the log table for general corresponding messages and broad sanity. Ran GC via `bin/phd debug trigger`, no issues. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10228 Differential Revision: https://secure.phabricator.com/D15127
2016-01-28 14:21:38 +01:00
'DiffusionPullEventGarbageCollector' => 'PhabricatorGarbageCollector',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'DiffusionPushCapability' => 'PhabricatorPolicyCapability',
Provide an "event" page for push logs, which shows details on all events in a given push Summary: Ref T4677. This shows a more detailed view of an entire "git push", "hg push", or "svn commit". This is mostly to give push summary emails a reasonable, stable URI to link to for T4677. Test Plan: - Pushed into SVN, Git and Mercurial. - Viewed partial and imported event records. {F134864} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4677 Differential Revision: https://secure.phabricator.com/D8616
2014-03-26 15:42:30 +01:00
'DiffusionPushEventViewController' => 'DiffusionPushLogController',
'DiffusionPushLogController' => 'DiffusionController',
Move Push log rendering to SearchEngine Summary: Ref T4986. Move push logs to a View, then have all the stuff that needs to use it use that View. Test Plan: Viewed push logs and transaction detail in Diffusion. Created a panel. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9104
2014-05-13 23:00:24 +02:00
'DiffusionPushLogListController' => 'DiffusionPushLogController',
'DiffusionPushLogListView' => 'AphrontView',
Framework for external symbol search Summary: Ref T7984. With this, an install can add an ExternalSymbolsSource to src/extensions, which will include whatever source they have. Test Plan: search for php and python builtins. Reviewers: joshuaspence, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7984 Differential Revision: https://secure.phabricator.com/D13036
2015-05-31 16:36:54 +02:00
'DiffusionPythonExternalSymbolsSource' => 'DiffusionExternalSymbolsSource',
Make DiffusionQuery extend PhabricatorQuery Summary: Ref T2683. Provides access to `formatWhereClause()`, etc. I plan to eventually unify the various DiffusionQuery execute methods as well, which all have special names right now (`loadModifiedPaths()`, `loadWhateverBlah()`, etc). Test Plan: Ran EverythingImplemented test. Browsed Diffusion. Reviewers: vrana Reviewed By: vrana CC: aran Maniphest Tasks: T2683 Differential Revision: https://secure.phabricator.com/D5251
2013-04-30 19:54:02 +02:00
'DiffusionQuery' => 'PhabricatorQuery',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionQueryCommitsConduitAPIMethod' => 'DiffusionConduitAPIMethod',
'DiffusionQueryConduitAPIMethod' => 'DiffusionConduitAPIMethod',
'DiffusionQueryPathsConduitAPIMethod' => 'DiffusionQueryConduitAPIMethod',
Add "DiffusionRawDiffQuery" Summary: - This is only slightly useful for updating Differential, since DiffQuery (vs RawDiffQuery) already gets you most of what you need. The only thing is that DiffQuery returns the diff for one path only right now(and the SVN version is very "special"). Should be easy to fix in the Git/HG cases at least, though (or maybe just use RawDiffQuery to avoid the SVN mess). - Added a "download raw diff" link. Test Plan: Viewed Diffusion and raw commits for SVN, Mercurial and Git repositories. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2350
2012-05-02 22:43:45 +02:00
'DiffusionRawDiffQuery' => 'DiffusionQuery',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionRawDiffQueryConduitAPIMethod' => 'DiffusionQueryConduitAPIMethod',
Fix diffusion.readmequery to work in a cluster enviroment Summary: Ref T2783. This method is kind of goofballs: - We send a big list of paths to it. - It sends back a giant blob of HTML. Instead, just figure out the path we want locally, then fetch the content with `diffusion.filecontentquery`. Test Plan: - Viewed main view and directory view, saw a README. - See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2783 Differential Revision: https://secure.phabricator.com/D11099
2014-12-31 20:54:52 +01:00
'DiffusionReadmeView' => 'DiffusionView',
Add a DiffusionRefDatasource for typeahead'ing branches, tags, bookmarks and refs Summary: Ref T9952. This will let me put a "Branch: [____]" control on the "Land Revision" dialog so users can choose a branch to target. Test Plan: Used `/typeahead/class/` to vet basic behavior. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9952 Differential Revision: https://secure.phabricator.com/D14732
2015-12-10 22:17:11 +01:00
'DiffusionRefDatasource' => 'PhabricatorTypeaheadDatasource',
Throw a more tailored exception after failing to resolve a ref Summary: Ref T2683. Throw a more tailored exception to allow callers to distinguish between bad refs (which are expected, if users try to visit garbage branches) and other types of errors. Test Plan: Tried to view branch "alksndfklansdf". Viewed branch "master". Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2683 Differential Revision: https://secure.phabricator.com/D9094
2014-05-13 22:52:33 +02:00
'DiffusionRefNotFoundException' => 'Exception',
Add a "refs" table to Diffusion Summary: Ref T7100. When a user navigates to a branch like "default" which is ambiguous: - don't fatal; - choose one alternative to resolve it to (currently more or less at random); - sometimes show what we did in the UI. Also, add a new table to show the alternatives. This will get refined in followup changes. Test Plan: {F384335} {F384336} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7100 Differential Revision: https://secure.phabricator.com/D12547
2015-04-27 12:49:57 +02:00
'DiffusionRefTableController' => 'DiffusionController',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionRefsQueryConduitAPIMethod' => 'DiffusionQueryConduitAPIMethod',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DiffusionRenameHistoryQuery' => 'Phobject',
Port "Actions" to new Repository UI Summary: Ref T10748. This brings the "Actions" items (publish/notify + autoclose enabled) into the new UI. Test Plan: - Edited this stuff via EditEngine and Conduit. - Viewed via new Manage UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15811
2016-04-28 00:40:35 +02:00
'DiffusionRepositoryActionsManagementPanel' => 'DiffusionRepositoryManagementPanel',
Port "Automation" panel to new Repository Manage UI Summary: Ref T10748. Ports this UI and exposes it on the EditEngine. Test Plan: - Edited via EditEngine. - Viewed new manage UI. Reviewers: chad Reviewed By: chad Subscribers: hach-que Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15804
2016-04-27 00:54:01 +02:00
'DiffusionRepositoryAutomationManagementPanel' => 'DiffusionRepositoryManagementPanel',
Rough in basics + policies + history repository management panels Summary: Ref T10748. This is roughly where I'm headed, if it makes some kind of sense? The "Edit" links in sub-sections don't work yet since I haven't built the thing. Probably depends on D15736. Test Plan: Manually navigated to `/manage/`, clicked around. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15737
2016-04-17 02:33:27 +02:00
'DiffusionRepositoryBasicsManagementPanel' => 'DiffusionRepositoryManagementPanel',
Port Repository "Branches" to new UI Summary: Ref T10748. Makes a "Branches" panel, enables these transactions in the EditEngine. Test Plan: - Edited via EditEngine + Conduit. - Viewed via manage UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15809
2016-04-27 19:51:13 +02:00
'DiffusionRepositoryBranchesManagementPanel' => 'DiffusionRepositoryManagementPanel',
make repo callsigns optional Summary: Ref T4245 Make repo callsigns optional This is far from done and still very ugly. I'm just submitting it to check if i'm solving this in the right places. Right now there's three places with duplicate code and building the identifierMap in the CommitQuery is very ugly. If we only want to support this in the user frontend then i could hack it into the Markup rule itself and not touch the CommitQuery. Even uglier but more limited in scope... Generally this approach will need a lot of "check this first and then try the other" in a few places. I could move the Repository queries into a specialised PhabricatorRepositoryQuery method (withCallsignOrID) but i'm not sure about that. Test Plan: - phid.lookup works with R1 and rTEST (which is the same repo) - R1 and rTEST euqally work in remarkup (tested in comments). - Reviewed the following syntax also all works: rTEST rTESTd773137a7cb9 rTEST:d773137a7cb9 R1 R1:d773137a7cb9 d773137a7cb9 {rTEST} {rTESTd773137a7cb9} {rTEST:d773137a7cb9} {R1} {R1:d773137a7cb9} {d773137a7cb9} Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T4245 Differential Revision: https://secure.phabricator.com/D11050
2015-01-01 17:07:26 +01:00
'DiffusionRepositoryByIDRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Move all cluster locking logic to a separate class Summary: Ref T10860. This doesn't change anything, it just separates all this stuff out of `PhabricatorRepository` since I'm planning to add a bit more state to it and it's already pretty big and fairly separable. Test Plan: Pulled, pushed, browsed Diffusion. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10860 Differential Revision: https://secure.phabricator.com/D15790
2016-04-24 18:04:27 +02:00
'DiffusionRepositoryClusterEngine' => 'Phobject',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionRepositoryController' => 'DiffusionController',
Modernize "repositories" typeahead datasource Summary: Ref T4420. - Allow tokenizers to accept either a `Datasource` object (new style) or a URI (old style). - Read URI and placeholder text from object, if available. - Swap the "repositories" datasource (which seemed like the simplest one) over to the new stuff. - Tweak/update the repo tokens a little bit. Test Plan: - Used tokenizer in Herald, Differential (search), Differential (edit), Push Logs. - Grepped for other callsites. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9874
2014-07-11 01:18:04 +02:00
'DiffusionRepositoryDatasource' => 'PhabricatorTypeaheadDatasource',
Accept and route VCS HTTP requests Summary: Mostly ripped from D7391, with some changes: - Serve repositories at `/diffusion/X/`, with no special `/git/` or `/serve/` URI component. - This requires a little bit of magic, but I got the magic working for Git, Mercurial and SVN, and it seems reasonable. - I think having one URI for everything will make it easier for users to understand. - One downside is that git will clone into `X` by default, but I think that's not a big deal, and we can work around that in the future easily enough. - Accept HTTP requests for Git, SVN and Mercurial repositories. - Auth logic is a little different in order to be more consistent with how other things work. - Instead of AphrontBasicAuthResponse, added "VCSResponse". Mercurial can print strings we send it on the CLI if we're careful, so support that. I did a fair amount of digging and didn't have any luck with git or svn. - Commands we don't know about are assumed to require "Push" capability by default. No actual VCS data going over the wire yet. Test Plan: Ran a bunch of stuff like this: $ hg clone http://local.aphront.com:8080/diffusion/P/ abort: HTTP Error 403: This repository is not available over HTTP. ...and got pretty reasonable-seeming errors in all cases. All this can do is produce errors for now. Reviewers: hach-que, btrahan Reviewed By: hach-que CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7417
2013-10-26 16:56:17 +02:00
'DiffusionRepositoryDefaultController' => 'DiffusionController',
Document most of the new Diffusion management panel Summary: Ref T10923. This isn't complete yet, but reduces lies and increases truths. Test Plan: Read documentation, clicked new "Documentation" nav item. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10923 Differential Revision: https://secure.phabricator.com/D15868
2016-05-09 17:10:21 +02:00
'DiffusionRepositoryDocumentationManagementPanel' => 'DiffusionRepositoryManagementPanel',
Sort out EditController / ManageController / EditproController Diffusion hierarchy Summary: Ref T10923. This cleans up the remaining "pro" mess left by the cutover. Test Plan: Viewed, managed, edited a repository. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10923 Differential Revision: https://secure.phabricator.com/D15871
2016-05-09 23:24:21 +02:00
'DiffusionRepositoryEditActivateController' => 'DiffusionRepositoryManageController',
Trivially implement RepositoryEditEngine and API methods Summary: Ref T10748. Ref T10337. This technically implements this stuff, but it does not do anything useful yet. This skips all the hard stuff. Test Plan: - Technically used `diffusion.repository.search` to get repository information. - Technically used `diffusion.repository.edit` to change a repository name. - Used `editpro/` to edit a repository name. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10337, T10748 Differential Revision: https://secure.phabricator.com/D15736
2016-04-17 01:45:19 +02:00
'DiffusionRepositoryEditConduitAPIMethod' => 'PhabricatorEditEngineAPIMethod',
Sort out EditController / ManageController / EditproController Diffusion hierarchy Summary: Ref T10923. This cleans up the remaining "pro" mess left by the cutover. Test Plan: Viewed, managed, edited a repository. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10923 Differential Revision: https://secure.phabricator.com/D15871
2016-05-09 23:24:21 +02:00
'DiffusionRepositoryEditController' => 'DiffusionRepositoryManageController',
'DiffusionRepositoryEditDangerousController' => 'DiffusionRepositoryManageController',
'DiffusionRepositoryEditDeleteController' => 'DiffusionRepositoryManageController',
Trivially implement RepositoryEditEngine and API methods Summary: Ref T10748. Ref T10337. This technically implements this stuff, but it does not do anything useful yet. This skips all the hard stuff. Test Plan: - Technically used `diffusion.repository.search` to get repository information. - Technically used `diffusion.repository.edit` to change a repository name. - Used `editpro/` to edit a repository name. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10337, T10748 Differential Revision: https://secure.phabricator.com/D15736
2016-04-17 01:45:19 +02:00
'DiffusionRepositoryEditEngine' => 'PhabricatorEditEngine',
Sort out EditController / ManageController / EditproController Diffusion hierarchy Summary: Ref T10923. This cleans up the remaining "pro" mess left by the cutover. Test Plan: Viewed, managed, edited a repository. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10923 Differential Revision: https://secure.phabricator.com/D15871
2016-05-09 23:24:21 +02:00
'DiffusionRepositoryEditUpdateController' => 'DiffusionRepositoryManageController',
Rough in basics + policies + history repository management panels Summary: Ref T10748. This is roughly where I'm headed, if it makes some kind of sense? The "Edit" links in sub-sections don't work yet since I haven't built the thing. Probably depends on D15736. Test Plan: Manually navigated to `/manage/`, clicked around. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15737
2016-04-17 02:33:27 +02:00
'DiffusionRepositoryHistoryManagementPanel' => 'DiffusionRepositoryManagementPanel',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'DiffusionRepositoryListController' => 'DiffusionController',
Rough cut at new "pro" Diffusion edit UI skeleton Summary: Ref T4292. This puts a very rough skeleton in place for the new "Manage Repository" UI, somewhat similar to the "Settings" UI. Right now, it has one panel with no content, and is not reachable from the UI. Test Plan: {F1214525} Reviewers: chad Reviewed By: chad Maniphest Tasks: T4292 Differential Revision: https://secure.phabricator.com/D15683
2016-04-11 19:17:46 +02:00
'DiffusionRepositoryManageController' => 'DiffusionController',
Sort out EditController / ManageController / EditproController Diffusion hierarchy Summary: Ref T10923. This cleans up the remaining "pro" mess left by the cutover. Test Plan: Viewed, managed, edited a repository. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10923 Differential Revision: https://secure.phabricator.com/D15871
2016-05-09 23:24:21 +02:00
'DiffusionRepositoryManagePanelsController' => 'DiffusionRepositoryManageController',
Rough cut at new "pro" Diffusion edit UI skeleton Summary: Ref T4292. This puts a very rough skeleton in place for the new "Manage Repository" UI, somewhat similar to the "Settings" UI. Right now, it has one panel with no content, and is not reachable from the UI. Test Plan: {F1214525} Reviewers: chad Reviewed By: chad Maniphest Tasks: T4292 Differential Revision: https://secure.phabricator.com/D15683
2016-04-11 19:17:46 +02:00
'DiffusionRepositoryManagementPanel' => 'Phobject',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DiffusionRepositoryPath' => 'Phobject',
Rough in basics + policies + history repository management panels Summary: Ref T10748. This is roughly where I'm headed, if it makes some kind of sense? The "Edit" links in sub-sections don't work yet since I haven't built the thing. Probably depends on D15736. Test Plan: Manually navigated to `/manage/`, clicked around. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15737
2016-04-17 02:33:27 +02:00
'DiffusionRepositoryPoliciesManagementPanel' => 'DiffusionRepositoryManagementPanel',
Remove DiffusionBranchInformation in favor of DiffusionRepositoryRef Summary: Ref T4327. At some point these two very similar classes got introduced. Collapse `DiffusionBranchInformation` into the nearly identical `DiffusionRepositoryRef`, which enjoys slightly more generality and support. Test Plan: Viewed branch overview and detail pages. Ran `repository refs` and `repository discover`. Grepped for removed symbols. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D8002
2014-01-18 01:10:56 +01:00
'DiffusionRepositoryRef' => 'Phobject',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'DiffusionRepositoryRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Trivially implement RepositoryEditEngine and API methods Summary: Ref T10748. Ref T10337. This technically implements this stuff, but it does not do anything useful yet. This skips all the hard stuff. Test Plan: - Technically used `diffusion.repository.search` to get repository information. - Technically used `diffusion.repository.edit` to change a repository name. - Used `editpro/` to edit a repository name. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10337, T10748 Differential Revision: https://secure.phabricator.com/D15736
2016-04-17 01:45:19 +02:00
'DiffusionRepositorySearchConduitAPIMethod' => 'PhabricatorSearchEngineAPIMethod',
Port "Staging Area" repository section to new management UI Summary: Ref T10748. Brings this over and adds EditEngine support for it. Test Plan: Viewed and edited staging area information. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15801
2016-04-26 14:54:51 +02:00
'DiffusionRepositoryStagingManagementPanel' => 'DiffusionRepositoryManagementPanel',
Copy repository status to a management panel Summary: Ref T10748. Pretty straightforward. I'd like to put a little "!" icon in the menu if there's a warning/error eventually, but can deal with that latre. Test Plan: {F1223096} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15741
2016-04-17 14:10:18 +02:00
'DiffusionRepositoryStatusManagementPanel' => 'DiffusionRepositoryManagementPanel',
Port local storage path to new repository Manage UI Summary: Ref T10748. This merges "Storage" and "Cluster" into a single UI which combines the information of both. Test Plan: {F1246882} Reviewers: chad Reviewed By: chad Subscribers: hach-que Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15800
2016-04-26 14:43:35 +02:00
'DiffusionRepositoryStorageManagementPanel' => 'DiffusionRepositoryManagementPanel',
Restore edit UI for "Import Only" in Subversion Summary: Ref T10923. Although I'd ideally like to get rid of this eventually, keep it around for now. Test Plan: - Edited value for an SVN repository. - Observed no panel present for a Git repository. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10923 Differential Revision: https://secure.phabricator.com/D15883
2016-05-11 02:13:11 +02:00
'DiffusionRepositorySubversionManagementPanel' => 'DiffusionRepositoryManagementPanel',
Port Repository "Symbols" to Manage/Panel UI Summary: Ref T10748. Port this, add EditEngine support, add some type validation to the transaction. Test Plan: - Edited via EditEngine. - Edited via Conduit. - Viewed via Management UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15808
2016-04-27 19:32:43 +02:00
'DiffusionRepositorySymbolsManagementPanel' => 'DiffusionRepositoryManagementPanel',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DiffusionRepositoryTag' => 'Phobject',
Sort out EditController / ManageController / EditproController Diffusion hierarchy Summary: Ref T10923. This cleans up the remaining "pro" mess left by the cutover. Test Plan: Viewed, managed, edited a repository. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10923 Differential Revision: https://secure.phabricator.com/D15871
2016-05-09 23:24:21 +02:00
'DiffusionRepositoryTestAutomationController' => 'DiffusionRepositoryManageController',
Fill in new URI credential edit web UI interfaces Summary: Ref T10748. Ref T10366. Allows users to set credential for new URIs. - Ref T7221. Our handling of the "git://" protocol is currently incorrect. This protocol is not authenticated, but is considered an SSH protocol. In the new UI, it is considered an anonymous/unauthenticated protocol instead. - Ref T10241. This fixes the `PassphraseCredentialControl` so it doesn't silently edit the value if the current value is not visible to you and/or not valid. Test Plan: Performed a whole lot of credential edits, removals, and adjustments. I'll give this additional vetting before cutting over to it. {F1253207} Reviewers: chad Reviewed By: chad Maniphest Tasks: T7221, T10241, T10366, T10748 Differential Revision: https://secure.phabricator.com/D15829
2016-05-01 15:59:22 +02:00
'DiffusionRepositoryURICredentialController' => 'DiffusionController',
Flesh out more web UI actions for new URI interface Summary: Ref T10748. - Allow users to add new URIs by clicking a button instead of knowing a secret URI. - Validate that URIs are actually valid URIs. - Add enable/disable action and strings. Test Plan: - Created a new URI. - Tried to create a nonsense URI, created a good URI. - Enabled/disabled a URI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15825
2016-04-30 01:51:05 +02:00
'DiffusionRepositoryURIDisableController' => 'DiffusionController',
'DiffusionRepositoryURIEditController' => 'DiffusionController',
Add repository URI view pages and IO/Display edit logic Summary: Ref T10748. - New View page for repository URIs. - Make display and I/O behavior (observe, mirror, read, read/write) editable. - Add a bunch of checks to prevent you from completely screwing up a repository by making it writable from a bunch of differnet sources. Test Plan: {F1249866} {F1249867} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15816
2016-04-28 19:40:35 +02:00
'DiffusionRepositoryURIViewController' => 'DiffusionController',
Move repository URIs to a dedicated index Summary: Ref T4705 (there are also some other adjacent related tasks dealing with URIs). Currently, we issue a "get repositories matching URIs: ..." query by loading every possible repository and then checking their URIs in PHP. Instead, put URIs in a separate table. I plan for each repository to potentially have multiple URIs soon, so this prepares for that. Test Plan: - Ran migrations. - Looked at index table, made sure it appeared sensible. - Ran some queries by `uri` to find repositories, found the repositories I expected. - Updated the remote URI of a repository, saw queries / index update appropriately. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4705 Differential Revision: https://secure.phabricator.com/D15005
2016-01-12 15:45:17 +01:00
'DiffusionRepositoryURIsIndexEngineExtension' => 'PhabricatorIndexEngineExtension',
Rough in the new custom URI panel Summary: Ref T10748. Ref T10366. No support for editing and no impact on the UI, but get some of the basics in place. Test Plan: {F1223279} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10366, T10748 Differential Revision: https://secure.phabricator.com/D15742
2016-04-17 17:17:49 +02:00
'DiffusionRepositoryURIsManagementPanel' => 'DiffusionRepositoryManagementPanel',
Allow callers to query information about repository URIs from diffusion.repository.search Summary: Ref T10748. Adds a "uris" attachment with URI information. Test Plan: Queried URI information via Conduit, saw reasonable looking information. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15822
2016-04-29 23:10:04 +02:00
'DiffusionRepositoryURIsSearchEngineAttachment' => 'PhabricatorSearchEngineAttachment',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DiffusionRequest' => 'Phobject',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionResolveRefsConduitAPIMethod' => 'DiffusionQueryConduitAPIMethod',
Provide a standalone query for resolution of commit author/committer into Phabricator users Summary: Ref T4195. To implement the "Author" and "Committer" rules, I need to resolve author/committer strings into Phabricator users. The code to do this is currently buried in the daemons. Extract it into a standalone query. I also added `bin/repository lookup-users <commit>` to test this query, both to improve confidence I'm getting this right and to provide a diagnostic command for users, since there's occasionally some confusion over how author/committer strings resolve into valid users. Test Plan: I tested this using `bin/repository lookup-users` and `reparse.php --message` on Git, Mercurial and SVN commits. Here's the `lookup-users` output: >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rINIS3 Examining commit rINIS3... Raw author string: epriestley Phabricator user: epriestley (Evan Priestley ) Raw committer string: null >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rPOEMS165b6c54f487c8 Examining commit rPOEMS165b6c54f487... Raw author string: epriestley <git@epriestley.com> Phabricator user: epriestley (Evan Priestley ) Raw committer string: epriestley <git@epriestley.com> Phabricator user: epriestley (Evan Priestley ) >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rINIH6d24c1aee7741e Examining commit rINIH6d24c1aee774... Raw author string: epriestley <hg@yghe.net> Phabricator user: epriestley (Evan Priestley ) Raw committer string: null >>> orbital ~/devtools/phabricator $ The `reparse.php` output was similar, and all VCSes resolved authors correctly. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1731, T4195 Differential Revision: https://secure.phabricator.com/D7801
2013-12-19 20:05:17 +01:00
'DiffusionResolveUserQuery' => 'Phobject',
Route some VCS connections over SSH Summary: - Add web UI for configuring SSH hosting. - Route git reads (`git-upload-pack` over SSH). Test Plan: >>> orbital ~ $ git clone ssh://127.0.0.1/ Cloning into '127.0.0.1'... Exception: Unrecognized repository path "/". Expected a path like "/diffusion/X/". fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. >>> orbital ~ $ git clone ssh://127.0.0.1/diffusion/X/ Cloning into 'X'... Exception: No repository "X" exists! fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. >>> orbital ~ $ git clone ssh://127.0.0.1/diffusion/MT/ Cloning into 'MT'... Exception: This repository is not available over SSH. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. >>> orbital ~ $ git clone ssh://127.0.0.1/diffusion/P/ Cloning into 'P'... Exception: TODO: Implement serve over SSH. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Reviewers: btrahan Reviewed By: btrahan CC: hach-que, aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7421
2013-10-26 19:46:09 +02:00
'DiffusionSSHWorkflow' => 'PhabricatorSSHWorkflow',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionSearchQueryConduitAPIMethod' => 'DiffusionQueryConduitAPIMethod',
Split Diffusion VSC serve code into its own controller Summary: This is starting to get a bit sizable and it turns out Mercurial is sort of a beast, so split the VCS serve stuff into a separate controller. Test Plan: Pushed and pulled an authenticated Git repository. Reviewers: btrahan Reviewed By: btrahan CC: aran, hach-que Differential Revision: https://secure.phabricator.com/D7494
2013-11-07 02:55:46 +01:00
'DiffusionServeController' => 'DiffusionController',
Rename `DiffusionSetPasswordPanel` for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11178
2015-01-03 14:46:28 +01:00
'DiffusionSetPasswordSettingsPanel' => 'PhabricatorSettingsPanel',
Replace AphrontUsageException with AphrontMalformedRequestException Summary: Ref T1806. Ref T7173. Context here is that I want to fix "you can not log in to this instance" being a confusing mess with an opaque error. To do this without hacks, I want to: - clean up some exception handling behavior (this diff); - modularize exception handling (next diff); - replace confusing, over-general exceptions with tailored ones in the Phacility cluster, using the new modular stuff. This cleans up an awkward "AphrontUsageException" which does some weird stuff right now. In particular, it is extensible and extended in one place in Diffusion, but that extension is meaningless. Realign this as "AphrontMalformedRequestException", which is a better description of what it is and does: raises errors before we can get as far as normal routing and site handling. Test Plan: Hit some of these exceptions, saw the expected "abandon all hope" error page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14047
2015-09-03 19:04:17 +02:00
'DiffusionSetupException' => 'Exception',
Extract repository command construction from Repositories Summary: Ref T4292. Ref T10366. Depends on D15751. Today, generating repository commands is purely a function of the repository, so they use protocols and credentials based on the repository configuration. For example, a repository with an SSH "remote URI" always generate SSH "remote commands". This needs to change in the future: - After T10366, repositories won't necessarily just have one type of remote URI. They can only have one at a time still, but the repository itself won't change based on which one is currently active. - For T4292, I need to generate intracluster commands, regardless of repository configuration. These will have different protocols and credentials. Prepare for these cases by separating out command construction, so they'll be able to generate commands in a more flexible way. Test Plan: - Added unit tests. - Browsed diffusion. - Ran `bin/phd debug pull` to pull a bunch of repos. - Ran daemons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4292, T10366 Differential Revision: https://secure.phabricator.com/D15752
2016-04-19 00:22:52 +02:00
'DiffusionSubversionCommandEngine' => 'DiffusionCommandEngine',
Rename `DiffusionSSHWorkflow` subclasses for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11185
2015-01-04 20:33:18 +01:00
'DiffusionSubversionSSHWorkflow' => 'DiffusionSSHWorkflow',
'DiffusionSubversionServeSSHWorkflow' => 'DiffusionSubversionSSHWorkflow',
Support serving SVN repositories over SSH Summary: Ref T2230. The SVN protocol has a sensible protocol format with a good spec here: http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_ra_svn/protocol Particularly, compare this statement to the clown show that is the Mercurial wire protocol: > It is possible to parse an item without knowing its type in advance. WHAT A REASONABLE STATEMENT TO BE ABLE TO MAKE ABOUT A WIRE PROTOCOL Although it makes substantially more sense than Mercurial, it's much heavier-weight than the Git or Mercurial protocols, since it isn't distributed. It's also not possible to figure out if a request is a write request (or even which repository it is against) without proxying some of the protocol frames. Finally, several protocol commands embed repository URLs, and we need to reach into the protocol and translate them. Test Plan: Ran various SVN commands over SSH (`svn log`, `svn up`, `svn commit`, etc). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7556
2013-11-11 21:19:06 +01:00
'DiffusionSubversionWireProtocol' => 'Phobject',
'DiffusionSubversionWireProtocolTestCase' => 'PhabricatorTestCase',
Implement a dedicated "diffusion.blame" API method Summary: Fixes T2451. Several motivations here, from strongest to weakest: - Currently, getting blame and file content are closely entwined. This makes fixing T9319 more difficult, and I want to fix it. I want to separate blame from content so there's more flexibility in how we approach this issue. - This makes pursuing T2450 easier, if it turns out to be a meaningful win. - If we can get a win on blame performance, we can do `arc blame` eventually if we want. Test Plan: - Blamed in SVN, Git and Mercurial. Reviewers: chad Reviewed By: chad Maniphest Tasks: T2451 Differential Revision: https://secure.phabricator.com/D14957
2016-01-06 13:56:27 +01:00
'DiffusionSvnBlameQuery' => 'DiffusionBlameQuery',
Browse / git improvements.
2011-03-14 06:03:30 +01:00
'DiffusionSvnFileContentQuery' => 'DiffusionFileContentQuery',
Add "DiffusionRawDiffQuery" Summary: - This is only slightly useful for updating Differential, since DiffQuery (vs RawDiffQuery) already gets you most of what you need. The only thing is that DiffQuery returns the diff for one path only right now(and the SVN version is very "special"). Should be easy to fix in the Git/HG cases at least, though (or maybe just use RawDiffQuery to avoid the SVN mess). - Added a "download raw diff" link. Test Plan: Viewed Diffusion and raw commits for SVN, Mercurial and Git repositories. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2350
2012-05-02 22:43:45 +02:00
'DiffusionSvnRawDiffQuery' => 'DiffusionRawDiffQuery',
Add syntax highlight to diffusion. Summary: use XHPAST parser to parse the file, and generate a table for the code to highlight it. This is part of the task of "Port Diffusion's Browse File view to Phabricator". Test Plan: browse file, try commit version, line number functionality. Reviewed By: epriestley Reviewers: epriestley CC: epriestley Differential Revision: 83
2011-03-23 03:34:47 +01:00
'DiffusionSvnRequest' => 'DiffusionRequest',
Add a simple symbol lookup interface for cross-references Summary: This will get fancier, but here's a basic interface for doing symbol lookups. Still all pretty tentative. Test Plan: Looked up various things, got some sensible results. Reviewers: jungejason, nh, tuomaspelkonen, aran Reviewed By: tuomaspelkonen CC: aran, tuomaspelkonen Differential Revision: 900
2011-09-05 19:43:24 +02:00
'DiffusionSymbolController' => 'DiffusionController',
Modernize global search typeahead datasource Summary: Ref T4420. Bring the global search up to date. Test Plan: Typed various things into global search. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9889
2014-07-18 00:48:36 +02:00
'DiffusionSymbolDatasource' => 'PhabricatorTypeaheadDatasource',
Include symbols in main typeahead Summary: - Include symbols in main typeahead results. - Simplify the symbol query a bit and extend PhabricatorOffsetPagedQuery. There was some stuff around language ranking that I got rid of, I think the theory there was that mapping file extensions to languages might not work in general but I think it works fine in practice, and we have more config stuff now around guessing languages and getting the mappings right. - Make it easier to debug the typeahead by showing the results in page format for non-ajax requests. - When we have too many results, show only the top few of each type. Depends on D3116, D3117 Test Plan: Used typeahead, got symbols in results. Hit endpoint with non-ajax, got useful debug view. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3118
2012-08-01 21:36:47 +02:00
'DiffusionSymbolQuery' => 'PhabricatorOffsetPagedQuery',
Add a paginated list of all repository tags to Diffusion Summary: Now supports more than 25 tags! Test Plan: Set page size to 1, paginated. Verified SVN / Hg don't break/explode. Reviewers: davidreuss, vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1130 Differential Revision: https://secure.phabricator.com/D2268
2012-04-19 18:39:19 +02:00
'DiffusionTagListController' => 'DiffusionController',
Add very basic tag support to Diffusion Summary: Lists the 25 most recent tags on the "Repository" page. Test Plan: Looked at a git repository with a tag, saw it. Looked at HG/SVN repos, they didn't break. Reviewers: davidreuss, 20after4, btrahan, vrana, jungejason Reviewed By: davidreuss CC: aran Maniphest Tasks: T1130 Differential Revision: https://secure.phabricator.com/D2255
2012-04-18 17:02:08 +02:00
'DiffusionTagListView' => 'DiffusionView',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionTagsQueryConduitAPIMethod' => 'DiffusionQueryConduitAPIMethod',
Add `diffusion.uri.edit` for creating and editing repository URIs Summary: Ref T10748. Brings the rest of the transactions to EditEngine, supports creating via API. Test Plan: - Created a URI via API. - Created a URI via web. - Tried to apply sneaky transactions, got rejected with good error messages. <_< >_> Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15821
2016-04-29 22:10:37 +02:00
'DiffusionURIEditConduitAPIMethod' => 'PhabricatorEditEngineAPIMethod',
Rough sketch of new repository URI editing Summary: Ref T10748. Ref T10366. This adds a new EditEngine, EditController, Editor, Query, and Transaction for RepositoryURIs. None of these really do anything helpful yet, and these URIs are still unused in the actual application. Test Plan: {F1249794} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10366, T10748 Differential Revision: https://secure.phabricator.com/D15815
2016-04-28 17:33:44 +02:00
'DiffusionURIEditEngine' => 'PhabricatorEditEngine',
'DiffusionURIEditor' => 'PhabricatorApplicationTransactionEditor',
Replace ArcanistPhutilTestCase refs with PhutilTestCase Summary: Ref T7977. Remove the `PhabricatorTestCase::getLink` method. Depends on D12665. Test Plan: `arc unit`. Reviewers: avivey, #blessed_reviewers, epriestley Reviewed By: avivey, #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7977 Differential Revision: https://secure.phabricator.com/D12667
2015-05-20 01:37:39 +02:00
'DiffusionURITestCase' => 'PhutilTestCase',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'DiffusionUpdateCoverageConduitAPIMethod' => 'DiffusionConduitAPIMethod',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionView' => 'AphrontView',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerArticleAtomizer' => 'DivinerAtomizer',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DivinerAtom' => 'Phobject',
Add a publish cache for the Diviner static publisher Summary: Keep track of what we've written to disk, and regenerate only new documents. Test Plan: Changed a small number of files, saw that number of files get regenerated. Ran with "--clean" and saw everything regenerate. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4897
2013-02-18 00:40:00 +01:00
'DivinerAtomCache' => 'DivinerDiskCache',
Add an Atom controller to Diviner Summary: Ref T988. Lots of rough edges still, but this pulls the right data and dumps it into a reasonable-looking shell. Test Plan: {F44883} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6104
2013-06-01 00:14:39 +02:00
'DivinerAtomController' => 'DivinerController',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'DivinerAtomListController' => 'DivinerController',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'DivinerAtomPHIDType' => 'PhabricatorPHIDType',
Use ApplicationSearch in Diviner Summary: Ref T988. Ref T2625. Rough cut of ApplicationSearch in Diviner, for detailed Atom queries. This isn't useful yet, and isn't linked in the UI. Test Plan: {F44836} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T2625 Differential Revision: https://secure.phabricator.com/D6094
2013-05-31 19:52:25 +02:00
'DivinerAtomQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DivinerAtomRef' => 'Phobject',
Use ApplicationSearch in Diviner Summary: Ref T988. Ref T2625. Rough cut of ApplicationSearch in Diviner, for detailed Atom queries. This isn't useful yet, and isn't linked in the UI. Test Plan: {F44836} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T2625 Differential Revision: https://secure.phabricator.com/D6094
2013-05-31 19:52:25 +02:00
'DivinerAtomSearchEngine' => 'PhabricatorApplicationSearchEngine',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerAtomizeWorkflow' => 'DivinerWorkflow',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DivinerAtomizer' => 'Phobject',
Add a book controller and various amenities to Diviner's live view Summary: Ref T988. Mostly backend changes, with a very rough frontend on top of them. See Conpherence discussion. Test Plan: {F45010} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6113
2013-06-04 20:15:34 +02:00
'DivinerBookController' => 'DivinerController',
Allow atoms to be queried by book Summary: Ref T4558. Allows querying for atoms from specified books. Depends on D13091. Test Plan: Poked around at `/diviner/query/`. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4558 Differential Revision: https://secure.phabricator.com/D13303
2015-06-19 10:06:53 +02:00
'DivinerBookDatasource' => 'PhabricatorTypeaheadDatasource',
Modernize Diviner Summary: Ref T4558. This diff modernizes the #diviner application. Basically: - Add an edit controller, accessible at `/book/$BOOK/edit/`. - Add edit/view policies. - Added an action menu to the `DivinerBookController` to expose the edit interface. - Allows projects to be associated with books. - Implement edges and transactions. - Implemented `PhabricatorApplicationTransactionInterface` in `DivinerLiveBook`. Test Plan: - Generated a Diviner book with `./bin/diviner generate`. - Added projects to a book and ensured that they persisted. - Changed the view policy on a book and made sure it was effective. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4558 Differential Revision: https://secure.phabricator.com/D13091
2015-06-16 23:09:53 +02:00
'DivinerBookEditController' => 'DivinerController',
Diviner Book Index styles Summary: Slightly more readable, less space than current index. LMK if you hate it though. Test Plan: Look at user and dev book indexes. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6932
2013-09-10 18:39:50 +02:00
'DivinerBookItemView' => 'AphrontTagView',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'DivinerBookPHIDType' => 'PhabricatorPHIDType',
Use ApplicationSearch in Diviner Summary: Ref T988. Ref T2625. Rough cut of ApplicationSearch in Diviner, for detailed Atom queries. This isn't useful yet, and isn't linked in the UI. Test Plan: {F44836} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T2625 Differential Revision: https://secure.phabricator.com/D6094
2013-05-31 19:52:25 +02:00
'DivinerBookQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'DivinerController' => 'PhabricatorController',
Add "live" publisher and storage to Diviner Summary: Ref T988. This adds basics for the non-static publishing target: - Storage (called "Live", e.g. `DivinerLiveAtom` to distinguish it from shared classes like `DivinerAtom`). - Mostly populate the storage. - Some minor fixes and improvements. Test Plan: Generated docs, looked at DB, saw mostly-sensible output. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D5973
2013-05-20 19:18:26 +02:00
'DivinerDAO' => 'PhabricatorLiskDAO',
Modernize Diviner Summary: Ref T4558. This diff modernizes the #diviner application. Basically: - Add an edit controller, accessible at `/book/$BOOK/edit/`. - Add edit/view policies. - Added an action menu to the `DivinerBookController` to expose the edit interface. - Allows projects to be associated with books. - Implement edges and transactions. - Implemented `PhabricatorApplicationTransactionInterface` in `DivinerLiveBook`. Test Plan: - Generated a Diviner book with `./bin/diviner generate`. - Added projects to a book and ensured that they persisted. - Changed the view policy on a book and made sure it was effective. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4558 Differential Revision: https://secure.phabricator.com/D13091
2015-06-16 23:09:53 +02:00
'DivinerDefaultEditCapability' => 'PhabricatorPolicyCapability',
Move Diviner further toward usability Summary: - Complete the "project" -> "book" stuff. This is cleaner conceptually and keeps us from having yet another meaning for the word "project". - Normalize symbols during atomization. This simplifies publishing a great deal, and allows static documentation to link to dynamic documentation and vice versa, because the canonical names of symbols are agreed upon (we can tweak the actual algorithm). - Give articles a specifiable name distinct from the title, and default to something like "support" instead of "Get Help! Get Support!" so URIs end up more readable (not "Get_Help!_Get_Support!"). - Have the atomizers set book information on atoms. - Implement very basic publishers. Publishers are basically glue code between the atomization process and the rendering process -- the two we'll have initially are "static" (publish to files on disk) and "phabricator" (or similar -- publish into the database). - Handle duplicate symbol definitions in the atomize and publish pipelines. This fixes the issue where a project defines two functions named "idx()" and we currently tell them not to do that and break. Realistically, this is common in the real world and we should just roll our eyes and do the legwork to generate documentation as best we can. - Particularly, dirty all atoms with the same name as a dirty atom (e.g., if 'function f()' is updated, regnerate the documentation for all functions named f() in the book). - When publishing, we publish these at "function/f/@1", "function/f/@2". The base page will offer to disambiguate ("There are 8 functions named 'f' in this codebase, which one do you want?"). - Implement a very very basic renderer. This generates the actual HTML (or text, or XML, or whatever else) for the documentation, which the publisher dumps onto disk or into a database or whatever. - The atomize workflow actually needs to depend on books, at least sort of, so make it load config and use it properly. - Propagate multilevel dirties through the graph. If "C extends B" and "B extends A", we should regenerate C when A changes. Prior to this diff, we would regnerate B only. Test Plan: Generated some documentation. Named two articles "feedback", generated docs, saw "article/feedback/@1/" and "article/feedback/@2/" created. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4896
2013-02-18 00:39:36 +01:00
'DivinerDefaultRenderer' => 'DivinerRenderer',
Modernize Diviner Summary: Ref T4558. This diff modernizes the #diviner application. Basically: - Add an edit controller, accessible at `/book/$BOOK/edit/`. - Add edit/view policies. - Added an action menu to the `DivinerBookController` to expose the edit interface. - Allows projects to be associated with books. - Implement edges and transactions. - Implemented `PhabricatorApplicationTransactionInterface` in `DivinerLiveBook`. Test Plan: - Generated a Diviner book with `./bin/diviner generate`. - Added projects to a book and ensured that they persisted. - Changed the view policy on a book and made sure it was effective. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4558 Differential Revision: https://secure.phabricator.com/D13091
2015-06-16 23:09:53 +02:00
'DivinerDefaultViewCapability' => 'PhabricatorPolicyCapability',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DivinerDiskCache' => 'Phobject',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerFileAtomizer' => 'DivinerAtomizer',
Diviner: improve links, book index, and atom view Summary: Ref T988. Minor improvements to diviner: link stuff to a valid endpoint which actually works; fix group names on the book index; improve the topics index for atom views. Test Plan: Clicked links in an article, viewed book index, viewed an article with long headers. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6598
2013-07-28 22:07:30 +02:00
'DivinerFindController' => 'DivinerController',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerGenerateWorkflow' => 'DivinerWorkflow',
Add another pattern to quoted email body stripping Summary: Ref T3217. @hlau has an email client which quotes text with: ________________________________________ From: ... Add a regular expression to correctly detect this as quoted body text. Test Plan: Add unit test; executed unit test. Reviewers: btrahan, chad Reviewed By: chad CC: hlau, aran Maniphest Tasks: T3217 Differential Revision: https://secure.phabricator.com/D5986
2013-05-21 00:52:54 +02:00
'DivinerLiveAtom' => 'DivinerDAO',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'DivinerLiveBook' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'DivinerDAO',
'PhabricatorPolicyInterface',
Modernize Diviner Summary: Ref T4558. This diff modernizes the #diviner application. Basically: - Add an edit controller, accessible at `/book/$BOOK/edit/`. - Add edit/view policies. - Added an action menu to the `DivinerBookController` to expose the edit interface. - Allows projects to be associated with books. - Implement edges and transactions. - Implemented `PhabricatorApplicationTransactionInterface` in `DivinerLiveBook`. Test Plan: - Generated a Diviner book with `./bin/diviner generate`. - Added projects to a book and ensured that they persisted. - Changed the view policy on a book and made sure it was effective. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4558 Differential Revision: https://secure.phabricator.com/D13091
2015-06-16 23:09:53 +02:00
'PhabricatorProjectInterface',
Add a "did verify email" event to Phabricator Summary: Ref T7152. Gives us an event hook so we can go make users a member of any instance they've been invited to as soon as they verify an email address. Test Plan: - Used `bin/auth verify` to trigger the event. - Build out the invite flow in rSERVICES. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11752
2015-02-11 23:39:06 +01:00
'PhabricatorDestructibleInterface',
Modernize Diviner Summary: Ref T4558. This diff modernizes the #diviner application. Basically: - Add an edit controller, accessible at `/book/$BOOK/edit/`. - Add edit/view policies. - Added an action menu to the `DivinerBookController` to expose the edit interface. - Allows projects to be associated with books. - Implement edges and transactions. - Implemented `PhabricatorApplicationTransactionInterface` in `DivinerLiveBook`. Test Plan: - Generated a Diviner book with `./bin/diviner generate`. - Added projects to a book and ensured that they persisted. - Changed the view policy on a book and made sure it was effective. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4558 Differential Revision: https://secure.phabricator.com/D13091
2015-06-16 23:09:53 +02:00
'PhabricatorApplicationTransactionInterface',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorFulltextInterface',
Add "live" publisher and storage to Diviner Summary: Ref T988. This adds basics for the non-static publishing target: - Storage (called "Live", e.g. `DivinerLiveAtom` to distinguish it from shared classes like `DivinerAtom`). - Mostly populate the storage. - Some minor fixes and improvements. Test Plan: Generated docs, looked at DB, saw mostly-sensible output. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D5973
2013-05-20 19:18:26 +02:00
),
Modernize Diviner Summary: Ref T4558. This diff modernizes the #diviner application. Basically: - Add an edit controller, accessible at `/book/$BOOK/edit/`. - Add edit/view policies. - Added an action menu to the `DivinerBookController` to expose the edit interface. - Allows projects to be associated with books. - Implement edges and transactions. - Implemented `PhabricatorApplicationTransactionInterface` in `DivinerLiveBook`. Test Plan: - Generated a Diviner book with `./bin/diviner generate`. - Added projects to a book and ensured that they persisted. - Changed the view policy on a book and made sure it was effective. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4558 Differential Revision: https://secure.phabricator.com/D13091
2015-06-16 23:09:53 +02:00
'DivinerLiveBookEditor' => 'PhabricatorApplicationTransactionEditor',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'DivinerLiveBookFulltextEngine' => 'PhabricatorFulltextEngine',
Modernize Diviner Summary: Ref T4558. This diff modernizes the #diviner application. Basically: - Add an edit controller, accessible at `/book/$BOOK/edit/`. - Add edit/view policies. - Added an action menu to the `DivinerBookController` to expose the edit interface. - Allows projects to be associated with books. - Implement edges and transactions. - Implemented `PhabricatorApplicationTransactionInterface` in `DivinerLiveBook`. Test Plan: - Generated a Diviner book with `./bin/diviner generate`. - Added projects to a book and ensured that they persisted. - Changed the view policy on a book and made sure it was effective. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4558 Differential Revision: https://secure.phabricator.com/D13091
2015-06-16 23:09:53 +02:00
'DivinerLiveBookTransaction' => 'PhabricatorApplicationTransaction',
'DivinerLiveBookTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Add "live" publisher and storage to Diviner Summary: Ref T988. This adds basics for the non-static publishing target: - Storage (called "Live", e.g. `DivinerLiveAtom` to distinguish it from shared classes like `DivinerAtom`). - Mostly populate the storage. - Some minor fixes and improvements. Test Plan: Generated docs, looked at DB, saw mostly-sensible output. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D5973
2013-05-20 19:18:26 +02:00
'DivinerLivePublisher' => 'DivinerPublisher',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'DivinerLiveSymbol' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'DivinerDAO',
'PhabricatorPolicyInterface',
'PhabricatorMarkupInterface',
Add a "did verify email" event to Phabricator Summary: Ref T7152. Gives us an event hook so we can go make users a member of any instance they've been invited to as soon as they verify an email address. Test Plan: - Used `bin/auth verify` to trigger the event. - Build out the invite flow in rSERVICES. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11752
2015-02-11 23:39:06 +01:00
'PhabricatorDestructibleInterface',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorFulltextInterface',
Use ApplicationSearch in Diviner Summary: Ref T988. Ref T2625. Rough cut of ApplicationSearch in Diviner, for detailed Atom queries. This isn't useful yet, and isn't linked in the UI. Test Plan: {F44836} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T2625 Differential Revision: https://secure.phabricator.com/D6094
2013-05-31 19:52:25 +02:00
),
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'DivinerLiveSymbolFulltextEngine' => 'PhabricatorFulltextEngine',
Give Diviner a non-legacy root controller Summary: Ref T988. Instead of hard-coding the application landing page, make the Diviner root show books if any have been generated. Otherwise, show a helpful message about how to generate documentation locally. Test Plan: {F122723} {F122724} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D8416
2014-03-05 22:07:50 +01:00
'DivinerMainController' => 'DivinerController',
Generate PHP function documentation in Diviner Summary: Ref T988. Various improvements: - Generate function documentation, mostly correctly. - Raise some warnings about bad documentation. - Allow `.book` files to exclude paths from generation. - Add a book for technical docs. - Exclude "ghosts" from common queries (atoms which used to exist, but no longer do, but which we want to keep the PHIDs around for in case they come back later). This is a bit rough still, but puts us much closer to being able to get rid of the old Diviner. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6812
2013-08-27 12:14:00 +02:00
'DivinerPHPAtomizer' => 'DivinerAtomizer',
'DivinerParameterTableView' => 'AphrontTagView',
Add a publish cache for the Diviner static publisher Summary: Keep track of what we've written to disk, and regenerate only new documents. Test Plan: Changed a small number of files, saw that number of files get regenerated. Ran with "--clean" and saw everything regenerate. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4897
2013-02-18 00:40:00 +01:00
'DivinerPublishCache' => 'DivinerDiskCache',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DivinerPublisher' => 'Phobject',
'DivinerRenderer' => 'Phobject',
Generate PHP function documentation in Diviner Summary: Ref T988. Various improvements: - Generate function documentation, mostly correctly. - Raise some warnings about bad documentation. - Allow `.book` files to exclude paths from generation. - Add a book for technical docs. - Exclude "ghosts" from common queries (atoms which used to exist, but no longer do, but which we want to keep the PHIDs around for in case they come back later). This is a bit rough still, but puts us much closer to being able to get rid of the old Diviner. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6812
2013-08-27 12:14:00 +02:00
'DivinerReturnTableView' => 'AphrontTagView',
Modernize Diviner Summary: Ref T4558. This diff modernizes the #diviner application. Basically: - Add an edit controller, accessible at `/book/$BOOK/edit/`. - Add edit/view policies. - Added an action menu to the `DivinerBookController` to expose the edit interface. - Allows projects to be associated with books. - Implement edges and transactions. - Implemented `PhabricatorApplicationTransactionInterface` in `DivinerLiveBook`. Test Plan: - Generated a Diviner book with `./bin/diviner generate`. - Added projects to a book and ensured that they persisted. - Changed the view policy on a book and made sure it was effective. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4558 Differential Revision: https://secure.phabricator.com/D13091
2015-06-16 23:09:53 +02:00
'DivinerSchemaSpec' => 'PhabricatorConfigSchemaSpec',
More Diviner style updates Summary: This adds a number of new styles for Diviner documentation. Not sure I've covered all the bases or wrote this in the most efficient manner, but passing it along now for early review before tightening everything up. Test Plan: Review various class pages. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6888
2013-09-05 21:29:07 +02:00
'DivinerSectionView' => 'AphrontTagView',
Move Diviner further toward usability Summary: - Complete the "project" -> "book" stuff. This is cleaner conceptually and keeps us from having yet another meaning for the word "project". - Normalize symbols during atomization. This simplifies publishing a great deal, and allows static documentation to link to dynamic documentation and vice versa, because the canonical names of symbols are agreed upon (we can tweak the actual algorithm). - Give articles a specifiable name distinct from the title, and default to something like "support" instead of "Get Help! Get Support!" so URIs end up more readable (not "Get_Help!_Get_Support!"). - Have the atomizers set book information on atoms. - Implement very basic publishers. Publishers are basically glue code between the atomization process and the rendering process -- the two we'll have initially are "static" (publish to files on disk) and "phabricator" (or similar -- publish into the database). - Handle duplicate symbol definitions in the atomize and publish pipelines. This fixes the issue where a project defines two functions named "idx()" and we currently tell them not to do that and break. Realistically, this is common in the real world and we should just roll our eyes and do the legwork to generate documentation as best we can. - Particularly, dirty all atoms with the same name as a dirty atom (e.g., if 'function f()' is updated, regnerate the documentation for all functions named f() in the book). - When publishing, we publish these at "function/f/@1", "function/f/@2". The base page will offer to disambiguate ("There are 8 functions named 'f' in this codebase, which one do you want?"). - Implement a very very basic renderer. This generates the actual HTML (or text, or XML, or whatever else) for the documentation, which the publisher dumps onto disk or into a database or whatever. - The atomize workflow actually needs to depend on books, at least sort of, so make it load config and use it properly. - Propagate multilevel dirties through the graph. If "C extends B" and "B extends A", we should regenerate C when A changes. Prior to this diff, we would regnerate B only. Test Plan: Generated some documentation. Named two articles "feedback", generated docs, saw "article/feedback/@1/" and "article/feedback/@2/" created. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4896
2013-02-18 00:39:36 +01:00
'DivinerStaticPublisher' => 'DivinerPublisher',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'DivinerSymbolRemarkupRule' => 'PhutilRemarkupRule',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'DivinerWorkflow' => 'PhabricatorManagementWorkflow',
Rename `DoorkeeperFeedWorker` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11148
2015-01-03 00:25:25 +01:00
'DoorkeeperAsanaFeedWorker' => 'DoorkeeperFeedWorker',
Rename some remarkup classes Summary: Ref T5655. Rename `DoorkeeperRemarkupRuleAsana` and `DoorkeeperRemarkupRuleJIRA` for consistency. Test Plan: N/A Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D13165
2015-06-08 03:27:19 +02:00
'DoorkeeperAsanaRemarkupRule' => 'DoorkeeperRemarkupRule',
Add DoorkeeperObjectRef, DoorkeeperBridge, DoorkeeperBridgeAsana Summary: - `DoorkeeperObjectRef` is a convenience object to keep track of `<applicationType, applicationDomain, objectType, objectID>` tuples. - `DoorkeeperBridge` provides pull/push between Phabricator and external systems. - `DoorkeeperBridgeAsana` is a bridge to Asana. Test Plan: Ran this snippet and got a task from Asana: {P871} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6273
2013-06-25 00:54:54 +02:00
'DoorkeeperBridge' => 'Phobject',
'DoorkeeperBridgeAsana' => 'DoorkeeperBridge',
Begin bridging GitHub objects through Doorkeeper Summary: Ref T10538. This sets up a Doorkeeper bridge for GitHub issues, and pulls issues from GitHub to create ExternalObject references. Broadly, does nothing useful. Test Plan: Put a `var_dump()` in there somewhere and saw it probably do something when running `bin/nuance update --item 44`. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10538 Differential Revision: https://secure.phabricator.com/D15447
2016-03-09 15:30:22 +01:00
'DoorkeeperBridgeGitHub' => 'DoorkeeperBridge',
'DoorkeeperBridgeGitHubIssue' => 'DoorkeeperBridgeGitHub',
Bridge GitHub users into Phabricator and attribute actions to them Summary: Ref T10538. Ref T10537. This creates PHIDs which represent GitHub users, and uses them as the actors for synchronized comments. I've just made them Doorkeeper objects. There are three major kinds of objects they //could// possibly be: - Nuance requestor objects. - External account objects. - Doorkeeper objects. I don't think we actually need distinct nuance requestor objects. These don't really do anything right now, and were originally created before Doorkeeper. I think Doorkeeper is a superset of nuance requestor functionality, and better developed and more flexible. Likewise, doorkeeper objects are much more flexible than external account objects, and it's nice to imagine that we can import from Twootfeed or whatever without needing to build full OAuth for it. I also like less stuff touching auth code, when possible. Making these separate from external accounts does make it a bit harder to reconcile external users with internal users, but I think that's OK, and that it's generally desirable to show the real source of a piece of content. That is, if I wrote a comment on GitHub but also have a Phabricator account, I think it's good to show "epriestley (GitHub)" (the GitHub user) as the author, not "epriestley" (the Phabricator user). I think this is generally less confusing overall, and we can add more linkage later to make it clearer. Test Plan: {F1194104} {F1194105} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537, T10538 Differential Revision: https://secure.phabricator.com/D15541
2016-03-28 21:01:18 +02:00
'DoorkeeperBridgeGitHubUser' => 'DoorkeeperBridgeGitHub',
Add JIRA doorkeeper and remarkup support Summary: Ref T3687. Adds a Doorkeeper bridge for JIRA issues, plus remarkup support. In particular: - The Asana and JIRA remarkup rules shared most of their implementation, so I refactored what I could into a base class. - Actual bridge implementation is straightforward and similar to Asana, although probably not similar enough to really justify refactoring. Test Plan: - When logged in as a JIRA-connected user, pasted a JIRA issue link and saw it enriched at rendering time. - Logged in and out with JIRA. - Tested an Asana link, too (seems I haven't broken anything). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6878
2013-09-04 02:27:38 +02:00
'DoorkeeperBridgeJIRA' => 'DoorkeeperBridge',
Fix JIRA issue URI selection for JIRA installs which are not on the domain root Summary: Fixes T4859. See that for details. Test Plan: - Verified things still work on my local (domain root) install. - Added some unit tests. - Did not verify a non-root install since I don't have one handy, hopefully @salehe can help. Reviewers: btrahan Reviewed By: btrahan Subscribers: salehe, epriestley Maniphest Tasks: T4859 Differential Revision: https://secure.phabricator.com/D8836
2014-05-18 14:45:21 +02:00
'DoorkeeperBridgeJIRATestCase' => 'PhabricatorTestCase',
When an object has been imported from an external source, show a curtain panel Summary: Ref T10537. Show when an object is bridged to something external. Test Plan: {F1190099} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15520
2016-03-25 13:29:19 +01:00
'DoorkeeperBridgedObjectCurtainExtension' => 'PHUICurtainExtension',
Add DoorkeeperExternalObject Summary: Ref T2852. This table holds data about external objects and allows us to write edges to them. Objects are identified with an `<applicationType, applicationDomain, objectType, objectID>` tuple. For example, Asana tasks will be, e.g., `<asana, asana.com, asana:task, 93829279873>` or similar. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6271
2013-06-25 00:54:36 +02:00
'DoorkeeperDAO' => 'PhabricatorLiskDAO',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'DoorkeeperExternalObject' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'DoorkeeperDAO',
'PhabricatorPolicyInterface',
Add DoorkeeperExternalObject Summary: Ref T2852. This table holds data about external objects and allows us to write edges to them. Objects are identified with an `<applicationType, applicationDomain, objectType, objectID>` tuple. For example, Asana tasks will be, e.g., `<asana, asana.com, asana:task, 93829279873>` or similar. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6271
2013-06-25 00:54:36 +02:00
),
Bridge GitHub users into Phabricator and attribute actions to them Summary: Ref T10538. Ref T10537. This creates PHIDs which represent GitHub users, and uses them as the actors for synchronized comments. I've just made them Doorkeeper objects. There are three major kinds of objects they //could// possibly be: - Nuance requestor objects. - External account objects. - Doorkeeper objects. I don't think we actually need distinct nuance requestor objects. These don't really do anything right now, and were originally created before Doorkeeper. I think Doorkeeper is a superset of nuance requestor functionality, and better developed and more flexible. Likewise, doorkeeper objects are much more flexible than external account objects, and it's nice to imagine that we can import from Twootfeed or whatever without needing to build full OAuth for it. I also like less stuff touching auth code, when possible. Making these separate from external accounts does make it a bit harder to reconcile external users with internal users, but I think that's OK, and that it's generally desirable to show the real source of a piece of content. That is, if I wrote a comment on GitHub but also have a Phabricator account, I think it's good to show "epriestley (GitHub)" (the GitHub user) as the author, not "epriestley" (the Phabricator user). I think this is generally less confusing overall, and we can add more linkage later to make it clearer. Test Plan: {F1194104} {F1194105} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537, T10538 Differential Revision: https://secure.phabricator.com/D15541
2016-03-28 21:01:18 +02:00
'DoorkeeperExternalObjectPHIDType' => 'PhabricatorPHIDType',
Add DoorkeeperExternalObjectQuery, expose more ref/import APIs Summary: Ref T2852. - Broadly, we support "I have a Ref, I need a PHID" well but not "I have a PHID, I need a Ref". - Add DoorkeeperExternalObjectQuery, and use it to query ExternalObjects. - Allow external objects to be imported by their internal PHIDs. Basically, if we have an edge pointing at an ExternalObject, we can say "load all the data about this" from just the PHID and have it hit all the same code. - Allow construction of Refs from ExternalObjects. This makes the "I have a PHID, I need a Ref" easier. Test Plan: - Verified Asana links still enrich properly at display time. - Used in future revision. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6294
2013-06-26 01:30:44 +02:00
'DoorkeeperExternalObjectQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DoorkeeperFeedStoryPublisher' => 'Phobject',
Refactor shared code between JIRA + Asana publishers into a base class Summary: Ref T3687. See some discussion in D6892. The JIRA doorkeeper publisher shares a reasonable amount of code with the Asana publisher. Remedy this: - Create `DoorkeeperFeedWorker`, where shared functionality lives (mostly related to building story context objects). - Push responsibility for enabling/disabling a worker into this new layer, via `isEnabled()`. This allows `FeedPublisherWorker` to dynamically find and schedule doorkeeper publishers, so third parties can add additional doorkeeper publishers. - Some general cleanup/documentation. Test Plan: Used `bin/feed republish` to republish stories about objects with JIRA and Asana links. Verified that doorkeeper publishers activated properly, made calls, and published events into the remote systems. Reviewers: btrahan, akopanev22 Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6906
2013-09-11 00:22:01 +02:00
'DoorkeeperFeedWorker' => 'FeedPushWorker',
Add remarkup support for Asana URIs Summary: Ref T2852. Primarily, this expands API access to Asana. As a user-visible effect, it links Asana tasks in Remarkup. When a user enters an Asana URI, we register an onload behavior to make an Ajax call for the lookup. This respects privacy imposed by the API without creating a significant performance impact. Test Plan: {F47183} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6274
2013-06-25 00:55:08 +02:00
'DoorkeeperImportEngine' => 'Phobject',
Rename `DoorkeeperFeedWorker` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11148
2015-01-03 00:25:25 +01:00
'DoorkeeperJIRAFeedWorker' => 'DoorkeeperFeedWorker',
Rename some remarkup classes Summary: Ref T5655. Rename `DoorkeeperRemarkupRuleAsana` and `DoorkeeperRemarkupRuleJIRA` for consistency. Test Plan: N/A Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D13165
2015-06-08 03:27:19 +02:00
'DoorkeeperJIRARemarkupRule' => 'DoorkeeperRemarkupRule',
Make "JIRA Issues" field work better with noncredentialed accounts Summary: Currently, users get an error when making any changes to this field if they don't have a linked JIRA account. Instead: - We should only raise an error if they're trying to //add// issues, and only on the new issues. It's always fine to remove issues, and existing issues the author can't see are also fine. - When we can't add things because there's no account (vs because there's a permissions error or they don't exist), raise a more tailored exception. Test Plan: - As JIRA and non-JIRA users, made various edits to this field. - Got appropriate exceptions, including better tailoring. Reviewers: btrahan Reviewed By: btrahan Subscribers: mbishopim3, epriestley Differential Revision: https://secure.phabricator.com/D8676
2014-04-02 21:03:59 +02:00
'DoorkeeperMissingLinkException' => 'Exception',
Add DoorkeeperObjectRef, DoorkeeperBridge, DoorkeeperBridgeAsana Summary: - `DoorkeeperObjectRef` is a convenience object to keep track of `<applicationType, applicationDomain, objectType, objectID>` tuples. - `DoorkeeperBridge` provides pull/push between Phabricator and external systems. - `DoorkeeperBridgeAsana` is a bridge to Asana. Test Plan: Ran this snippet and got a task from Asana: {P871} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6273
2013-06-25 00:54:54 +02:00
'DoorkeeperObjectRef' => 'Phobject',
Add JIRA doorkeeper and remarkup support Summary: Ref T3687. Adds a Doorkeeper bridge for JIRA issues, plus remarkup support. In particular: - The Asana and JIRA remarkup rules shared most of their implementation, so I refactored what I could into a base class. - Actual bridge implementation is straightforward and similar to Asana, although probably not similar enough to really justify refactoring. Test Plan: - When logged in as a JIRA-connected user, pasted a JIRA issue link and saw it enriched at rendering time. - Logged in and out with JIRA. - Tested an Asana link, too (seems I haven't broken anything). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6878
2013-09-04 02:27:38 +02:00
'DoorkeeperRemarkupRule' => 'PhutilRemarkupRule',
Generate expected schemata for Doorkeeper, Draft, Drydock, Feed Summary: Ref T1191. Notable: - Allowed objects to remove default columns (some feed tables have no `id`). - Added a "note" severity and moved all the charset stuff down to that to make progress more clear. Test Plan: Trying to make the whole thing blue... {F205970} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10519
2014-09-18 20:15:49 +02:00
'DoorkeeperSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Render linked JIRA issues with a Doorkeeper tag Summary: Fixes T3687. Instead of rendering "JIRA Issues" in Differential using plain links, render them using Doorkeeper tags so they get the nice "enhance with object name" effect. Test Plan: {F84886} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D7648
2013-11-25 23:54:35 +01:00
'DoorkeeperTagView' => 'AphrontView',
Add remarkup support for Asana URIs Summary: Ref T2852. Primarily, this expands API access to Asana. As a user-visible effect, it links Asana tasks in Remarkup. When a user enters an Asana URI, we register an onload behavior to make an Ajax call for the lookup. This respects privacy imposed by the API without creating a significant performance impact. Test Plan: {F47183} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6274
2013-06-25 00:55:08 +02:00
'DoorkeeperTagsController' => 'PhabricatorController',
Implement a rough AlmanacService blueprint in Drydock Summary: Ref T9253. Broadly, this realigns Allocator behavior to be more consistent and straightforward and amenable to intended future changes. This attempts to make language more consistent: resources are "allocated" and leases are "acquired". This prepares for (but does not implement) optimistic "slot locking", as discussed in D10304. Although I suspect some blueprints will need to perform other locking eventually, this does feel like a good fit for most of the locking blueprints need to do. In particular, I've made the blueprint operations on `$resource` and `$lease` objects more purposeful: they need to invoke an activator on the appropriate object to be implemented correctly. Before they invoke this activator method, they configure the object. In a future diff, this configuration will include specifying slot locks that the lease or resource must acquire. So the API will be something like: $lease ->setActivateWhenAcquired(true) ->needSlotLock('x') ->needSlotLock('y') ->acquireOnResource($resource); In the common case where slot locks are a good fit, I think this should make correct blueprint implementation very straightforward. This prepares for (but does not implement) resources and leases which need significant setup steps. I've basically carved out two modes: - The "activate immediately" mode, as here, immediately opens the resource or activates the lease. This is appropriate if little or no setup is required. I expect many leases to operate in this mode, although I expect many resources will operate in the other mode. - The "allocate now, activate later" mode, which is not fully implemented yet. This will queue setup workers when the allocator exits. Overall, this will work very similarly to Harbormaster. - This new structure makes it acceptable for blueprints to sleep as long as they want during resource allocation and lease acquisition, so long as they are not waiting on anything which needs to be completed by the queue. Putting a `sleep(15 * 60)` in your EC2Blueprint to wait for EC2 to bring a machine up will perform worse than using delayed activation, but won't deadlock the queue or block any locks. Overall, this flow is more similar to Harbormaster's flow. Having consistency between Harbormaster's model and Drydock's model is good, and I think Harbormaster's model is also simply much better than Drydock's (what exists today in Drydock was implemented a long time ago, and we had more support and infrastructure by the time Harbormaster was implemented, as well as a more clearly defined problem). The particular strength of Harbormaster is that objects always (or almost always, at least) have a single, clearly defined writer. Ensuring objects have only one writer prevents races and makes reasoning about everything easier. Drydock does not currently have a clearly defined single writer, but this moves us in that direction. We'll probably need more primitives eventually to flesh this out, like Harbormaster's command queue for messaging objects which you can't write to. This blueprint was originally implemented in D13843. This makes a few changes to the blueprint itself: - A bunch of code from that (e.g., interfaces) doesn't exist yet. - I let the blueprint have multiple services. This simplifies the code a little and seems like it costs us nothing. This also removes `bin/drydock create-resource`, which no longer makes sense to expose. It won't get locking, leasing, etc., correct, and can not be made correct. NOTE: This technically works but doesn't do anything useful yet. Test Plan: Used `bin/drydock lease --type host` to acquire leases against these blueprints. Reviewers: hach-que, chad Reviewed By: hach-que, chad Subscribers: Mnkras Maniphest Tasks: T9253 Differential Revision: https://secure.phabricator.com/D14117
2015-09-21 13:43:53 +02:00
'DrydockAlmanacServiceHostBlueprintImplementation' => 'DrydockBlueprintImplementation',
More Drydock Stuff Summary: - Still really really rough. - Adds a full synchronous mode for debugging. - Adds some logging. - It can now allocate EC2 machines and put webroots on them in a hacky, terrible way. - Adds a base query class. Test Plan: oh hey look a test page? http://ec2-50-18-65-151.us-west-1.compute.amazonaws.com:2011/ Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D2026
2012-03-27 05:54:26 +02:00
'DrydockApacheWebrootInterface' => 'DrydockWebrootInterface',
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 16:15:25 +02:00
'DrydockAuthorization' => array(
'DrydockDAO',
'PhabricatorPolicyInterface',
),
'DrydockAuthorizationAuthorizeController' => 'DrydockController',
'DrydockAuthorizationListController' => 'DrydockController',
'DrydockAuthorizationListView' => 'AphrontView',
'DrydockAuthorizationPHIDType' => 'PhabricatorPHIDType',
'DrydockAuthorizationQuery' => 'DrydockQuery',
'DrydockAuthorizationSearchEngine' => 'PhabricatorApplicationSearchEngine',
'DrydockAuthorizationViewController' => 'DrydockController',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'DrydockBlueprint' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'DrydockDAO',
Transactions - land buildTransactionTimeline in a bunch more apps Summary: Ref T4712. Specifically... - Dashboards - two objects needed PhabricatorApplicationTransactionInterface - Macros - Paste - Phlux - one object needed PhabricatorApplicationTransactionInterface - added setShouldTerminate(true) - Files - one object needed PhabricatorApplicationTransactionInterface - Passphrase - one object needed PhabricatorApplicationTransactionInterface - added setShouldTerminate(true) - Drydock - one object needed PhabricatorApplicationTransactionInterface - added setShouldTerminate(true) Test Plan: foreach application, verify that the timeline(s) showed up correctly, including with appropriate setShouldTerminate-ness Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10924
2014-12-03 22:16:15 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
Allow Drydock blueprints to define and use custom fields Summary: This allows Drydock blueprints to define custom fields for blueprint settings. Test Plan: Pulled out of EC2 allocator diff. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D10224
2014-08-12 00:39:00 +02:00
'PhabricatorCustomFieldInterface',
Allow Drydock blueprints to be searched by name Summary: Ref T10457. The ngram indexing seems to be working well; extend it into Drydock. Also clean up the list controller a little bit. Test Plan: - Ran migrations. - Searched for blueprints by name. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15389
2016-03-03 13:17:24 +01:00
'PhabricatorNgramsInterface',
Allow Drydock blueprints to be tagged and searched, and give types some little icons Summary: Ref T10457. - Let blueprints be tagged so you can search and annotate them a little more easily. - Give each blueprint type an optional icon to make things a little easier to parse visually. Test Plan: - Tagged blueprints. - Searched by tags. - Looked at nice little icons. {F1139712} Reviewers: chad Reviewed By: chad Subscribers: yelirekim Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15392
2016-03-03 14:52:21 +01:00
'PhabricatorProjectInterface',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
),
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockBlueprintController' => 'DrydockController',
Allow Drydock blueprints to define and use custom fields Summary: This allows Drydock blueprints to define custom fields for blueprint settings. Test Plan: Pulled out of EC2 allocator diff. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D10224
2014-08-12 00:39:00 +02:00
'DrydockBlueprintCoreCustomField' => array(
'DrydockBlueprintCustomField',
'PhabricatorStandardCustomFieldInterface',
),
'DrydockBlueprintCustomField' => 'PhabricatorCustomField',
Improve Drydock log search engine Summary: Ref T2015. This allows searching based on blueprints, resources or leases when viewing the logs, which helps when searching for events that occured to a particular blueprint / resource / lease. Unlike the logs shown on the resource / lease pages, the search engine supports paging properly, which means it can be used to find entries in the past. Test Plan: Used the Drydock log search page. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: joshuaspence, Korvin, epriestley Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D10874
2015-08-24 13:13:20 +02:00
'DrydockBlueprintDatasource' => 'PhabricatorTypeaheadDatasource',
Allow Drydock blueprints to be disabled Summary: Ref T9252. If you have a blueprint and you do not like that blueprint very much, you can disable it. Test Plan: Disabled / enabled some blueprints. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14156
2015-09-24 19:18:17 +02:00
'DrydockBlueprintDisableController' => 'DrydockBlueprintController',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockBlueprintEditController' => 'DrydockBlueprintController',
Convert DrydockBlueprints to EditEngine Summary: Ref T10457. Fixes T10024. This primarily just modernizes blueprints to use EditEngine. This also fixes T10024, which was an issue with stored properties not being flagged correctly. Also slightly improves typeaheads for blueprints (more information, disabled state). Test Plan: - Created and edited various types of blueprints. - Set and removed limits. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10024, T10457 Differential Revision: https://secure.phabricator.com/D15390
2016-03-03 13:34:47 +01:00
'DrydockBlueprintEditEngine' => 'PhabricatorEditEngine',
Add transactions to Drydock blueprint editing Summary: Ref T2015. Fixes TODO. Test Plan: {F100338} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7922
2014-01-09 21:19:54 +01:00
'DrydockBlueprintEditor' => 'PhabricatorApplicationTransactionEditor',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DrydockBlueprintImplementation' => 'Phobject',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'DrydockBlueprintImplementationTestCase' => 'PhabricatorTestCase',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'DrydockBlueprintListController' => 'DrydockBlueprintController',
Allow Drydock blueprints to be searched by name Summary: Ref T10457. The ngram indexing seems to be working well; extend it into Drydock. Also clean up the list controller a little bit. Test Plan: - Ran migrations. - Searched for blueprints by name. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15389
2016-03-03 13:17:24 +01:00
'DrydockBlueprintNameNgrams' => 'PhabricatorSearchNgrams',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'DrydockBlueprintPHIDType' => 'PhabricatorPHIDType',
Introduce DrydockQuery to slightly reduce code duplication Summary: Ref T2015. All the Drydock query classes share the application method; move it into a shared base class to slightly shrink the codebase. Test Plan: Browsed query UIs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7837
2013-12-27 22:15:30 +01:00
'DrydockBlueprintQuery' => 'DrydockQuery',
Use ApplicationSearch for Drydock Blueprints Summary: Ref T2015. This turns the side nav into a bigger mess for now, but uses ApplicationSearch for blueprints. Test Plan: Queried blueprints in the UI. Reviewers: btrahan Reviewed By: btrahan CC: hach-que, aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7829
2013-12-26 21:30:04 +01:00
'DrydockBlueprintSearchEngine' => 'PhabricatorApplicationSearchEngine',
Add transactions to Drydock blueprint editing Summary: Ref T2015. Fixes TODO. Test Plan: {F100338} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7922
2014-01-09 21:19:54 +01:00
'DrydockBlueprintTransaction' => 'PhabricatorApplicationTransaction',
'DrydockBlueprintTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockBlueprintViewController' => 'DrydockBlueprintController',
Add a command queue to Drydock to manage lease/resource release Summary: Ref T9252. Broadly, Drydock currently races on releasing objects from the "active" state. To reproduce this: - Scatter some sleep()s pretty much anywhere in the release code. - Release several times from web UI or CLI in quick succession. Resources or leases will execute some release code twice or otherwise do inconsistent things. (I didn't chase down a detailed reproduction scenario for this since inspection of the code makes it clear that there are no meaningful locks or mechanisms preventing this.) Instead, add a Harbormaster-style command queue to resources and leases. When something wants to do a release, it adds a command to the queue and schedules a worker. The workers acquire a lock, then try to consume commands from the queue. This guarantees that only one process is responsible for writes to active resource/leases. This is the last major step to giving resources and leases a single writer during all states: - Resource, Unsaved: AllocatorWorker - Resource, Pending: ResourceWorker (Possible rename to "Allocated?") - Resource, Open: This diff, ResourceUpdateWorker. (Likely rename to "Active"). - Resource, Closed/Broken: Future destruction worker. (Likely rename to "Released" / "Broken"; maybe remove "Broken"). - Resource, Destroyed: No writes. - Lease, Unsaved: Whatever wants the lease. - Lease, Pending: AllocatorWorker - Lease, Acquired: LeaseWorker - Lease, Active: This diff, LeaseUpdateWorker. - Lease, Released/Broken: Future destruction worker (Maybe remove "Broken"?) - Lease, Expired: No writes. (Likely rename to "Destroyed"). In most phases, we can already guarantee that there is a single writer without doing any extra work. This is more complicated in the "Active" case because the release buttons on the web UI, the release tools on the CLI, the lease requestor itself, the garbage collector, and any other release process cleaning up related objects may try to effect a release. All of these could race one another (and, in many cases, race other processes from other phases because all of these get to act immediately) as this code is currently written. Using a queue here lets us make sure there's only a single writer in this phase. One thing which is notable is that whatever acquires a lease **can not write to it**! It is never the writer once it queues the lease for activation. It can not write to any resources, either. And, likewise, Blueprints can not write to resources while acquiring or releasing leases. We may need to provide a mechinism so that blueprints and/or resource/lease holders get to attach some storage to resources/leases for bookkeeping. For example, a blueprint might need to keep some kind of cache on a resource to help it manage state. But I think we can cross that bridge when we come to it, and nothing else would need to write to this storage so it's technically straightforward to introduce such a mechanism if we need one. Test Plan: - Viewed buttons in web UI, checked enabled/disabled states. - Clicked the buttons. - Saw commands show up in the command queue. - Saw some daemon stuff get scheduled. - Ran CLI tools, saw commands get consumed and resources/leases release. Reviewers: hach-que, chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14143
2015-09-23 16:42:08 +02:00
'DrydockCommand' => array(
'DrydockDAO',
'PhabricatorPolicyInterface',
),
Improve Drydock errors for empty commits and missing changes Summary: Ref T10093. Show better errors when a commit fails because it has already been merged and when a fetch fails because the ref isn't present in the remote. Test Plan: {F1160794} {F1160795} Reviewers: chad Reviewed By: chad Subscribers: michaeljs1990, yelirekim Maniphest Tasks: T10093 Differential Revision: https://secure.phabricator.com/D15420
2016-03-07 00:13:40 +01:00
'DrydockCommandError' => 'Phobject',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockCommandInterface' => 'DrydockInterface',
Add a command queue to Drydock to manage lease/resource release Summary: Ref T9252. Broadly, Drydock currently races on releasing objects from the "active" state. To reproduce this: - Scatter some sleep()s pretty much anywhere in the release code. - Release several times from web UI or CLI in quick succession. Resources or leases will execute some release code twice or otherwise do inconsistent things. (I didn't chase down a detailed reproduction scenario for this since inspection of the code makes it clear that there are no meaningful locks or mechanisms preventing this.) Instead, add a Harbormaster-style command queue to resources and leases. When something wants to do a release, it adds a command to the queue and schedules a worker. The workers acquire a lock, then try to consume commands from the queue. This guarantees that only one process is responsible for writes to active resource/leases. This is the last major step to giving resources and leases a single writer during all states: - Resource, Unsaved: AllocatorWorker - Resource, Pending: ResourceWorker (Possible rename to "Allocated?") - Resource, Open: This diff, ResourceUpdateWorker. (Likely rename to "Active"). - Resource, Closed/Broken: Future destruction worker. (Likely rename to "Released" / "Broken"; maybe remove "Broken"). - Resource, Destroyed: No writes. - Lease, Unsaved: Whatever wants the lease. - Lease, Pending: AllocatorWorker - Lease, Acquired: LeaseWorker - Lease, Active: This diff, LeaseUpdateWorker. - Lease, Released/Broken: Future destruction worker (Maybe remove "Broken"?) - Lease, Expired: No writes. (Likely rename to "Destroyed"). In most phases, we can already guarantee that there is a single writer without doing any extra work. This is more complicated in the "Active" case because the release buttons on the web UI, the release tools on the CLI, the lease requestor itself, the garbage collector, and any other release process cleaning up related objects may try to effect a release. All of these could race one another (and, in many cases, race other processes from other phases because all of these get to act immediately) as this code is currently written. Using a queue here lets us make sure there's only a single writer in this phase. One thing which is notable is that whatever acquires a lease **can not write to it**! It is never the writer once it queues the lease for activation. It can not write to any resources, either. And, likewise, Blueprints can not write to resources while acquiring or releasing leases. We may need to provide a mechinism so that blueprints and/or resource/lease holders get to attach some storage to resources/leases for bookkeeping. For example, a blueprint might need to keep some kind of cache on a resource to help it manage state. But I think we can cross that bridge when we come to it, and nothing else would need to write to this storage so it's technically straightforward to introduce such a mechanism if we need one. Test Plan: - Viewed buttons in web UI, checked enabled/disabled states. - Clicked the buttons. - Saw commands show up in the command queue. - Saw some daemon stuff get scheduled. - Ran CLI tools, saw commands get consumed and resources/leases release. Reviewers: hach-que, chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14143
2015-09-23 16:42:08 +02:00
'DrydockCommandQuery' => 'DrydockQuery',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockConsoleController' => 'DrydockController',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DrydockConstants' => 'Phobject',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockController' => 'PhabricatorController',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'DrydockCreateBlueprintsCapability' => 'PhabricatorPolicyCapability',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockDAO' => 'PhabricatorLiskDAO',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'DrydockDefaultEditCapability' => 'PhabricatorPolicyCapability',
'DrydockDefaultViewCapability' => 'PhabricatorPolicyCapability',
Implement "Upload Artifact" build step Summary: This implements a build step for uploading an artifact from a build machine to Phabricator. It uses SFTP so that it will work on both UNIX and Windows build machines. Test Plan: Ran an "Upload Artifact" build against a Windows machine (with FreeSSHD installed). The artifact uploaded to Phabricator, appeared on the build view and the file contents could be viewed from Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7582
2013-12-06 04:11:05 +01:00
'DrydockFilesystemInterface' => 'DrydockInterface',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'DrydockInterface' => 'Phobject',
Rough cut of DrydockRepositoryOperation Summary: Ref T182. This doesn't do anything interesting yet and is mostly scaffolding, but here's roughly the workflow. From previous revision, you can configure "Repository Automation" for a repository: {F875741} If it's configured, a new "Land Revision" button shows up: {F875743} Once you click it you get a big warning dialog that it won't work, and then this shows up at the top of the revision (completely temporary/placeholder UI, some day a nice progress bar or whatever): {F875747} If you're lucky, the operation eventually sort of works: {F875750} It only runs `git show` right now, doesn't actually do any writes or anything. Test Plan: - Clicked "Land Revision". - Watched `phd debug task`. - Saw it log `git show` to output. - Verified operation success in UI (by fiddling URL, no way to get there normally yet). Reviewers: chad Reviewed By: chad Subscribers: revi Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D14266
2015-10-14 00:46:12 +02:00
'DrydockLandRepositoryOperation' => 'DrydockRepositoryOperationType',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'DrydockLease' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'DrydockDAO',
'PhabricatorPolicyInterface',
Use ApplicationSearch to manage DrydockLeases Summary: Ref T2015. Applies ApplicationSearch to DrydockLease. This makes the left nav in Drydock a little funky. It will probably get worse for a bit before it gets better, since I want to bring everything to ApplicationSearch and then sort out the details. Test Plan: Queried leases in Drydock. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7827
2013-12-26 19:42:00 +01:00
),
Add Drydock log types and more logging Summary: Ref T9252. Make log types modular so they can be translated and have complicated rendering logic if necessary (currently, none have this). Test Plan: {F855330} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14198
2015-10-01 17:10:07 +02:00
'DrydockLeaseAcquiredLogType' => 'DrydockLogType',
'DrydockLeaseActivatedLogType' => 'DrydockLogType',
Add more Drydock log types and some additional logging Summary: Ref T9252. Add a bit more logging and improve some behaviors. Test Plan: Restarted a build, got a good result. Reviewers: chad, hach-que Reviewed By: hach-que Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14210
2015-10-01 17:11:42 +02:00
'DrydockLeaseActivationFailureLogType' => 'DrydockLogType',
'DrydockLeaseActivationYieldLogType' => 'DrydockLogType',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockLeaseController' => 'DrydockController',
Improve Drydock log search engine Summary: Ref T2015. This allows searching based on blueprints, resources or leases when viewing the logs, which helps when searching for events that occured to a particular blueprint / resource / lease. Unlike the logs shown on the resource / lease pages, the search engine supports paging properly, which means it can be used to find entries in the past. Test Plan: Used the Drydock log search page. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: joshuaspence, Korvin, epriestley Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D10874
2015-08-24 13:13:20 +02:00
'DrydockLeaseDatasource' => 'PhabricatorTypeaheadDatasource',
Add Drydock log types and more logging Summary: Ref T9252. Make log types modular so they can be translated and have complicated rendering logic if necessary (currently, none have this). Test Plan: {F855330} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14198
2015-10-01 17:10:07 +02:00
'DrydockLeaseDestroyedLogType' => 'DrydockLogType',
Move Drydock object list rendering to SearchEngine Summary: Ref T4986. Allows the Drydock search engines to render as panels. Test Plan: Viewed affected interfaces in Drydock. Created panels from each engine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9103
2014-05-13 21:14:33 +02:00
'DrydockLeaseListController' => 'DrydockLeaseController',
'DrydockLeaseListView' => 'AphrontView',
Use Drydock authorizations when acquiring leases Summary: Ref T9519. When acquiring leases on resources: - Only consider resources created by authorized blueprints. - Only consider authorized blueprints when creating new resources. - Fail with a tailored error if no blueprints are allowed. - Fail with a tailored error if missing authorizations are causing acquisition failure. One somewhat-substantial issue with this is that it's pretty hard to figure out from the Harbormaster side. Specifically, the Build step UI does not show field value anywhere, so the presence of unapproved blueprints is not communicated. This is much more clear in Drydock. I'll plan to address this in future changes to Harbormaster, since there are other related/similar issues anyway. Test Plan: {F872527} Reviewers: hach-que, chad Reviewed By: chad Maniphest Tasks: T9519 Differential Revision: https://secure.phabricator.com/D14254
2015-10-13 02:02:35 +02:00
'DrydockLeaseNoAuthorizationsLogType' => 'DrydockLogType',
'DrydockLeaseNoBlueprintsLogType' => 'DrydockLogType',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'DrydockLeasePHIDType' => 'PhabricatorPHIDType',
Introduce DrydockQuery to slightly reduce code duplication Summary: Ref T2015. All the Drydock query classes share the application method; move it into a shared base class to slightly shrink the codebase. Test Plan: Browsed query UIs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7837
2013-12-27 22:15:30 +01:00
'DrydockLeaseQuery' => 'DrydockQuery',
Add Drydock log types and more logging Summary: Ref T9252. Make log types modular so they can be translated and have complicated rendering logic if necessary (currently, none have this). Test Plan: {F855330} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14198
2015-10-01 17:10:07 +02:00
'DrydockLeaseQueuedLogType' => 'DrydockLogType',
Make Drydock reclaim unused resources when it reaches a resource limit Summary: Fixes T9994. Currently, when Drydock can't allocate a new resource because some limit has been reached, it waits patiently for a resource to become available. It is possible that no resource will ever become available. Particularly with "Working Copy" resources, the new lease may want a copy of `rB`, but the resource may already be maxed out on `rA`. Right now, no process exists to automatically reclaim the unused `rA`. When we encounter this situation, try to reclaim one of the other resources if it is just sitting there unused. Specifically: - Add a "reclaim" command which means "release this resource //if// it is completely unused". - Add a `bin/drydock reclaim` to send this command to every active resource. - When we try to acquire a resource and can't, but only because of some kind of limit / utilization problem, try to release an unused resource to free up some room. Test Plan: - Set "Working Copy" resource limit to 1. - Ran "Test Configuration" in `rA`, which worked. - Ran "Test Configuration" in `rB`, which hung forever. - Applied patch. - Ran "Test Configuration" in `rB`, saw it reclaim the `rA` resource, use the slot, then succeed. - Ran "Test Configuration" in `rA` again, saw it grab the slot back. - Ran `bin/drydock reclaim` and saw it reclaim a bunch of old orphaned resources. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9994 Differential Revision: https://secure.phabricator.com/D14819
2015-12-18 17:44:13 +01:00
'DrydockLeaseReclaimLogType' => 'DrydockLogType',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockLeaseReleaseController' => 'DrydockLeaseController',
Add Drydock log types and more logging Summary: Ref T9252. Make log types modular so they can be translated and have complicated rendering logic if necessary (currently, none have this). Test Plan: {F855330} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14198
2015-10-01 17:10:07 +02:00
'DrydockLeaseReleasedLogType' => 'DrydockLogType',
Use ApplicationSearch to manage DrydockLeases Summary: Ref T2015. Applies ApplicationSearch to DrydockLease. This makes the left nav in Drydock a little funky. It will probably get worse for a bit before it gets better, since I want to bring everything to ApplicationSearch and then sort out the details. Test Plan: Queried leases in Drydock. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7827
2013-12-26 19:42:00 +01:00
'DrydockLeaseSearchEngine' => 'PhabricatorApplicationSearchEngine',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockLeaseStatus' => 'DrydockConstants',
Add a command queue to Drydock to manage lease/resource release Summary: Ref T9252. Broadly, Drydock currently races on releasing objects from the "active" state. To reproduce this: - Scatter some sleep()s pretty much anywhere in the release code. - Release several times from web UI or CLI in quick succession. Resources or leases will execute some release code twice or otherwise do inconsistent things. (I didn't chase down a detailed reproduction scenario for this since inspection of the code makes it clear that there are no meaningful locks or mechanisms preventing this.) Instead, add a Harbormaster-style command queue to resources and leases. When something wants to do a release, it adds a command to the queue and schedules a worker. The workers acquire a lock, then try to consume commands from the queue. This guarantees that only one process is responsible for writes to active resource/leases. This is the last major step to giving resources and leases a single writer during all states: - Resource, Unsaved: AllocatorWorker - Resource, Pending: ResourceWorker (Possible rename to "Allocated?") - Resource, Open: This diff, ResourceUpdateWorker. (Likely rename to "Active"). - Resource, Closed/Broken: Future destruction worker. (Likely rename to "Released" / "Broken"; maybe remove "Broken"). - Resource, Destroyed: No writes. - Lease, Unsaved: Whatever wants the lease. - Lease, Pending: AllocatorWorker - Lease, Acquired: LeaseWorker - Lease, Active: This diff, LeaseUpdateWorker. - Lease, Released/Broken: Future destruction worker (Maybe remove "Broken"?) - Lease, Expired: No writes. (Likely rename to "Destroyed"). In most phases, we can already guarantee that there is a single writer without doing any extra work. This is more complicated in the "Active" case because the release buttons on the web UI, the release tools on the CLI, the lease requestor itself, the garbage collector, and any other release process cleaning up related objects may try to effect a release. All of these could race one another (and, in many cases, race other processes from other phases because all of these get to act immediately) as this code is currently written. Using a queue here lets us make sure there's only a single writer in this phase. One thing which is notable is that whatever acquires a lease **can not write to it**! It is never the writer once it queues the lease for activation. It can not write to any resources, either. And, likewise, Blueprints can not write to resources while acquiring or releasing leases. We may need to provide a mechinism so that blueprints and/or resource/lease holders get to attach some storage to resources/leases for bookkeeping. For example, a blueprint might need to keep some kind of cache on a resource to help it manage state. But I think we can cross that bridge when we come to it, and nothing else would need to write to this storage so it's technically straightforward to introduce such a mechanism if we need one. Test Plan: - Viewed buttons in web UI, checked enabled/disabled states. - Clicked the buttons. - Saw commands show up in the command queue. - Saw some daemon stuff get scheduled. - Ran CLI tools, saw commands get consumed and resources/leases release. Reviewers: hach-que, chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14143
2015-09-23 16:42:08 +02:00
'DrydockLeaseUpdateWorker' => 'DrydockWorker',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockLeaseViewController' => 'DrydockLeaseController',
Add more Drydock log types and some additional logging Summary: Ref T9252. Add a bit more logging and improve some behaviors. Test Plan: Restarted a build, got a good result. Reviewers: chad, hach-que Reviewed By: hach-que Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14210
2015-10-01 17:11:42 +02:00
'DrydockLeaseWaitingForResourcesLogType' => 'DrydockLogType',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'DrydockLog' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'DrydockDAO',
'PhabricatorPolicyInterface',
Use ApplicationSearch for DrydockLog Summary: Ref T2015. Move logs over to ApplicationSearch. Test Plan: Browsed logs in UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7832
2013-12-26 21:30:29 +01:00
),
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockLogController' => 'DrydockController',
Garbage collect Drydock logs after 30 days Summary: Ref T9252. Drydock logs are almost exclusively useful as a diagnostic tool for debugging immediate problems, so GC them fairly aggressively. (I expect 99% of the usefulness of these logs to be within the first 24 hours, basically "why isn't my thing working". I can't really think of any cases where having old logs would be useful.) Test Plan: - Ran GC, saw it hit the log table (with no effect). - Changed TTL from 30 days to 30 seconds, ran GC, saw it wipe recent logs. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14197
2015-10-01 17:09:27 +02:00
'DrydockLogGarbageCollector' => 'PhabricatorGarbageCollector',
Move Drydock object list rendering to SearchEngine Summary: Ref T4986. Allows the Drydock search engines to render as panels. Test Plan: Viewed affected interfaces in Drydock. Created panels from each engine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9103
2014-05-13 21:14:33 +02:00
'DrydockLogListController' => 'DrydockLogController',
'DrydockLogListView' => 'AphrontView',
Introduce DrydockQuery to slightly reduce code duplication Summary: Ref T2015. All the Drydock query classes share the application method; move it into a shared base class to slightly shrink the codebase. Test Plan: Browsed query UIs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7837
2013-12-27 22:15:30 +01:00
'DrydockLogQuery' => 'DrydockQuery',
Use ApplicationSearch for DrydockLog Summary: Ref T2015. Move logs over to ApplicationSearch. Test Plan: Browsed logs in UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7832
2013-12-26 21:30:29 +01:00
'DrydockLogSearchEngine' => 'PhabricatorApplicationSearchEngine',
Add Drydock log types and more logging Summary: Ref T9252. Make log types modular so they can be translated and have complicated rendering logic if necessary (currently, none have this). Test Plan: {F855330} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14198
2015-10-01 17:10:07 +02:00
'DrydockLogType' => 'Phobject',
Allow AlmanacHost blueprints to build a meaningful CommandInterface Summary: Ref T9253. Provide a meaningful command interface for Almanac hosts. Test Plan: Configued and leased a real host (`sbuild001.phacility.net`) and ran a command on it. ``` $ ./bin/drydock command --lease 90 -- ls / bin boot core dev etc home initrd.img lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var vmlinuz ``` Reviewers: chad, hach-que Reviewed By: chad, hach-que Maniphest Tasks: T9253 Differential Revision: https://secure.phabricator.com/D14126
2015-09-21 13:46:02 +02:00
'DrydockManagementCommandWorkflow' => 'DrydockManagementWorkflow',
Modernize the `drydock` script Summary: Add a bin/drydock symlink and break it into workflows. Nothing too special here. Test Plan: Ran `bin/drydock wait-for-lease`, `bin/drydock lease`, `bin/drydock help`, etc. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3867
2012-11-01 23:30:14 +01:00
'DrydockManagementLeaseWorkflow' => 'DrydockManagementWorkflow',
Make Drydock reclaim unused resources when it reaches a resource limit Summary: Fixes T9994. Currently, when Drydock can't allocate a new resource because some limit has been reached, it waits patiently for a resource to become available. It is possible that no resource will ever become available. Particularly with "Working Copy" resources, the new lease may want a copy of `rB`, but the resource may already be maxed out on `rA`. Right now, no process exists to automatically reclaim the unused `rA`. When we encounter this situation, try to reclaim one of the other resources if it is just sitting there unused. Specifically: - Add a "reclaim" command which means "release this resource //if// it is completely unused". - Add a `bin/drydock reclaim` to send this command to every active resource. - When we try to acquire a resource and can't, but only because of some kind of limit / utilization problem, try to release an unused resource to free up some room. Test Plan: - Set "Working Copy" resource limit to 1. - Ran "Test Configuration" in `rA`, which worked. - Ran "Test Configuration" in `rB`, which hung forever. - Applied patch. - Ran "Test Configuration" in `rB`, saw it reclaim the `rA` resource, use the slot, then succeed. - Ran "Test Configuration" in `rA` again, saw it grab the slot back. - Ran `bin/drydock reclaim` and saw it reclaim a bunch of old orphaned resources. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9994 Differential Revision: https://secure.phabricator.com/D14819
2015-12-18 17:44:13 +01:00
'DrydockManagementReclaimWorkflow' => 'DrydockManagementWorkflow',
Add a command queue to Drydock to manage lease/resource release Summary: Ref T9252. Broadly, Drydock currently races on releasing objects from the "active" state. To reproduce this: - Scatter some sleep()s pretty much anywhere in the release code. - Release several times from web UI or CLI in quick succession. Resources or leases will execute some release code twice or otherwise do inconsistent things. (I didn't chase down a detailed reproduction scenario for this since inspection of the code makes it clear that there are no meaningful locks or mechanisms preventing this.) Instead, add a Harbormaster-style command queue to resources and leases. When something wants to do a release, it adds a command to the queue and schedules a worker. The workers acquire a lock, then try to consume commands from the queue. This guarantees that only one process is responsible for writes to active resource/leases. This is the last major step to giving resources and leases a single writer during all states: - Resource, Unsaved: AllocatorWorker - Resource, Pending: ResourceWorker (Possible rename to "Allocated?") - Resource, Open: This diff, ResourceUpdateWorker. (Likely rename to "Active"). - Resource, Closed/Broken: Future destruction worker. (Likely rename to "Released" / "Broken"; maybe remove "Broken"). - Resource, Destroyed: No writes. - Lease, Unsaved: Whatever wants the lease. - Lease, Pending: AllocatorWorker - Lease, Acquired: LeaseWorker - Lease, Active: This diff, LeaseUpdateWorker. - Lease, Released/Broken: Future destruction worker (Maybe remove "Broken"?) - Lease, Expired: No writes. (Likely rename to "Destroyed"). In most phases, we can already guarantee that there is a single writer without doing any extra work. This is more complicated in the "Active" case because the release buttons on the web UI, the release tools on the CLI, the lease requestor itself, the garbage collector, and any other release process cleaning up related objects may try to effect a release. All of these could race one another (and, in many cases, race other processes from other phases because all of these get to act immediately) as this code is currently written. Using a queue here lets us make sure there's only a single writer in this phase. One thing which is notable is that whatever acquires a lease **can not write to it**! It is never the writer once it queues the lease for activation. It can not write to any resources, either. And, likewise, Blueprints can not write to resources while acquiring or releasing leases. We may need to provide a mechinism so that blueprints and/or resource/lease holders get to attach some storage to resources/leases for bookkeeping. For example, a blueprint might need to keep some kind of cache on a resource to help it manage state. But I think we can cross that bridge when we come to it, and nothing else would need to write to this storage so it's technically straightforward to introduce such a mechanism if we need one. Test Plan: - Viewed buttons in web UI, checked enabled/disabled states. - Clicked the buttons. - Saw commands show up in the command queue. - Saw some daemon stuff get scheduled. - Ran CLI tools, saw commands get consumed and resources/leases release. Reviewers: hach-que, chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14143
2015-09-23 16:42:08 +02:00
'DrydockManagementReleaseLeaseWorkflow' => 'DrydockManagementWorkflow',
'DrydockManagementReleaseResourceWorkflow' => 'DrydockManagementWorkflow',
'DrydockManagementUpdateLeaseWorkflow' => 'DrydockManagementWorkflow',
'DrydockManagementUpdateResourceWorkflow' => 'DrydockManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'DrydockManagementWorkflow' => 'PhabricatorManagementWorkflow',
Allow "Repository Automation" to be configured for repositories Summary: Ref T182. This allows you to assign blueprints that a repository can use to perform working copy operations. Eventually, this will support "merge this" in Differential, etc. This is just UI for now, with no material effects. Most of this diff is just taking logic that was in the existing "Blueprints" CustomField and putting it in more general places so Diffusion (which does not use CustomFields) can also access it. Test Plan: - Configured repository automation for a repository. - Removed repository automation for a repository. Reviewers: chad Reviewed By: chad Subscribers: avivey Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D14259
2015-10-14 00:45:59 +02:00
'DrydockObjectAuthorizationView' => 'AphrontView',
Introduce DrydockQuery to slightly reduce code duplication Summary: Ref T2015. All the Drydock query classes share the application method; move it into a shared base class to slightly shrink the codebase. Test Plan: Browsed query UIs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7837
2013-12-27 22:15:30 +01:00
'DrydockQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Rough cut of DrydockRepositoryOperation Summary: Ref T182. This doesn't do anything interesting yet and is mostly scaffolding, but here's roughly the workflow. From previous revision, you can configure "Repository Automation" for a repository: {F875741} If it's configured, a new "Land Revision" button shows up: {F875743} Once you click it you get a big warning dialog that it won't work, and then this shows up at the top of the revision (completely temporary/placeholder UI, some day a nice progress bar or whatever): {F875747} If you're lucky, the operation eventually sort of works: {F875750} It only runs `git show` right now, doesn't actually do any writes or anything. Test Plan: - Clicked "Land Revision". - Watched `phd debug task`. - Saw it log `git show` to output. - Verified operation success in UI (by fiddling URL, no way to get there normally yet). Reviewers: chad Reviewed By: chad Subscribers: revi Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D14266
2015-10-14 00:46:12 +02:00
'DrydockRepositoryOperation' => array(
'DrydockDAO',
'PhabricatorPolicyInterface',
),
Make Drydock repository operations a little more modern and consistent Summary: Ref T10457. Use modern controller and UI tech to build the list view and actions. Test Plan: - Viewed operation list. - Viewed operation detail. - Checked menus on mobile. {F1139757} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15393
2016-03-03 15:34:18 +01:00
'DrydockRepositoryOperationController' => 'DrydockController',
'DrydockRepositoryOperationDismissController' => 'DrydockRepositoryOperationController',
'DrydockRepositoryOperationListController' => 'DrydockRepositoryOperationController',
Rough cut of DrydockRepositoryOperation Summary: Ref T182. This doesn't do anything interesting yet and is mostly scaffolding, but here's roughly the workflow. From previous revision, you can configure "Repository Automation" for a repository: {F875741} If it's configured, a new "Land Revision" button shows up: {F875743} Once you click it you get a big warning dialog that it won't work, and then this shows up at the top of the revision (completely temporary/placeholder UI, some day a nice progress bar or whatever): {F875747} If you're lucky, the operation eventually sort of works: {F875750} It only runs `git show` right now, doesn't actually do any writes or anything. Test Plan: - Clicked "Land Revision". - Watched `phd debug task`. - Saw it log `git show` to output. - Verified operation success in UI (by fiddling URL, no way to get there normally yet). Reviewers: chad Reviewed By: chad Subscribers: revi Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D14266
2015-10-14 00:46:12 +02:00
'DrydockRepositoryOperationPHIDType' => 'PhabricatorPHIDType',
'DrydockRepositoryOperationQuery' => 'DrydockQuery',
Add a basic list view for repository operations Summary: Ref T182. Nothing fancy, just make these slightly easier to work with. Test Plan: {F884754} Reviewers: chad Reviewed By: chad Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D14295
2015-10-17 03:47:05 +02:00
'DrydockRepositoryOperationSearchEngine' => 'PhabricatorApplicationSearchEngine',
Make Drydock repository operations a little more modern and consistent Summary: Ref T10457. Use modern controller and UI tech to build the list view and actions. Test Plan: - Viewed operation list. - Viewed operation detail. - Checked menus on mobile. {F1139757} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15393
2016-03-03 15:34:18 +01:00
'DrydockRepositoryOperationStatusController' => 'DrydockRepositoryOperationController',
Show a more reasonable status element for pull requests Summary: Ref T182. Replace the total mess we had before with a sort-of-reasonable element. This automatically updates using "javascript". Test Plan: {F901983} {F901984} Used "Land Revision", saw the land status go from "Waiting" -> "Working" -> "Landed" without having to mash reload over and over again. Reviewers: chad Reviewed By: chad Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D14314
2015-10-21 20:28:26 +02:00
'DrydockRepositoryOperationStatusView' => 'AphrontView',
Rough cut of DrydockRepositoryOperation Summary: Ref T182. This doesn't do anything interesting yet and is mostly scaffolding, but here's roughly the workflow. From previous revision, you can configure "Repository Automation" for a repository: {F875741} If it's configured, a new "Land Revision" button shows up: {F875743} Once you click it you get a big warning dialog that it won't work, and then this shows up at the top of the revision (completely temporary/placeholder UI, some day a nice progress bar or whatever): {F875747} If you're lucky, the operation eventually sort of works: {F875750} It only runs `git show` right now, doesn't actually do any writes or anything. Test Plan: - Clicked "Land Revision". - Watched `phd debug task`. - Saw it log `git show` to output. - Verified operation success in UI (by fiddling URL, no way to get there normally yet). Reviewers: chad Reviewed By: chad Subscribers: revi Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D14266
2015-10-14 00:46:12 +02:00
'DrydockRepositoryOperationType' => 'Phobject',
'DrydockRepositoryOperationUpdateWorker' => 'DrydockWorker',
Make Drydock repository operations a little more modern and consistent Summary: Ref T10457. Use modern controller and UI tech to build the list view and actions. Test Plan: - Viewed operation list. - Viewed operation detail. - Checked menus on mobile. {F1139757} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15393
2016-03-03 15:34:18 +01:00
'DrydockRepositoryOperationViewController' => 'DrydockRepositoryOperationController',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'DrydockResource' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'DrydockDAO',
'PhabricatorPolicyInterface',
Update a few things in Drydock for policies Summary: DrydockResource has been updated to be policy-aware (although there are no policy columns). Test Plan: Clicked around in Drydock, viewed resources and leases, everything still seemed to work. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T3605, T4111 Differential Revision: https://secure.phabricator.com/D7595
2013-11-27 22:32:51 +01:00
),
Add more Drydock log types and some additional logging Summary: Ref T9252. Add a bit more logging and improve some behaviors. Test Plan: Restarted a build, got a good result. Reviewers: chad, hach-que Reviewed By: hach-que Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14210
2015-10-01 17:11:42 +02:00
'DrydockResourceActivationFailureLogType' => 'DrydockLogType',
'DrydockResourceActivationYieldLogType' => 'DrydockLogType',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockResourceController' => 'DrydockController',
Improve Drydock log search engine Summary: Ref T2015. This allows searching based on blueprints, resources or leases when viewing the logs, which helps when searching for events that occured to a particular blueprint / resource / lease. Unlike the logs shown on the resource / lease pages, the search engine supports paging properly, which means it can be used to find entries in the past. Test Plan: Used the Drydock log search page. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: joshuaspence, Korvin, epriestley Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D10874
2015-08-24 13:13:20 +02:00
'DrydockResourceDatasource' => 'PhabricatorTypeaheadDatasource',
Move Drydock object list rendering to SearchEngine Summary: Ref T4986. Allows the Drydock search engines to render as panels. Test Plan: Viewed affected interfaces in Drydock. Created panels from each engine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9103
2014-05-13 21:14:33 +02:00
'DrydockResourceListController' => 'DrydockResourceController',
'DrydockResourceListView' => 'AphrontView',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'DrydockResourcePHIDType' => 'PhabricatorPHIDType',
Introduce DrydockQuery to slightly reduce code duplication Summary: Ref T2015. All the Drydock query classes share the application method; move it into a shared base class to slightly shrink the codebase. Test Plan: Browsed query UIs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7837
2013-12-27 22:15:30 +01:00
'DrydockResourceQuery' => 'DrydockQuery',
Make Drydock reclaim unused resources when it reaches a resource limit Summary: Fixes T9994. Currently, when Drydock can't allocate a new resource because some limit has been reached, it waits patiently for a resource to become available. It is possible that no resource will ever become available. Particularly with "Working Copy" resources, the new lease may want a copy of `rB`, but the resource may already be maxed out on `rA`. Right now, no process exists to automatically reclaim the unused `rA`. When we encounter this situation, try to reclaim one of the other resources if it is just sitting there unused. Specifically: - Add a "reclaim" command which means "release this resource //if// it is completely unused". - Add a `bin/drydock reclaim` to send this command to every active resource. - When we try to acquire a resource and can't, but only because of some kind of limit / utilization problem, try to release an unused resource to free up some room. Test Plan: - Set "Working Copy" resource limit to 1. - Ran "Test Configuration" in `rA`, which worked. - Ran "Test Configuration" in `rB`, which hung forever. - Applied patch. - Ran "Test Configuration" in `rB`, saw it reclaim the `rA` resource, use the slot, then succeed. - Ran "Test Configuration" in `rA` again, saw it grab the slot back. - Ran `bin/drydock reclaim` and saw it reclaim a bunch of old orphaned resources. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9994 Differential Revision: https://secure.phabricator.com/D14819
2015-12-18 17:44:13 +01:00
'DrydockResourceReclaimLogType' => 'DrydockLogType',
Add a command queue to Drydock to manage lease/resource release Summary: Ref T9252. Broadly, Drydock currently races on releasing objects from the "active" state. To reproduce this: - Scatter some sleep()s pretty much anywhere in the release code. - Release several times from web UI or CLI in quick succession. Resources or leases will execute some release code twice or otherwise do inconsistent things. (I didn't chase down a detailed reproduction scenario for this since inspection of the code makes it clear that there are no meaningful locks or mechanisms preventing this.) Instead, add a Harbormaster-style command queue to resources and leases. When something wants to do a release, it adds a command to the queue and schedules a worker. The workers acquire a lock, then try to consume commands from the queue. This guarantees that only one process is responsible for writes to active resource/leases. This is the last major step to giving resources and leases a single writer during all states: - Resource, Unsaved: AllocatorWorker - Resource, Pending: ResourceWorker (Possible rename to "Allocated?") - Resource, Open: This diff, ResourceUpdateWorker. (Likely rename to "Active"). - Resource, Closed/Broken: Future destruction worker. (Likely rename to "Released" / "Broken"; maybe remove "Broken"). - Resource, Destroyed: No writes. - Lease, Unsaved: Whatever wants the lease. - Lease, Pending: AllocatorWorker - Lease, Acquired: LeaseWorker - Lease, Active: This diff, LeaseUpdateWorker. - Lease, Released/Broken: Future destruction worker (Maybe remove "Broken"?) - Lease, Expired: No writes. (Likely rename to "Destroyed"). In most phases, we can already guarantee that there is a single writer without doing any extra work. This is more complicated in the "Active" case because the release buttons on the web UI, the release tools on the CLI, the lease requestor itself, the garbage collector, and any other release process cleaning up related objects may try to effect a release. All of these could race one another (and, in many cases, race other processes from other phases because all of these get to act immediately) as this code is currently written. Using a queue here lets us make sure there's only a single writer in this phase. One thing which is notable is that whatever acquires a lease **can not write to it**! It is never the writer once it queues the lease for activation. It can not write to any resources, either. And, likewise, Blueprints can not write to resources while acquiring or releasing leases. We may need to provide a mechinism so that blueprints and/or resource/lease holders get to attach some storage to resources/leases for bookkeeping. For example, a blueprint might need to keep some kind of cache on a resource to help it manage state. But I think we can cross that bridge when we come to it, and nothing else would need to write to this storage so it's technically straightforward to introduce such a mechanism if we need one. Test Plan: - Viewed buttons in web UI, checked enabled/disabled states. - Clicked the buttons. - Saw commands show up in the command queue. - Saw some daemon stuff get scheduled. - Ran CLI tools, saw commands get consumed and resources/leases release. Reviewers: hach-que, chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14143
2015-09-23 16:42:08 +02:00
'DrydockResourceReleaseController' => 'DrydockResourceController',
Use ApplicationSearch for Drydock Resources Summary: Ref T2015. Bring ApplicationSearch to Resources, too. Test Plan: Browsed/queried resources in UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7830
2013-12-26 21:30:10 +01:00
'DrydockResourceSearchEngine' => 'PhabricatorApplicationSearchEngine',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockResourceStatus' => 'DrydockConstants',
Add a command queue to Drydock to manage lease/resource release Summary: Ref T9252. Broadly, Drydock currently races on releasing objects from the "active" state. To reproduce this: - Scatter some sleep()s pretty much anywhere in the release code. - Release several times from web UI or CLI in quick succession. Resources or leases will execute some release code twice or otherwise do inconsistent things. (I didn't chase down a detailed reproduction scenario for this since inspection of the code makes it clear that there are no meaningful locks or mechanisms preventing this.) Instead, add a Harbormaster-style command queue to resources and leases. When something wants to do a release, it adds a command to the queue and schedules a worker. The workers acquire a lock, then try to consume commands from the queue. This guarantees that only one process is responsible for writes to active resource/leases. This is the last major step to giving resources and leases a single writer during all states: - Resource, Unsaved: AllocatorWorker - Resource, Pending: ResourceWorker (Possible rename to "Allocated?") - Resource, Open: This diff, ResourceUpdateWorker. (Likely rename to "Active"). - Resource, Closed/Broken: Future destruction worker. (Likely rename to "Released" / "Broken"; maybe remove "Broken"). - Resource, Destroyed: No writes. - Lease, Unsaved: Whatever wants the lease. - Lease, Pending: AllocatorWorker - Lease, Acquired: LeaseWorker - Lease, Active: This diff, LeaseUpdateWorker. - Lease, Released/Broken: Future destruction worker (Maybe remove "Broken"?) - Lease, Expired: No writes. (Likely rename to "Destroyed"). In most phases, we can already guarantee that there is a single writer without doing any extra work. This is more complicated in the "Active" case because the release buttons on the web UI, the release tools on the CLI, the lease requestor itself, the garbage collector, and any other release process cleaning up related objects may try to effect a release. All of these could race one another (and, in many cases, race other processes from other phases because all of these get to act immediately) as this code is currently written. Using a queue here lets us make sure there's only a single writer in this phase. One thing which is notable is that whatever acquires a lease **can not write to it**! It is never the writer once it queues the lease for activation. It can not write to any resources, either. And, likewise, Blueprints can not write to resources while acquiring or releasing leases. We may need to provide a mechinism so that blueprints and/or resource/lease holders get to attach some storage to resources/leases for bookkeeping. For example, a blueprint might need to keep some kind of cache on a resource to help it manage state. But I think we can cross that bridge when we come to it, and nothing else would need to write to this storage so it's technically straightforward to introduce such a mechanism if we need one. Test Plan: - Viewed buttons in web UI, checked enabled/disabled states. - Clicked the buttons. - Saw commands show up in the command queue. - Saw some daemon stuff get scheduled. - Ran CLI tools, saw commands get consumed and resources/leases release. Reviewers: hach-que, chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14143
2015-09-23 16:42:08 +02:00
'DrydockResourceUpdateWorker' => 'DrydockWorker',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockResourceViewController' => 'DrydockResourceController',
Implement "Upload Artifact" build step Summary: This implements a build step for uploading an artifact from a build machine to Phabricator. It uses SFTP so that it will work on both UNIX and Windows build machines. Test Plan: Ran an "Upload Artifact" build against a Windows machine (with FreeSSHD installed). The artifact uploaded to Phabricator, appeared on the build view and the file contents could be viewed from Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7582
2013-12-06 04:11:05 +01:00
'DrydockSFTPFilesystemInterface' => 'DrydockFilesystemInterface',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockSSHCommandInterface' => 'DrydockCommandInterface',
Allow Drydock blueprints to be tagged and searched, and give types some little icons Summary: Ref T10457. - Let blueprints be tagged so you can search and annotate them a little more easily. - Give each blueprint type an optional icon to make things a little easier to parse visually. Test Plan: - Tagged blueprints. - Searched by tags. - Looked at nice little icons. {F1139712} Reviewers: chad Reviewed By: chad Subscribers: yelirekim Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15392
2016-03-03 14:52:21 +01:00
'DrydockSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Implement optimistic "slot locks" in Drydock Summary: See discussion in D10304. There's a lot of context there, but the general idea is: - Blueprints should manage locks in a granular way during the actual allocation/acquisition phase. - Optimistic "slot locks" might a pretty good primitive to make that easy to implement and reason about in most cases. The way these locks work is that you just pick some name for the lock (like the PHID of a resource) and say that it needs to be acquired for the allocation/acquisition to work: ``` ... ->needSlotLock("mylock(PHID-XYZQ-...)") ... ``` When you fire off the acquisition or allocation, it fails unless it could acquire the slot with that name. This is really simple (no explicit lock management) and a pretty good fit for most of the locking that blueprints and leases need to do. If you need to do limit-based locks (e.g., maximum of 3 locks) you could acquire a lock like this: ``` mylock(whatever).slot(2) ``` Blueprints generally only contend with themselves, so it's normally OK for them to pick whatever strategy works best for them in naming locks. This may not work as well if you have a huge number of slots (e.g., 100TB you want to give out in 1MB chunks), or other complex needs for locks (like you have to synchronize access to some external resource), but slot locks don't need to be the only mechanism that blueprints use. If they run into a problem that slot locks aren't a good fit for, they can use something else instead. For now, slot locks seem like a good fit for the problems we currently face and most of the problems I anticipate facing. (The release workflows have other race issues which I'm not addressing here. They work fine if nothing races, but aren't race-safe.) Test Plan: To create a race where the same binding is allocated as a resource twice: - Add `sleep(10)` near the beginning of `allocateResource()`, after the free bindings are loaded but before resources are allocated. - (Comment out slot lock acquisition if you have this patch.) - Run `bin/drydock lease ...` in two windows, within 10 seconds of one another. This will reliably double-allocate the binding because both blueprints see a view of the world where the binding is free. To verify the lock works, un-comment it (or apply this patch) and run the same test again. Now, the lock fails in one process and only one resource is allocated. Reviewers: hach-que, chad Reviewed By: hach-que, chad Differential Revision: https://secure.phabricator.com/D14118
2015-09-21 13:45:25 +02:00
'DrydockSlotLock' => 'DrydockDAO',
Support working copies and separate allocate + activate steps for resources/leases in Drydock Summary: Ref T9253. For resources and leases that need to do something which takes a lot of time or requires waiting, allow them to allocate/acquire first and then activate later. When we allocate a resource or acquire a lease, the blueprint can either activate it immediately (if all the work can happen quickly/inline) or activate it later. If the blueprint activates it later, we queue a worker to handle activating it. Rebuild the "working copy" blueprint to work with this model: it allocates/acquires and activates in a separate step, once it is able to acquire a host. Test Plan: With some power of imagination, brought up a bunch of working copies with `bin/drydock lease --type working-copy ...` Reviewers: hach-que, chad Reviewed By: hach-que, chad Maniphest Tasks: T9253 Differential Revision: https://secure.phabricator.com/D14127
2015-09-21 13:46:24 +02:00
'DrydockSlotLockException' => 'Exception',
Add more Drydock log types and some additional logging Summary: Ref T9252. Add a bit more logging and improve some behaviors. Test Plan: Restarted a build, got a good result. Reviewers: chad, hach-que Reviewed By: hach-que Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14210
2015-10-01 17:11:42 +02:00
'DrydockSlotLockFailureLogType' => 'DrydockLogType',
Add some Drydock documentation plus "Test Configuration" for repository automation Summary: Ref T182. Ref T9252. - Adds a "Test" repository operation that just runs `git status` to see if things work. - Adds a button for it in Edit Repository. - Shows operation status on the operation detail view to make this workflow work a little better. - Adds a lot of words. Words words words words. Test Plan: - Tested repository operation. - Read words. Reviewers: chad Reviewed By: chad Maniphest Tasks: T182, T9252 Differential Revision: https://secure.phabricator.com/D14349
2015-10-27 19:04:02 +01:00
'DrydockTestRepositoryOperation' => 'DrydockRepositoryOperationType',
More Drydock Stuff Summary: - Still really really rough. - Adds a full synchronous mode for debugging. - Adds some logging. - It can now allocate EC2 machines and put webroots on them in a hacky, terrible way. - Adds a base query class. Test Plan: oh hey look a test page? http://ec2-50-18-65-151.us-west-1.compute.amazonaws.com:2011/ Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D2026
2012-03-27 05:54:26 +02:00
'DrydockWebrootInterface' => 'DrydockInterface',
Support working copies and separate allocate + activate steps for resources/leases in Drydock Summary: Ref T9253. For resources and leases that need to do something which takes a lot of time or requires waiting, allow them to allocate/acquire first and then activate later. When we allocate a resource or acquire a lease, the blueprint can either activate it immediately (if all the work can happen quickly/inline) or activate it later. If the blueprint activates it later, we queue a worker to handle activating it. Rebuild the "working copy" blueprint to work with this model: it allocates/acquires and activates in a separate step, once it is able to acquire a host. Test Plan: With some power of imagination, brought up a bunch of working copies with `bin/drydock lease --type working-copy ...` Reviewers: hach-que, chad Reviewed By: hach-que, chad Maniphest Tasks: T9253 Differential Revision: https://secure.phabricator.com/D14127
2015-09-21 13:46:24 +02:00
'DrydockWorker' => 'PhabricatorWorker',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockWorkingCopyBlueprintImplementation' => 'DrydockBlueprintImplementation',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'FeedConduitAPIMethod' => 'ConduitAPIMethod',
'FeedPublishConduitAPIMethod' => 'FeedConduitAPIMethod',
Push feed publishing deeper into the task queue Summary: Ref T2852. I want to model Asana integration as a response to feed events. Currently, we queue one feed event for each HTTP hook. Instead, always queue one feed event and then have it queue any necessary followup events (now, http hooks; soon, asana). Add a script to make it easy to reproducibly fire feed event publishing. Test Plan: Republished a feed event and verified it hit configured HTTP hooks correctly. $ ./bin/feed republish 5765774156541908292 --trace >>> [2] <connect> phabricator2_feed <<< [2] <connect> 1,660 us >>> [3] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [3] <query> 595 us >>> [4] <connect> phabricator2_differential <<< [4] <connect> 760 us >>> [5] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [5] <query> 478 us >>> [6] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [6] <query> 449 us >>> [7] <connect> phabricator2_user <<< [7] <connect> 1,062 us >>> [8] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [8] <query> 540 us >>> [9] <connect> phabricator2_file <<< [9] <connect> 951 us >>> [10] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [10] <query> 498 us >>> [11] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [11] <query> 507 us Republishing story... >>> [12] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [12] <query> 685 us >>> [13] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [13] <query> 489 us >>> [14] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [14] <query> 512 us >>> [15] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [15] <query> 601 us >>> [16] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [16] <query> 405 us >>> [17] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [17] <query> 551 us >>> [18] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [18] <query> 507 us >>> [19] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [19] <query> 428 us >>> [20] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [20] <query> 419 us >>> [21] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [21] <query> 591 us >>> [22] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [22] <query> 406 us >>> [23] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [23] <query> 593 us >>> [24] <http> http://127.0.0.1/derp/ <<< [24] <http> 746,157 us [2013-06-24 20:23:26] EXCEPTION: (HTTPFutureResponseStatusHTTP) [HTTP/500] Internal Server Error Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6291
2013-06-26 01:29:47 +02:00
'FeedPublisherHTTPWorker' => 'FeedPushWorker',
'FeedPublisherWorker' => 'FeedPushWorker',
'FeedPushWorker' => 'PhabricatorWorker',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'FeedQueryConduitAPIMethod' => 'FeedConduitAPIMethod',
Garbage collect old notifications Summary: Fixes T8473. Adds garbage collection to the `phabricator_feed.feed_storynotification` table. Test Plan: Reduced the TTL to a really small value and ran the trigger daemon. Saw feed notifications removed from the database. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T8473 Differential Revision: https://secure.phabricator.com/D13233
2015-06-10 15:08:57 +02:00
'FeedStoryNotificationGarbageCollector' => 'PhabricatorGarbageCollector',
Add a chunking storage engine for files Summary: Ref T7149. This isn't complete and isn't active yet, but does basically work. I'll shore it up in the next few diffs. The new workflow goes like this: > Client, file.allocate(): I'd like to upload a file with length L, metadata M, and hash H. Then the server returns `upload` (a boolean) and `filePHID` (a PHID). These mean: | upload | filePHID | means | |---|---|---| | false | false | Server can't accept file. | false | true | File data already known, file created from hash. | true | false | Just upload normally. | true | true | Query chunks to start or resume a chunked upload. All but the last case are uninteresting and work like exising uploads with `file.uploadhash` (which we can eventually deprecate). In the last case: > Client, file.querychunks(): Give me a list of chunks that I should upload. This returns all the chunks for the file. Chunks have a start byte, an end byte, and a "complete" flag to indicate that the server already has the data. Then, the client fills in chunks by sending them: > Client, file.uploadchunk(): Here is the data for one chunk. This stuff doesn't work yet or has some caveats: - I haven't tested resume much. - Files need an "isPartial()" flag for partial uploads, and the UI needs to respect it. - The JS client needs to become chunk-aware. - Chunk size is set crazy low to make testing easier. - Some debugging flags that I'll remove soon-ish. - Downloading works, but still streams the whole file into memory. - This storage engine is disabled by default (hardcoded as a unit test engine) because it's still sketchy. - Need some code to remove the "isParital" flag when the last chunk is uploaded. - Maybe do checksumming on chunks. Test Plan: - Hacked up `arc upload` (see next diff) to be chunk-aware and uploaded a readme in 18 32-byte chunks. Then downloaded it. Got the same file back that I uploaded. - File UI now shows some basic chunk info for chunked files: {F336434} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12060
2015-03-13 19:30:02 +01:00
'FileAllocateConduitAPIMethod' => 'FileConduitAPIMethod',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'FileConduitAPIMethod' => 'ConduitAPIMethod',
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
'FileCreateMailReceiver' => 'PhabricatorMailReceiver',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'FileDownloadConduitAPIMethod' => 'FileConduitAPIMethod',
'FileInfoConduitAPIMethod' => 'FileConduitAPIMethod',
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
'FileMailReceiver' => 'PhabricatorObjectMailReceiver',
Add a chunking storage engine for files Summary: Ref T7149. This isn't complete and isn't active yet, but does basically work. I'll shore it up in the next few diffs. The new workflow goes like this: > Client, file.allocate(): I'd like to upload a file with length L, metadata M, and hash H. Then the server returns `upload` (a boolean) and `filePHID` (a PHID). These mean: | upload | filePHID | means | |---|---|---| | false | false | Server can't accept file. | false | true | File data already known, file created from hash. | true | false | Just upload normally. | true | true | Query chunks to start or resume a chunked upload. All but the last case are uninteresting and work like exising uploads with `file.uploadhash` (which we can eventually deprecate). In the last case: > Client, file.querychunks(): Give me a list of chunks that I should upload. This returns all the chunks for the file. Chunks have a start byte, an end byte, and a "complete" flag to indicate that the server already has the data. Then, the client fills in chunks by sending them: > Client, file.uploadchunk(): Here is the data for one chunk. This stuff doesn't work yet or has some caveats: - I haven't tested resume much. - Files need an "isPartial()" flag for partial uploads, and the UI needs to respect it. - The JS client needs to become chunk-aware. - Chunk size is set crazy low to make testing easier. - Some debugging flags that I'll remove soon-ish. - Downloading works, but still streams the whole file into memory. - This storage engine is disabled by default (hardcoded as a unit test engine) because it's still sketchy. - Need some code to remove the "isParital" flag when the last chunk is uploaded. - Maybe do checksumming on chunks. Test Plan: - Hacked up `arc upload` (see next diff) to be chunk-aware and uploaded a readme in 18 32-byte chunks. Then downloaded it. Got the same file back that I uploaded. - File UI now shows some basic chunk info for chunked files: {F336434} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12060
2015-03-13 19:30:02 +01:00
'FileQueryChunksConduitAPIMethod' => 'FileConduitAPIMethod',
Subclass most ReplyHandlers from TransactionReplyHandler Summary: Ref T7199. Half of these aren't even reachable, but make some progress toward reducing the amount of nonsense and garbage in mail handling. Test Plan: Tested all reachable handlers with `bin/mail receive-test`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12237
2015-04-01 17:39:50 +02:00
'FileReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Add a chunking storage engine for files Summary: Ref T7149. This isn't complete and isn't active yet, but does basically work. I'll shore it up in the next few diffs. The new workflow goes like this: > Client, file.allocate(): I'd like to upload a file with length L, metadata M, and hash H. Then the server returns `upload` (a boolean) and `filePHID` (a PHID). These mean: | upload | filePHID | means | |---|---|---| | false | false | Server can't accept file. | false | true | File data already known, file created from hash. | true | false | Just upload normally. | true | true | Query chunks to start or resume a chunked upload. All but the last case are uninteresting and work like exising uploads with `file.uploadhash` (which we can eventually deprecate). In the last case: > Client, file.querychunks(): Give me a list of chunks that I should upload. This returns all the chunks for the file. Chunks have a start byte, an end byte, and a "complete" flag to indicate that the server already has the data. Then, the client fills in chunks by sending them: > Client, file.uploadchunk(): Here is the data for one chunk. This stuff doesn't work yet or has some caveats: - I haven't tested resume much. - Files need an "isPartial()" flag for partial uploads, and the UI needs to respect it. - The JS client needs to become chunk-aware. - Chunk size is set crazy low to make testing easier. - Some debugging flags that I'll remove soon-ish. - Downloading works, but still streams the whole file into memory. - This storage engine is disabled by default (hardcoded as a unit test engine) because it's still sketchy. - Need some code to remove the "isParital" flag when the last chunk is uploaded. - Maybe do checksumming on chunks. Test Plan: - Hacked up `arc upload` (see next diff) to be chunk-aware and uploaded a readme in 18 32-byte chunks. Then downloaded it. Got the same file back that I uploaded. - File UI now shows some basic chunk info for chunked files: {F336434} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12060
2015-03-13 19:30:02 +01:00
'FileUploadChunkConduitAPIMethod' => 'FileConduitAPIMethod',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'FileUploadConduitAPIMethod' => 'FileConduitAPIMethod',
'FileUploadHashConduitAPIMethod' => 'FileConduitAPIMethod',
Add default policy to Files application Summary: **WIP** This adds default capability to the Files application Test Plan: Set default to public, go to Files page, see public preset. Upload File. Doesn't work. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6564 Differential Revision: https://secure.phabricator.com/D10888
2014-11-21 20:17:20 +01:00
'FilesDefaultViewCapability' => 'PhabricatorPolicyCapability',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'FlagConduitAPIMethod' => 'ConduitAPIMethod',
'FlagDeleteConduitAPIMethod' => 'FlagConduitAPIMethod',
'FlagEditConduitAPIMethod' => 'FlagConduitAPIMethod',
'FlagQueryConduitAPIMethod' => 'FlagConduitAPIMethod',
Allow users to back initiatives in Fund Summary: Ref T5835. This is still completely made up (no payment integration), but you can "back" an initiative, type a number in the box, and generate a database row. You can then seach for backers and things you've backed and such. Notable changes: - Renamed "FundBacking" to "FundBacker". The former name was sort of because you can back things multiple times, but stuff like `$backings` was just too weird. - I think that's it? Test Plan: - Backed an initiative. - Viewed that I became a backer. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10486
2014-09-12 15:31:11 +02:00
'FundBacker' => array(
Scaffolding for Fund Summary: Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet. You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc). Only notable decisions: - Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative. - I think that's it? Test Plan: - Created an initiative. - Edited an initiative. - Changed application policy defaults. - Searched for initiatives. - Subscribed to an initiative. - Opened/closed an initiative. - Used `I123` and `{I123}` in remarkup. - Destroyed an initiative. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
'FundDAO',
'PhabricatorPolicyInterface',
'PhabricatorApplicationTransactionInterface',
),
Give applications control over Phortune cart logic Summary: Ref T2787. Similar to D10634, give applications more control over the cart workflow. For now this just means they get to pick exit URIs, but in the future they can manage more details of cart behavior. Test Plan: Funded an initiative and got returned to the initiative instead of dead-ending in Phortune. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10638
2014-10-06 23:19:08 +02:00
'FundBackerCart' => 'PhortuneCartImplementation',
Allow users to back initiatives in Fund Summary: Ref T5835. This is still completely made up (no payment integration), but you can "back" an initiative, type a number in the box, and generate a database row. You can then seach for backers and things you've backed and such. Notable changes: - Renamed "FundBacking" to "FundBacker". The former name was sort of because you can back things multiple times, but stuff like `$backings` was just too weird. - I think that's it? Test Plan: - Backed an initiative. - Viewed that I became a backer. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10486
2014-09-12 15:31:11 +02:00
'FundBackerEditor' => 'PhabricatorApplicationTransactionEditor',
'FundBackerListController' => 'FundController',
'FundBackerPHIDType' => 'PhabricatorPHIDType',
Move Phortune product logic into applications Summary: Ref T2787. `Product` is currently a fairly heavy object, but as Phortune develops it makes a lot of sense to make it a lighter object and put more product logic in applications. Convert it into a fairly lightweight reference to applications. The idea is that Phortune is mostly providing a cart flow, and applications manage the details of products. Test Plan: Funded an initiative for $1. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10634
2014-10-06 19:30:06 +02:00
'FundBackerProduct' => 'PhortuneProductImplementation',
Allow users to back initiatives in Fund Summary: Ref T5835. This is still completely made up (no payment integration), but you can "back" an initiative, type a number in the box, and generate a database row. You can then seach for backers and things you've backed and such. Notable changes: - Renamed "FundBacking" to "FundBacker". The former name was sort of because you can back things multiple times, but stuff like `$backings` was just too weird. - I think that's it? Test Plan: - Backed an initiative. - Viewed that I became a backer. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10486
2014-09-12 15:31:11 +02:00
'FundBackerQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'FundBackerSearchEngine' => 'PhabricatorApplicationSearchEngine',
'FundBackerTransaction' => 'PhabricatorApplicationTransaction',
'FundBackerTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Scaffolding for Fund Summary: Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet. You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc). Only notable decisions: - Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative. - I think that's it? Test Plan: - Created an initiative. - Edited an initiative. - Changed application policy defaults. - Searched for initiatives. - Subscribed to an initiative. - Opened/closed an initiative. - Used `I123` and `{I123}` in remarkup. - Destroyed an initiative. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
'FundController' => 'PhabricatorController',
'FundCreateInitiativesCapability' => 'PhabricatorPolicyCapability',
'FundDAO' => 'PhabricatorLiskDAO',
'FundDefaultViewCapability' => 'PhabricatorPolicyCapability',
'FundInitiative' => array(
'FundDAO',
'PhabricatorPolicyInterface',
'PhabricatorProjectInterface',
'PhabricatorApplicationTransactionInterface',
'PhabricatorSubscribableInterface',
'PhabricatorMentionableInterface',
'PhabricatorFlaggableInterface',
'PhabricatorTokenReceiverInterface',
'PhabricatorDestructibleInterface',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorFulltextInterface',
Scaffolding for Fund Summary: Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet. You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc). Only notable decisions: - Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative. - I think that's it? Test Plan: - Created an initiative. - Edited an initiative. - Changed application policy defaults. - Searched for initiatives. - Subscribed to an initiative. - Opened/closed an initiative. - Used `I123` and `{I123}` in remarkup. - Destroyed an initiative. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
),
Allow users to back initiatives in Fund Summary: Ref T5835. This is still completely made up (no payment integration), but you can "back" an initiative, type a number in the box, and generate a database row. You can then seach for backers and things you've backed and such. Notable changes: - Renamed "FundBacking" to "FundBacker". The former name was sort of because you can back things multiple times, but stuff like `$backings` was just too weird. - I think that's it? Test Plan: - Backed an initiative. - Viewed that I became a backer. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10486
2014-09-12 15:31:11 +02:00
'FundInitiativeBackController' => 'FundController',
Scaffolding for Fund Summary: Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet. You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc). Only notable decisions: - Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative. - I think that's it? Test Plan: - Created an initiative. - Edited an initiative. - Changed application policy defaults. - Searched for initiatives. - Subscribed to an initiative. - Opened/closed an initiative. - Used `I123` and `{I123}` in remarkup. - Destroyed an initiative. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
'FundInitiativeCloseController' => 'FundController',
Add commenting to Fund Summary: Adds basic commenting to Fund Initiatives. Test Plan: Leave a comment, see comment. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15554
2016-04-01 00:29:42 +02:00
'FundInitiativeCommentController' => 'FundController',
Scaffolding for Fund Summary: Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet. You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc). Only notable decisions: - Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative. - I think that's it? Test Plan: - Created an initiative. - Edited an initiative. - Changed application policy defaults. - Searched for initiatives. - Subscribed to an initiative. - Opened/closed an initiative. - Used `I123` and `{I123}` in remarkup. - Destroyed an initiative. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
'FundInitiativeEditController' => 'FundController',
'FundInitiativeEditor' => 'PhabricatorApplicationTransactionEditor',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'FundInitiativeFulltextEngine' => 'PhabricatorFulltextEngine',
Scaffolding for Fund Summary: Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet. You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc). Only notable decisions: - Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative. - I think that's it? Test Plan: - Created an initiative. - Edited an initiative. - Changed application policy defaults. - Searched for initiatives. - Subscribed to an initiative. - Opened/closed an initiative. - Used `I123` and `{I123}` in remarkup. - Destroyed an initiative. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
'FundInitiativeListController' => 'FundController',
'FundInitiativePHIDType' => 'PhabricatorPHIDType',
'FundInitiativeQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'FundInitiativeRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Subclass most ReplyHandlers from TransactionReplyHandler Summary: Ref T7199. Half of these aren't even reachable, but make some progress toward reducing the amount of nonsense and garbage in mail handling. Test Plan: Tested all reachable handlers with `bin/mail receive-test`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12237
2015-04-01 17:39:50 +02:00
'FundInitiativeReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Scaffolding for Fund Summary: Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet. You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc). Only notable decisions: - Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative. - I think that's it? Test Plan: - Created an initiative. - Edited an initiative. - Changed application policy defaults. - Searched for initiatives. - Subscribed to an initiative. - Opened/closed an initiative. - Used `I123` and `{I123}` in remarkup. - Destroyed an initiative. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
'FundInitiativeSearchEngine' => 'PhabricatorApplicationSearchEngine',
'FundInitiativeTransaction' => 'PhabricatorApplicationTransaction',
Add commenting to Fund Summary: Adds basic commenting to Fund Initiatives. Test Plan: Leave a comment, see comment. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15554
2016-04-01 00:29:42 +02:00
'FundInitiativeTransactionComment' => 'PhabricatorApplicationTransactionComment',
Scaffolding for Fund Summary: Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet. You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc). Only notable decisions: - Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative. - I think that's it? Test Plan: - Created an initiative. - Edited an initiative. - Changed application policy defaults. - Searched for initiatives. - Subscribed to an initiative. - Opened/closed an initiative. - Used `I123` and `{I123}` in remarkup. - Destroyed an initiative. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
'FundInitiativeTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'FundInitiativeViewController' => 'FundController',
Add expected schemata for Fund, Files, Flags and Legalpad Summary: Ref T1191. Nothing too exciting in these. Test Plan: Saw more blue in UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10521
2014-09-19 14:44:40 +02:00
'FundSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Add "Autoplans" to Harbormaster Summary: Ref T8095. Two general problems: - I want Harbormaster to own all lint and unit test results. - I don't want users to have to configure anything for `arc` to keep working automatically. These are in conflict because generic lint/unit test ownership in Harbormaster requires that build targets exist which we can attach build results to. However, we can't currently create build targets on demand: Harbormaster assumes it is responsible for creating targets, then running code or making third-party service calls to actually run the builds. I considered two broad approaches to let `arc` push results into Harbormaster without requiring administrators to configure some kind of "arc results" build plan: # Add magic target PHIDs like `PHID-MAGIC-this-is-really-arc-unit`. # Add new code to build real targets with real PHIDs. (1) is probably a bit less work to get off the ground, but I think it's worse overall and very likely to create more problems in the long run. I particularly worry that it will lead to a small amount of special casing in a very large number of places, which seems more fragile. (2) is more work upfront but I think does a better job of putting all the special casing in one place that we can, e.g., more reasonably unit test, and letting the rest of the code rarely/never care about this case since it's just dealing with normal plans/steps/targets as far as it can tell. This diff introduces "autoplans", which are source templates for plans/steps. This let us "push" these targets into Harbormaster. Hypthetically, any process "like" arc can use autoplans to upload test/lint/etc results. In practice, probably only `arc` will ever use this, but I think it's still quite a bit cleaner than the alternative despite all the generality. Workflow is basically: - `arc` creates a diff. - `arc` calls `harbormaster.queryautotargets`, passing the diff PHID and saying "I have some lint and unit results I want to stick on this thing". - Harbormaster builds the plan, steps, and targets (if any of them don't already exist), and hands back the target PHIDs so `arc` has a completely standard-looking place to put results. - `arc` uploads the test results to the right targets, as though Harbormaster had asked it to run unit/lint in the first place. (This doesn't actually do any of that yet, just sets things up.) I'll maybe doc turn that ^^^^^^ into a doc for posterity since I think it's hard to guess what an "autotarget" is, but I'm going to grab some lunch first. Test Plan: - Added unit tests to make sure we can build these things properly. - Used `harbormaster.queryautotargets` to build autotargets for a bunch of diffs. - Verified targets come up in "waiting for message" state. - Verified plans and steps are not editable. Reviewers: btrahan Reviewed By: btrahan Subscribers: hach-que, epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13345
2015-06-21 18:04:21 +02:00
'HarbormasterArcLintBuildStepImplementation' => 'HarbormasterBuildStepImplementation',
'HarbormasterArcUnitBuildStepImplementation' => 'HarbormasterBuildStepImplementation',
Add `harbormaster.createartifact` Summary: Ref T8659. In the general case, this eventually allows build processes to do things like: - Upload build results (like a ".app" or ".exe" or other binary). - Pass complex results between build steps (e.g., build step A does something hard and build step B uses it to do something else). Today, we're a long way away from having the infrastructure for that. However, it is useful to let third party build processes (like Jenkins) upload URIs that link back to the external build results. This adds `harbormaster.createartifact` so they can do that. The only useful thing to do with this method today is have your Jenkins build do this: params = array( "uri": "https://jenkins.mycompany.com/build/23923/details/", "name": "View Build Results in Jenkins", "ui.external": true, ); harbormaster.createartifact(target, 'uri', params); Then (after the next diff) we'll show a link in Differential and a prominent link in Harbormaster. I didn't actually do the UI stuff in this diff since it's already pretty big. This change moves a lot of code around, too: - Adds PHIDs to artifacts. - It modularizes build artifact types (currently "file", "host" and "URI"). - It formalizes build artifact parameters and construction: - This lets me generate usable documentation about how to create artifacts. - This prevents users from doing dangerous or policy-violating things. - It does some other general modernization. Test Plan: {F715633} {F715634} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8659 Differential Revision: https://secure.phabricator.com/D13900
2015-08-15 16:28:56 +02:00
'HarbormasterArtifact' => 'Phobject',
Add "Autoplans" to Harbormaster Summary: Ref T8095. Two general problems: - I want Harbormaster to own all lint and unit test results. - I don't want users to have to configure anything for `arc` to keep working automatically. These are in conflict because generic lint/unit test ownership in Harbormaster requires that build targets exist which we can attach build results to. However, we can't currently create build targets on demand: Harbormaster assumes it is responsible for creating targets, then running code or making third-party service calls to actually run the builds. I considered two broad approaches to let `arc` push results into Harbormaster without requiring administrators to configure some kind of "arc results" build plan: # Add magic target PHIDs like `PHID-MAGIC-this-is-really-arc-unit`. # Add new code to build real targets with real PHIDs. (1) is probably a bit less work to get off the ground, but I think it's worse overall and very likely to create more problems in the long run. I particularly worry that it will lead to a small amount of special casing in a very large number of places, which seems more fragile. (2) is more work upfront but I think does a better job of putting all the special casing in one place that we can, e.g., more reasonably unit test, and letting the rest of the code rarely/never care about this case since it's just dealing with normal plans/steps/targets as far as it can tell. This diff introduces "autoplans", which are source templates for plans/steps. This let us "push" these targets into Harbormaster. Hypthetically, any process "like" arc can use autoplans to upload test/lint/etc results. In practice, probably only `arc` will ever use this, but I think it's still quite a bit cleaner than the alternative despite all the generality. Workflow is basically: - `arc` creates a diff. - `arc` calls `harbormaster.queryautotargets`, passing the diff PHID and saying "I have some lint and unit results I want to stick on this thing". - Harbormaster builds the plan, steps, and targets (if any of them don't already exist), and hands back the target PHIDs so `arc` has a completely standard-looking place to put results. - `arc` uploads the test results to the right targets, as though Harbormaster had asked it to run unit/lint in the first place. (This doesn't actually do any of that yet, just sets things up.) I'll maybe doc turn that ^^^^^^ into a doc for posterity since I think it's hard to guess what an "autotarget" is, but I'm going to grab some lunch first. Test Plan: - Added unit tests to make sure we can build these things properly. - Used `harbormaster.queryautotargets` to build autotargets for a bunch of diffs. - Verified targets come up in "waiting for message" state. - Verified plans and steps are not editable. Reviewers: btrahan Reviewed By: btrahan Subscribers: hach-que, epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13345
2015-06-21 18:04:21 +02:00
'HarbormasterAutotargetsTestCase' => 'PhabricatorTestCase',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'HarbormasterBuild' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'HarbormasterDAO',
Transactions - deploy buildTransactionTimeline to remaining applications Summary: Ref T4712. Specifically... - Differential - needed getApplicationTransactionViewObject() implemented - Audit - needed getApplicationTransactionViewObject() implemented - Repository - one object needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) - Ponder - BONUS BUG FIX - leaving a comment on an answer had a bad redirect URI - both PonderQuestion and PonderAnswer needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on both "history" controllers - left a "TODO" on buildAnswers on the question view controller, which is non-standard and should be re-written eventually - Phortune - BONUS BUG FIX - fix new user "createNewAccount" code to not fatal - PhortuneAccount, PhortuneMerchant, and PhortuneCart needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on Account view, merchant view, and cart view controller - Fund - Legalpad - Nuance - NuanceSource needed PhabricatorApplicationTransactionInterface implemented - Releeph (this product is kind of a mess...) - HACKQUEST - had to manually create an arcanist project to even be able to make a "product" and get started...! - BONUS BUG FIX - make sure to "setName" on product edit - ReleephProject (should be ReleepProduct...?), ReleephBranch, and ReleepRequest needed PhabricatorApplicationTransactionInterface implemented - Harbormaster - HarbormasterBuildable, HarbormasterBuild, HarbormasterBuildPlan, and HarbormasterBuildStep all needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) all over the place Test Plan: foreach application, viewed the timeline(s) and made sure they still rendered Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10925
2014-12-04 00:35:47 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
),
Abort previous build targets when a build is restarted Summary: Ref T5936. This implements build implementations aborting early when the build has since been restarted. Build steps now periodically poll to see if the build's current generation does not match their generation, and they throw a `HarbormasterBuildAbortedException` if that is the case. Test Plan: Tested locally on my machine with the sleep build step. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5936 Differential Revision: https://secure.phabricator.com/D10322
2014-08-26 12:46:23 +02:00
'HarbormasterBuildAbortedException' => 'Exception',
Replace "Cancel Build" with "Stop", "Resume" and "Restart" Summary: Ref T1049. Currently you can cancel a build, but now that we're tracking a lot more state we can stop, resume, and restart builds. When the user issues a command against a build, I'm writing it into an auxiliary queue (`HarbormasterBuildCommand`) and then reading them out in the worker. This is mostly to avoid race messes where we try to `save()` the object in multiple places: basically, the BuildEngine is the //only// thing that writes to Build objects, and it holds a lock while it does it. Test Plan: - Created a plan which runs "sleep 2" a bunch of times in a row. - Stopped, resumed, and restarted it. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7892
2014-01-06 21:32:20 +01:00
'HarbormasterBuildActionController' => 'HarbormasterController',
Add "Autoplans" to Harbormaster Summary: Ref T8095. Two general problems: - I want Harbormaster to own all lint and unit test results. - I don't want users to have to configure anything for `arc` to keep working automatically. These are in conflict because generic lint/unit test ownership in Harbormaster requires that build targets exist which we can attach build results to. However, we can't currently create build targets on demand: Harbormaster assumes it is responsible for creating targets, then running code or making third-party service calls to actually run the builds. I considered two broad approaches to let `arc` push results into Harbormaster without requiring administrators to configure some kind of "arc results" build plan: # Add magic target PHIDs like `PHID-MAGIC-this-is-really-arc-unit`. # Add new code to build real targets with real PHIDs. (1) is probably a bit less work to get off the ground, but I think it's worse overall and very likely to create more problems in the long run. I particularly worry that it will lead to a small amount of special casing in a very large number of places, which seems more fragile. (2) is more work upfront but I think does a better job of putting all the special casing in one place that we can, e.g., more reasonably unit test, and letting the rest of the code rarely/never care about this case since it's just dealing with normal plans/steps/targets as far as it can tell. This diff introduces "autoplans", which are source templates for plans/steps. This let us "push" these targets into Harbormaster. Hypthetically, any process "like" arc can use autoplans to upload test/lint/etc results. In practice, probably only `arc` will ever use this, but I think it's still quite a bit cleaner than the alternative despite all the generality. Workflow is basically: - `arc` creates a diff. - `arc` calls `harbormaster.queryautotargets`, passing the diff PHID and saying "I have some lint and unit results I want to stick on this thing". - Harbormaster builds the plan, steps, and targets (if any of them don't already exist), and hands back the target PHIDs so `arc` has a completely standard-looking place to put results. - `arc` uploads the test results to the right targets, as though Harbormaster had asked it to run unit/lint in the first place. (This doesn't actually do any of that yet, just sets things up.) I'll maybe doc turn that ^^^^^^ into a doc for posterity since I think it's hard to guess what an "autotarget" is, but I'm going to grab some lunch first. Test Plan: - Added unit tests to make sure we can build these things properly. - Used `harbormaster.queryautotargets` to build autotargets for a bunch of diffs. - Verified targets come up in "waiting for message" state. - Verified plans and steps are not editable. Reviewers: btrahan Reviewed By: btrahan Subscribers: hach-que, epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13345
2015-06-21 18:04:21 +02:00
'HarbormasterBuildArcanistAutoplan' => 'HarbormasterBuildAutoplan',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'HarbormasterBuildArtifact' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'HarbormasterDAO',
'PhabricatorPolicyInterface',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
),
Add `harbormaster.createartifact` Summary: Ref T8659. In the general case, this eventually allows build processes to do things like: - Upload build results (like a ".app" or ".exe" or other binary). - Pass complex results between build steps (e.g., build step A does something hard and build step B uses it to do something else). Today, we're a long way away from having the infrastructure for that. However, it is useful to let third party build processes (like Jenkins) upload URIs that link back to the external build results. This adds `harbormaster.createartifact` so they can do that. The only useful thing to do with this method today is have your Jenkins build do this: params = array( "uri": "https://jenkins.mycompany.com/build/23923/details/", "name": "View Build Results in Jenkins", "ui.external": true, ); harbormaster.createartifact(target, 'uri', params); Then (after the next diff) we'll show a link in Differential and a prominent link in Harbormaster. I didn't actually do the UI stuff in this diff since it's already pretty big. This change moves a lot of code around, too: - Adds PHIDs to artifacts. - It modularizes build artifact types (currently "file", "host" and "URI"). - It formalizes build artifact parameters and construction: - This lets me generate usable documentation about how to create artifacts. - This prevents users from doing dangerous or policy-violating things. - It does some other general modernization. Test Plan: {F715633} {F715634} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8659 Differential Revision: https://secure.phabricator.com/D13900
2015-08-15 16:28:56 +02:00
'HarbormasterBuildArtifactPHIDType' => 'PhabricatorPHIDType',
Introduce HarbormasterBuildTarget to snapshot build steps through a build Summary: This implements build targets as outlined in D7582. Build targets represent an instance of a build step particular to the build. Logs and artifacts have been adjusted to attach to build targets instead of build / build step pairs. Test Plan: Ran builds and clicked around the interface. Everything seemed to work. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T1049 Differential Revision: https://secure.phabricator.com/D7703
2013-12-05 02:01:12 +01:00
'HarbormasterBuildArtifactQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add "Autoplans" to Harbormaster Summary: Ref T8095. Two general problems: - I want Harbormaster to own all lint and unit test results. - I don't want users to have to configure anything for `arc` to keep working automatically. These are in conflict because generic lint/unit test ownership in Harbormaster requires that build targets exist which we can attach build results to. However, we can't currently create build targets on demand: Harbormaster assumes it is responsible for creating targets, then running code or making third-party service calls to actually run the builds. I considered two broad approaches to let `arc` push results into Harbormaster without requiring administrators to configure some kind of "arc results" build plan: # Add magic target PHIDs like `PHID-MAGIC-this-is-really-arc-unit`. # Add new code to build real targets with real PHIDs. (1) is probably a bit less work to get off the ground, but I think it's worse overall and very likely to create more problems in the long run. I particularly worry that it will lead to a small amount of special casing in a very large number of places, which seems more fragile. (2) is more work upfront but I think does a better job of putting all the special casing in one place that we can, e.g., more reasonably unit test, and letting the rest of the code rarely/never care about this case since it's just dealing with normal plans/steps/targets as far as it can tell. This diff introduces "autoplans", which are source templates for plans/steps. This let us "push" these targets into Harbormaster. Hypthetically, any process "like" arc can use autoplans to upload test/lint/etc results. In practice, probably only `arc` will ever use this, but I think it's still quite a bit cleaner than the alternative despite all the generality. Workflow is basically: - `arc` creates a diff. - `arc` calls `harbormaster.queryautotargets`, passing the diff PHID and saying "I have some lint and unit results I want to stick on this thing". - Harbormaster builds the plan, steps, and targets (if any of them don't already exist), and hands back the target PHIDs so `arc` has a completely standard-looking place to put results. - `arc` uploads the test results to the right targets, as though Harbormaster had asked it to run unit/lint in the first place. (This doesn't actually do any of that yet, just sets things up.) I'll maybe doc turn that ^^^^^^ into a doc for posterity since I think it's hard to guess what an "autotarget" is, but I'm going to grab some lunch first. Test Plan: - Added unit tests to make sure we can build these things properly. - Used `harbormaster.queryautotargets` to build autotargets for a bunch of diffs. - Verified targets come up in "waiting for message" state. - Verified plans and steps are not editable. Reviewers: btrahan Reviewed By: btrahan Subscribers: hach-que, epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13345
2015-06-21 18:04:21 +02:00
'HarbormasterBuildAutoplan' => 'Phobject',
Replace "Cancel Build" with "Stop", "Resume" and "Restart" Summary: Ref T1049. Currently you can cancel a build, but now that we're tracking a lot more state we can stop, resume, and restart builds. When the user issues a command against a build, I'm writing it into an auxiliary queue (`HarbormasterBuildCommand`) and then reading them out in the worker. This is mostly to avoid race messes where we try to `save()` the object in multiple places: basically, the BuildEngine is the //only// thing that writes to Build objects, and it holds a lock while it does it. Test Plan: - Created a plan which runs "sleep 2" a bunch of times in a row. - Stopped, resumed, and restarted it. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7892
2014-01-06 21:32:20 +01:00
'HarbormasterBuildCommand' => 'HarbormasterDAO',
Implement build simulation; convert Harbormaster to be purely dependency based Summary: Depends on D9806. This implements the build simulator, which is used to calculate the order of build steps in the plan editor. This includes a migration script to convert existing plans from sequential based to dependency based, and then drops the sequence column. Because build plans are now dependency based, the grippable and re-order behaviour has been removed. Test Plan: Tested the migration, saw the dependencies appear correctly. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D9847
2014-07-31 03:39:49 +02:00
'HarbormasterBuildDependencyDatasource' => 'PhabricatorTypeaheadDatasource',
Split Harbormaster workers apart so build steps can run in parallel Summary: Ref T1049. Currently, the Harbormaster worker looks like this: foreach (step) { run_step(step); } This means steps can't ever be run in parallel. Instead, split it into two workers. The "Build" worker starts things off, and basically does: update_build(); (We could theoretically do this in the original process because it should never take very long, but since there's a lock and it's a little bit complex it seemed cleaner to separate it.) The "Target" worker runs an individual target (like a command, or an HTTP request, or whatever), then updates the build: run_one_step(step); update_build(); The new `update_build()` mechanism in `HarbormasterBuildEngine` does this, roughly: figure_out_overall_status_of_all_steps(); if (build is done) { done(); } if (build is fail) { fail(); } foreach (step that is ready to run) { queue_target_worker_for_step(step); } So, overall: - The part of the code that updates Builds is completely separated from the part of the code that updates Targets. - Targets can run in parallel. Test Plan: - Ran a bunch of builds via `bin/harbormaster build`. - Ran a bunch of builds via web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7890
2014-01-06 21:32:10 +01:00
'HarbormasterBuildEngine' => 'Phobject',
Allow build steps to explicitly fail the build Summary: We've received feedback that the "core - exception" is incredibly confusing, to the point where developers see this and write off the build failure as a Phabricator error that is unrelated to their changes. Test Plan: Ran a build with a `exit 1` run step, didn't see the "core - exception" appear. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D10090
2014-08-01 00:08:28 +02:00
'HarbormasterBuildFailureException' => 'Exception',
Implement build simulation; convert Harbormaster to be purely dependency based Summary: Depends on D9806. This implements the build simulator, which is used to calculate the order of build steps in the plan editor. This includes a migration script to convert existing plans from sequential based to dependency based, and then drops the sequence column. Because build plans are now dependency based, the grippable and re-order behaviour has been removed. Test Plan: Tested the migration, saw the dependencies appear correctly. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D9847
2014-07-31 03:39:49 +02:00
'HarbormasterBuildGraph' => 'AbstractDirectedGraph',
Replace Harbormaster "BuildItem" with Lint/Unit messages Summary: Ref T8095. Harbormaster has a `BuildItem` class, but it has no table and is unused. This was an earlier idea about representing lint/unit results and some other possible types of messages, but I think we want to be more specific than this. Remove `BuildItem` and add `Lint` and `Unit` storage. These tables roughly parallel how we store lint/unit messages today, with some guesses about how where they'll go in the future. Test Plan: Ran `bin/storage upgrade` and got a clean adjust out of it. Reviewers: btrahan Reviewed By: btrahan Subscribers: hach-que, epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13329
2015-06-21 18:00:00 +02:00
'HarbormasterBuildLintMessage' => 'HarbormasterDAO',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'HarbormasterBuildLog' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'HarbormasterDAO',
'PhabricatorPolicyInterface',
Implemented support for build logs Summary: Depends on D7519. This implements support for build logs in Harbormaster. This includes support for appending to a log from the "Run Remote Command" build step. It also adds the ability to cancel builds. Currently the build view page doesn't update the logs live; I'm sure this can be achieved with Javelin, but I don't have enough experience with Javelin to actually make it poll from updates to content in the background. {F79151} {F79153} {F79150} {F79152} Test Plan: Tested this by setting up SSH on a Windows machine and using a Remote Command configured with: ``` C:\Windows\system32\cmd.exe /C cd C:\Build && mkdir Build_${timestamp} && cd Build_${timestamp} && git clone --recursive https://github.com/hach-que/Tychaia.git && cd Tychaia && Protobuild.exe && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Tychaia.Windows.sln ``` and observed the output of the build stream from the Windows machine into Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7521
2013-11-09 03:09:03 +01:00
),
Give HarbormasterBuildLogChunk a real table Summary: Ref T10457. Currently, this table is an ad-hoc table, but can easily be turned into a normal table. This will make iterating over log chunks to compress and archive them easier. Test Plan: Viewed logs, ran `bin/storage adjust` with no issues. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15376
2016-03-01 21:10:27 +01:00
'HarbormasterBuildLogChunk' => 'HarbormasterDAO',
Implement an iterator for build log chunks Summary: Ref T5822. This will make it easier to compress and archive chunks without needing to hold them in memory. Test Plan: Ran a build, looked at some logs. Reviewers: chad Reviewed By: chad Maniphest Tasks: T5822 Differential Revision: https://secure.phabricator.com/D15378
2016-03-01 21:22:14 +01:00
'HarbormasterBuildLogChunkIterator' => 'PhutilBufferedIterator',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'HarbormasterBuildLogPHIDType' => 'PhabricatorPHIDType',
Implemented support for build logs Summary: Depends on D7519. This implements support for build logs in Harbormaster. This includes support for appending to a log from the "Run Remote Command" build step. It also adds the ability to cancel builds. Currently the build view page doesn't update the logs live; I'm sure this can be achieved with Javelin, but I don't have enough experience with Javelin to actually make it poll from updates to content in the background. {F79151} {F79153} {F79150} {F79152} Test Plan: Tested this by setting up SSH on a Windows machine and using a Remote Command configured with: ``` C:\Windows\system32\cmd.exe /C cd C:\Build && mkdir Build_${timestamp} && cd Build_${timestamp} && git clone --recursive https://github.com/hach-que/Tychaia.git && cd Tychaia && Protobuild.exe && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Tychaia.Windows.sln ``` and observed the output of the build stream from the Windows machine into Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7521
2013-11-09 03:09:03 +01:00
'HarbormasterBuildLogQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'HarbormasterBuildMessage' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'HarbormasterDAO',
'PhabricatorPolicyInterface',
Allow external systems to send messages to build targets Summary: Ref T1049. Allows external systems to send a message to a build target. The primary intended use case is: - You make an HTTP request to Jenkins. - The build goes into a "waiting" state. - Later, Jenkins calls `harbormaster.sendmessage` to report that the target passed or failed. - The build continues as appropriate. This is deceptively complicated because: - There are a lot of race concerns. We might get a message back from an external system before it even responds to the request we made. We want to make sure we process these messages no matter when we receive them. - These messages need to be sent to a build target (vs a build or buildable) because we'll get into trouble with parallelization later on otherwise (Jenkins is told to do 3 builds; we can't tell which ones failed or what overall state is unless the message are sent to targets). - I initially thought about implementing this as a separate "Wait for a response from an external system" build step. This gets a lot more complicated for users once we do parallelization, though. Particularly, in the case where you've told Jenkins to do 3 builds, the three "wait" steps need to know which target they're waiting for (and jenkins needs to know some unique identifier for each target). So this pretty much boils down to a more complicated, more error-prone version of using target PHIDs. This makes the already-muddy Build UI a bit worse, but it needs a general clarity pass anyway (it's showing way too much uninteresting data, and should show a better summary of results instead). Test Plan: - This doesn't really do anything interesting yet. - Used Conduit to send messages to build plans. - Viewed the messages on the build screen. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8604
2014-03-26 00:11:28 +01:00
),
'HarbormasterBuildMessageQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'HarbormasterBuildPHIDType' => 'PhabricatorPHIDType',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'HarbormasterBuildPlan' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'HarbormasterDAO',
Transactions - deploy buildTransactionTimeline to remaining applications Summary: Ref T4712. Specifically... - Differential - needed getApplicationTransactionViewObject() implemented - Audit - needed getApplicationTransactionViewObject() implemented - Repository - one object needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) - Ponder - BONUS BUG FIX - leaving a comment on an answer had a bad redirect URI - both PonderQuestion and PonderAnswer needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on both "history" controllers - left a "TODO" on buildAnswers on the question view controller, which is non-standard and should be re-written eventually - Phortune - BONUS BUG FIX - fix new user "createNewAccount" code to not fatal - PhortuneAccount, PhortuneMerchant, and PhortuneCart needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on Account view, merchant view, and cart view controller - Fund - Legalpad - Nuance - NuanceSource needed PhabricatorApplicationTransactionInterface implemented - Releeph (this product is kind of a mess...) - HACKQUEST - had to manually create an arcanist project to even be able to make a "product" and get started...! - BONUS BUG FIX - make sure to "setName" on product edit - ReleephProject (should be ReleepProduct...?), ReleephBranch, and ReleepRequest needed PhabricatorApplicationTransactionInterface implemented - Harbormaster - HarbormasterBuildable, HarbormasterBuild, HarbormasterBuildPlan, and HarbormasterBuildStep all needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) all over the place Test Plan: foreach application, viewed the timeline(s) and made sure they still rendered Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10925
2014-12-04 00:35:47 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
'PhabricatorSubscribableInterface',
Support searching for Harbormater build plans by name substring Summary: Ref T10457. Allow build plans to be queried by name. Test Plan: - Searched for plans by name. - Renamed a plan, searched for new name. {F1133085} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15359
2016-02-27 17:59:33 +01:00
'PhabricatorNgramsInterface',
Allow Harbormaster build plans to be tagged with projects and searched by tag Summary: Ref T10457. This is mostly just for consitency, but I imagine it will make managing large/complex build processes easier, and if we support Herald rules it would eventually let you write "Build plan's tags include [whatever]" to apply behavior to a group of plans. Test Plan: {F1133107} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15360
2016-02-27 18:19:20 +01:00
'PhabricatorProjectInterface',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
),
Modernize "build plans" typeahead datasource Summary: Ref T4420. Modernize build plans. Test Plan: - Used build plan typeahead in Harbormaster. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9878
2014-07-11 01:20:58 +02:00
'HarbormasterBuildPlanDatasource' => 'PhabricatorTypeaheadDatasource',
Give Harbormaster Build Plans real policies Summary: Ref T9614. Currently, a lot of Build Plan behavior is covered by a global "can manage" policy. One install in particular is experiencing difficulty with warring factions within engineering aborting one another's builds. As a first step to remedy this, and also generally make Harbormaster more flexible and bring it in line with other applications in terms of policy power: - Give Build Plans normal view/edit policies. - Require "Can Edit" to run a plan manually. Having "Can View" on plans may be a little weird in some cases (the status of a Buildable might be bad because of a build you can't see) but we can cross that bridge when we come to it. Next change here will require "Can Edit" to abort a build. This will reasonably allow installs to reserve pause/abort for administrators/adults. (I might let anyone restart a plan, though?) Test Plan: - Created a new build plan. - Verified defaults were inherited from application defaults (swapped them around, too). - Saved build plan. - Edited policies. - Verified autoplans get the right policies. - Verified old plans got migrated properly. - Tried to run a plan I couldn't edit (denied). - Ran a plan from CLI with `bin/harbormaster`. - Tried to create a plan with an unprivileged user. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9614 Differential Revision: https://secure.phabricator.com/D14321
2015-10-26 20:38:21 +01:00
'HarbormasterBuildPlanDefaultEditCapability' => 'PhabricatorPolicyCapability',
'HarbormasterBuildPlanDefaultViewCapability' => 'PhabricatorPolicyCapability',
Use EditEngine for Harbormaster Build Plans, fix some crumbs/mobile stuff Summary: Ref T10457. - Use EditEngine for Build Plans. - Fix some minor issues with crumbs being inconsistent. - Fix some minor issues with mobile menus not being consistent/available. Test Plan: - Created and edited build plans. - Poked around in mobile width, verified mobile menu had the right stuff in it. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15357
2016-02-27 04:12:55 +01:00
'HarbormasterBuildPlanEditEngine' => 'PhabricatorEditEngine',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildPlanEditor' => 'PhabricatorApplicationTransactionEditor',
Support searching for Harbormater build plans by name substring Summary: Ref T10457. Allow build plans to be queried by name. Test Plan: - Searched for plans by name. - Renamed a plan, searched for new name. {F1133085} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15359
2016-02-27 17:59:33 +01:00
'HarbormasterBuildPlanNameNgrams' => 'PhabricatorSearchNgrams',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'HarbormasterBuildPlanPHIDType' => 'PhabricatorPHIDType',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildPlanQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'HarbormasterBuildPlanSearchEngine' => 'PhabricatorApplicationSearchEngine',
'HarbormasterBuildPlanTransaction' => 'PhabricatorApplicationTransaction',
'HarbormasterBuildPlanTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'HarbormasterBuildQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Allow builds to have parameters Summary: Ref T9352. See D13635. Build targets can have variables already, but let builds have them too. This mostly enables future use cases (sub-builds, more sophisticated build triggers). Test Plan: With a custom Herald rule + action like the one in T9352, updated a revision and saw it generate multiple builds with varying parameters. Reviewers: chad, hach-que Reviewed By: hach-que Maniphest Tasks: T9352 Differential Revision: https://secure.phabricator.com/D14222
2015-10-02 15:32:08 +02:00
'HarbormasterBuildRequest' => 'Phobject',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'HarbormasterBuildStep' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'HarbormasterDAO',
Transactions - deploy buildTransactionTimeline to remaining applications Summary: Ref T4712. Specifically... - Differential - needed getApplicationTransactionViewObject() implemented - Audit - needed getApplicationTransactionViewObject() implemented - Repository - one object needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) - Ponder - BONUS BUG FIX - leaving a comment on an answer had a bad redirect URI - both PonderQuestion and PonderAnswer needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on both "history" controllers - left a "TODO" on buildAnswers on the question view controller, which is non-standard and should be re-written eventually - Phortune - BONUS BUG FIX - fix new user "createNewAccount" code to not fatal - PhortuneAccount, PhortuneMerchant, and PhortuneCart needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on Account view, merchant view, and cart view controller - Fund - Legalpad - Nuance - NuanceSource needed PhabricatorApplicationTransactionInterface implemented - Releeph (this product is kind of a mess...) - HACKQUEST - had to manually create an arcanist project to even be able to make a "product" and get started...! - BONUS BUG FIX - make sure to "setName" on product edit - ReleephProject (should be ReleepProduct...?), ReleephBranch, and ReleepRequest needed PhabricatorApplicationTransactionInterface implemented - Harbormaster - HarbormasterBuildable, HarbormasterBuild, HarbormasterBuildPlan, and HarbormasterBuildStep all needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) all over the place Test Plan: foreach application, viewed the timeline(s) and made sure they still rendered Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10925
2014-12-04 00:35:47 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
'PhabricatorCustomFieldInterface',
Add build step implementation infrastructure and sleep build step. Summary: Depends on D7498. This implements support for a "build step implementation". Build steps have an associated class name (which makes the class in PHP) and a details field, which is serialized JSON (same as PhabricatorRepository). This also implements a SleepBuildStepImplementation which just pauses the build for a specified period of seconds. Test Plan: Inserted a build step with `insert into harbormaster_buildstep (phid, buildPlanPHID, className, details, dateCreated, dateModified) values ('', 'PHID-HMCP-zkh5w6czfbfpk2gxwdeo', 'SleepBuildStepImplementation', '{"seconds":5}', NOW(), NOW());` (adjusting the build plan PHID as appropriate). Started the daemon and applied the build plan to a buildable, and saw the daemon take a 5 second delay after creating `SleepBuildStepImplementation`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7499
2013-11-05 22:34:14 +01:00
),
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'HarbormasterBuildStepCoreCustomField' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'HarbormasterBuildStepCustomField',
'PhabricatorStandardCustomFieldInterface',
Use ApplicationTransactions and CustomField to implement build steps Summary: Ref T1049. Fixes T4602. Moves all the funky field stuff to CustomField. Uses ApplicationTransactions to apply and record edits. This makes "artifact" fields a little less nice (but still perfectly usable). With D8599, I think they're reasonable overall. We can improve this in the future. All other field types are better (e.g., fixes weird bugs with "bool", fixes lots of weird behavior around required fields), and this gives us access to many new field types. Test Plan: Made a bunch of step edits. Here's an example: {F133694} Note that: - "Required" fields work correctly. - the transaction record is shown at the bottom of the page. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4602, T1049 Differential Revision: https://secure.phabricator.com/D8600
2014-03-26 00:08:40 +01:00
),
'HarbormasterBuildStepCustomField' => 'PhabricatorCustomField',
'HarbormasterBuildStepEditor' => 'PhabricatorApplicationTransactionEditor',
Lump Harbormaster build steps into groups Summary: Ref T8089. We have a lot of broken/confusing/prototype build steps that I want to hide from users when we unprototype Harbormaster. The dialog is also just kind of unwieldy. Organize this UI a little better and put all the sketchy junk in a "prototypes" group that you can't see unless prototypes are enabled. This doesn't break anything (the old steps will still work fine), but should reduce user confusion. Test Plan: Old UI: {F691439} New UI (prototypes off): {F691440} New UI (prototypes on): {F691441} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8089 Differential Revision: https://secure.phabricator.com/D13803
2015-08-06 13:19:42 +02:00
'HarbormasterBuildStepGroup' => 'Phobject',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'HarbormasterBuildStepImplementation' => 'Phobject',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'HarbormasterBuildStepImplementationTestCase' => 'PhabricatorTestCase',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'HarbormasterBuildStepPHIDType' => 'PhabricatorPHIDType',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildStepQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Use ApplicationTransactions and CustomField to implement build steps Summary: Ref T1049. Fixes T4602. Moves all the funky field stuff to CustomField. Uses ApplicationTransactions to apply and record edits. This makes "artifact" fields a little less nice (but still perfectly usable). With D8599, I think they're reasonable overall. We can improve this in the future. All other field types are better (e.g., fixes weird bugs with "bool", fixes lots of weird behavior around required fields), and this gives us access to many new field types. Test Plan: Made a bunch of step edits. Here's an example: {F133694} Note that: - "Required" fields work correctly. - the transaction record is shown at the bottom of the page. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4602, T1049 Differential Revision: https://secure.phabricator.com/D8600
2014-03-26 00:08:40 +01:00
'HarbormasterBuildStepTransaction' => 'PhabricatorApplicationTransaction',
'HarbormasterBuildStepTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'HarbormasterBuildTarget' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'HarbormasterDAO',
'PhabricatorPolicyInterface',
Introduce HarbormasterBuildTarget to snapshot build steps through a build Summary: This implements build targets as outlined in D7582. Build targets represent an instance of a build step particular to the build. Logs and artifacts have been adjusted to attach to build targets instead of build / build step pairs. Test Plan: Ran builds and clicked around the interface. Everything seemed to work. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T1049 Differential Revision: https://secure.phabricator.com/D7703
2013-12-05 02:01:12 +01:00
),
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'HarbormasterBuildTargetPHIDType' => 'PhabricatorPHIDType',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildTargetQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Show command transactions in Harbormaster builds Summary: Create transaction, editor, etc, and move command generation over to editor. Show in a timeline in the buildable page. Also prevent Engine from creating an empty transaction when build starts (Fixes T4885). Fixes T4886. Test Plan: Restart builds and buildables, look at timeline. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4885, T4886 Differential Revision: https://secure.phabricator.com/D9110
2014-05-15 16:02:30 +02:00
'HarbormasterBuildTransaction' => 'PhabricatorApplicationTransaction',
'HarbormasterBuildTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
'HarbormasterBuildTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Replace Harbormaster "BuildItem" with Lint/Unit messages Summary: Ref T8095. Harbormaster has a `BuildItem` class, but it has no table and is unused. This was an earlier idea about representing lint/unit results and some other possible types of messages, but I think we want to be more specific than this. Remove `BuildItem` and add `Lint` and `Unit` storage. These tables roughly parallel how we store lint/unit messages today, with some guesses about how where they'll go in the future. Test Plan: Ran `bin/storage upgrade` and got a clean adjust out of it. Reviewers: btrahan Reviewed By: btrahan Subscribers: hach-que, epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13329
2015-06-21 18:00:00 +02:00
'HarbormasterBuildUnitMessage' => 'HarbormasterDAO',
Implemented support for build logs Summary: Depends on D7519. This implements support for build logs in Harbormaster. This includes support for appending to a log from the "Run Remote Command" build step. It also adds the ability to cancel builds. Currently the build view page doesn't update the logs live; I'm sure this can be achieved with Javelin, but I don't have enough experience with Javelin to actually make it poll from updates to content in the background. {F79151} {F79153} {F79150} {F79152} Test Plan: Tested this by setting up SSH on a Windows machine and using a Remote Command configured with: ``` C:\Windows\system32\cmd.exe /C cd C:\Build && mkdir Build_${timestamp} && cd Build_${timestamp} && git clone --recursive https://github.com/hach-que/Tychaia.git && cd Tychaia && Protobuild.exe && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Tychaia.Windows.sln ``` and observed the output of the build stream from the Windows machine into Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7521
2013-11-09 03:09:03 +01:00
'HarbormasterBuildViewController' => 'HarbormasterController',
Split Harbormaster workers apart so build steps can run in parallel Summary: Ref T1049. Currently, the Harbormaster worker looks like this: foreach (step) { run_step(step); } This means steps can't ever be run in parallel. Instead, split it into two workers. The "Build" worker starts things off, and basically does: update_build(); (We could theoretically do this in the original process because it should never take very long, but since there's a lock and it's a little bit complex it seemed cleaner to separate it.) The "Target" worker runs an individual target (like a command, or an HTTP request, or whatever), then updates the build: run_one_step(step); update_build(); The new `update_build()` mechanism in `HarbormasterBuildEngine` does this, roughly: figure_out_overall_status_of_all_steps(); if (build is done) { done(); } if (build is fail) { fail(); } foreach (step that is ready to run) { queue_target_worker_for_step(step); } So, overall: - The part of the code that updates Builds is completely separated from the part of the code that updates Targets. - Targets can run in parallel. Test Plan: - Ran a bunch of builds via `bin/harbormaster build`. - Ran a bunch of builds via web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7890
2014-01-06 21:32:10 +01:00
'HarbormasterBuildWorker' => 'HarbormasterWorker',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'HarbormasterBuildable' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'HarbormasterDAO',
Transactions - deploy buildTransactionTimeline to remaining applications Summary: Ref T4712. Specifically... - Differential - needed getApplicationTransactionViewObject() implemented - Audit - needed getApplicationTransactionViewObject() implemented - Repository - one object needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) - Ponder - BONUS BUG FIX - leaving a comment on an answer had a bad redirect URI - both PonderQuestion and PonderAnswer needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on both "history" controllers - left a "TODO" on buildAnswers on the question view controller, which is non-standard and should be re-written eventually - Phortune - BONUS BUG FIX - fix new user "createNewAccount" code to not fatal - PhortuneAccount, PhortuneMerchant, and PhortuneCart needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on Account view, merchant view, and cart view controller - Fund - Legalpad - Nuance - NuanceSource needed PhabricatorApplicationTransactionInterface implemented - Releeph (this product is kind of a mess...) - HACKQUEST - had to manually create an arcanist project to even be able to make a "product" and get started...! - BONUS BUG FIX - make sure to "setName" on product edit - ReleephProject (should be ReleepProduct...?), ReleephBranch, and ReleepRequest needed PhabricatorApplicationTransactionInterface implemented - Harbormaster - HarbormasterBuildable, HarbormasterBuild, HarbormasterBuildPlan, and HarbormasterBuildStep all needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) all over the place Test Plan: foreach application, viewed the timeline(s) and made sure they still rendered Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10925
2014-12-04 00:35:47 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
'HarbormasterBuildableInterface',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
),
Allow entire buildables to restart/stop/resume Summary: Ref T1049. Creates convenience actions at the Buildable level to stop, resume, or restart all builds. Test Plan: - Stopped all builds. - Resumed all builds. - Restarted all builds. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7899
2014-01-06 23:12:15 +01:00
'HarbormasterBuildableActionController' => 'HarbormasterController',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'HarbormasterBuildableListController' => 'HarbormasterController',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'HarbormasterBuildablePHIDType' => 'PhabricatorPHIDType',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildableQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'HarbormasterBuildableSearchEngine' => 'PhabricatorApplicationSearchEngine',
Show command transactions in Harbormaster builds Summary: Create transaction, editor, etc, and move command generation over to editor. Show in a timeline in the buildable page. Also prevent Engine from creating an empty transaction when build starts (Fixes T4885). Fixes T4886. Test Plan: Restart builds and buildables, look at timeline. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4885, T4886 Differential Revision: https://secure.phabricator.com/D9110
2014-05-15 16:02:30 +02:00
'HarbormasterBuildableTransaction' => 'PhabricatorApplicationTransaction',
'HarbormasterBuildableTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
'HarbormasterBuildableTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildableViewController' => 'HarbormasterController',
Lump Harbormaster build steps into groups Summary: Ref T8089. We have a lot of broken/confusing/prototype build steps that I want to hide from users when we unprototype Harbormaster. The dialog is also just kind of unwieldy. Organize this UI a little better and put all the sketchy junk in a "prototypes" group that you can't see unless prototypes are enabled. This doesn't break anything (the old steps will still work fine), but should reduce user confusion. Test Plan: Old UI: {F691439} New UI (prototypes off): {F691440} New UI (prototypes on): {F691441} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8089 Differential Revision: https://secure.phabricator.com/D13803
2015-08-06 13:19:42 +02:00
'HarbormasterBuiltinBuildStepGroup' => 'HarbormasterBuildStepGroup',
Add a "Build with CircleCI" build step Summary: Ref T9456. Some rough edges and we can't complete the build yet since I haven't written a webhook, but this mostly seems to be working. Test Plan: - Ran this build on some stuff. - Ran a normal HTTP step build to make sure I didn't break that. {F880301} {F880302} {F880303} Reviewers: chad Reviewed By: chad Subscribers: JustinTulloss, joshma Maniphest Tasks: T9456 Differential Revision: https://secure.phabricator.com/D14286
2015-10-15 05:01:22 +02:00
'HarbormasterCircleCIBuildStepImplementation' => 'HarbormasterBuildStepImplementation',
Add a CircleCI webhook Summary: Ref T9456. This makes everything work, except that CircleCI doesn't fetch tags which are not ancestors of branch heads. Test Plan: Ran passing builds through CircleCI. Reviewers: chad Reviewed By: chad Subscribers: dpaola2, JustinTulloss Maniphest Tasks: T9456 Differential Revision: https://secure.phabricator.com/D14288
2015-10-15 18:07:31 +02:00
'HarbormasterCircleCIHookController' => 'HarbormasterController',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'HarbormasterConduitAPIMethod' => 'ConduitAPIMethod',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterController' => 'PhabricatorController',
Add `harbormaster.createartifact` Summary: Ref T8659. In the general case, this eventually allows build processes to do things like: - Upload build results (like a ".app" or ".exe" or other binary). - Pass complex results between build steps (e.g., build step A does something hard and build step B uses it to do something else). Today, we're a long way away from having the infrastructure for that. However, it is useful to let third party build processes (like Jenkins) upload URIs that link back to the external build results. This adds `harbormaster.createartifact` so they can do that. The only useful thing to do with this method today is have your Jenkins build do this: params = array( "uri": "https://jenkins.mycompany.com/build/23923/details/", "name": "View Build Results in Jenkins", "ui.external": true, ); harbormaster.createartifact(target, 'uri', params); Then (after the next diff) we'll show a link in Differential and a prominent link in Harbormaster. I didn't actually do the UI stuff in this diff since it's already pretty big. This change moves a lot of code around, too: - Adds PHIDs to artifacts. - It modularizes build artifact types (currently "file", "host" and "URI"). - It formalizes build artifact parameters and construction: - This lets me generate usable documentation about how to create artifacts. - This prevents users from doing dangerous or policy-violating things. - It does some other general modernization. Test Plan: {F715633} {F715634} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8659 Differential Revision: https://secure.phabricator.com/D13900
2015-08-15 16:28:56 +02:00
'HarbormasterCreateArtifactConduitAPIMethod' => 'HarbormasterConduitAPIMethod',
Give Harbormaster Build Plans real policies Summary: Ref T9614. Currently, a lot of Build Plan behavior is covered by a global "can manage" policy. One install in particular is experiencing difficulty with warring factions within engineering aborting one another's builds. As a first step to remedy this, and also generally make Harbormaster more flexible and bring it in line with other applications in terms of policy power: - Give Build Plans normal view/edit policies. - Require "Can Edit" to run a plan manually. Having "Can View" on plans may be a little weird in some cases (the status of a Buildable might be bad because of a build you can't see) but we can cross that bridge when we come to it. Next change here will require "Can Edit" to abort a build. This will reasonably allow installs to reserve pause/abort for administrators/adults. (I might let anyone restart a plan, though?) Test Plan: - Created a new build plan. - Verified defaults were inherited from application defaults (swapped them around, too). - Saved build plan. - Edited policies. - Verified autoplans get the right policies. - Verified old plans got migrated properly. - Tried to run a plan I couldn't edit (denied). - Ran a plan from CLI with `bin/harbormaster`. - Tried to create a plan with an unprivileged user. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9614 Differential Revision: https://secure.phabricator.com/D14321
2015-10-26 20:38:21 +01:00
'HarbormasterCreatePlansCapability' => 'PhabricatorPolicyCapability',
Remove PHID database, add Harbormaster database Summary: - We currently write every PHID we generate to a table. This was motivated by two concerns: - **Understanding Data**: At Facebook, the data was sometimes kind of a mess. You could look at a random user in the ID tool and see 9000 assocs with random binary data attached to them, pointing at a zillion other objects with no idea how any of it got there. I originally created this table to have a canonical source of truth about PHID basics, at least. In practice, our data model has been really tidy and consistent, and we don't use any of the auxiliary data in this table (or even write it). The handle abstraction is powerful and covers essentially all of the useful data in the app, and we have human-readable types in the keys. So I don't think we have a real need here, and this table isn't serving it if we do. - **Uniqueness**: With a unique key, we can be sure they're unique, even if we get astronomically unlucky and get a collision. But every table we use them in has a unique key anyway. So we actually get pretty much nothing here, except maybe some vague guarantee that we won't reallocate a key later if the original object is deleted. But it's hard to imagine any install will ever have a collision, given that the key space is 36^20 per object type. - We also currently use PHIDs and Users in tests sometimes. This is silly and can break (see D2461). - Drop the PHID database. - Introduce a "Harbormaster" database (the eventual CI tool, after Drydock). - Add a scratch table to the Harbormaster database for doing unit test meta-tests. - Now, PHID generation does no writes, and unit tests are isolated from the application. - @csilvers: This should slightly improve the performance of the large query-bound tail in D2457. Test Plan: Ran unit tests. Ran storage upgrade. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: csilvers, aran, nh, edward Differential Revision: https://secure.phabricator.com/D2466
2012-05-20 23:46:01 +02:00
'HarbormasterDAO' => 'PhabricatorLiskDAO',
Put Drydock build steps into their own group in Harbormaster Summary: Ref T9252. Move these into a new "Drydock" group. Test Plan: Clicked "Add Build Step", saw Drydock steps in a Drydock group. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14237
2015-10-06 00:59:35 +02:00
'HarbormasterDrydockBuildStepGroup' => 'HarbormasterBuildStepGroup',
Allow Harbormaster to run commands on Drydock working copies Summary: Ref T9252. This mostly cleans up future and log handling, and edges us closer to being able to do useful work with Harbormaster / Drydock. Test Plan: - Added a "Run `ls -alh`" step to my trivial build plan. - Ran it a bunch of times. - Worked great. - Also did an HTTP plan. {F835227} {F835228} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14161
2015-09-25 19:43:32 +02:00
'HarbormasterDrydockCommandBuildStepImplementation' => 'HarbormasterBuildStepImplementation',
Allow Harbormaster to lease working copies from Drydock Summary: Ref T9252. This is still crude in a few ways but basically works, at least for commits. Test Plan: - Made a build plan with just this build step. - Ran `bin/harbormaster build --plan 10 ...` on a commit. - It actually built a working copy, leased it, took no action, and released the lease. MAGIC~~~ Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14160
2015-09-25 02:29:47 +02:00
'HarbormasterDrydockLeaseArtifact' => 'HarbormasterArtifact',
Allow Harbormaster to run commands on Drydock working copies Summary: Ref T9252. This mostly cleans up future and log handling, and edges us closer to being able to do useful work with Harbormaster / Drydock. Test Plan: - Added a "Run `ls -alh`" step to my trivial build plan. - Ran it a bunch of times. - Worked great. - Also did an HTTP plan. {F835227} {F835228} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14161
2015-09-25 19:43:32 +02:00
'HarbormasterExecFuture' => 'Future',
Lump Harbormaster build steps into groups Summary: Ref T8089. We have a lot of broken/confusing/prototype build steps that I want to hide from users when we unprototype Harbormaster. The dialog is also just kind of unwieldy. Organize this UI a little better and put all the sketchy junk in a "prototypes" group that you can't see unless prototypes are enabled. This doesn't break anything (the old steps will still work fine), but should reduce user confusion. Test Plan: Old UI: {F691439} New UI (prototypes off): {F691440} New UI (prototypes on): {F691441} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8089 Differential Revision: https://secure.phabricator.com/D13803
2015-08-06 13:19:42 +02:00
'HarbormasterExternalBuildStepGroup' => 'HarbormasterBuildStepGroup',
Add `harbormaster.createartifact` Summary: Ref T8659. In the general case, this eventually allows build processes to do things like: - Upload build results (like a ".app" or ".exe" or other binary). - Pass complex results between build steps (e.g., build step A does something hard and build step B uses it to do something else). Today, we're a long way away from having the infrastructure for that. However, it is useful to let third party build processes (like Jenkins) upload URIs that link back to the external build results. This adds `harbormaster.createartifact` so they can do that. The only useful thing to do with this method today is have your Jenkins build do this: params = array( "uri": "https://jenkins.mycompany.com/build/23923/details/", "name": "View Build Results in Jenkins", "ui.external": true, ); harbormaster.createartifact(target, 'uri', params); Then (after the next diff) we'll show a link in Differential and a prominent link in Harbormaster. I didn't actually do the UI stuff in this diff since it's already pretty big. This change moves a lot of code around, too: - Adds PHIDs to artifacts. - It modularizes build artifact types (currently "file", "host" and "URI"). - It formalizes build artifact parameters and construction: - This lets me generate usable documentation about how to create artifacts. - This prevents users from doing dangerous or policy-violating things. - It does some other general modernization. Test Plan: {F715633} {F715634} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8659 Differential Revision: https://secure.phabricator.com/D13900
2015-08-15 16:28:56 +02:00
'HarbormasterFileArtifact' => 'HarbormasterArtifact',
Rename "BuildStepImplementation" to "HarbormasterBuildStepImplementation" Summary: Ref T1049. D8588 already required custom code to change what it extends, so this is as good a time as we're going to get to move to more standard class name. Test Plan: `arc liberate`; `arc lint` Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8601
2014-03-26 00:09:21 +01:00
'HarbormasterHTTPRequestBuildStepImplementation' => 'HarbormasterBuildStepImplementation',
Allow Harbormaster to lease working copies from Drydock Summary: Ref T9252. This is still crude in a few ways but basically works, at least for commits. Test Plan: - Made a build plan with just this build step. - Ran `bin/harbormaster build --plan 10 ...` on a commit. - It actually built a working copy, leased it, took no action, and released the lease. MAGIC~~~ Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14160
2015-09-25 02:29:47 +02:00
'HarbormasterHostArtifact' => 'HarbormasterDrydockLeaseArtifact',
'HarbormasterLeaseWorkingCopyBuildStepImplementation' => 'HarbormasterBuildStepImplementation',
Improve lint/unit limit, sort, view all, collapse behaviors Summary: Ref T8096. Various tweaks here: - Sort result lists by importance (even lint -- "errors first" seems better than "alphabetical by file", I think?). - Do sane stuff with display limits. - Add a "view all" view. - Don't show a huge table of passing tests in Differential. - Link to full results. Test Plan: See screenshots. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8096 Differential Revision: https://secure.phabricator.com/D13407
2015-06-23 22:34:25 +02:00
'HarbormasterLintMessagesController' => 'HarbormasterController',
Render lint results as Harbormaster lint messages Summary: Ref T8095. Render lint results in a future-ready way. This makes the renderer accept `HarbormasterBuildLintMessage` objects. If we have legacy data instead, it converts it into `HarbormasterBuildLintMessage` objects. Design is a bit rough but will be cleaned up later after T7739. This moves away from "postponed linters", which are obsolete after Harbormaster (and were only ever used by Facebook). Test Plan: {F523429} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13377
2015-06-21 19:11:53 +02:00
'HarbormasterLintPropertyView' => 'AphrontView',
Compress Harbormaster build logs inline Summary: Ref T5822. - After a log is closed, compress it if possible. - Provide `bin/harbormaster archive-logs` to make it easier to change the storage format of logs. Test Plan: - Ran `bin/harbormaster archive-logs` on a bunch of logs, compressing and decompressing them without issues (same hashes, same decompressed size across multiple iterations). - Ran new builds, verified logs were compressed after they closed. Reviewers: chad Reviewed By: chad Maniphest Tasks: T5822 Differential Revision: https://secure.phabricator.com/D15380
2016-03-01 22:53:13 +01:00
'HarbormasterManagementArchiveLogsWorkflow' => 'HarbormasterManagementWorkflow',
Add `bin/harbormaster` to make builds easier to debug Summary: Ref T1049. Adds `bin/harbormaster` and `bin/harbormaster build` for applying plans from the console. Since this gets `--trace`, it's much easier to debug what's going on. This doesn't work properly with some of the Drydock steps yet, I need to look at those. I think `setRunAllTasksInProcess` probably obsoletes some of the mechanisms. It might also not work with "Wait for Builds" but I didn't check. Test Plan: Used `bin/harbormaster` to run a bunch of builds. Ran builds from web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7825
2013-12-26 19:40:52 +01:00
'HarbormasterManagementBuildWorkflow' => 'HarbormasterManagementWorkflow',
Give Buildables a status, populate it, and return it over Conduit Summary: Ref T4809. Currently, buildables have a status field but nothing populates it. Populate it: - When builds change state, update the Buildable state. - Use the new Buildable state on the web UI. - Return the new Buildable state from Conduit. To make it easier to debug/test this: - Provide `bin/harbormaster update Bxxx ...` to force foreground update of a Buildable. Test Plan: - Used `bin/harbormaster update Bxxx --force --trace` to update buildables. - Looked at buidlable list, saw statuses reported properly. - Used Conduit to read statuses. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4809 Differential Revision: https://secure.phabricator.com/D8799
2014-04-18 01:01:16 +02:00
'HarbormasterManagementUpdateWorkflow' => 'HarbormasterManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'HarbormasterManagementWorkflow' => 'PhabricatorManagementWorkflow',
Document how to use `harbormaster.sendmessage` to report lint and unit results Summary: Fixes T7419. This doesn't really do anything, just adds documentation. Test Plan: - Read the documentation: {F688899} - Created a build plan which makes an HTTP request to `example.com` and waits for a result. - Ran that build plan manually. - Called `harbormaster.sendmessage` manually with the example lint/unit values to provide a result. - Saw the results report correctly and the message ("fail") process as expected: {F688902} Reviewers: chad Reviewed By: chad Maniphest Tasks: T7419 Differential Revision: https://secure.phabricator.com/D13789
2015-08-04 22:05:52 +02:00
'HarbormasterMessageType' => 'Phobject',
Add a generic object for unit tests Summary: A later diff adds unit tests against edges, but we need real objects to connect with edges. Add some trivial objects to the Harbormaster database to compliment the similar HarbormasterScratchTable. On its own, this does nothing interesting. Test Plan: Built unit tests on this in a followup. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D2937
2012-07-09 19:39:14 +02:00
'HarbormasterObject' => 'HarbormasterDAO',
Lump Harbormaster build steps into groups Summary: Ref T8089. We have a lot of broken/confusing/prototype build steps that I want to hide from users when we unprototype Harbormaster. The dialog is also just kind of unwieldy. Organize this UI a little better and put all the sketchy junk in a "prototypes" group that you can't see unless prototypes are enabled. This doesn't break anything (the old steps will still work fine), but should reduce user confusion. Test Plan: Old UI: {F691439} New UI (prototypes off): {F691440} New UI (prototypes on): {F691441} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8089 Differential Revision: https://secure.phabricator.com/D13803
2015-08-06 13:19:42 +02:00
'HarbormasterOtherBuildStepGroup' => 'HarbormasterBuildStepGroup',
Replace "Cancel Build" with "Stop", "Resume" and "Restart" Summary: Ref T1049. Currently you can cancel a build, but now that we're tracking a lot more state we can stop, resume, and restart builds. When the user issues a command against a build, I'm writing it into an auxiliary queue (`HarbormasterBuildCommand`) and then reading them out in the worker. This is mostly to avoid race messes where we try to `save()` the object in multiple places: basically, the BuildEngine is the //only// thing that writes to Build objects, and it holds a lock while it does it. Test Plan: - Created a plan which runs "sleep 2" a bunch of times in a row. - Stopped, resumed, and restarted it. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7892
2014-01-06 21:32:20 +01:00
'HarbormasterPlanController' => 'HarbormasterController',
Allow Harbormaster build plans to be disabled Summary: Fixes T4187. Ref T1049. Allows build plans to be enabled or disabled. Test Plan: Enabled and disabled build plans. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4187, T1049 Differential Revision: https://secure.phabricator.com/D7822
2013-12-26 19:40:22 +01:00
'HarbormasterPlanDisableController' => 'HarbormasterPlanController',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterPlanEditController' => 'HarbormasterPlanController',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'HarbormasterPlanListController' => 'HarbormasterPlanController',
Use EditEngine for Harbormaster Build Plans, fix some crumbs/mobile stuff Summary: Ref T10457. - Use EditEngine for Build Plans. - Fix some minor issues with crumbs being inconsistent. - Fix some minor issues with mobile menus not being consistent/available. Test Plan: - Created and edited build plans. - Poked around in mobile width, verified mobile menu had the right stuff in it. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15357
2016-02-27 04:12:55 +01:00
'HarbormasterPlanRunController' => 'HarbormasterPlanController',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterPlanViewController' => 'HarbormasterPlanController',
Lump Harbormaster build steps into groups Summary: Ref T8089. We have a lot of broken/confusing/prototype build steps that I want to hide from users when we unprototype Harbormaster. The dialog is also just kind of unwieldy. Organize this UI a little better and put all the sketchy junk in a "prototypes" group that you can't see unless prototypes are enabled. This doesn't break anything (the old steps will still work fine), but should reduce user confusion. Test Plan: Old UI: {F691439} New UI (prototypes off): {F691440} New UI (prototypes on): {F691441} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8089 Differential Revision: https://secure.phabricator.com/D13803
2015-08-06 13:19:42 +02:00
'HarbormasterPrototypeBuildStepGroup' => 'HarbormasterBuildStepGroup',
Rename concrete Harbormaster step implementations Summary: Ref T1049. For consistency, rename these to "Harbormaster...". Test Plan: Ran migration, ran builds, everything still works fine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8602
2014-03-26 00:09:51 +01:00
'HarbormasterPublishFragmentBuildStepImplementation' => 'HarbormasterBuildStepImplementation',
Add "Autoplans" to Harbormaster Summary: Ref T8095. Two general problems: - I want Harbormaster to own all lint and unit test results. - I don't want users to have to configure anything for `arc` to keep working automatically. These are in conflict because generic lint/unit test ownership in Harbormaster requires that build targets exist which we can attach build results to. However, we can't currently create build targets on demand: Harbormaster assumes it is responsible for creating targets, then running code or making third-party service calls to actually run the builds. I considered two broad approaches to let `arc` push results into Harbormaster without requiring administrators to configure some kind of "arc results" build plan: # Add magic target PHIDs like `PHID-MAGIC-this-is-really-arc-unit`. # Add new code to build real targets with real PHIDs. (1) is probably a bit less work to get off the ground, but I think it's worse overall and very likely to create more problems in the long run. I particularly worry that it will lead to a small amount of special casing in a very large number of places, which seems more fragile. (2) is more work upfront but I think does a better job of putting all the special casing in one place that we can, e.g., more reasonably unit test, and letting the rest of the code rarely/never care about this case since it's just dealing with normal plans/steps/targets as far as it can tell. This diff introduces "autoplans", which are source templates for plans/steps. This let us "push" these targets into Harbormaster. Hypthetically, any process "like" arc can use autoplans to upload test/lint/etc results. In practice, probably only `arc` will ever use this, but I think it's still quite a bit cleaner than the alternative despite all the generality. Workflow is basically: - `arc` creates a diff. - `arc` calls `harbormaster.queryautotargets`, passing the diff PHID and saying "I have some lint and unit results I want to stick on this thing". - Harbormaster builds the plan, steps, and targets (if any of them don't already exist), and hands back the target PHIDs so `arc` has a completely standard-looking place to put results. - `arc` uploads the test results to the right targets, as though Harbormaster had asked it to run unit/lint in the first place. (This doesn't actually do any of that yet, just sets things up.) I'll maybe doc turn that ^^^^^^ into a doc for posterity since I think it's hard to guess what an "autotarget" is, but I'm going to grab some lunch first. Test Plan: - Added unit tests to make sure we can build these things properly. - Used `harbormaster.queryautotargets` to build autotargets for a bunch of diffs. - Verified targets come up in "waiting for message" state. - Verified plans and steps are not editable. Reviewers: btrahan Reviewed By: btrahan Subscribers: hach-que, epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13345
2015-06-21 18:04:21 +02:00
'HarbormasterQueryAutotargetsConduitAPIMethod' => 'HarbormasterConduitAPIMethod',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'HarbormasterQueryBuildablesConduitAPIMethod' => 'HarbormasterConduitAPIMethod',
'HarbormasterQueryBuildsConduitAPIMethod' => 'HarbormasterConduitAPIMethod',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'HarbormasterRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Modularize the Harbormaster "Run build plan" Herald action Ref T8726. Modularizes "Run build plan" in Differential and Diffusion.
2015-07-30 21:22:35 +02:00
'HarbormasterRunBuildPlansHeraldAction' => 'HeraldAction',
Generate expected schemata for Harbormaster Summary: Ref T1191. Nothing too notable here: - Allow a Lisk object to specify that there's no expectation that a table exists. We have one Harbormaster object and one Token object like this. - Removed BuildPlanTransactionComment because it's currently unused. Test Plan: - Saw ~200 fewer warnings; just ~800 left. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10583
2014-10-01 16:40:36 +02:00
'HarbormasterSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Remove PHID database, add Harbormaster database Summary: - We currently write every PHID we generate to a table. This was motivated by two concerns: - **Understanding Data**: At Facebook, the data was sometimes kind of a mess. You could look at a random user in the ID tool and see 9000 assocs with random binary data attached to them, pointing at a zillion other objects with no idea how any of it got there. I originally created this table to have a canonical source of truth about PHID basics, at least. In practice, our data model has been really tidy and consistent, and we don't use any of the auxiliary data in this table (or even write it). The handle abstraction is powerful and covers essentially all of the useful data in the app, and we have human-readable types in the keys. So I don't think we have a real need here, and this table isn't serving it if we do. - **Uniqueness**: With a unique key, we can be sure they're unique, even if we get astronomically unlucky and get a collision. But every table we use them in has a unique key anyway. So we actually get pretty much nothing here, except maybe some vague guarantee that we won't reallocate a key later if the original object is deleted. But it's hard to imagine any install will ever have a collision, given that the key space is 36^20 per object type. - We also currently use PHIDs and Users in tests sometimes. This is silly and can break (see D2461). - Drop the PHID database. - Introduce a "Harbormaster" database (the eventual CI tool, after Drydock). - Add a scratch table to the Harbormaster database for doing unit test meta-tests. - Now, PHID generation does no writes, and unit tests are isolated from the application. - @csilvers: This should slightly improve the performance of the large query-bound tail in D2457. Test Plan: Ran unit tests. Ran storage upgrade. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: csilvers, aran, nh, edward Differential Revision: https://secure.phabricator.com/D2466
2012-05-20 23:46:01 +02:00
'HarbormasterScratchTable' => 'HarbormasterDAO',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'HarbormasterSendMessageConduitAPIMethod' => 'HarbormasterConduitAPIMethod',
Rename concrete Harbormaster step implementations Summary: Ref T1049. For consistency, rename these to "Harbormaster...". Test Plan: Ran migration, ran builds, everything still works fine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8602
2014-03-26 00:09:51 +01:00
'HarbormasterSleepBuildStepImplementation' => 'HarbormasterBuildStepImplementation',
Use EditEngine for Harbormaster Build Plans, fix some crumbs/mobile stuff Summary: Ref T10457. - Use EditEngine for Build Plans. - Fix some minor issues with crumbs being inconsistent. - Fix some minor issues with mobile menus not being consistent/available. Test Plan: - Created and edited build plans. - Poked around in mobile width, verified mobile menu had the right stuff in it. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15357
2016-02-27 04:12:55 +01:00
'HarbormasterStepAddController' => 'HarbormasterPlanController',
'HarbormasterStepDeleteController' => 'HarbormasterPlanController',
'HarbormasterStepEditController' => 'HarbormasterPlanController',
'HarbormasterStepViewController' => 'HarbormasterPlanController',
Add "Autoplans" to Harbormaster Summary: Ref T8095. Two general problems: - I want Harbormaster to own all lint and unit test results. - I don't want users to have to configure anything for `arc` to keep working automatically. These are in conflict because generic lint/unit test ownership in Harbormaster requires that build targets exist which we can attach build results to. However, we can't currently create build targets on demand: Harbormaster assumes it is responsible for creating targets, then running code or making third-party service calls to actually run the builds. I considered two broad approaches to let `arc` push results into Harbormaster without requiring administrators to configure some kind of "arc results" build plan: # Add magic target PHIDs like `PHID-MAGIC-this-is-really-arc-unit`. # Add new code to build real targets with real PHIDs. (1) is probably a bit less work to get off the ground, but I think it's worse overall and very likely to create more problems in the long run. I particularly worry that it will lead to a small amount of special casing in a very large number of places, which seems more fragile. (2) is more work upfront but I think does a better job of putting all the special casing in one place that we can, e.g., more reasonably unit test, and letting the rest of the code rarely/never care about this case since it's just dealing with normal plans/steps/targets as far as it can tell. This diff introduces "autoplans", which are source templates for plans/steps. This let us "push" these targets into Harbormaster. Hypthetically, any process "like" arc can use autoplans to upload test/lint/etc results. In practice, probably only `arc` will ever use this, but I think it's still quite a bit cleaner than the alternative despite all the generality. Workflow is basically: - `arc` creates a diff. - `arc` calls `harbormaster.queryautotargets`, passing the diff PHID and saying "I have some lint and unit results I want to stick on this thing". - Harbormaster builds the plan, steps, and targets (if any of them don't already exist), and hands back the target PHIDs so `arc` has a completely standard-looking place to put results. - `arc` uploads the test results to the right targets, as though Harbormaster had asked it to run unit/lint in the first place. (This doesn't actually do any of that yet, just sets things up.) I'll maybe doc turn that ^^^^^^ into a doc for posterity since I think it's hard to guess what an "autotarget" is, but I'm going to grab some lunch first. Test Plan: - Added unit tests to make sure we can build these things properly. - Used `harbormaster.queryautotargets` to build autotargets for a bunch of diffs. - Verified targets come up in "waiting for message" state. - Verified plans and steps are not editable. Reviewers: btrahan Reviewed By: btrahan Subscribers: hach-que, epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13345
2015-06-21 18:04:21 +02:00
'HarbormasterTargetEngine' => 'Phobject',
Split Harbormaster workers apart so build steps can run in parallel Summary: Ref T1049. Currently, the Harbormaster worker looks like this: foreach (step) { run_step(step); } This means steps can't ever be run in parallel. Instead, split it into two workers. The "Build" worker starts things off, and basically does: update_build(); (We could theoretically do this in the original process because it should never take very long, but since there's a lock and it's a little bit complex it seemed cleaner to separate it.) The "Target" worker runs an individual target (like a command, or an HTTP request, or whatever), then updates the build: run_one_step(step); update_build(); The new `update_build()` mechanism in `HarbormasterBuildEngine` does this, roughly: figure_out_overall_status_of_all_steps(); if (build is done) { done(); } if (build is fail) { fail(); } foreach (step that is ready to run) { queue_target_worker_for_step(step); } So, overall: - The part of the code that updates Builds is completely separated from the part of the code that updates Targets. - Targets can run in parallel. Test Plan: - Ran a bunch of builds via `bin/harbormaster build`. - Ran a bunch of builds via web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7890
2014-01-06 21:32:10 +01:00
'HarbormasterTargetWorker' => 'HarbormasterWorker',
Lump Harbormaster build steps into groups Summary: Ref T8089. We have a lot of broken/confusing/prototype build steps that I want to hide from users when we unprototype Harbormaster. The dialog is also just kind of unwieldy. Organize this UI a little better and put all the sketchy junk in a "prototypes" group that you can't see unless prototypes are enabled. This doesn't break anything (the old steps will still work fine), but should reduce user confusion. Test Plan: Old UI: {F691439} New UI (prototypes off): {F691440} New UI (prototypes on): {F691441} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8089 Differential Revision: https://secure.phabricator.com/D13803
2015-08-06 13:19:42 +02:00
'HarbormasterTestBuildStepGroup' => 'HarbormasterBuildStepGroup',
Rename "BuildStepImplementation" to "HarbormasterBuildStepImplementation" Summary: Ref T1049. D8588 already required custom code to change what it extends, so this is as good a time as we're going to get to move to more standard class name. Test Plan: `arc liberate`; `arc lint` Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8601
2014-03-26 00:09:21 +01:00
'HarbormasterThrowExceptionBuildStep' => 'HarbormasterBuildStepImplementation',
Render build status on revisions and commits Summary: This uses an event listener to render the status of builds on their buildables. The revision and commit view now renders out the status of each of the builds. Currently the revision controller has the results for the latest diff rendered out. We might want to show the status of previous diffs in the future, but for now I think the latest diff should do fine. There's also a number of bug fixes in this diff, including a particularly nasty one where builds would have a build plan PHID generated for them, which resulted in handle lookups always returning invalid objects. Test Plan: Ran builds against diffs and commits, saw them appear on the revision and commit view controllers. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7544
2013-11-10 00:02:07 +01:00
'HarbormasterUIEventListener' => 'PhabricatorEventListener',
Add `harbormaster.createartifact` Summary: Ref T8659. In the general case, this eventually allows build processes to do things like: - Upload build results (like a ".app" or ".exe" or other binary). - Pass complex results between build steps (e.g., build step A does something hard and build step B uses it to do something else). Today, we're a long way away from having the infrastructure for that. However, it is useful to let third party build processes (like Jenkins) upload URIs that link back to the external build results. This adds `harbormaster.createartifact` so they can do that. The only useful thing to do with this method today is have your Jenkins build do this: params = array( "uri": "https://jenkins.mycompany.com/build/23923/details/", "name": "View Build Results in Jenkins", "ui.external": true, ); harbormaster.createartifact(target, 'uri', params); Then (after the next diff) we'll show a link in Differential and a prominent link in Harbormaster. I didn't actually do the UI stuff in this diff since it's already pretty big. This change moves a lot of code around, too: - Adds PHIDs to artifacts. - It modularizes build artifact types (currently "file", "host" and "URI"). - It formalizes build artifact parameters and construction: - This lets me generate usable documentation about how to create artifacts. - This prevents users from doing dangerous or policy-violating things. - It does some other general modernization. Test Plan: {F715633} {F715634} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8659 Differential Revision: https://secure.phabricator.com/D13900
2015-08-15 16:28:56 +02:00
'HarbormasterURIArtifact' => 'HarbormasterArtifact',
Show additional details for failed builds in Harbormaster Summary: Ref T10457. When tests fail, it currently takes several clicks to figure out //why// they failed. In this project, map rebuilds and `liberate` are fairly common failure conditions, but verifying that they were the root issue requires jumping into a build, then scrolling through a log. Instead, display details if they're available. Test Plan: Before: {F1135453} After: {F1135454} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9951, T10457 Differential Revision: https://secure.phabricator.com/D15363
2016-02-29 15:26:01 +01:00
'HarbormasterUnitMessageListController' => 'HarbormasterController',
'HarbormasterUnitMessageViewController' => 'HarbormasterController',
Render unit results as Harbormaster unit messages Summary: Ref T8095. Same as D13377, but for unit results. This is a bit rough and there's some duplication between this and unit results. I'll likely merge them later, but I think some of it is superficial since these iterations are still a little crude. Test Plan: {F523499} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8095 Differential Revision: https://secure.phabricator.com/D13378
2015-06-21 19:37:55 +02:00
'HarbormasterUnitPropertyView' => 'AphrontView',
Begin making Harbormaster unit test results a little easier to read Summary: Ref T10457. These lack color and iconography and are difficult to parse. Make them easier to read. Test Plan: Before: {F1135396} After: {F1135399} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15362
2016-02-29 15:15:13 +01:00
'HarbormasterUnitStatus' => 'Phobject',
Give unit test results their own table in Differential Summary: Ref T10457. This gives unit test results a more first-class treatment in the Differential UI, and consolidates some rendering code. Test Plan: Before: {F1135536} After: {F1135537} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10457 Differential Revision: https://secure.phabricator.com/D15365
2016-02-29 18:53:46 +01:00
'HarbormasterUnitSummaryView' => 'AphrontView',
Rename concrete Harbormaster step implementations Summary: Ref T1049. For consistency, rename these to "Harbormaster...". Test Plan: Ran migration, ran builds, everything still works fine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8602
2014-03-26 00:09:51 +01:00
'HarbormasterUploadArtifactBuildStepImplementation' => 'HarbormasterBuildStepImplementation',
'HarbormasterWaitForPreviousBuildStepImplementation' => 'HarbormasterBuildStepImplementation',
Split Harbormaster workers apart so build steps can run in parallel Summary: Ref T1049. Currently, the Harbormaster worker looks like this: foreach (step) { run_step(step); } This means steps can't ever be run in parallel. Instead, split it into two workers. The "Build" worker starts things off, and basically does: update_build(); (We could theoretically do this in the original process because it should never take very long, but since there's a lock and it's a little bit complex it seemed cleaner to separate it.) The "Target" worker runs an individual target (like a command, or an HTTP request, or whatever), then updates the build: run_one_step(step); update_build(); The new `update_build()` mechanism in `HarbormasterBuildEngine` does this, roughly: figure_out_overall_status_of_all_steps(); if (build is done) { done(); } if (build is fail) { fail(); } foreach (step that is ready to run) { queue_target_worker_for_step(step); } So, overall: - The part of the code that updates Builds is completely separated from the part of the code that updates Targets. - Targets can run in parallel. Test Plan: - Ran a bunch of builds via `bin/harbormaster build`. - Ran a bunch of builds via web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7890
2014-01-06 21:32:10 +01:00
'HarbormasterWorker' => 'PhabricatorWorker',
Allow Harbormaster to lease working copies from Drydock Summary: Ref T9252. This is still crude in a few ways but basically works, at least for commits. Test Plan: - Made a build plan with just this build step. - Ran `bin/harbormaster build --plan 10 ...` on a commit. - It actually built a working copy, leased it, took no action, and released the lease. MAGIC~~~ Reviewers: chad Reviewed By: chad Maniphest Tasks: T9252 Differential Revision: https://secure.phabricator.com/D14160
2015-09-25 02:29:47 +02:00
'HarbormasterWorkingCopyArtifact' => 'HarbormasterDrydockLeaseArtifact',
Make Herald action modularization more aggressive Summary: Ref T8726. Herald actions are technically sort-of modular already, but make them more aggressively modular similar to `HeraldField`. I plan to obsolete and replace `HeraldCustomAction`. Test Plan: Saw actions in nice groups; created and ran a "Do Nothing" action. Transcripts are a bit rough for now. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13646
2015-07-17 19:27:38 +02:00
'HeraldAction' => 'Phobject',
'HeraldActionGroup' => 'HeraldGroup',
Rename "HeraldAction" to "HeraldActionRecord" Summary: Ref T8726. I want to modularize actions like fields, but the base class should be "HeraldAction". Eventually, "HeraldCondition" should probably be "HeraldFieldRecord", and then both Action and Condition should just be rolled into Rule, probably, but that can wait and doesn't block anything. Test Plan: Ran migration, poked around UI, used `git grep`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13644
2015-07-23 22:26:40 +02:00
'HeraldActionRecord' => 'HeraldDAO',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'HeraldAdapter' => 'Phobject',
Modularize more Herald fields Summary: Ref T8726. Continue making Herald fields more modular than they currently are. Test Plan: - Created a rule using all the affected fields. - Ran the rule. - Saw reasonable object field values. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13495
2015-07-06 22:15:47 +02:00
'HeraldAlwaysField' => 'HeraldField',
'HeraldAnotherRuleField' => 'HeraldField',
Modularize Maniphest Herald "Assign Task" action Summary: Ref T8726. No surprises here. Test Plan: - Created rules using this action. - Applied migration. - Verified rules still work. {F659324} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13706
2015-07-24 21:51:30 +02:00
'HeraldApplicationActionGroup' => 'HeraldActionGroup',
Generate expected schemata for Fact, Owners, Herald and Diviner Summary: Ref T1191. Notable: - `HeraldApplyTranscript` is not actually a DAO and has no table (it is serialized into HeraldTranscript). Test Plan: Down to fewer than 300 issues. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10588
2014-10-01 16:53:12 +02:00
'HeraldApplyTranscript' => 'Phobject',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'HeraldBasicFieldGroup' => 'HeraldFieldGroup',
Modularize the Harbormaster "Run build plan" Herald action Ref T8726. Modularizes "Run build plan" in Differential and Diffusion.
2015-07-30 21:22:35 +02:00
'HeraldCommitAdapter' => array(
'HeraldAdapter',
'HarbormasterBuildableAdapterInterface',
),
Herald skeleton.
2011-03-22 21:22:40 +01:00
'HeraldCondition' => 'HeraldDAO',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'HeraldConditionTranscript' => 'Phobject',
Begin modularizing Herald fields Summary: Ref T8726. This lays groundwork for modularizing Herald fields and modularizes the "Content source" field. This doesn't touch conditions or values yet. Test Plan: Created a rule with a "content source" field, created a new task, saw rule apply. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13488
2015-07-06 22:15:33 +02:00
'HeraldContentSourceField' => 'HeraldField',
Rough cut of Herald home controller.
2011-03-22 21:49:46 +01:00
'HeraldController' => 'PhabricatorController',
Herald skeleton.
2011-03-22 21:22:40 +01:00
'HeraldDAO' => 'PhabricatorLiskDAO',
Allow Herald "diff" rules to reject content before it is written Summary: Fixes T5915. Occasionally, users derp up and diff private key material. Adding a pre-write Herald phase enables configuration of a partial layer of protection that will reject these changes before they hit disk, provided they can be detected by, e.g., filename. Test Plan: - Added a rule with checks on every field, verified they looked fine in the transcript. - Created some revisions to test those changes (I have a bunch of revision rules locally). - Verified rejects don't write transcripts to the database. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5915 Differential Revision: https://secure.phabricator.com/D10305
2014-08-20 23:26:29 +02:00
'HeraldDifferentialAdapter' => 'HeraldAdapter',
'HeraldDifferentialDiffAdapter' => 'HeraldDifferentialAdapter',
Modularize the Harbormaster "Run build plan" Herald action Ref T8726. Modularizes "Run build plan" in Differential and Diffusion.
2015-07-30 21:22:35 +02:00
'HeraldDifferentialRevisionAdapter' => array(
'HeraldDifferentialAdapter',
'HarbormasterBuildableAdapterInterface',
),
Allow Herald rules to be disabled, instead of deleted Summary: Ref T603. Ref T1279. Further improves transaction and policy support for Herald. - Instead of deleting rules (which wipes out history and can't be undone) allow them to be disabled. - Track disables with transactions. - Gate disables with policy controls. - Show policy and status information in the headers. - Show transaction history on rule detail screens. - Remove the delete controller. - Support disabled queries in the ApplicationSearch. Test Plan: - Enabled and disabled rules. - Searched for enabled/disabled rules. - Verified disabled rules don't activate. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1279, T603 Differential Revision: https://secure.phabricator.com/D7247
2013-10-07 02:10:29 +02:00
'HeraldDisableController' => 'HeraldController',
Make Herald action modularization more aggressive Summary: Ref T8726. Herald actions are technically sort-of modular already, but make them more aggressively modular similar to `HeraldField`. I plan to obsolete and replace `HeraldCustomAction`. Test Plan: Saw actions in nice groups; created and ran a "Do Nothing" action. Transcripts are a bit rough for now. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13646
2015-07-17 19:27:38 +02:00
'HeraldDoNothingAction' => 'HeraldAction',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'HeraldEditFieldGroup' => 'HeraldFieldGroup',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'HeraldEffect' => 'Phobject',
Begin modularizing Herald field values Summary: Ref T8726. I'm primarily trying to modularize tokenizer values so we don't have to update JS to add a new one. This is ultimately the blocker for "select" custom fields working in Herald. This inches us toward that. I'm //not// modularizing conditions or control types in this round, but hope to end up with hard-coded conditions (which are highly general and very rarely change), hard-coded control types (which are also highly general and very rarely change) and completely modular fields and values (which have mid-to-low generality and change frequently). Test Plan: Used UI to interact with "none", "text", and new-style "select" controls. No actual support for tokenizers yet. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13613
2015-07-16 23:12:00 +02:00
'HeraldEmptyFieldValue' => 'HeraldFieldValue',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'HeraldEngine' => 'Phobject',
Add Herald support for projects Summary: Ref T10054. Ref T6113. I'm going to remove subscribers from projects to fix the confusion between "watch" and "subscribe". Users who have unusual use cases where they legitimately want to know when a project's description is updated or members change can use Herald to follow it. This is also useful in general and improves consistency, although I don't have too many use cases for it. Test Plan: Wrote a Herald rule, edited a project, saw the rule fire and send me email about the change. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6113, T10054 Differential Revision: https://secure.phabricator.com/D15061
2016-01-20 02:18:17 +01:00
'HeraldExactProjectsField' => 'HeraldField',
Begin modularizing Herald fields Summary: Ref T8726. This lays groundwork for modularizing Herald fields and modularizes the "Content source" field. This doesn't touch conditions or values yet. Test Plan: Created a rule with a "content source" field, created a new task, saw rule apply. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13488
2015-07-06 22:15:33 +02:00
'HeraldField' => 'Phobject',
Make Herald action modularization more aggressive Summary: Ref T8726. Herald actions are technically sort-of modular already, but make them more aggressively modular similar to `HeraldField`. I plan to obsolete and replace `HeraldCustomAction`. Test Plan: Saw actions in nice groups; created and ran a "Do Nothing" action. Transcripts are a bit rough for now. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13646
2015-07-17 19:27:38 +02:00
'HeraldFieldGroup' => 'HeraldGroup',
Add a trivial test case for HeraldField Summary: Adds a trivial test case to ensure that `HeraldField` subclasses are properly implemented. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13577
2015-07-07 15:05:02 +02:00
'HeraldFieldTestCase' => 'PhutilTestCase',
Begin modularizing Herald field values Summary: Ref T8726. I'm primarily trying to modularize tokenizer values so we don't have to update JS to add a new one. This is ultimately the blocker for "select" custom fields working in Herald. This inches us toward that. I'm //not// modularizing conditions or control types in this round, but hope to end up with hard-coded conditions (which are highly general and very rarely change), hard-coded control types (which are also highly general and very rarely change) and completely modular fields and values (which have mid-to-low generality and change frequently). Test Plan: Used UI to interact with "none", "text", and new-style "select" controls. No actual support for tokenizers yet. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13613
2015-07-16 23:12:00 +02:00
'HeraldFieldValue' => 'Phobject',
Make Herald action modularization more aggressive Summary: Ref T8726. Herald actions are technically sort-of modular already, but make them more aggressively modular similar to `HeraldField`. I plan to obsolete and replace `HeraldCustomAction`. Test Plan: Saw actions in nice groups; created and ran a "Do Nothing" action. Transcripts are a bit rough for now. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13646
2015-07-17 19:27:38 +02:00
'HeraldGroup' => 'Phobject',
Remove HeraldActionConfig, HeraldFieldConfig Summary: Ref T2769. Move all of this stuff into Adapters and get rid of the hard-coded classes. I cheated in two places. Test Plan: Edited and activated Herald rules. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6688
2013-08-06 20:23:01 +02:00
'HeraldInvalidActionException' => 'Exception',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'HeraldInvalidConditionException' => 'Exception',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'HeraldManageGlobalRulesCapability' => 'PhabricatorPolicyCapability',
Add herald support for Maniphest Summary: standing on the shoulders of the badass work to move Maniphest to ApplicationTransactions, this diff implements a few methods and adds an adapter class. For now, we can add cc and flag tasks. I figure see what people ask for? Ref T1368. Test Plan: created herald rules for title and description text hits. made tasks and verified CC and flags worked. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T1368, T1638 Differential Revision: https://secure.phabricator.com/D7122
2013-09-25 20:50:15 +02:00
'HeraldManiphestTaskAdapter' => 'HeraldAdapter',
Herald 'new rule type' interface.
2011-03-22 22:34:38 +01:00
'HeraldNewController' => 'HeraldController',
Modularize more Herald fields Summary: Ref T8726. Continue making Herald fields more modular than they currently are. Test Plan: - Created a rule using all the affected fields. - Ran the rule. - Saw reasonable object field values. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13495
2015-07-06 22:15:47 +02:00
'HeraldNewObjectField' => 'HeraldField',
Make Herald action modularization more aggressive Summary: Ref T8726. Herald actions are technically sort-of modular already, but make them more aggressively modular similar to `HeraldField`. I plan to obsolete and replace `HeraldCustomAction`. Test Plan: Saw actions in nice groups; created and ran a "Do Nothing" action. Transcripts are a bit rough for now. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13646
2015-07-17 19:27:38 +02:00
'HeraldNotifyActionGroup' => 'HeraldActionGroup',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'HeraldObjectTranscript' => 'Phobject',
Add Herald Adapters to Phame Summary: Adds a basic HeraldAdapter to Phame Blogs and Posts. Test Plan: Make a Herald rule to CC me on new posts or blogs automatically. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14897
2015-12-28 05:19:39 +01:00
'HeraldPhameBlogAdapter' => 'HeraldAdapter',
'HeraldPhamePostAdapter' => 'HeraldAdapter',
Integrate Pholio with Herald Summary: Ref T2766. Does the integration via ApplicationTransactionsEditor. Only did addCC and Flag for proof of concept. Test Plan: Made a rule to cc, made a rule to flag. They worked! (will attach screens to diff) Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T2766 Differential Revision: https://secure.phabricator.com/D6766
2013-08-15 22:10:45 +02:00
'HeraldPholioMockAdapter' => 'HeraldAdapter',
Add basic Herald support to Ponder Summary: Ref T6919, Just a basic herald adapter (new questions) for Ponder Test Plan: Created a Personal Rule, got subscribed to new question, saw transcript. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T6919 Differential Revision: https://secure.phabricator.com/D13828
2015-08-08 19:22:18 +02:00
'HeraldPonderQuestionAdapter' => 'HeraldAdapter',
Allow Herald pre-commit rules to act on repository projects Summary: Fixes T4264. Adds: - New "Repository's projects" field to Herald pre-commit rules, so you can write global rules which act based on projects. - Allows pre-ref/pre-content rules to bind to projects, and fire for all repositories in that project, so users with limited power can write rules which apply to many repositories. - The pre-ref and pre-content classes were starting to share a fair amount of code, so I made them both extend an abstract base class. Test Plan: Wrote new pre-ref and pre-content rules bound to projects, then pushed commits into repositories in those projects and not in those projects. The "repository projects" field populated, and the rules fired for repositories in the relevant projects. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4264 Differential Revision: https://secure.phabricator.com/D7883
2014-01-03 21:24:28 +01:00
'HeraldPreCommitAdapter' => 'HeraldAdapter',
'HeraldPreCommitContentAdapter' => 'HeraldPreCommitAdapter',
'HeraldPreCommitRefAdapter' => 'HeraldPreCommitAdapter',
Make Herald action modularization more aggressive Summary: Ref T8726. Herald actions are technically sort-of modular already, but make them more aggressively modular similar to `HeraldField`. I plan to obsolete and replace `HeraldCustomAction`. Test Plan: Saw actions in nice groups; created and ran a "Do Nothing" action. Transcripts are a bit rough for now. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13646
2015-07-17 19:27:38 +02:00
'HeraldPreventActionGroup' => 'HeraldActionGroup',
Modularize more Herald fields Summary: Ref T8726. Continue making Herald fields more modular than they currently are. Test Plan: - Created a rule using all the affected fields. - Ran the rule. - Saw reasonable object field values. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13495
2015-07-06 22:15:47 +02:00
'HeraldProjectsField' => 'HeraldField',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'HeraldRecursiveConditionsException' => 'Exception',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'HeraldRelatedFieldGroup' => 'HeraldFieldGroup',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'HeraldRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'HeraldRepetitionPolicyConfig' => 'Phobject',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'HeraldRule' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'HeraldDAO',
Transactions - deploy buildTransactionTimeline against a few more applications Summary: Ref T4712. Thus far, it seems that most "non-standard" things can be done pretty easily in the controller. Aside from deploying, this diff had to fix a few bugs / missing implementations of stuff. (Notably, PhabricatorAuthProviderConfig, HeraldRule, PhabricatorSlowvotePoll, and AlmanacNetwork needed to implement PhabricatorApplicationTransactionInterface, PhabricatorAuthAuthProviderPHIDType had to be added, and a rendering bug in transactions of type PhabricatorOAuth2AuthProvider had to be fixed.) Test Plan: Almanac - looked at binding, device, network, and service view controllers and verified timeline displayed properly. Herald - looked at a rule and verified timeline. Slowvote - looked at a vote and verified timeline. Auth - looked at an auth provider (Facebook) and verified proper display of transactions within timeline. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10921
2014-12-02 23:33:59 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorFlaggableInterface',
'PhabricatorPolicyInterface',
'PhabricatorDestructibleInterface',
Make Herald rules subscribable Summary: Fixes T9757. Test Plan: Created a Herald rule and then subscribed to it with a different account. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Maniphest Tasks: T9757 Differential Revision: https://secure.phabricator.com/D14468
2015-11-16 20:27:12 +01:00
'PhabricatorSubscribableInterface',
Make HeraldRule implement PhabricatorPolicyInterface Summary: Ref T603. Ref T2769. Herald currently interacts with policies in a bad way; specifically, I can create a rule which emails me for everything, and thus learn about objects I can't otherwise see. This shouldn't be possible, so I'm going to reduce personal rules to have only the viewer's scope. For global rules, I think I'm always going to let any user edit them, but make who the rule acts as part of the configuration. There will be an option to make a rule omnipotent, but only admins (or some other special subset of users) will be able to select it. Transactions/subscriptions will provide a check against users editing global rules in ways that are bad. Test Plan: Next diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2769 Differential Revision: https://secure.phabricator.com/D6649
2013-08-02 15:21:43 +02:00
),
Horrendously rough cut of Herald rule editor.
2011-03-22 23:27:52 +01:00
'HeraldRuleController' => 'HeraldController',
Allow Herald rules to be disabled, instead of deleted Summary: Ref T603. Ref T1279. Further improves transaction and policy support for Herald. - Instead of deleting rules (which wipes out history and can't be undone) allow them to be disabled. - Track disables with transactions. - Gate disables with policy controls. - Show policy and status information in the headers. - Show transaction history on rule detail screens. - Remove the delete controller. - Support disabled queries in the ApplicationSearch. Test Plan: - Enabled and disabled rules. - Searched for enabled/disabled rules. - Verified disabled rules don't activate. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1279, T603 Differential Revision: https://secure.phabricator.com/D7247
2013-10-07 02:10:29 +02:00
'HeraldRuleEditor' => 'PhabricatorApplicationTransactionEditor',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'HeraldRuleListController' => 'HeraldController',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'HeraldRulePHIDType' => 'PhabricatorPHIDType',
Make HeraldRuleQuery policy-aware Summary: Ref T2769. dem policy checks Test Plan: Loaded `/herald/`; loaded rule editor. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6650
2013-08-02 15:38:17 +02:00
'HeraldRuleQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Use ApplicationSearch in Herald Summary: Ref T2769. Ref T2625. Herald is currently a giant mishmash of hard-codes and weird special cases. Move toward modernization and normality. Test Plan: {F52716} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625, T2769 Differential Revision: https://secure.phabricator.com/D6652
2013-08-02 15:53:01 +02:00
'HeraldRuleSearchEngine' => 'PhabricatorApplicationSearchEngine',
Drive Herald edits via transactions Summary: This is kinda bad in terms of UI (It just makes a json of the thing and diffs that), but it's a start. Test Plan: edit rule, create rule, add/remove/edit conditions, actions Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15542
2016-03-29 01:02:41 +02:00
'HeraldRuleSerializer' => 'Phobject',
Make execution order of Herald rules explicit Summary: Fixes T6211. This gives Herald rules an explicit execution order, which seems generally good. See some discussion on T6211 and inline. Test Plan: - Added unit test. - Dry ran rules and saw rules appear in the expected order in the transcript. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6211 Differential Revision: https://secure.phabricator.com/D10624
2014-10-02 18:49:32 +02:00
'HeraldRuleTestCase' => 'PhabricatorTestCase',
Add ApplicationTransactions to Herald Summary: Ref T2769. I'm planning to keep this pretty simple, but we have this ad-hoc edit log for rules already and some other mess that we can clean up. Test Plan: No effect yet; see future changes. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6654
2013-08-02 17:28:55 +02:00
'HeraldRuleTransaction' => 'PhabricatorApplicationTransaction',
'HeraldRuleTransactionComment' => 'PhabricatorApplicationTransactionComment',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'HeraldRuleTranscript' => 'Phobject',
'HeraldRuleTypeConfig' => 'Phobject',
Add a normal "view" page for Herald rules Summary: Ref T2769. This will house the transaction list and replace the "edit log" stuff. The UI is a little bit rough and can probably share more code with the transaction history, but seems mostly-reasonable. Test Plan: {F53253} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6690
2013-08-06 22:43:45 +02:00
'HeraldRuleViewController' => 'HeraldController',
Generate expected schemata for Fact, Owners, Herald and Diviner Summary: Ref T1191. Notable: - `HeraldApplyTranscript` is not actually a DAO and has no table (it is serialized into HeraldTranscript). Test Plan: Down to fewer than 300 issues. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10588
2014-10-01 16:53:12 +02:00
'HeraldSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Begin modularizing Herald field values Summary: Ref T8726. I'm primarily trying to modularize tokenizer values so we don't have to update JS to add a new one. This is ultimately the blocker for "select" custom fields working in Herald. This inches us toward that. I'm //not// modularizing conditions or control types in this round, but hope to end up with hard-coded conditions (which are highly general and very rarely change), hard-coded control types (which are also highly general and very rarely change) and completely modular fields and values (which have mid-to-low generality and change frequently). Test Plan: Used UI to interact with "none", "text", and new-style "select" controls. No actual support for tokenizers yet. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13613
2015-07-16 23:12:00 +02:00
'HeraldSelectFieldValue' => 'HeraldFieldValue',
Modularize more Herald fields Summary: Ref T8726. Continue making Herald fields more modular than they currently are. Test Plan: - Created a rule using all the affected fields. - Ran the rule. - Saw reasonable object field values. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13495
2015-07-06 22:15:47 +02:00
'HeraldSpaceField' => 'HeraldField',
'HeraldSubscribersField' => 'HeraldField',
Make Herald action modularization more aggressive Summary: Ref T8726. Herald actions are technically sort-of modular already, but make them more aggressively modular similar to `HeraldField`. I plan to obsolete and replace `HeraldCustomAction`. Test Plan: Saw actions in nice groups; created and ran a "Do Nothing" action. Transcripts are a bit rough for now. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13646
2015-07-17 19:27:38 +02:00
'HeraldSupportActionGroup' => 'HeraldActionGroup',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'HeraldSupportFieldGroup' => 'HeraldFieldGroup',
Very rough cut at Herald test console.
2011-03-24 21:49:21 +01:00
'HeraldTestConsoleController' => 'HeraldController',
Begin modularizing Herald field values Summary: Ref T8726. I'm primarily trying to modularize tokenizer values so we don't have to update JS to add a new one. This is ultimately the blocker for "select" custom fields working in Herald. This inches us toward that. I'm //not// modularizing conditions or control types in this round, but hope to end up with hard-coded conditions (which are highly general and very rarely change), hard-coded control types (which are also highly general and very rarely change) and completely modular fields and values (which have mid-to-low generality and change frequently). Test Plan: Used UI to interact with "none", "text", and new-style "select" controls. No actual support for tokenizers yet. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13613
2015-07-16 23:12:00 +02:00
'HeraldTextFieldValue' => 'HeraldFieldValue',
Fully modularize Herald field values Summary: Ref T8726. This gets rid of all the `VALUE_*` constants and lets Fields provide arbitrary typeaheads without upstream/JS changes. Test Plan: Used all tokenizers. Used "Another Herald Rule". Grepped for all removed constants. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13616
2015-07-16 23:12:44 +02:00
'HeraldTokenizerFieldValue' => 'HeraldFieldValue',
Allow Herald rules to be disabled, instead of deleted Summary: Ref T603. Ref T1279. Further improves transaction and policy support for Herald. - Instead of deleting rules (which wipes out history and can't be undone) allow them to be disabled. - Track disables with transactions. - Gate disables with policy controls. - Show policy and status information in the headers. - Show transaction history on rule detail screens. - Remove the delete controller. - Support disabled queries in the ApplicationSearch. Test Plan: - Enabled and disabled rules. - Searched for enabled/disabled rules. - Verified disabled rules don't activate. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1279, T603 Differential Revision: https://secure.phabricator.com/D7247
2013-10-07 02:10:29 +02:00
'HeraldTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'HeraldTranscript' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'HeraldDAO',
'PhabricatorPolicyInterface',
When destroying an object, destroy its Herald transcripts too Summary: Ref T5915. Make `bin/remove destroy` a bit more thorough, since Herald transcripts can have field information in them. Test Plan: Used `bin/remove destroy` to nuke revisions, saw their transcripts vanish too. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5915 Differential Revision: https://secure.phabricator.com/D10306
2014-08-21 00:04:34 +02:00
'PhabricatorDestructibleInterface',
Migrate all Differential reviewer data to edges Summary: Ref T1279. @champo did a lot of this work already; we've been doing double writes for a long time. Add "double reads" (reading the edge table as both the "relationship" table and as the "reviewer status" table), and migrate all the data. I'm not bothering to try to recover old reviewer status (e.g., we could infer from transactions who accepted old revisions) because it wold be very complicated and doesn't seem too valuable. Test Plan: - Without doing the migration, used Differential. Verified that reads and writes worked. Most of the data was there anyway since we've been double-writing. - Performed the migration. Verified that everything was still unchanged. - Dropped the edge table, verified all reviweer data vanished. - Migrated again, verified the reviewer stuff was restored. - Did various cc/reviewer/subscriber queries, got consistent results. Reviewers: btrahan Reviewed By: btrahan CC: champo, aran Maniphest Tasks: T1279 Differential Revision: https://secure.phabricator.com/D7227
2013-10-05 22:48:45 +02:00
),
Rough cut of herald transcripts and Differential adapter.
2011-03-25 05:32:26 +01:00
'HeraldTranscriptController' => 'HeraldController',
Fully modularize DestructionEngine Summary: Ref T9979. Convert all DestructionEngine behaviors to extensions. Test Plan: {F1033244} Destroyed an object, verifying: - Herald transcripts were destroyed; - edges were destroyed; - flags were destroyed; - tokens were destroyed; - transactions were destroyed; - worker tasks were cancelled. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14832
2015-12-20 17:11:59 +01:00
'HeraldTranscriptDestructionEngineExtension' => 'PhabricatorDestructionEngineExtension',
Modularize the Garbage Collector Summary: The GC is a big block of hard-coded application GCs right now. Among other things, this means third parties can't tap into the infrastructure. Modularize it into `GarbageCollector` classes. This implements only one to prove the new stuff works; I'll followup with the rest in the next diff or few depending on how much mess I run into. Test Plan: Used `bin/phd debug garbage` to run the collector in debug mode, observed reasonable output and behavior. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7970
2014-01-15 19:02:24 +01:00
'HeraldTranscriptGarbageCollector' => 'PhabricatorGarbageCollector',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'HeraldTranscriptListController' => 'HeraldController',
Add PHIDType for HeraldTransaction Test Plan: Paste a HLXS phid to the quick-search box, get transaction page. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D15028
2016-01-15 17:40:48 +01:00
'HeraldTranscriptPHIDType' => 'PhabricatorPHIDType',
Make Herald transcripts policy-aware Summary: Ref T603. Herald transcripts potentially leak a bunch of content (task text, revision/commit content). Don't let users see them if they can't see the actual objects. This is a little messy but ends up mostly reasonable-ish. Test Plan: - Verified that transcripts for objects I couldn't see no longer appear in the list, and reject access. - Verified that transcripts for objects in applications I can't see reject access, albeit less gracefully. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7221
2013-10-05 00:17:18 +02:00
'HeraldTranscriptQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Herald - add application search for transcripts Summary: this diff also makes the "test console" appear with the main search nav *and* updates application search to use the page title as the crumb rather than just search. Fixes T4399. Test Plan: queried for transcript ids - success! queried for TX and MX - success! saved the TX and MX query and it worked again! Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4399 Differential Revision: https://secure.phabricator.com/D8297
2014-02-21 21:51:25 +01:00
'HeraldTranscriptSearchEngine' => 'PhabricatorApplicationSearchEngine',
Truncate object fields in Herald transcripts Summary: A few users have hit cases where Herald transcripts of large commits exceed the MySQL packet limit, because one of the fields in the transcript is an enomrous textual diff. There's no value in saving these huge amounts of data. Transcripts are useful for understanding the action of Herald rules, but can be reconstructed later. Instead of saving all of the data, limit each field to 4KB of data. For strings, we just truncate at 4KB. For arrays, we truncate after 4KB of values. Test Plan: Ran unit tests. Artificially decreased limit and ran transcripts, saw them truncate properly. Reviewers: btrahan Reviewed By: btrahan CC: frgtn, aran Differential Revision: https://secure.phabricator.com/D7783
2013-12-18 20:59:53 +01:00
'HeraldTranscriptTestCase' => 'PhabricatorTestCase',
Make Herald action modularization more aggressive Summary: Ref T8726. Herald actions are technically sort-of modular already, but make them more aggressively modular similar to `HeraldField`. I plan to obsolete and replace `HeraldCustomAction`. Test Plan: Saw actions in nice groups; created and ran a "Do Nothing" action. Transcripts are a bit rough for now. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13646
2015-07-17 19:27:38 +02:00
'HeraldUtilityActionGroup' => 'HeraldActionGroup',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'Javelin' => 'Phobject',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'JavelinReactorUIExample' => 'PhabricatorUIExample',
Add support for placeholders Summary: Support placeholder text for inputs. We currently don't use this because it requires JS and doesn't degrade (no JS means you have zero idea what the input is for if it isn't separately labeled) but there are some cases where intent is obvious from context (for example, the search input in the menu bar, which is fairly obvious on its own and will soon have a magnifying glass icon) and in such cases it's much prettier and saves a bunch of space over an explicit label. Add a behavior so we can add placeholders where they make sense. This implementation is somewhat sanity-checked agianst the two jQuery placeholder implementations I was able to google: https://github.com/danielstocks/jQuery-Placeholder/ https://github.com/mathiasbynens/jquery-placeholder Since we don't currently have any uses cases, I haven't included support for making JS access to the `value` work, for password inputs, or for dynamically altering the placeholder. Test Plan: Played around with the placeholder in the UI example in various browsers and couldn't break it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3103
2012-07-31 01:08:10 +02:00
'JavelinUIExample' => 'PhabricatorUIExample',
Examples using JX.View Summary: Provide a dirt-simple working example of client-side templating and reactive programming. Test Plan: Load the examples Reviewers: epriestley, mroch, tomo Reviewed By: epriestley CC: ide, schrockn, aran, rzadorozny, epriestley Differential Revision: 908
2011-09-07 23:01:13 +02:00
'JavelinViewExampleServerView' => 'AphrontView',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'JavelinViewUIExample' => 'PhabricatorUIExample',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadController' => 'PhabricatorController',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'LegalpadCreateDocumentsCapability' => 'PhabricatorPolicyCapability',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadDAO' => 'PhabricatorLiskDAO',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'LegalpadDefaultEditCapability' => 'PhabricatorPolicyCapability',
'LegalpadDefaultViewCapability' => 'PhabricatorPolicyCapability',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'LegalpadDocument' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'LegalpadDAO',
'PhabricatorPolicyInterface',
'PhabricatorSubscribableInterface',
'PhabricatorApplicationTransactionInterface',
'PhabricatorDestructibleInterface',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
),
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'LegalpadDocumentBody' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'LegalpadDAO',
'PhabricatorMarkupInterface',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
),
'LegalpadDocumentCommentController' => 'LegalpadController',
Modernize "legalpad" typeahead datasource Summary: Ref T4420. Modernize legalpad. Test Plan: - Used typeahead in Herald rules. - Used typeahead in Policy dialog. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9876
2014-07-11 01:18:48 +02:00
'LegalpadDocumentDatasource' => 'PhabricatorTypeaheadDatasource',
Streamline Legalpad signature workflow Summary: Generally reduces friction, standardizes, and simplifies this workflow. Particularly, this removes "address" and "phone", which I think we can wait for user demand for. For logged-in users, we just always use their primary email. Test Plan: See screenshots. Reviewers: chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9735
2014-06-26 16:16:42 +02:00
'LegalpadDocumentDoneController' => 'LegalpadController',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadDocumentEditController' => 'LegalpadController',
'LegalpadDocumentEditor' => 'PhabricatorApplicationTransactionEditor',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'LegalpadDocumentListController' => 'LegalpadController',
Make view/sign page the primary Legalpad page Summary: - Makes the "legal document" page the main page. - Links to the "manage" page. - The "manage" operation now requires CAN_EDIT. - Modernize some crumbs and such. Test Plan: {F170213} Reviewers: chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9733
2014-06-26 03:38:07 +02:00
'LegalpadDocumentManageController' => 'LegalpadController',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadDocumentQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'LegalpadDocumentRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadDocumentSearchEngine' => 'PhabricatorApplicationSearchEngine',
Legalpad - add signature page Summary: Fixes T3481. Sort of - this thing be very ugly. Also it assumes that you'll "always" want to sign terms. I was thinking in a future diff that should be optional as well as configurable, though it was unclear to me if either was worth pursuing... Generally very hideous as the three main elements (PHUIDocument, AphrontErrorView, and AphrontForm with an AphrontFormInset) have never really played together before. Test Plan: agreed to some test terms. noted UI displayed nicely. reloaded and noted UI told me I had signed it already. Went to different terms and filled them out wrong and got sensical errors. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3481 Differential Revision: https://secure.phabricator.com/D6399
2013-07-10 20:46:39 +02:00
'LegalpadDocumentSignController' => 'LegalpadController',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'LegalpadDocumentSignature' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'LegalpadDAO',
'PhabricatorPolicyInterface',
Legalpad - add a view signatures page Summary: ...needs to add a LegalpadDocumentSignatureQuery class to get this done, which is also re-deployed everywhere we were issuing raw queries. Ref T3116. Test Plan: viewed some signatures. Verified color and footer icons showed up how I wanted them to. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D7986
2014-01-17 20:40:26 +01:00
),
Allow Legalpad document managers to add signature exemptions Summary: Ref T5532. Allow document managers to add exemptions, which act like signatures but are tracked a little differently. The primary use case for us is users who sign a corporate CLA and need a user-level exemption if they don't want to sign an individual CLA. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T5532 Differential Revision: https://secure.phabricator.com/D9795
2014-07-02 13:59:35 +02:00
'LegalpadDocumentSignatureAddController' => 'LegalpadController',
Legalpad - add a view signatures page Summary: ...needs to add a LegalpadDocumentSignatureQuery class to get this done, which is also re-deployed everywhere we were issuing raw queries. Ref T3116. Test Plan: viewed some signatures. Verified color and footer icons showed up how I wanted them to. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D7986
2014-01-17 20:40:26 +01:00
'LegalpadDocumentSignatureListController' => 'LegalpadController',
'LegalpadDocumentSignatureQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Use ApplicationSearch to search for Legalpad signatures Summary: Ref T3116. Currently, document signatures are just in a big list that you can't search through. - Make it easier to check if a specific user has signed. - Restrict this UI to users who have edit permission on the document (roughly, you need to be a document manager to see the full signature list). (It's currently possible to generate a Dashboard panel using this query, but it will just throw an exception. I'm going to leave it like that for now, we might reasonably expose some "view signatures across doucments" UI later so someone can quickly check if a user has signed 5 documents or something.) Test Plan: {F171576} Reviewers: chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D9765
2014-06-29 01:36:37 +02:00
'LegalpadDocumentSignatureSearchEngine' => 'PhabricatorApplicationSearchEngine',
Legalpad - make it work for not logged in users Summary: Adds "verified" and "secretKey" to Legalpad document signatures. For logged in users using an email address they own, things are verified right away. Otherwise, the email is sent a verification letter. When the user clicks the link the signature is marked verified. Test Plan: signed the document with a bogus email address not logged in. verified the email that would be sent looked good from command line. followed link and successfully verified bogus email address Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, asherkin Maniphest Tasks: T4283 Differential Revision: https://secure.phabricator.com/D7930
2014-01-15 02:17:18 +01:00
'LegalpadDocumentSignatureVerificationController' => 'LegalpadController',
Allow Legalpad document managers to add signature exemptions Summary: Ref T5532. Allow document managers to add exemptions, which act like signatures but are tracked a little differently. The primary use case for us is users who sign a corporate CLA and need a user-level exemption if they don't want to sign an individual CLA. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T5532 Differential Revision: https://secure.phabricator.com/D9795
2014-07-02 13:59:35 +02:00
'LegalpadDocumentSignatureViewController' => 'LegalpadController',
Expose all application mail receivers Summary: Fixes T7199. This still isn't a shining example of perfect code, but the raw amount of copy/paste is much lower than it used to be. - Reduce code duplication between existing receivers. - Expose receiving objects in help menus where appropriate. - Connect some "TODO" receivers. Test Plan: - Sent mail to every supported object type. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12249
2015-04-01 20:01:21 +02:00
'LegalpadMailReceiver' => 'PhabricatorObjectMailReceiver',
Modernize Legalpad edge types Summary: Modernize Legalpad edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: # Created a Herald rule to require legal signatures on all diffs. # Created a new diff. # Saw the transaction string appear correctly. I wasn't able to check the inverse transaction because there is none. Also, I couldn't see any text on the feed (presumably, transactions authored by Herald do not generate feed items) Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Krenair, chad, epriestley Differential Revision: https://secure.phabricator.com/D11082
2015-01-01 01:15:34 +01:00
'LegalpadObjectNeedsSignatureEdgeType' => 'PhabricatorEdgeType',
Subclass most ReplyHandlers from TransactionReplyHandler Summary: Ref T7199. Half of these aren't even reachable, but make some progress toward reducing the amount of nonsense and garbage in mail handling. Test Plan: Tested all reachable handlers with `bin/mail receive-test`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12237
2015-04-01 17:39:50 +02:00
'LegalpadReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Modularize the Legalpad "Require Signature" Herald Action Ref T8726. Modularizes "Require Signatures" for Legalpad.
2015-07-30 21:09:17 +02:00
'LegalpadRequireSignatureHeraldAction' => 'HeraldAction',
Add expected schemata for Fund, Files, Flags and Legalpad Summary: Ref T1191. Nothing too exciting in these. Test Plan: Saw more blue in UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10521
2014-09-19 14:44:40 +02:00
'LegalpadSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Modernize Legalpad edge types Summary: Modernize Legalpad edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: # Created a Herald rule to require legal signatures on all diffs. # Created a new diff. # Saw the transaction string appear correctly. I wasn't able to check the inverse transaction because there is none. Also, I couldn't see any text on the feed (presumably, transactions authored by Herald do not generate feed items) Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Krenair, chad, epriestley Differential Revision: https://secure.phabricator.com/D11082
2015-01-01 01:15:34 +01:00
'LegalpadSignatureNeededByObjectEdgeType' => 'PhabricatorEdgeType',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadTransaction' => 'PhabricatorApplicationTransaction',
'LegalpadTransactionComment' => 'PhabricatorApplicationTransactionComment',
'LegalpadTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'LegalpadTransactionView' => 'PhabricatorApplicationTransactionView',
Implement a more compact, general database-backed key-value cache Summary: See discussion in D4204. Facebook currently has a 314MB remarkup cache with a 55MB index, which is slow to access. Under the theory that this is an index size/quality problem (the current index is on a potentially-384-byte field, with many keys sharing prefixes), provide a more general index with fancy new features: - It implements PhutilKeyValueCache, so it can be a component in cache stacks and supports TTL. - It has a 12-byte hash-based key. - It automatically compresses large blocks of data (most of what we store is highly-compressible HTML). Test Plan: - Basics: - Loaded /paste/, saw caches generate and save. - Reloaded /paste/, saw the page hit cache. - GC: - Ran GC daemon, saw nothing. - Set maximum lifetime to 1 second, ran GC daemon, saw it collect the entire cache. - Deflate: - Selected row formats from the database, saw a mixture of 'raw' and 'deflate' storage. - Used profiler to verify that 'deflate' is fast (12 calls @ 220us on my paste list). - Ran unit tests Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D4259
2012-12-21 23:17:56 +01:00
'LiskChunkTestCase' => 'PhabricatorTestCase',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'LiskDAO' => 'Phobject',
'LiskDAOSet' => 'Phobject',
Add regression test for LiskDAO::__call() Summary: D3606 Test Plan: Deleted `call()`, ran the test. Reviewers: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3814
2012-10-24 21:47:53 +02:00
'LiskDAOTestCase' => 'PhabricatorTestCase',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'LiskEphemeralObjectException' => 'Exception',
Provide isolated, read/write storage fixtures for unit tests Summary: - Unit tests can request storage fixtures. - We build one fixture across all tests in the process, which can quickstart (takes roughly 1s to build, 200ms to destroy for me). This is a one-time cost for running an arbitrary number of fixture-based tests. - We isolate all the connections inside transactions for each test, so individual tests don't affect one another. Test Plan: Ran unit tests, which cover the important properties of fixtures. Reviewers: btrahan, vrana, jungejason, edward Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T140 Differential Revision: https://secure.phabricator.com/D2345
2012-05-02 21:42:23 +02:00
'LiskFixtureTestCase' => 'PhabricatorTestCase',
Provide connection isolation to Lisk and enable it by default in tests Summary: Allow Lisk to be put into process-isolated mode which establishes only isolated connections. By default, put it into this mode when running unit tests. Build some simple unit tests around object insertion and updating. NOTE: The one flaw in this is that $dao->establishConnection() still punches through the isolation layer. I need to do an API change to fix this though so I'm holding it for now. It will probably just rename getConnection() to establishConnection() and then rename establishConnection() to something scary like establishLiveExternalConnection(). Test Plan: Ran unit tests. Reviewed By: aran Reviewers: aran, tuomaspelkonen, jungejason CC: aran, epriestley Differential Revision: 194
2011-04-30 19:11:59 +02:00
'LiskIsolationTestCase' => 'PhabricatorTestCase',
'LiskIsolationTestDAO' => 'LiskDAO',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'LiskIsolationTestDAOException' => 'Exception',
Add PhutilFactsUpateIterator Summary: This iterator processes objects that have been updated. Test Plan: Ran this test script: $cursor = null; $table = new DifferentialRevision(); while (true) { $iterator = new PhabricatorFactsUpdateIterator($table, $cursor); foreach ($iterator as $new_cursor => $update) { echo "{$new_cursor} => D".$update->getID()."\n"; $cursor = $new_cursor; } echo "Zzz...\n"; sleep(5); } Verified it iterated over every object and then stopped. Made a comment on a differenial revision, verified it iterated over the object after 15 seconds. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3077
2012-07-26 22:09:36 +02:00
'LiskMigrationIterator' => 'PhutilBufferedIterator',
Add LiskRawMigrationIterator Summary: Ref T2222. I need this to migrate the Differential comment tables, because they are large. We have the similar `LiskMigrationIterator` already, but it won't work here because I intend to destroy the original objects after migrating them. Test Plan: Wrote a script to iterate over the `differential_comment` table, got reasonable output: {P869} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D6264
2013-06-21 21:55:07 +02:00
'LiskRawMigrationIterator' => 'PhutilBufferedIterator',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'MacroConduitAPIMethod' => 'ConduitAPIMethod',
'MacroCreateMemeConduitAPIMethod' => 'MacroConduitAPIMethod',
'MacroQueryConduitAPIMethod' => 'MacroConduitAPIMethod',
Move Maniphest to modular mail commands Summary: Ref T7199. This fully modularizes mail command handling in Maniphest. I had to add a couple of minor not-totally-solid-feeling tricks to deal with the "create" case, but they feel not-too-bad, and a million times better than what came before. Test Plan: Used all commands with `receive-test`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12240
2015-04-01 17:40:42 +02:00
'ManiphestAssignEmailCommand' => 'ManiphestEmailCommand',
Collapse "Show unassigned tasks" in Maniphest into a parameterized owners typeahead Summary: Ref T4100. Support viewer(), members(), and add a new none(). Test Plan: - Used all new functions. - Batch edited tasks with unassign action. - Saved a query from master, upgrade it to this patch, checkbox migrated cleanly into a "no one" token. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12470
2015-04-19 17:23:56 +02:00
'ManiphestAssigneeDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Rough batch editor for Maniphest Summary: First stab at a batch editor for Maniphest. Basically, you can select a group of tasks and then import them into the "batch" interface, where you can edit all of them at once. High level goal is to make it easier for users in PM/filer/support/QA roles to deal with large numbers of tasks quickly. This implementation has a few major limitations: - The only available actions are "add projects" and "remove projects". - There is no review / undo / log stuff. - All the changes are applied in-process, which may not scale terribly well. However, the immediate need is just around projects and this seemed like a reasonable place to draw the line for a minimal useful version of the tool. Test Plan: Used batch editor to add and remove projects from groups of tasks. Reviewers: btrahan, yairlivne Reviewed By: btrahan CC: aran, epriestley, sandra Maniphest Tasks: T441 Differential Revision: https://secure.phabricator.com/D1680
2012-02-24 22:00:48 +01:00
'ManiphestBatchEditController' => 'ManiphestController',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'ManiphestBulkEditCapability' => 'PhabricatorPolicyCapability',
Move Maniphest to modular mail commands Summary: Ref T7199. This fully modularizes mail command handling in Maniphest. I had to add a couple of minor not-totally-solid-feeling tricks to deal with the "create" case, but they feel not-too-bad, and a million times better than what came before. Test Plan: Used all commands with `receive-test`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12240
2015-04-01 17:40:42 +02:00
'ManiphestClaimEmailCommand' => 'ManiphestEmailCommand',
'ManiphestCloseEmailCommand' => 'ManiphestEmailCommand',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ManiphestConduitAPIMethod' => 'ConduitAPIMethod',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'ManiphestConfiguredCustomField' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'ManiphestCustomField',
'PhabricatorStandardCustomFieldInterface',
Convert maniphest to use standard fields Summary: Ref T3794. Drop auxiliary field, use standard field. Test Plan: Performed migration, field seemed to survive it intact. Edited and viewed tasks. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3794 Differential Revision: https://secure.phabricator.com/D7036
2013-09-19 20:56:15 +02:00
),
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'ManiphestConstants' => 'Phobject',
Maniphest wireframes Summary: Test Plan: Reviewers: CC:
2011-02-08 19:53:59 +01:00
'ManiphestController' => 'PhabricatorController',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ManiphestCreateMailReceiver' => 'PhabricatorMailReceiver',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ManiphestCreateTaskConduitAPIMethod' => 'ManiphestConduitAPIMethod',
Make Maniphest custom fields extend PhabricatorCustomField Summary: Ref T418. These implementations share no method names, so we can safely just move Maniphest fields into the `PhabricatorCustomField` hierarchy. Replaces two Maniphest-specific custom field exceptions which nothing catches. Test Plan: Viewed Maniphest, edited/altered custom fields. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D6927
2013-09-11 00:31:48 +02:00
'ManiphestCustomField' => 'PhabricatorCustomField',
Provide generalized custom field storage and custom field indexes in Maniphest Summary: Ref T418. Depends on D6992. This adds index and value storage for Maniphest custom fields. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D6995
2013-09-16 23:06:41 +02:00
'ManiphestCustomFieldNumericIndex' => 'PhabricatorCustomFieldNumericIndexStorage',
Bring "fixes x as y" parser forward and use new parsers instead of old ones Summary: Fixes T3872. Ref T1812. Ref T3886. Modernize the "closes x as y" string parser, and use all the new parsers instead of the old ones. Test Plan: Made a commit full of a pile of these trigger strings, then used `scripts/repository/reparse.php --message` to reparse it. Verified that parses came back as expected using a bunch of `var_dump()`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1812, T3872, T3886 Differential Revision: https://secure.phabricator.com/D8263
2014-02-18 00:59:13 +01:00
'ManiphestCustomFieldStatusParser' => 'PhabricatorCustomFieldMonogramParser',
'ManiphestCustomFieldStatusParserTestCase' => 'PhabricatorTestCase',
Provide generalized custom field storage and custom field indexes in Maniphest Summary: Ref T418. Depends on D6992. This adds index and value storage for Maniphest custom fields. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D6995
2013-09-16 23:06:41 +02:00
'ManiphestCustomFieldStorage' => 'PhabricatorCustomFieldStorage',
'ManiphestCustomFieldStringIndex' => 'PhabricatorCustomFieldStringIndexStorage',
Maniphest wireframes Summary: Test Plan: Reviewers: CC:
2011-02-08 19:53:59 +01:00
'ManiphestDAO' => 'PhabricatorLiskDAO',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'ManiphestDefaultEditCapability' => 'PhabricatorPolicyCapability',
'ManiphestDefaultViewCapability' => 'PhabricatorPolicyCapability',
'ManiphestEditAssignCapability' => 'PhabricatorPolicyCapability',
Rough in EditEngine for Maniphest Summary: Ref T9132. I'm going hold this until after the release cut since it isn't going to land completely smoothly, but I think I can prep it today/tomorrow and hopefully get it close enough to working to put in HEAD on Saturday after the push. This adds the basics: new EditEngine, new EditController, and new `maniphest.edit` API endpoint. I put the new stuff at `editpro/` for now until it works a little better. Some notes on stuff this is dropping/changing/not-working-yet: - Preview for the description. I'd rather solve this by putting a "Preview" button on every Remarkup area if we want to retain it. Particularly, it does not generalize to adding custom remarkup fields in its current form. See also T3967. - Per-field policies are no longer enforced. They were never truly enforced anyway (for example, any user who can edit a task has always been able to edit every field via Conduit or email actions or Herald, where Herald supports things), and only really served as a hint to users. I think we can obsolete this by having installs hide/lock these fields instead. This is a desirable outcome for me, since I don't like retaining these policies and the idea of truly enforcing them properly is worrisome. These were originally added for Uber as an onboarding sort of thing. I'll prepare users for this in greater detail in the documentation. - Couple of minor bugs with ordering / defaults / only-one-owner-allowed in this diff that I'll clean up in future diffs before this stuff lands. - I don't have a concrete plan on "Create Similar Task" / "Clone" yet (do you have thoughts? Is this worth trying to do in every application?). I'll probably just mostly mimic the current behavior. Test Plan: I'll vet this more thoroughly in followups, just banged around some tasks for now and created/edited via the API. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14659
2015-12-03 23:32:40 +01:00
'ManiphestEditConduitAPIMethod' => 'PhabricatorEditEngineAPIMethod',
'ManiphestEditEngine' => 'PhabricatorEditEngine',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'ManiphestEditPoliciesCapability' => 'PhabricatorPolicyCapability',
'ManiphestEditPriorityCapability' => 'PhabricatorPolicyCapability',
'ManiphestEditProjectsCapability' => 'PhabricatorPolicyCapability',
'ManiphestEditStatusCapability' => 'PhabricatorPolicyCapability',
Move Maniphest to modular mail commands Summary: Ref T7199. This fully modularizes mail command handling in Maniphest. I had to add a couple of minor not-totally-solid-feeling tricks to deal with the "create" case, but they feel not-too-bad, and a million times better than what came before. Test Plan: Used all commands with `receive-test`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12240
2015-04-01 17:40:42 +02:00
'ManiphestEmailCommand' => 'MetaMTAEmailTransactionCommand',
Implemented support for different export formats. Summary: This adds support for different export formats to Excel via a drop-down on the Export page as per the discussion in D5443. Test Plan: Export some things from Maniphest. Do a simple implementation of ManiphestExcelFormat just for testing and make sure that it appears in the list after you run `arc liberate`. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2575 Differential Revision: https://secure.phabricator.com/D5642 Conflicts: src/applications/maniphest/controller/ManiphestExportController.php
2013-04-11 20:22:06 +02:00
'ManiphestExcelDefaultFormat' => 'ManiphestExcelFormat',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'ManiphestExcelFormat' => 'Phobject',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'ManiphestExcelFormatTestCase' => 'PhabricatorTestCase',
Add excel export to Maniphest Summary: Allow Maniphest result sets to be exported to Excel. Spreadsheet_Excel_Writer is awful but comparatively easy to get working. There's also a "PHPExcel" package but it has some autoload conflicts right now and this seems good-enough. Test Plan: Exported a bunch of tasks to Excel. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T923 Differential Revision: https://secure.phabricator.com/D1721
2012-02-29 06:07:12 +01:00
'ManiphestExportController' => 'ManiphestController',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ManiphestGetTaskTransactionsConduitAPIMethod' => 'ManiphestConduitAPIMethod',
Modernize Hovercard implementation Summary: Ref T8980. Move away from events to EngineExtensions. This also simplifies hovercards a bit: - Removes tasks from revision cards. - Removes blockers/blocked from task cards. - Removes "Send Message" from user cards. These mostly felt cluttery to me. Open to arguments to retain them. I think we can make better use of the space, though (e.g., flags, projects + board columns). Test Plan: - Viewed people, task, revision, commit and project hovercards. {F1043256} {F1043257} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8980 Differential Revision: https://secure.phabricator.com/D14878
2015-12-24 20:20:18 +01:00
'ManiphestHovercardEngineExtension' => 'PhabricatorHovercardEngineExtension',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ManiphestInfoConduitAPIMethod' => 'ManiphestConduitAPIMethod',
Provide and populate an object name index for Maniphest Summary: See discussion in D6955. This provides a table we can JOIN against to (effectively) "ORDER BY project name", populates it intially, and keeps it up to date as projects are edited. Test Plan: - Ran storage upgrade, verified projects populated into the table. - Edited a project, verified its entry updated. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6957
2013-09-12 22:06:44 +02:00
'ManiphestNameIndex' => 'ManiphestDAO',
Permit users to touch `maniphest.points` Summary: Ref T4427. Seems fine / not egregiously broken. Test Plan: Edited points configuration. Tried to set a bad value. Set a good value. Persued examples and help text. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4427 Differential Revision: https://secure.phabricator.com/D15256
2016-02-12 02:32:44 +01:00
'ManiphestPointsConfigOptionType' => 'PhabricatorConfigJSONOptionType',
Validate configuration of `maniphest.priorities` Summary: Fixes T6132. We currently allow invalid configuration here; validate it. Test Plan: Tried to save invalid config (negative priorities, string priorities, etc). Reviewers: chad Reviewed By: chad Maniphest Tasks: T6132 Differential Revision: https://secure.phabricator.com/D14689
2015-12-06 01:35:36 +01:00
'ManiphestPriorityConfigOptionType' => 'PhabricatorConfigJSONOptionType',
Implement the "!priority" and "!status" mail commands Summary: Ref T7199. Adds "!priority" and "!status". Test Plan: - Used `!priority` and `!status` to adjust tasks. - Changed config and provided keywords. {F355976} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12248
2015-04-01 19:09:47 +02:00
'ManiphestPriorityEmailCommand' => 'ManiphestEmailCommand',
Remove TYPE_SEARCH_DIDUPDATEINDEX event Summary: Ref T9979. This event had one weird callsite and no known third-party callers. It can be done more cleanly as an extension, now. This index is used to allow us to "Group By: Project" in Maniphest without joining into the Projects database. Test Plan: - Ran a query with "Group By: Project" in Maniphest. - Renamed project "Apples" to "Zebras". - Reloaded page. - UI properly moved "Zebras" tasks to the bottom of the list. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14836
2015-12-21 15:55:23 +01:00
'ManiphestProjectNameFulltextEngineExtension' => 'PhabricatorFulltextEngineExtension',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ManiphestQueryConduitAPIMethod' => 'ManiphestConduitAPIMethod',
'ManiphestQueryStatusesConduitAPIMethod' => 'ManiphestConduitAPIMethod',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'ManiphestRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Move Maniphest to modular mail commands Summary: Ref T7199. This fully modularizes mail command handling in Maniphest. I had to add a couple of minor not-totally-solid-feeling tricks to deal with the "create" case, but they feel not-too-bad, and a million times better than what came before. Test Plan: Used all commands with `receive-test`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12240
2015-04-01 17:40:42 +02:00
'ManiphestReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Add very very basic reporting to Maniphest Summary: Rough cut for Quora, we want this too eventually but it's super basic right now so I'm not linking it anywhere. Once we get a couple more iterations I'll put it in the UI. Test Plan: Looked at stats for test data. Reviewers: btrahan Reviewed By: btrahan CC: anjali, aran, epriestley Differential Revision: https://secure.phabricator.com/D1594
2012-02-08 18:47:14 +01:00
'ManiphestReportController' => 'ManiphestController',
Generate expected schemata for Maniphest Summary: Ref T1191. - Adds support for custom fields. - Adds support for partial indexes (indexes on a prefix of a column). - Drops old auxiliary storage table: this was moved to custom field storage about a year ago. - Drops old project table: this was moved to edges about two months ago. Test Plan: - Viewed web UI, saw fewer issues. - Used `grep` to verify no readers/writers for storage or project table. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10526
2014-09-19 20:46:44 +02:00
'ManiphestSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Add "maniphest.search" Conduit API endpoint Summary: Ref T9964. This is a basic implementation of the new "maniphest.search" endpoint. Test Plan: Clicked the button in the web UI, got meaningful results back. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14760
2015-12-13 11:31:09 +01:00
'ManiphestSearchConduitAPIMethod' => 'PhabricatorSearchEngineAPIMethod',
Make Maniphest task statuses user configurable Summary: Fixes T1812. Moves the internal configuration into public space and documents it. Test Plan: - Tried to set it to some invalid stuff. - Set it to various valid things. - Browsed around, changed statuses, filtered statuses, viewed statuses, merged duplictes, examined transaction record, created tasks. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1812 Differential Revision: https://secure.phabricator.com/D8585
2014-03-25 22:05:36 +01:00
'ManiphestStatusConfigOptionType' => 'PhabricatorConfigJSONOptionType',
Implement the "!priority" and "!status" mail commands Summary: Ref T7199. Adds "!priority" and "!status". Test Plan: - Used `!priority` and `!status` to adjust tasks. - Changed config and provided keywords. {F355976} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12248
2015-04-01 19:09:47 +02:00
'ManiphestStatusEmailCommand' => 'ManiphestEmailCommand',
Allow tasks to be subprioritized by drag-and-drop Summary: Like the title says, similar to Facebook Tasks. Not sure how I really feel about this, but I guess it's kind of OK? I never used this feature in Facebook Tasks but I think some people like it. The drag-and-drop to repri across priorities feels okayish. Because subpriority is a double and we just split the difference when reprioritizing, you lose ~a bit of precision every time you repri two tasks against each other and so you can break it by swapping the priorities of two tasks ~50 times. This case is pretty silly and pathological. We can add some code to deal with this at some point if necessary. I think this also fixes the whacky task layout widths once and for all. (There are a couple of minor UI glitches like headers not vanishing and header counts not updating that I'm not fixing because I am lazy.) Test Plan: Dragged and dropped tasks around. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley, mgummelt Maniphest Tasks: T859 Differential Revision: https://secure.phabricator.com/D1731
2012-04-02 21:12:04 +02:00
'ManiphestSubpriorityController' => 'ManiphestController',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'ManiphestTask' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'ManiphestDAO',
Maniphest - use subscribers framework properly Summary: Fixes T5604. This should fix some random bugs, lets us move forward more easily, and all that good stuff about killing code debt. Test Plan: - Conduit method maniphest.createtask - verified creating user subscribed - verified subscription transaction - Conduit method maniphest.update - verified subscribers set as specified to ccPHIDs parameter - verified subscription transaction - Herald - verified herald rule to add subscriber worked - verified no subscribers removed accidentally - edit controller - test create and verify author gets added IFF they put themselves in subscribers control box - test update gets set to exactly what user enters - lipsum generator'd tasks work - bulk add subscribers works - bulk remove subscriber works - detail controller - added myself by leaving a comment - added another user via explicit action - added another user via implicit mention - task merge via search attach controller - mail reply handler - add subscriber via ./bin/mail receive-test - unsubscribe via ./bin/mail receive-test Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5604 Differential Revision: https://secure.phabricator.com/D10965
2014-12-11 01:27:30 +01:00
'PhabricatorSubscribableInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorMarkupInterface',
'PhabricatorPolicyInterface',
'PhabricatorTokenReceiverInterface',
'PhabricatorFlaggableInterface',
Transactions - add infrastructure for "mentions" Summary: Fixes T4036. Now if you say something on diff X like "This reminds me of Tx and Dy and commitHashFoo and Px." each of those objects gets a little visible transaction that the mention occurred. No feed, email, or notifications. Test Plan: made a comment like above and verified transactions. also submitted a diff that "Fixes Tx" and Tx did not get the transaction as expected. Reviewers: epriestley Reviewed By: epriestley Subscribers: joshuaspence, epriestley, Korvin Maniphest Tasks: T4036 Differential Revision: https://secure.phabricator.com/D10451
2014-09-09 23:21:13 +02:00
'PhabricatorMentionableInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhrequentTrackableInterface',
'PhabricatorCustomFieldInterface',
'PhabricatorDestructibleInterface',
'PhabricatorApplicationTransactionInterface',
Implement PhabricatorProjectInterface on ManiphestTask Summary: Ref T5245. This removes some hacks and activates two meaningful interactions: - The "projects" field goes through shared code now. - Mentioning projects in tasks using hashtags now tags them. Test Plan: - Viewed a task with projects. - Viewed a task with no projects. - Viewed a task with projects and board positions. - Viewed a revision with projects. - Made a `#hashtag` comment in Maniphest and got a project association. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5245 Differential Revision: https://secure.phabricator.com/D10177
2014-08-08 00:44:12 +02:00
'PhabricatorProjectInterface',
Support Spaces in Maniphest Summary: Ref T8493. Tricks: - "Create Similar Task" and "Create Subtask" should copy the parent's Space. - Normal list view + workboard card view. Test Plan: - Created a task, edited space, etc. - Viewed tasks with different users. - Created a "Similar Task" (saw proper Space). - Created a subtask (saw proper Space). - Viewed workboard. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8493 Differential Revision: https://secure.phabricator.com/D13232
2015-06-11 00:53:04 +02:00
'PhabricatorSpacesInterface',
Add "maniphest.search" Conduit API endpoint Summary: Ref T9964. This is a basic implementation of the new "maniphest.search" endpoint. Test Plan: Clicked the button in the web UI, got meaningful results back. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14760
2015-12-13 11:31:09 +01:00
'PhabricatorConduitResultInterface',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorFulltextInterface',
Introduce "bridged" objects Summary: Ref T10537. These are objects which are bound to some external object, like a Maniphest task which is a representation of a GitHub issue. This doesn't do much yet and may change, but my thinking is: - I'm putting these on-object instead of on edges because I think we want to actively change the UI for them (e.g., clearly call out that the object is bridged) but don't want every page to need to do extra queries in the common case where zero bridged objects exist anywhere in the system. - I'm making these one-to-one, more or less: an issue can't be bridged to a bunch of tasks, nor can a bunch of tasks be bridged to a single issue. Pretty sure this makes sense? I can't come up with any reasonable, realistic cases where you want a single GitHub issue to publish to multiple different tasks in Maniphest. - Technically, one type of each bridgable object could be bridged, but I expect this to never actually occur. Hopefully. Test Plan: Ran storage upgrade, loaded some pages. Reviewers: chad Reviewed By: chad Subscribers: Luke081515.2 Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15502
2016-03-09 17:40:19 +01:00
'DoorkeeperBridgedObjectInterface',
Add a differential.createinline method to Conduit Summary: a silly thing because I was bored Test Plan: and I said "arc call-conduit", and there were comments Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1500 Differential Revision: https://secure.phabricator.com/D2971
2012-07-16 20:49:06 +02:00
),
Modularize Maniphest Herald "Assign Task" action Summary: Ref T8726. No surprises here. Test Plan: - Created rules using this action. - Applied migration. - Verified rules still work. {F659324} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13706
2015-07-24 21:51:30 +02:00
'ManiphestTaskAssignHeraldAction' => 'HeraldAction',
'ManiphestTaskAssignOtherHeraldAction' => 'ManiphestTaskAssignHeraldAction',
'ManiphestTaskAssignSelfHeraldAction' => 'ManiphestTaskAssignHeraldAction',
Modularize all remaining Maniphest Herald fields Summary: Ref T8726. The only notable bit here is that the "body" / "title" fields (which are currently shared across a bunch of types) are getting split into application variants. Among other things, this will let us label the field "Commit message" for commits, for example. Test Plan: - Created a rule using all four fields. - Applied patch, saw rule break ("unknown field"). - Ran storage upgrade, saw rule fix itself in the migration. - Edited tasks, triggered rule, viewed transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13501
2015-07-06 22:17:14 +02:00
'ManiphestTaskAssigneeHeraldField' => 'ManiphestTaskHeraldField',
'ManiphestTaskAuthorHeraldField' => 'ManiphestTaskHeraldField',
Allow different policy rules for different types of objects Summary: Ref T5681. Policy rules can now select objects they can apply to, so a rule like "task author" only shows up where it makes sense (when defining task policies). This will let us define rules like "members of thread" in Conpherence, "subscribers", etc., to make custom policies more flexible. Notes: - Per D13251, we need to do a little work to get the right options for policies like "Maniphest > Default View Policy". This should allow "task" policies. - This implements a "task author" policy as a simple example. - The `willApplyRule()` signature now accepts `$objects` to support bulk-loading things like subscribers. Test Plan: - Defined a task to be "visible to: task author", verified author could see it and other users could not. - `var_dump()`'d willApplyRule() inputs, verified they were correct (exactly the objects which use the rule). - Set `default view policy` to a task-specific policy. - Verified that other policies like "Can Use Bulk Editor" don't have these options. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5681 Differential Revision: https://secure.phabricator.com/D13252
2015-06-14 00:44:03 +02:00
'ManiphestTaskAuthorPolicyRule' => 'PhabricatorPolicyRule',
Implement open() and closed() Maniphest tokenizer status functions, plus cleanup Summary: Ref T4100. - Make it easy to choose all open or closed tasks. - Make "special" tokenizers composable. - Get `viewer()` generating documentation properly. Test Plan: - Ran queries with new tokens. - Browsed new tokens. - Viewed docs on new tokens. - Used plain status tokens. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12530
2015-04-23 15:47:30 +02:00
'ManiphestTaskClosedStatusDatasource' => 'PhabricatorTypeaheadDatasource',
Migrate Maniphest task blockers to modern EdgeType classes Summary: Prevents "edited tasks, added: 1; removed: 1" Fixes T6757, using D9839 as an example Test Plan: Added and removed blockers to/from tasks, saw the expected history entries. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T6757 Differential Revision: https://secure.phabricator.com/D11045
2014-12-28 15:10:49 +01:00
'ManiphestTaskDependedOnByTaskEdgeType' => 'PhabricatorEdgeType',
'ManiphestTaskDependsOnTaskEdgeType' => 'PhabricatorEdgeType',
Modularize all remaining Maniphest Herald fields Summary: Ref T8726. The only notable bit here is that the "body" / "title" fields (which are currently shared across a bunch of types) are getting split into application variants. Among other things, this will let us label the field "Commit message" for commits, for example. Test Plan: - Created a rule using all four fields. - Applied patch, saw rule break ("unknown field"). - Ran storage upgrade, saw rule fix itself in the migration. - Edited tasks, triggered rule, viewed transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13501
2015-07-06 22:17:14 +02:00
'ManiphestTaskDescriptionHeraldField' => 'ManiphestTaskHeraldField',
Maniphest wireframes Summary: Test Plan: Reviewers: CC:
2011-02-08 19:53:59 +01:00
'ManiphestTaskDetailController' => 'ManiphestController',
Execute Maniphest batch edits in the background with a web UI progress bar Summary: Ref T8637. This does nothing interesting, just has empty scaffolding for a bulk job queue. Basic idea is that when you do something like a batch edit in Maniphest, we: - Create a BulkJob with all the details. - Queue a worker to start the job. - Send you to a progress bar page for the job. In the background: - The "start job" worker creates a ton of Task objects, then queues worker tasks to do the work. In the foreground: - Fancy ajax animates the progress bar and it goes wooosh. In general: - Big jobs actually work. - Jobs get logged. - You can monitor jobs. - Terrible junk like T8637 should be much harder to write and much easier to catch and diagnose. Test Plan: No interesting code/beahavior yet. Clean `storage adjust`. {F526411} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8637 Differential Revision: https://secure.phabricator.com/D13392
2015-06-23 22:36:16 +02:00
'ManiphestTaskEditBulkJobType' => 'PhabricatorWorkerBulkJobType',
Drop "-pro" suffix and "editpro" URIs for EditEngine in Maniphest Summary: Ref T9908. Move all the "pro" stuff into the old locations. Test Plan: Created/edited tasks, looked at URIs, saw non-pro ones. Grepped for `editpro`. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9908 Differential Revision: https://secure.phabricator.com/D14717
2015-12-09 01:54:46 +01:00
'ManiphestTaskEditController' => 'ManiphestController',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'ManiphestTaskFulltextEngine' => 'PhabricatorFulltextEngine',
Modernize commit/edge transaction when parsing commit messages Summary: Ref T5245. With work elsewhere (notably, D9839) we can remove this TODO and use real transactions. Test Plan: Pushed a `closes Txxx` commit and got a close + transaction. Reviewers: chad, btrahan, joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5245 Differential Revision: https://secure.phabricator.com/D9848
2014-07-18 00:42:06 +02:00
'ManiphestTaskHasCommitEdgeType' => 'PhabricatorEdgeType',
Modernize Pholio edges Summary: Modernize Pholio edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Attached a mock to a task, observed the expected comment in the transaction view (both ways). Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11113
2015-01-02 00:11:41 +01:00
'ManiphestTaskHasMockEdgeType' => 'PhabricatorEdgeType',
Modernize task/revision edges and write inverse transactions Summary: Ref T5245. See some discussion in D9838. When we attach object A to object B, we'd like to write transactions on both sides but only write the actual edges once. To do this, allow edge types to `shouldWriteInverseTransactions()`. When an edge type opts into this, have editors apply the inverse transactions before writing the edge. These inverse transactions don't actually apply effects, they just show up in the transaction log. Test Plan: Attached and detached revisions from tasks, saw transactions appear on both sides of the operation. Reviewers: chad, btrahan, joshuaspence Reviewed By: btrahan, joshuaspence Subscribers: epriestley Maniphest Tasks: T5245 Differential Revision: https://secure.phabricator.com/D9839
2014-07-18 00:41:08 +02:00
'ManiphestTaskHasRevisionEdgeType' => 'PhabricatorEdgeType',
Modularize all remaining Maniphest Herald fields Summary: Ref T8726. The only notable bit here is that the "body" / "title" fields (which are currently shared across a bunch of types) are getting split into application variants. Among other things, this will let us label the field "Commit message" for commits, for example. Test Plan: - Created a rule using all four fields. - Applied patch, saw rule break ("unknown field"). - Ran storage upgrade, saw rule fix itself in the migration. - Edited tasks, triggered rule, viewed transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13501
2015-07-06 22:17:14 +02:00
'ManiphestTaskHeraldField' => 'HeraldField',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'ManiphestTaskHeraldFieldGroup' => 'HeraldFieldGroup',
Move Maniphest list rendering to SearchEngine Summary: Ref T4986. Moves Maniphest over. Nothing tricky here, just a complex block of rendering. Test Plan: Viewed Maniphest list. Created Maniphest panel. Used batch editor, drag-and-drop. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9139
2014-05-16 04:17:38 +02:00
'ManiphestTaskListController' => 'ManiphestController',
Make "Create Subtask" work properly in EditEngine Summary: Ref T9908. This fixes "Create Subtask" so it works with the new stuff. Mostly straightforward. Test Plan: Created some subtasks. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9908 Differential Revision: https://secure.phabricator.com/D14706
2015-12-08 16:54:01 +01:00
'ManiphestTaskListHTTPParameterType' => 'AphrontListHTTPParameterType',
Slightly improve Maniphest documentation.
2011-07-04 22:04:22 +02:00
'ManiphestTaskListView' => 'ManiphestView',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ManiphestTaskMailReceiver' => 'PhabricatorObjectMailReceiver',
Implement open() and closed() Maniphest tokenizer status functions, plus cleanup Summary: Ref T4100. - Make it easy to choose all open or closed tasks. - Make "special" tokenizers composable. - Get `viewer()` generating documentation properly. Test Plan: - Ran queries with new tokens. - Browsed new tokens. - Viewed docs on new tokens. - Used plain status tokens. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12530
2015-04-23 15:47:30 +02:00
'ManiphestTaskOpenStatusDatasource' => 'PhabricatorTypeaheadDatasource',
Make "Create Subtask" work properly in EditEngine Summary: Ref T9908. This fixes "Create Subtask" so it works with the new stuff. Mostly straightforward. Test Plan: Created some subtasks. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9908 Differential Revision: https://secure.phabricator.com/D14706
2015-12-08 16:54:01 +01:00
'ManiphestTaskPHIDResolver' => 'PhabricatorPHIDResolver',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'ManiphestTaskPHIDType' => 'PhabricatorPHIDType',
Support enabling a formal points field in Maniphest Summary: Ref T4427. - New config option for labels, enabling, etc., but no UI/niceness yet. - When enabled, add a field. - Allow nonnegative values, including fractional values. - EditEngine is nice and Conduit / actions basically just work with a tiny bit of extra support code. Test Plan: - Edited points via "Edit". - Edited points via Conduit. - Edited points via stacked actions. - Tried to set "zebra" points. - Tried to set -1 points. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4427 Differential Revision: https://secure.phabricator.com/D15220
2016-02-09 00:24:52 +01:00
'ManiphestTaskPoints' => 'Phobject',
Slightly improve Maniphest documentation.
2011-07-04 22:04:22 +02:00
'ManiphestTaskPriority' => 'ManiphestConstants',
Modernize "task priority" datasource Summary: Ref T4420. Test Plan: - Used typeahead in Herald rules. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9877
2014-07-11 01:20:40 +02:00
'ManiphestTaskPriorityDatasource' => 'PhabricatorTypeaheadDatasource',
Add a "Change priority to: ..." Herald action Summary: Ref T7848. This is a companion to "Change status to: ...". (I'm pretty sure the only reason I didn't originally write these was the tokenizer bug in D14682, I just forgot about it). This is basically a copy/paste of the "status" action. Test Plan: - Wrote a rule to change task priorities. - Edited a task. - Saw rule fire properly. - Tokens also stick around correctly. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7848 Differential Revision: https://secure.phabricator.com/D14683
2015-12-05 20:15:29 +01:00
'ManiphestTaskPriorityHeraldAction' => 'HeraldAction',
Modularize all remaining Maniphest Herald fields Summary: Ref T8726. The only notable bit here is that the "body" / "title" fields (which are currently shared across a bunch of types) are getting split into application variants. Among other things, this will let us label the field "Commit message" for commits, for example. Test Plan: - Created a rule using all four fields. - Applied patch, saw rule break ("unknown field"). - Ran storage upgrade, saw rule fix itself in the migration. - Edited tasks, triggered rule, viewed transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13501
2015-07-06 22:17:14 +02:00
'ManiphestTaskPriorityHeraldField' => 'ManiphestTaskHeraldField',
Make ManiphestTaskQuery a (mostly) policy-aware query Summary: Ref T603. Test Plan: Viewed home and maniphest, fiddled all the knobs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D6930
2013-09-10 16:53:27 +02:00
'ManiphestTaskQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Move Maniphest list rendering to SearchEngine Summary: Ref T4986. Moves Maniphest over. Nothing tricky here, just a complex block of rendering. Test Plan: Viewed Maniphest list. Created Maniphest panel. Used batch editor, drag-and-drop. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9139
2014-05-16 04:17:38 +02:00
'ManiphestTaskResultListView' => 'ManiphestView',
Introduce ManiphestTaskSearchEngine plus ManiphestTaskListControllerPro Summary: Ref T603. Ref T2625. Cutting this over is tricky because of Maniphest's existing saved queries. Plan here is: - Build out the "pro" controller at `/maniphest/query/`. - Once it's at parity, migrate custom queries. - Nuke the old UI. This provides a minimal implementation with no filter support. Test Plan: Looked at `/maniphest/query/`, saw results technically available. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6933
2013-09-10 19:04:26 +02:00
'ManiphestTaskSearchEngine' => 'PhabricatorApplicationSearchEngine',
Slightly improve Maniphest documentation.
2011-07-04 22:04:22 +02:00
'ManiphestTaskStatus' => 'ManiphestConstants',
T5015, Allow Herald rules for Maniphest to act on task status changes Summary: Fixes T5015, Allow Herald rules for Maniphest to act on task status changes. Test Plan: Create Herald rule for Maniphest tasks to flag a task with status "wontfix". Change status of Maniphest task to "wontfix". Task should be flagged. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5015 Differential Revision: https://secure.phabricator.com/D10842
2014-11-12 21:54:29 +01:00
'ManiphestTaskStatusDatasource' => 'PhabricatorTypeaheadDatasource',
Implement open() and closed() Maniphest tokenizer status functions, plus cleanup Summary: Ref T4100. - Make it easy to choose all open or closed tasks. - Make "special" tokenizers composable. - Get `viewer()` generating documentation properly. Test Plan: - Ran queries with new tokens. - Browsed new tokens. - Viewed docs on new tokens. - Used plain status tokens. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12530
2015-04-23 15:47:30 +02:00
'ManiphestTaskStatusFunctionDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Herald support for changing task status Summary: Ref T7848. This patch is incomplete and has the following issues: - Multiple statuses can be entered on the edit rule page (only the first one is used). - Statuses are not rendered correctly when re-editing a rule. Test Plan: Applied to our local phab instance and verified it works with our task workflow. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: joshuaspence, revi, epriestley, jsmith Maniphest Tasks: T7848 Differential Revision: https://secure.phabricator.com/D14359
2015-12-05 19:51:34 +01:00
'ManiphestTaskStatusHeraldAction' => 'HeraldAction',
Modularize all remaining Maniphest Herald fields Summary: Ref T8726. The only notable bit here is that the "body" / "title" fields (which are currently shared across a bunch of types) are getting split into application variants. Among other things, this will let us label the field "Commit message" for commits, for example. Test Plan: - Created a rule using all four fields. - Applied patch, saw rule break ("unknown field"). - Ran storage upgrade, saw rule fix itself in the migration. - Edited tasks, triggered rule, viewed transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13501
2015-07-06 22:17:14 +02:00
'ManiphestTaskStatusHeraldField' => 'ManiphestTaskHeraldField',
Add config validation for task status config Summary: Ref T1812. This still doesn't expose configuration to the user, but adds validation for it. Test Plan: Added a pile of unit tests. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1812 Differential Revision: https://secure.phabricator.com/D8584
2014-03-25 22:04:51 +01:00
'ManiphestTaskStatusTestCase' => 'PhabricatorTestCase',
Fix literally thousands of drag-to-reorder priority bugs Summary: Fixes T7563. Fixes T5201. Reframe this as two separate operations: - Move before or after a task. - Move to the beginning or end of a priority. Then: - Make all the order queries unambiguous and properly reversible, with an explicit `id` order. - Just reuse `ManiphestTask` to get results in the correct order. - Simplify the actual transaction apply logic. - Detect and recover from cases where tasks have identical or similar subpriorities. Test Plan: - Wrote and executed unit tests. - Dragged and dropped tasks within priorities and between priorities in the main Maniphest view. - Dragged and dropped tasks within priorities in the workboard view, when ordered by priority. - Also poked at the "natural" order, but that shouldn't be affected. Reviewers: btrahan, chad Reviewed By: chad Subscribers: chad, epriestley Maniphest Tasks: T5201, T7563 Differential Revision: https://secure.phabricator.com/D12121
2015-03-21 01:38:25 +01:00
'ManiphestTaskTestCase' => 'PhabricatorTestCase',
Modularize all remaining Maniphest Herald fields Summary: Ref T8726. The only notable bit here is that the "body" / "title" fields (which are currently shared across a bunch of types) are getting split into application variants. Among other things, this will let us label the field "Commit message" for commits, for example. Test Plan: - Created a rule using all four fields. - Applied patch, saw rule break ("unknown field"). - Ran storage upgrade, saw rule fix itself in the migration. - Edited tasks, triggered rule, viewed transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13501
2015-07-06 22:17:14 +02:00
'ManiphestTaskTitleHeraldField' => 'ManiphestTaskHeraldField',
Rename ManiphestTransactionPro -> ManiphestTransaction Summary: Ref T2217. Pro is the new standard. Test Plan: Lots of `grep`, made a pile of Maniphest views/edits. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2217 Differential Revision: https://secure.phabricator.com/D7093
2013-09-24 19:49:06 +02:00
'ManiphestTransaction' => 'PhabricatorApplicationTransaction',
Route all ManiphestTransaction reads through a single class Summary: Ref T2217. I'm going to do the fake-double-writes ("double reads"?) thing where we proxy the storage that worked pretty well for auth. That is: - (Some more cleanup diffs next, maybe?) - Move all the data to the new storage, and make `ManiphestTransaction` read and write by wrapping `ManiphestTransactionPro`. - If nothing breaks, it's a straight shot to nuking ManiphestTransaction callsite by callsite. I think Maniphest is way easier than Differential, because there are very few query sites and no inline comments. Test Plan: `grep` to find callsites. Loaded task view, called Conduit. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T2217 Differential Revision: https://secure.phabricator.com/D7067
2013-09-23 23:25:14 +02:00
'ManiphestTransactionComment' => 'PhabricatorApplicationTransactionComment',
Remove "ManiphestTransactionEditorPro" Summary: Drop the "Pro" bit. Test Plan: Created/edited tasks, moved tasks around, generally made a mess. Nothing burned down. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7352
2013-10-22 01:58:37 +02:00
'ManiphestTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
Migrate all Maniphest transaction data to new storage Summary: Ref T2217. This is the risky, hard part; everything after this should be smooth sailing. This is //mostly// clean, except: - The old format would opportunistically combine a comment with some other transaction type if it could. We no longer do that, so: - When migrating, "edit" + "comment" transactions need to be split in two. - When editing now, we should no longer combine these transaction types. - These changes are pretty straightforward and low-impact. - This migration promotes "auxiliary field" data to the new CustomField/StandardField format, so that's not a straight migration either. The formats are very similar, though. Broadly, this takes the same attack that the auth migration did: proxy all the code through to the new storage. `ManiphestTransaction` is now just an API on top of `ManiphestTransactionPro`, which is the new storage format. The two formats are very similar, so this was mostly a straight copy from one table to the other. Test Plan: - Without performing the migration, made a bunch of edits and comments on tasks and verified the new code works correctly. - Droped the test data and performed the migration. - Looked at the resulting data for obvious discrepancies. - Looked at a bunch of tasks and their transaction history. - Used Conduit to pull transaction data. - Edited task description and clicked "View Details" on transaction. - Used batch editor. - Made a bunch more edits. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2217 Differential Revision: https://secure.phabricator.com/D7068
2013-09-23 23:25:28 +02:00
'ManiphestTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ManiphestUpdateConduitAPIMethod' => 'ManiphestConduitAPIMethod',
Slightly improve Maniphest documentation.
2011-07-04 22:04:22 +02:00
'ManiphestView' => 'AphrontView',
Fully modularize mail commands Summary: Ref T7199. Everyone can have a mail command! You can have a mail command! You can have a mail command! Mail commands for everyone! Test Plan: Used `bin/mail receive-test` to issue commands against files and pastes. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12238
2015-04-01 17:40:00 +02:00
'MetaMTAEmailTransactionCommand' => 'Phobject',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'MetaMTAEmailTransactionCommandTestCase' => 'PhabricatorTestCase',
Add a GC for sent and received mail Summary: Ref T4368. We don't currently GC these tables, and the sent mail table is one of the largest on `secure.phabricator.com`. There's no value in retaining this information indefinitely. Instead, retain it for 90 days, which should be plenty of time to debug/diagnose any issues. Test Plan: Ran `phd debug garbage`, saw it clean up a reasonable amount of data from these tables. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4368 Differential Revision: https://secure.phabricator.com/D8127
2014-02-03 19:51:31 +01:00
'MetaMTAMailReceivedGarbageCollector' => 'PhabricatorGarbageCollector',
'MetaMTAMailSentGarbageCollector' => 'PhabricatorGarbageCollector',
Consolidate outbound mail status in a new class Summary: Ref T5791. This collects outbound mail status in one place and makes the list view a little spiffier. Test Plan: Looked at list and detail views. Grepped for changed classes/constants. Reviewers: chad Reviewed By: chad Maniphest Tasks: T5791 Differential Revision: https://secure.phabricator.com/D13884
2015-08-14 13:31:42 +02:00
'MetaMTAReceivedMailStatus' => 'Phobject',
Skeleton for "Multimeter", a performance sampling application Summary: Ref T6930. This application collects and displays performance samples -- roughly, things Phabricator spent some kind of resource on. It will collect samples on different types of resources and events: - Wall time (queries, service calls, pages) - Bytes In / Bytes Out (requests) - Implicit requests to CSS/JS (static resources) I've started with the simplest case (static resources), since this can be used in an immediate, straghtforward way to improve packaging (look at which individual files have the most requests recently). There's no aggregation yet and a lot of the data isn't collected properly. Future diffs will add more dimension data (controllers, users), more event and resource types (queries, service calls, wall time), and more display options (aggregation, sorting). Test Plan: {F389344} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6930 Differential Revision: https://secure.phabricator.com/D12623
2015-05-01 22:19:43 +02:00
'MultimeterContext' => 'MultimeterDimension',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'MultimeterControl' => 'Phobject',
Skeleton for "Multimeter", a performance sampling application Summary: Ref T6930. This application collects and displays performance samples -- roughly, things Phabricator spent some kind of resource on. It will collect samples on different types of resources and events: - Wall time (queries, service calls, pages) - Bytes In / Bytes Out (requests) - Implicit requests to CSS/JS (static resources) I've started with the simplest case (static resources), since this can be used in an immediate, straghtforward way to improve packaging (look at which individual files have the most requests recently). There's no aggregation yet and a lot of the data isn't collected properly. Future diffs will add more dimension data (controllers, users), more event and resource types (queries, service calls, wall time), and more display options (aggregation, sorting). Test Plan: {F389344} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6930 Differential Revision: https://secure.phabricator.com/D12623
2015-05-01 22:19:43 +02:00
'MultimeterController' => 'PhabricatorController',
'MultimeterDAO' => 'PhabricatorLiskDAO',
'MultimeterDimension' => 'MultimeterDAO',
'MultimeterEvent' => 'MultimeterDAO',
'MultimeterEventGarbageCollector' => 'PhabricatorGarbageCollector',
'MultimeterHost' => 'MultimeterDimension',
'MultimeterLabel' => 'MultimeterDimension',
'MultimeterSampleController' => 'MultimeterController',
'MultimeterViewer' => 'MultimeterDimension',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'NuanceConduitAPIMethod' => 'ConduitAPIMethod',
Add a main page to Nuance Summary: Ref T8783. There's nothing at `/nuance/` right now, put something basic there. Test Plan: {F747078} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8783 Differential Revision: https://secure.phabricator.com/D13965
2015-08-23 16:19:35 +02:00
'NuanceConsoleController' => 'NuanceController',
Add a Nuance content source, and make use of it Summary: Ref T10537. Add a new content source for Nuance. Prepare for better author attribution. Test Plan: {F1194038} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15539
2016-03-28 20:18:39 +02:00
'NuanceContentSource' => 'PhabricatorContentSource',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceController' => 'PhabricatorController',
'NuanceDAO' => 'PhabricatorLiskDAO',
Add Nuance daemons and item types Summary: Ref T10537. This adds an update daemon for pulling item data (e.g., figuring out who the author of a GitHub comment is) and routing items (e.g., sending them to a queue or applying them directly to a task). Also adds `bin/nuance update --item X` for doing this manually for debugging. And adds item types, for specializing item behavior. Previously, sources completely dictated item behavior, but I think we want something a little more flexible. Test Plan: - This still does nothing. - Ran `bin/nuance update --item 15`. - Saw an item route to a default queue. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15441
2016-03-08 22:07:22 +01:00
'NuanceGitHubEventItemType' => 'NuanceItemType',
Split the GitHub import cursor into separate repository and issues event importers Summary: Ref T10538. The primary GitHub event activity stream does not report minor events (labels, milestones, etc). GitHub has a second, similar activity stream which does report these events (the "Issues Events API"). Use two separate cursors: one consumes the primary stream; the second consumes the events stream. One possible issue with this is that we may write events in a different order than they occurred, so GitHub shows "comment, label, close" but we show "comment, close, label" or similar. This is probably OK because the secondary API doesn't seem to have any very important events (e.g., it's probably fine if label changes are out-of-order), but we can conceivably put some buffer stage in between the two if it's an issue. Test Plan: {F1164894} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10538 Differential Revision: https://secure.phabricator.com/D15446
2016-03-09 14:35:08 +01:00
'NuanceGitHubImportCursor' => 'NuanceImportCursor',
'NuanceGitHubIssuesImportCursor' => 'NuanceGitHubImportCursor',
Begin bridging GitHub objects through Doorkeeper Summary: Ref T10538. This sets up a Doorkeeper bridge for GitHub issues, and pulls issues from GitHub to create ExternalObject references. Broadly, does nothing useful. Test Plan: Put a `var_dump()` in there somewhere and saw it probably do something when running `bin/nuance update --item 44`. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10538 Differential Revision: https://secure.phabricator.com/D15447
2016-03-09 15:30:22 +01:00
'NuanceGitHubRawEvent' => 'Phobject',
Begin adding test coverage to GitHub Events API parsers Summary: Ref T10538. This is a tiny fraction of the API. GitHub has 25 primary event types; we currently partially parse 3 of them. GitHub has 17 issue event types; we currently partially parse 12. Test Plan: Ran `arc unit`. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10538 Differential Revision: https://secure.phabricator.com/D15448
2016-03-09 16:01:23 +01:00
'NuanceGitHubRawEventTestCase' => 'PhabricatorTestCase',
Split the GitHub import cursor into separate repository and issues event importers Summary: Ref T10538. The primary GitHub event activity stream does not report minor events (labels, milestones, etc). GitHub has a second, similar activity stream which does report these events (the "Issues Events API"). Use two separate cursors: one consumes the primary stream; the second consumes the events stream. One possible issue with this is that we may write events in a different order than they occurred, so GitHub shows "comment, label, close" but we show "comment, close, label" or similar. This is probably OK because the secondary API doesn't seem to have any very important events (e.g., it's probably fine if label changes are out-of-order), but we can conceivably put some buffer stage in between the two if it's an issue. Test Plan: {F1164894} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10538 Differential Revision: https://secure.phabricator.com/D15446
2016-03-09 14:35:08 +01:00
'NuanceGitHubRepositoryImportCursor' => 'NuanceGitHubImportCursor',
Add a Nuance GitHub repository source and basic polling Summary: Ref T10537. Ref T10538. This calls GitHub, sorta? Test Plan: ``` $ ./bin/nuance import --source poem <cursor:events.repository> Polling GitHub Repository API endpoint "/repos/epriestley/poems/events". <cursor:events.repository> This key has 4,988 remaining API request(s), limit resets in 1,871 second(s). <cursor:events.repository> ETag for this request was ""4abdd3d66ad5ca38f5117b094e76f4ba"". array(4) { [0]=> array(7) { ["id"]=> string(10) "3733510485" ... ``` Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537, T10538 Differential Revision: https://secure.phabricator.com/D15439
2016-03-08 16:50:43 +01:00
'NuanceGitHubRepositorySourceDefinition' => 'NuanceSourceDefinition',
Allow Nuances sources to provide import cursors Summary: Ref T10537. Some sources (like the future "GitHub Repository" source) need to poll remotes. - Provide a mechanism for sources to emit import cursors. - Hook them into the trigger daemon so they'll fire periodically. - Provide some storage. This diff does nothing useful or interesting, and is pure infrastructure. Test Plan: - Ran `bin/storage upgrade -f`, no adjustment issues. - Poked around Nuance. - Ran the trigger daemon, verified it didn't crash and checked for Nuance stuff to do. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15435
2016-03-08 14:59:24 +01:00
'NuanceImportCursor' => 'Phobject',
Import raw GitHub event data into Nuance Summary: Ref T10537. Ref T10538. This polls the GitHub events API and creates Nuance items from the raw data. It does nothing useful with them. Test Plan: - Polled GitHub. - Saw some items get created. - X-Poll-Interval seemed to work. - ETag seemed to work. - Recognizing when we hit items we've already seen seemed to work. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537, T10538 Differential Revision: https://secure.phabricator.com/D15440
2016-03-08 17:51:45 +01:00
'NuanceImportCursorData' => array(
'NuanceDAO',
'PhabricatorPolicyInterface',
),
Allow Nuances sources to provide import cursors Summary: Ref T10537. Some sources (like the future "GitHub Repository" source) need to poll remotes. - Provide a mechanism for sources to emit import cursors. - Hook them into the trigger daemon so they'll fire periodically. - Provide some storage. This diff does nothing useful or interesting, and is pure infrastructure. Test Plan: - Ran `bin/storage upgrade -f`, no adjustment issues. - Poked around Nuance. - Ran the trigger daemon, verified it didn't crash and checked for Nuance stuff to do. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15435
2016-03-08 14:59:24 +01:00
'NuanceImportCursorDataQuery' => 'NuanceQuery',
'NuanceImportCursorPHIDType' => 'PhabricatorPHIDType',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'NuanceItem' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'NuanceDAO',
'PhabricatorPolicyInterface',
Fix a couple of minor Nuance / transaction publisher issues Summary: I got a couple of tasks stuck in my local queue a while ago when touching Nuance, fix a couple minor issues to clean them up. Test Plan: Ran tasks in queue, got clean results. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D13532
2015-07-02 23:24:07 +02:00
'PhabricatorApplicationTransactionInterface',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
),
Allow Nuance item types to provide actions for items Summary: Ref T10537. This allows item types to expose item actions. Eventually these actions might be things like "promote to task", "tweet reply", "ban user forever", etc. For now, provide a simple action which shows a raw item in a dialog. Test Plan: {F1185573} Reviewers: chad Reviewed By: chad Subscribers: Luke081515.2 Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15504
2016-03-22 01:38:22 +01:00
'NuanceItemActionController' => 'NuanceController',
Add an ItemCommand queue to Nuance Summary: Ref T10537. Generally, when users interact with Nuance items we'll dump a command into a queue and apply it in the background. This avoids race conditions with multiple users interacting with an item, which Nuance is more subject to than other applications because it has an import/external component. The "sync" command doesn't actually do anything yet. Test Plan: {F1186365} Reviewers: chad Reviewed By: chad Subscribers: Luke081515.2 Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15506
2016-03-22 14:51:22 +01:00
'NuanceItemCommand' => array(
'NuanceDAO',
'PhabricatorPolicyInterface',
),
'NuanceItemCommandQuery' => 'NuanceQuery',
Import raw GitHub event data into Nuance Summary: Ref T10537. Ref T10538. This polls the GitHub events API and creates Nuance items from the raw data. It does nothing useful with them. Test Plan: - Polled GitHub. - Saw some items get created. - X-Poll-Interval seemed to work. - ETag seemed to work. - Recognizing when we hit items we've already seen seemed to work. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537, T10538 Differential Revision: https://secure.phabricator.com/D15440
2016-03-08 17:51:45 +01:00
'NuanceItemController' => 'NuanceController',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceItemEditor' => 'PhabricatorApplicationTransactionEditor',
Import raw GitHub event data into Nuance Summary: Ref T10537. Ref T10538. This polls the GitHub events API and creates Nuance items from the raw data. It does nothing useful with them. Test Plan: - Polled GitHub. - Saw some items get created. - X-Poll-Interval seemed to work. - ETag seemed to work. - Recognizing when we hit items we've already seen seemed to work. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537, T10538 Differential Revision: https://secure.phabricator.com/D15440
2016-03-08 17:51:45 +01:00
'NuanceItemListController' => 'NuanceItemController',
Move Nuance Items to two-column views Summary: Ref T10537. Test Plan: {F1164796} {F1164797} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15444
2016-03-09 13:01:17 +01:00
'NuanceItemManageController' => 'NuanceController',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'NuanceItemPHIDType' => 'PhabricatorPHIDType',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceItemQuery' => 'NuanceQuery',
Import raw GitHub event data into Nuance Summary: Ref T10537. Ref T10538. This polls the GitHub events API and creates Nuance items from the raw data. It does nothing useful with them. Test Plan: - Polled GitHub. - Saw some items get created. - X-Poll-Interval seemed to work. - ETag seemed to work. - Recognizing when we hit items we've already seen seemed to work. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537, T10538 Differential Revision: https://secure.phabricator.com/D15440
2016-03-08 17:51:45 +01:00
'NuanceItemSearchEngine' => 'PhabricatorApplicationSearchEngine',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceItemTransaction' => 'NuanceTransaction',
'NuanceItemTransactionComment' => 'PhabricatorApplicationTransactionComment',
'NuanceItemTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Add Nuance daemons and item types Summary: Ref T10537. This adds an update daemon for pulling item data (e.g., figuring out who the author of a GitHub comment is) and routing items (e.g., sending them to a queue or applying them directly to a task). Also adds `bin/nuance update --item X` for doing this manually for debugging. And adds item types, for specializing item behavior. Previously, sources completely dictated item behavior, but I think we want something a little more flexible. Test Plan: - This still does nothing. - Ran `bin/nuance update --item 15`. - Saw an item route to a default queue. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15441
2016-03-08 22:07:22 +01:00
'NuanceItemType' => 'Phobject',
'NuanceItemUpdateWorker' => 'NuanceWorker',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceItemViewController' => 'NuanceController',
Provide `bin/nuance import` and ngram indexes for sources Summary: Ref T10537. More infrastructure: - Put a `bin/nuance` in place with `bin/nuance import`. This has no useful behavior yet. - Allow sources to be searched by substring. This supports `bin/nuance import --source whatever` so you don't have to dig up PHIDs. Test Plan: - Applied migrations. - Ran `bin/nuance import --source ...` (no meaningful effect, but works fine). - Searched for sources by substring in the UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15436
2016-03-08 15:27:26 +01:00
'NuanceManagementImportWorkflow' => 'NuanceManagementWorkflow',
Add Nuance daemons and item types Summary: Ref T10537. This adds an update daemon for pulling item data (e.g., figuring out who the author of a GitHub comment is) and routing items (e.g., sending them to a queue or applying them directly to a task). Also adds `bin/nuance update --item X` for doing this manually for debugging. And adds item types, for specializing item behavior. Previously, sources completely dictated item behavior, but I think we want something a little more flexible. Test Plan: - This still does nothing. - Ran `bin/nuance update --item 15`. - Saw an item route to a default queue. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15441
2016-03-08 22:07:22 +01:00
'NuanceManagementUpdateWorkflow' => 'NuanceManagementWorkflow',
Provide `bin/nuance import` and ngram indexes for sources Summary: Ref T10537. More infrastructure: - Put a `bin/nuance` in place with `bin/nuance import`. This has no useful behavior yet. - Allow sources to be searched by substring. This supports `bin/nuance import --source whatever` so you don't have to dig up PHIDs. Test Plan: - Applied migrations. - Ran `bin/nuance import --source ...` (no meaningful effect, but works fine). - Searched for sources by substring in the UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15436
2016-03-08 15:27:26 +01:00
'NuanceManagementWorkflow' => 'PhabricatorManagementWorkflow',
Nuance - federate out the design of NuanceSource via NuanceSourceDefinition Summary: ...and get the basic edit flow "working" for a new NuanceSourceDefinition - the Phabricator Form. ...and fix a dumb bug in the query class so when you redirect to the view page / try to edit an existing NuanceSource you don't fatal. Test Plan: played around with the edit form and it worked! Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7585
2013-11-20 22:41:19 +01:00
'NuancePhabricatorFormSourceDefinition' => 'NuanceSourceDefinition',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'NuanceQueue' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'NuanceDAO',
'PhabricatorPolicyInterface',
Slightly modernize NuanceSource Summary: Ref T8434. Minor cleanup/modernization. I made type selection modal (like Herald, Auth, etc) so we can render the form on the next screen based on the type. {F472519} Test Plan: Created a new source, edited an existing source. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8434 Differential Revision: https://secure.phabricator.com/D13161
2015-06-05 19:44:02 +02:00
'PhabricatorApplicationTransactionInterface',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
),
Use modern SearchEngine construction in Nuance Summary: Ref T10537. Minor cleanup of controllers to be more modern / work better on mobile. Test Plan: Browsed all queue / source pages. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15428
2016-03-08 00:18:55 +01:00
'NuanceQueueController' => 'NuanceController',
Add very basic routing to Nuance Summary: Ref T8783. Sort out some relationships and fields: - Make Items 1:1 with Queues: each item is always in exactly one queue. Minor discussion on T8783. I think this is easier to understand and reason about (and implement!) and can't come up with any real cases where it isn't powerful enough. - Remove "QueueItem", which allowed items to be in multiple queues at once. - Remove "dateNuanced", which is equivalent to "dateCreated" in all cases. Then add really basic routing: - Add "Default Queue" for Sources. New items from the source route into that queue. - (Some day there will be routing rules, but for now the rule is "always route into the default queue".) - Show queue on items. - Show more / more useful edit history and transactions in several UIs. Test Plan: {F749445} {F749446} {F749447} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8783 Differential Revision: https://secure.phabricator.com/D13988
2015-08-24 18:21:56 +02:00
'NuanceQueueDatasource' => 'PhabricatorTypeaheadDatasource',
Use modern SearchEngine construction in Nuance Summary: Ref T10537. Minor cleanup of controllers to be more modern / work better on mobile. Test Plan: Browsed all queue / source pages. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15428
2016-03-08 00:18:55 +01:00
'NuanceQueueEditController' => 'NuanceQueueController',
Move Nuance Queues to EditEngine Summary: Ref T10537. Update queue editing to use EditEngine. Test Plan: - Created a new queue. - Edited an existing queue. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15431
2016-03-08 01:22:39 +01:00
'NuanceQueueEditEngine' => 'PhabricatorEditEngine',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceQueueEditor' => 'PhabricatorApplicationTransactionEditor',
Use modern SearchEngine construction in Nuance Summary: Ref T10537. Minor cleanup of controllers to be more modern / work better on mobile. Test Plan: Browsed all queue / source pages. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15428
2016-03-08 00:18:55 +01:00
'NuanceQueueListController' => 'NuanceQueueController',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'NuanceQueuePHIDType' => 'PhabricatorPHIDType',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceQueueQuery' => 'NuanceQuery',
Add Nuance Queue list/edit/detail views Summary: Ref T8434. Throw these together. Test Plan: Created a new Queue. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8434 Differential Revision: https://secure.phabricator.com/D13163
2015-06-05 19:49:35 +02:00
'NuanceQueueSearchEngine' => 'PhabricatorApplicationSearchEngine',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceQueueTransaction' => 'NuanceTransaction',
'NuanceQueueTransactionComment' => 'PhabricatorApplicationTransactionComment',
'NuanceQueueTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Use modern SearchEngine construction in Nuance Summary: Ref T10537. Minor cleanup of controllers to be more modern / work better on mobile. Test Plan: Browsed all queue / source pages. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15428
2016-03-08 00:18:55 +01:00
'NuanceQueueViewController' => 'NuanceQueueController',
Generate expected schemata for MetaMTA, Nuance, MetaData, OAuthServer Summary: Ref T1191. Handful of minor things here (T6150, T6149, T6148, T6147, T6146) but nothing very noteworthy. Test Plan: Viewed web UI, saw fewer errors. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10527
2014-09-24 22:50:00 +02:00
'NuanceSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'NuanceSource' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'NuanceDAO',
Transactions - deploy buildTransactionTimeline to remaining applications Summary: Ref T4712. Specifically... - Differential - needed getApplicationTransactionViewObject() implemented - Audit - needed getApplicationTransactionViewObject() implemented - Repository - one object needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) - Ponder - BONUS BUG FIX - leaving a comment on an answer had a bad redirect URI - both PonderQuestion and PonderAnswer needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on both "history" controllers - left a "TODO" on buildAnswers on the question view controller, which is non-standard and should be re-written eventually - Phortune - BONUS BUG FIX - fix new user "createNewAccount" code to not fatal - PhortuneAccount, PhortuneMerchant, and PhortuneCart needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on Account view, merchant view, and cart view controller - Fund - Legalpad - Nuance - NuanceSource needed PhabricatorApplicationTransactionInterface implemented - Releeph (this product is kind of a mess...) - HACKQUEST - had to manually create an arcanist project to even be able to make a "product" and get started...! - BONUS BUG FIX - make sure to "setName" on product edit - ReleephProject (should be ReleepProduct...?), ReleephBranch, and ReleepRequest needed PhabricatorApplicationTransactionInterface implemented - Harbormaster - HarbormasterBuildable, HarbormasterBuild, HarbormasterBuildPlan, and HarbormasterBuildStep all needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) all over the place Test Plan: foreach application, viewed the timeline(s) and made sure they still rendered Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10925
2014-12-04 00:35:47 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
Provide `bin/nuance import` and ngram indexes for sources Summary: Ref T10537. More infrastructure: - Put a `bin/nuance` in place with `bin/nuance import`. This has no useful behavior yet. - Allow sources to be searched by substring. This supports `bin/nuance import --source whatever` so you don't have to dig up PHIDs. Test Plan: - Applied migrations. - Ran `bin/nuance import --source ...` (no meaningful effect, but works fine). - Searched for sources by substring in the UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15436
2016-03-08 15:27:26 +01:00
'PhabricatorNgramsInterface',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
),
Give Nuance form sources a web UI Summary: Ref T8434. Hard-codes form sources as a complaint form. This form is close to perfect and I'm not actually sure we need to let users customize it at all. Test Plan: {F473587} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8434 Differential Revision: https://secure.phabricator.com/D13166
2015-06-05 20:01:06 +02:00
'NuanceSourceActionController' => 'NuanceController',
Use modern SearchEngine construction in Nuance Summary: Ref T10537. Minor cleanup of controllers to be more modern / work better on mobile. Test Plan: Browsed all queue / source pages. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15428
2016-03-08 00:18:55 +01:00
'NuanceSourceController' => 'NuanceController',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'NuanceSourceDefaultEditCapability' => 'PhabricatorPolicyCapability',
'NuanceSourceDefaultViewCapability' => 'PhabricatorPolicyCapability',
Nuance - federate out the design of NuanceSource via NuanceSourceDefinition Summary: ...and get the basic edit flow "working" for a new NuanceSourceDefinition - the Phabricator Form. ...and fix a dumb bug in the query class so when you redirect to the view page / try to edit an existing NuanceSource you don't fatal. Test Plan: played around with the edit form and it worked! Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7585
2013-11-20 22:41:19 +01:00
'NuanceSourceDefinition' => 'Phobject',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'NuanceSourceDefinitionTestCase' => 'PhabricatorTestCase',
Use modern SearchEngine construction in Nuance Summary: Ref T10537. Minor cleanup of controllers to be more modern / work better on mobile. Test Plan: Browsed all queue / source pages. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15428
2016-03-08 00:18:55 +01:00
'NuanceSourceEditController' => 'NuanceSourceController',
Convert Nuance Sources to EditEngine Summary: Ref T10537. Converts sources to EditEngine. Test Plan: - Created a new source. - Edited an existing source. - Submitted a complaint with the complaint form. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15434
2016-03-08 14:09:25 +01:00
'NuanceSourceEditEngine' => 'PhabricatorEditEngine',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceSourceEditor' => 'PhabricatorApplicationTransactionEditor',
Use modern SearchEngine construction in Nuance Summary: Ref T10537. Minor cleanup of controllers to be more modern / work better on mobile. Test Plan: Browsed all queue / source pages. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15428
2016-03-08 00:18:55 +01:00
'NuanceSourceListController' => 'NuanceSourceController',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'NuanceSourceManageCapability' => 'PhabricatorPolicyCapability',
Provide `bin/nuance import` and ngram indexes for sources Summary: Ref T10537. More infrastructure: - Put a `bin/nuance` in place with `bin/nuance import`. This has no useful behavior yet. - Allow sources to be searched by substring. This supports `bin/nuance import --source whatever` so you don't have to dig up PHIDs. Test Plan: - Applied migrations. - Ran `bin/nuance import --source ...` (no meaningful effect, but works fine). - Searched for sources by substring in the UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15436
2016-03-08 15:27:26 +01:00
'NuanceSourceNameNgrams' => 'PhabricatorSearchNgrams',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'NuanceSourcePHIDType' => 'PhabricatorPHIDType',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceSourceQuery' => 'NuanceQuery',
Add a list view for Nuance sources Summary: Ref T8434. Now you can list them. Test Plan: Listed sources. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8434 Differential Revision: https://secure.phabricator.com/D13162
2015-06-05 19:44:18 +02:00
'NuanceSourceSearchEngine' => 'PhabricatorApplicationSearchEngine',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceSourceTransaction' => 'NuanceTransaction',
'NuanceSourceTransactionComment' => 'PhabricatorApplicationTransactionComment',
'NuanceSourceTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Use modern SearchEngine construction in Nuance Summary: Ref T10537. Minor cleanup of controllers to be more modern / work better on mobile. Test Plan: Browsed all queue / source pages. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15428
2016-03-08 00:18:55 +01:00
'NuanceSourceViewController' => 'NuanceSourceController',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceTransaction' => 'PhabricatorApplicationTransaction',
Add Nuance daemons and item types Summary: Ref T10537. This adds an update daemon for pulling item data (e.g., figuring out who the author of a GitHub comment is) and routing items (e.g., sending them to a queue or applying them directly to a task). Also adds `bin/nuance update --item X` for doing this manually for debugging. And adds item types, for specializing item behavior. Previously, sources completely dictated item behavior, but I think we want something a little more flexible. Test Plan: - This still does nothing. - Ran `bin/nuance update --item 15`. - Saw an item route to a default queue. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15441
2016-03-08 22:07:22 +01:00
'NuanceWorker' => 'PhabricatorWorker',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'OwnersConduitAPIMethod' => 'ConduitAPIMethod',
Move Owners to EditEngine Summary: Ref T9132. Paste is in fairly good shape so Owners is up next. Reasoning: - One install wants API access for it. - It's a simple application for getting CustomFields working with EditEngine. This only does the EditEngine part, so CustomFields are no longer editable until I make that work. That will be up next, and I'll hold this until that's ready. Test Plan: - Created and edited packages via web UI. - Created and edited package editing forms via web UI. - Created and edited packages via Conduit. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14598
2015-11-29 18:33:36 +01:00
'OwnersEditConduitAPIMethod' => 'PhabricatorEditEngineAPIMethod',
Detect package change and send out email Summary: For package creation and deletion, send email to all the owners For package modification, detect important fields such as owners and paths, and then send out emails to all owners (including deleted owners and current owners) Also start using transaction for package creation/deletion/modification. Test Plan: - tested mail creation and deletion - tested modification to auditing enabled, primary owners, owners, paths Reviewers: epriestley, nh, vrana Reviewed By: epriestley CC: prithvi, aran, Koolvin Differential Revision: https://secure.phabricator.com/D2470
2012-05-07 09:19:44 +02:00
'OwnersPackageReplyHandler' => 'PhabricatorMailReplyHandler',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'OwnersQueryConduitAPIMethod' => 'OwnersConduitAPIMethod',
Add "owners.search" Conduit API endpoint, with CustomField support Summary: Ref T9964. Adds a new-style "owners.search" endpoint, and an extension for customfields. Puts enough indirection in place to give us nice, consistent "custom.key" user-facing keys instead of "std:custom:owners:na0shf9a8dfdsafl" junk. Test Plan: - Searched Owners via API. - Searched by ID. - Ordered by custom fields. - Reviewed API docs. - Used normal search with ordering. - Viewed custom field values in search results. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14758
2015-12-13 01:25:51 +01:00
'OwnersSearchConduitAPIMethod' => 'PhabricatorSearchEngineAPIMethod',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PHIDConduitAPIMethod' => 'ConduitAPIMethod',
'PHIDInfoConduitAPIMethod' => 'PHIDConduitAPIMethod',
'PHIDLookupConduitAPIMethod' => 'PHIDConduitAPIMethod',
'PHIDQueryConduitAPIMethod' => 'PHIDConduitAPIMethod',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PHUI' => 'Phobject',
PHUIActionPanelView Summary: Super duper sized panels for singluar actions. Test Plan: UIExamples, will need more testing in Phacility. {F286098} Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11709
2015-02-08 02:06:28 +01:00
'PHUIActionPanelExample' => 'PhabricatorUIExample',
'PHUIActionPanelView' => 'AphrontTagView',
Make mobile navigation work properly by default in more cases Summary: Fixes T5752. This obsoletes a bunch of old patterns and I'll follow up on those with a big "go do a bunch of mechanical code changes" task. Major goals are: - Don't load named queries multiple times on search pages. - Don't require extra code to get standard navigation right on mobile. - Reduce the amount of boilerplate in ListControllers. - Reduce the amount of boilerplate around navigation/menus in all controllers. Specifically, here's what this does: - The StandardPage is now a smarter/more structured object with `setNavigation()` and `setCrumbs()` methods. More rendering decisions are delayed until the last possible moment. - It uses this to automatically add crumb actions to the application menu. - It uses this to automatically reuse one SearchEngine instead of running queries multiple times. - The new preferred way to build responses is `$this->newPage()` (like `$this->newDialog()`), which has structured methods for adding stuff (`setTitle()`, etc). - SearchEngine exposes a new convenience method so you don't have to do all the controller delegation stuff. - Building menus is generally simpler. Test Plan: - Tested paste list, view, edit, comment, raw controllers for functionality, mobile menu, crumbs, navigation menu. - Edited saved queries. - Tested Differential, Maniphest (no changes). - Verified the paste pages don't run any duplicate NamedQuery queries. Reviewers: chad Reviewed By: chad Maniphest Tasks: T5752 Differential Revision: https://secure.phabricator.com/D14382
2015-11-02 21:06:28 +01:00
'PHUIApplicationMenuView' => 'Phobject',
PHUIBadgeView Summary: Resonable sketchout of a "Badge" UI for Profiles/Projects/Achievements. Test Plan: weee {F602729} Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T7992 Differential Revision: https://secure.phabricator.com/D13615
2015-07-10 00:12:11 +02:00
'PHUIBadgeBoxView' => 'AphrontTagView',
'PHUIBadgeExample' => 'PhabricatorUIExample',
PHUIBadgeMiniView Summary: Mini teeny little badges. With Timeline integration. Test Plan: Made some, UIExamples. {F603564} {F603565} Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13620
2015-07-10 19:49:28 +02:00
'PHUIBadgeMiniView' => 'AphrontTagView',
PHUIBadgeView Summary: Resonable sketchout of a "Badge" UI for Profiles/Projects/Achievements. Test Plan: weee {F602729} Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T7992 Differential Revision: https://secure.phabricator.com/D13615
2015-07-10 00:12:11 +02:00
'PHUIBadgeView' => 'AphrontTagView',
Basic NUX blank states Summary: Implement in Badges Test Plan: Test with nux=true. {F1033431} Reviewers: epriestley Reviewed By: epriestley Subscribers: johnny-bit, Korvin Differential Revision: https://secure.phabricator.com/D14833
2015-12-21 16:35:45 +01:00
'PHUIBigInfoView' => 'AphrontTagView',
PHUIBoxView Summary: Adds a basic div box that takes some styles. Not sure this is the best approach for the spacing, but overall hoping people can spend less time in CSS and just use this class. Test Plan: UIExamples Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin, AnhNhan Differential Revision: https://secure.phabricator.com/D5723
2013-04-18 20:34:02 +02:00
'PHUIBoxExample' => 'PhabricatorUIExample',
'PHUIBoxView' => 'AphrontTagView',
PHUIButtonBarView Summary: Adds a handy bar full of tiny buttons. Use only when directed. Ref: T4394 Test Plan: View UI Examples. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D8169
2014-02-10 20:11:36 +01:00
'PHUIButtonBarExample' => 'PhabricatorUIExample',
'PHUIButtonBarView' => 'AphrontTagView',
PHUIButtonView class Summary: Rough pass at a PHUIButtonView Class. Keeps phutil_tag intact and adds some image features if you use the class. Test Plan: UIExamples Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6192
2013-06-13 03:23:35 +02:00
'PHUIButtonExample' => 'PhabricatorUIExample',
'PHUIButtonView' => 'AphrontTagView',
First stab at day view Summary: Ref T4393, First stab at day view. Test Plan: Open Calendar Advanced Search, select "Day View (beta)", see rough day view of selected day. Reviewers: chad, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T4393 Differential Revision: https://secure.phabricator.com/D12685
2015-05-04 01:57:18 +02:00
'PHUICalendarDayView' => 'AphrontView',
Calendar upgrades Summary: Does a handful of things to make Calendar significantly more useful - Enabled overlapping events - Profile has a 'week view' of the user - Profile has a 'month view' of the users - Multiple users on a calendar are color coded - Browse view slightly more useful This stops short of implementing the new 'home' view on Calendar, mostly this is a big step though to make that happen next. Test Plan: Make lots of events on diffent users. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T2897, T4375 Differential Revision: https://secure.phabricator.com/D8317
2014-02-24 19:04:23 +01:00
'PHUICalendarListView' => 'AphrontTagView',
Modernize Calendar View Summary: Updates Calendar View to more modern components. Test Plan: Browse Calendar Forward and Back, Create a Status, Get Excited, Get PUMPED. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4392 Differential Revision: https://secure.phabricator.com/D8247
2014-02-16 18:25:29 +01:00
'PHUICalendarMonthView' => 'AphrontView',
Revert "Remove PHUICalendarWidgetView" Summary: This reverts commit 8ce8a761efe9995c371727fdfe9b9e5d7d1b4592. Test Plan: N/A Reviewers: chad, #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D12573
2015-04-27 15:42:32 +02:00
'PHUICalendarWidgetView' => 'AphrontTagView',
Color Palette Summary: Picked a set of standard colors. Based on our current Maniphest color set, but tweaked to the same hue with http://color.hailpixel.com/ Test Plan: Not intended to be end all be all, but a decent first cut. Applied to Maniphest and Tags. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6229
2013-06-19 00:35:14 +02:00
'PHUIColorPalletteExample' => 'PhabricatorUIExample',
Move PhabricatorCrumbs to PHUICrumbs Summary: Ref T7014, laying the groundwork for redesigning crumbs. Test Plan: Tested numberous pages, grep'd locations. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7014 Differential Revision: https://secure.phabricator.com/D11478
2015-01-23 20:35:09 +01:00
'PHUICrumbView' => 'AphrontView',
'PHUICrumbsView' => 'AphrontView',
Introduce "Curtain" views, panels, and extensions Summary: This opens up the new action column to have specialized rendering and behavior. Briefly: - Converted applications (right now, only Paste) render a `CurtainView` to build the column content. - This view uses new extensions to build panels (projects, subscribers, tokens). - The panel extension code and rendering can be changed without breaking old stuff. Minor changes: - Token awards now load their tokens, for consistency/simplicity. - Removed the rest of the "fork of" / "forked from" UI in Paste -- I essentially removed these features a while ago, and no one has complained. Test Plan: UI is a bit rough, but works, and it's going to get changed now anyway: {F1160550} {F1160551} Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15414
2016-03-05 23:45:56 +01:00
'PHUICurtainExtension' => 'Phobject',
'PHUICurtainPanelView' => 'AphrontTagView',
'PHUICurtainView' => 'AphrontTagView',
Rename inline comment views to "PHUIDiff" and give them a base class Summary: Ref T2009. These classes are "Differential" now, but are used elsewhere in diff infrastructure (e.g., Diffusion). - Rename them to "PHUIDiff". - Move them to "src/infrastructure/". - Give them a base class. Test Plan: Interacted with inlines in unified and side-by-side views. Reviewers: btrahan Subscribers: epriestley Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D11996
2015-03-06 14:11:29 +01:00
'PHUIDiffInlineCommentDetailView' => 'PHUIDiffInlineCommentView',
'PHUIDiffInlineCommentEditView' => 'PHUIDiffInlineCommentView',
Begin separating inline comment scaffolding from other renderers Summary: Ref T2009. Inline comments have "scaffolding", which is basically some empty table cells/rows around them to get the layout correct. The scaffolding depends on the renderer, since the cells are different for side-by-side vs unified diffs. This is currently duplicated all over the place: - Edit view has 1up/2up. - Detail view has 1up/2up. - 1up renderer has 1up. - 2up renderer has four separate copies of the 2up logic. These all have subtle differences, which are mostly bugs. Start making the scaffolding more composable so we can get rid of that mess. Test Plan: Added, edited, and removed inline comments on unified and side-by-side diffs. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D11997
2015-03-06 14:44:36 +01:00
'PHUIDiffInlineCommentRowScaffold' => 'AphrontView',
'PHUIDiffInlineCommentTableScaffold' => 'AphrontView',
Reduce code duplication for inline "Undo" Summary: Ref T2009. This is another almost-identical copy of the row scaffolding, which has the same 1up/2up bugs as the 8 other copies of this code. Turn the "undo" element into an InlineCommentView so we can scaffold it. Then, scaffold it with the same code as everything else. Test Plan: Hit "Undo", swapped from 1up to 2up, hit "undo" again, swapped back, tried left/right, everything rendered with proper scaffolding. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D12019
2015-03-08 23:27:16 +01:00
'PHUIDiffInlineCommentUndoView' => 'PHUIDiffInlineCommentView',
Rename inline comment views to "PHUIDiff" and give them a base class Summary: Ref T2009. These classes are "Differential" now, but are used elsewhere in diff infrastructure (e.g., Diffusion). - Rename them to "PHUIDiff". - Move them to "src/infrastructure/". - Give them a base class. Test Plan: Interacted with inlines in unified and side-by-side views. Reviewers: btrahan Subscribers: epriestley Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D11996
2015-03-06 14:11:29 +01:00
'PHUIDiffInlineCommentView' => 'AphrontView',
Begin separating inline comment scaffolding from other renderers Summary: Ref T2009. Inline comments have "scaffolding", which is basically some empty table cells/rows around them to get the layout correct. The scaffolding depends on the renderer, since the cells are different for side-by-side vs unified diffs. This is currently duplicated all over the place: - Edit view has 1up/2up. - Detail view has 1up/2up. - 1up renderer has 1up. - 2up renderer has four separate copies of the 2up logic. These all have subtle differences, which are mostly bugs. Start making the scaffolding more composable so we can get rid of that mess. Test Plan: Added, edited, and removed inline comments on unified and side-by-side diffs. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D11997
2015-03-06 14:44:36 +01:00
'PHUIDiffOneUpInlineCommentRowScaffold' => 'PHUIDiffInlineCommentRowScaffold',
Allow inline comments to be individually hidden Summary: Ref T7447. Implements per-viewer comment hiding. Once a comment is obsolete or uninteresting, you can hide it completely. This is sticky per-user. My hope is that this will strike a better balance between concerns than some of the other approaches (conservative porting, summarization, hide-all). Specifically, this adds a new action here: {F435621} Clicking it completely collapses the comment into a small icon on the previous line, and saves the comment state as hidden for you: {F435626} You can click the icon to reveal all hidden comments below the line. Test Plan: - Hid comments. - Showed comments. - Created, edited, deleted and submitted comments. - Used Diffusion comments (hiding is not implemented there yet, but I'd plan to bring it there eventually if it works out in Differential). Reviewers: btrahan, chad Reviewed By: btrahan Subscribers: jparise, yelirekim, epriestley Maniphest Tasks: T7447 Differential Revision: https://secure.phabricator.com/D13009
2015-05-27 19:28:38 +02:00
'PHUIDiffRevealIconView' => 'AphrontView',
Convert DifferentialRevision view to new PHUIDiffTableOfContentsListView Summary: Ref T2183. Introduces a new View which can (in theory) unify the Revision, Diff and Commit table of contents views. This has the same behavior as before, but accepts slightly more general primitives and parameters and has somewhat cleaner code. I've made one intentinoal behavior change: removing the "Open All in Editor" button. I suspect this is essentially unused, and is a pain to keep around. We can look at restoring it if anyone notices. Test Plan: Looked at a bunch of revisions, no changes from before. Reviewers: chad Reviewed By: chad Maniphest Tasks: T2183 Differential Revision: https://secure.phabricator.com/D13908
2015-08-15 20:43:12 +02:00
'PHUIDiffTableOfContentsItemView' => 'AphrontView',
'PHUIDiffTableOfContentsListView' => 'AphrontView',
Begin separating inline comment scaffolding from other renderers Summary: Ref T2009. Inline comments have "scaffolding", which is basically some empty table cells/rows around them to get the layout correct. The scaffolding depends on the renderer, since the cells are different for side-by-side vs unified diffs. This is currently duplicated all over the place: - Edit view has 1up/2up. - Detail view has 1up/2up. - 1up renderer has 1up. - 2up renderer has four separate copies of the 2up logic. These all have subtle differences, which are mostly bugs. Start making the scaffolding more composable so we can get rid of that mess. Test Plan: Added, edited, and removed inline comments on unified and side-by-side diffs. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D11997
2015-03-06 14:44:36 +01:00
'PHUIDiffTwoUpInlineCommentRowScaffold' => 'PHUIDiffInlineCommentRowScaffold',
PHUIList, PHUIDocument updates Summary: This diff covers a bit of ground. - PHUIDocumentExample has been added - PHUIDocument has been extended with new features - PhabricatorMenuView is now PHUIListView - PhabricatorMenuItemView is now PHUIItemListView Overall - I think I've gotten all the edges covered here. There is some derpi-ness that we can talk about, comments in the code. Responsive design is missing from the new features on PHUIDocument, will follow up later. Test Plan: Tested mobile and desktop menus, old phriction layout, new document views, new lists, and object lists. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6130
2013-06-05 17:41:43 +02:00
'PHUIDocumentExample' => 'PhabricatorUIExample',
Update PhameBlogView UI Summary: Creates a new PhameBlogView which is more of a blog landing page with the latest posts. Management has moved to PhameManageController with a new timeline. Test Plan: Edit Blog, Publish, Subscribe, view posts. {F1008400} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9360 Differential Revision: https://secure.phabricator.com/D14608
2015-11-30 17:47:46 +01:00
'PHUIDocumentSummaryView' => 'AphrontTagView',
Separate Phriction style into PHUIDocumentView Summary: Ref T988. Fixes T3150. I want to use this element in Diviner, so separate it from Phriction. This makes no changes to the actual display except for fixing {T3150} by adding `overflow: hidden;`. Test Plan: Viewed Phriction documents in mobile and desktop views. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T3150 Differential Revision: https://secure.phabricator.com/D6101
2013-06-01 00:03:59 +02:00
'PHUIDocumentView' => 'AphrontTagView',
Redesign Diviner Summary: This implements `PHUIDocumentViewPro` which should move to be the base for all documents (Phame, Phriction, Legalpad, Diviner). Overall this feels really good to me, but I'd like to roll it out into Diviner specifically first to work through the issues and then move into other apps and drop `PHUIDocumentView` once everything is converted. Some features are: - White Background, no border on page - Table of Contents is move to hidden menu (more space for documentation) - Property List sits under the document Some design decisions above are in anticipation of Phriction v3 and Unbeta Phame, specifically commenting and maybe some cool new Remarkup text layout options for Phame. Test Plan: Went through tons of pages on Diviner on Desktop, Tablet, Mobile. Bounce back to Phriction to make sure DocumentView CSS changes actually look better there. {F930518} {F930519} {F930520} {F930521} Reviewers: epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, joshuaspence, Korvin Differential Revision: https://secure.phabricator.com/D14374
2015-11-01 17:56:46 +01:00
'PHUIDocumentViewPro' => 'AphrontTagView',
Feed Story UI Examples. Summary: This provides some new display methods and examples to PHUIFeedStory. Test Plan: Tested UIExamples Page, mobile layouts, and existing Feed Pages (feed, profile, etc). I want to add a bit more but am stopping here since it's not a priority. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5749
2013-04-25 00:18:58 +02:00
'PHUIFeedStoryExample' => 'PhabricatorUIExample',
PHUIFeedStoryView, Update Profile Summary: This moves Feed's rendering over to a PHUI class. I want to build it out and have it power Ponder, Phame, Feed, as well as Profiles and Projects in some fashion. It also provides some more data depth over ObjectItemView. Also updated Profile for mobile and fixed some other display issues there. Test Plan: Tested Feed, Profile. Used iOS and Chrome. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin, AnhNhan Differential Revision: https://secure.phabricator.com/D5687
2013-04-15 04:32:26 +02:00
'PHUIFeedStoryView' => 'AphrontView',
Add instructions about READMEs to new Diffusion basic editor Summary: Provide contextual, in-app documentation about README files. Test Plan: {F44181} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6033
2013-05-24 21:38:27 +02:00
'PHUIFormDividerControl' => 'AphrontFormControl',
Add a date range query to Macros Summary: Ref T1163. Ref T2625. This could probably use some tweaks, but I kept things mostly-generic. I added a new control for freeform dates so we can have it render help or whatever later on. Test Plan: See screenshots. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625, T1163 Differential Revision: https://secure.phabricator.com/D6084
2013-05-31 02:32:12 +02:00
'PHUIFormFreeformDateControl' => 'AphrontFormControl',
Provide a "PHUIFormIconSetControl" Summary: Ref T9992. This is a step on the path to getting EditEngine working in Badges, Projects and Calendar. This doesn't add a new `EditField` for icons yet, just standardizes the old stuff. New stuff is more general and I saved 150 lines of code. I put the endpoint in Files because the similar "choose a profile picture" endpoint will definitely go there, and this endpoint might eventually feature, like, "draw your own icon~~" or something. Test Plan: - Created events, projects and badges with custom icons. - Edited events, projects and badges, changing their icons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9992 Differential Revision: https://secure.phabricator.com/D14799
2015-12-16 16:53:13 +01:00
'PHUIFormIconSetControl' => 'AphrontFormControl',
Linkify Registration Email Summary: Missed this in previous pass. Send these as links in HTML emails. Test Plan: Register a new user that nees approval. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D10815
2014-11-07 23:16:30 +01:00
'PHUIFormInsetView' => 'AphrontView',
Update Form Layouts Summary: This attempts some consistency in form layouts. Notably, they all now contain headers and are 16px off the sides and tops of pages. Also updated dialogs to the same look and feel. I think I got 98% of forms with this pass, but it's likely I missed some buried somewhere. TODO: will take another pass as consolidating these colors and new gradients in another diff. Test Plan: Played in my sandbox all week. Please play with it too and let me know how they feel. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6806
2013-08-26 20:53:11 +02:00
'PHUIFormLayoutView' => 'AphrontView',
Add a basic multipage form Summary: Ref T2232. Very busy day on IRC so I feel like I've made 20 minutes of progress in 1-minute spurts here, but this adds the basics for a form that can have multiple pages and automatically handle pagination and reading to/from the request, objects and responses. The UIExample is reasonably instructive. Basically, you make a form, add pages to the form, and add controls to the pages. The core flow control looks like this: if ($request->isFormPost()) { $form->readFromRequest($request); // (1) if ($form->isComplete()) { // (2) $response = $form->writeToResponse($response); // (3) // Process result here. // (4) } } else { $form->readFromObject($object); // (5) } The key parts are: # This reads the form state from the request, including reading all the inactive pages. # This tests if all pages are valid and the user just clicked "Done" on the last page. # This produces a "response", which might be writing to an object (for simpler forms) or creating a transaction record (for more complex forms). # Here, we would save the object or apply the transactions. # When the user views the form for the first time, we preload all the values from some object (which might just be empty). Ultimate goal here is to fix repository creation to not be a terrible pit of awfulness. There are probably a lot of rough edges and missing features still, but this seems to not be totally crazy. I'm using two submit buttons with different names which doesn't work on IE7 or something, but we can JS our way out of that if we need to. Test Plan: Paged forward and backward through the form. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2232 Differential Revision: https://secure.phabricator.com/D6003
2013-05-23 23:39:01 +02:00
'PHUIFormMultiSubmitControl' => 'AphrontFormControl',
'PHUIFormPageView' => 'AphrontView',
Prepare a replacement for Controller->renderHandlesForPHIDs() Summary: Ref T7689. This gives HandleLists `renderList()` and `renderHandle()` methods, which return views that can perform just-in-time data fetching and generally look and feel like other rendering code, instead of being odd pseudo-functional methods on `Controller`. Also converts callsites on the Maniphest detail page to use these methods. Next changes will wipe out more of the callsites. Test Plan: - Viewed Maniphest detail page with many relevant handles. - Created a new subtask. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7689 Differential Revision: https://secure.phabricator.com/D12205
2015-03-30 15:18:54 +02:00
'PHUIHandleListView' => 'AphrontTagView',
Use standard tag elements instead of "maniphest project tag" to show tags in list views Summary: Standardizes tag rendering in Maniphest and Maniphest/Diffusion list views. (This might need some size/spacing tweaks, I tried to make it look reasonable.) Test Plan: See screenshots. Reviewers: chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9741
2014-06-26 17:49:44 +02:00
'PHUIHandleTagListView' => 'AphrontTagView',
Prepare a replacement for Controller->renderHandlesForPHIDs() Summary: Ref T7689. This gives HandleLists `renderList()` and `renderHandle()` methods, which return views that can perform just-in-time data fetching and generally look and feel like other rendering code, instead of being odd pseudo-functional methods on `Controller`. Also converts callsites on the Maniphest detail page to use these methods. Next changes will wipe out more of the callsites. Test Plan: - Viewed Maniphest detail page with many relevant handles. - Created a new subtask. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7689 Differential Revision: https://secure.phabricator.com/D12205
2015-03-30 15:18:54 +02:00
'PHUIHandleView' => 'AphrontView',
Solidify PHUITwoColumnView as a page layout Summary: Rolls out a new "Object Page" design with PHUITwoColumnView. This is reasonably polished, but wanted to post it up for you now for feedback before chasing down minor bugs. This implements TwoColumn in the following applications: - Ponder - Paste - Slowvote - Countdown - Projects - Profile - Passphrase This helped track down display issues and inconsistencies and make sure the layout was flexible for different pages. Test Plan: Test each of the applications on mobile, tablet, and desktop breakpoints. {F1135705} {F1135706} {F1135707} {F1135708} {F1135709} {F1135710} {F1135711} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15366
2016-02-26 23:34:51 +01:00
'PHUIHeadThingView' => 'AphrontTagView',
Implement PHUIHeaderView from AphrontTagView Summary: Looking at implementing ManiphestTaskListView as standard components, need to add this functionality for Headers. Test Plan: Browsed various pages, couldn't spot any regressions offhand. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D12802
2015-05-12 15:55:46 +02:00
'PHUIHeaderView' => 'AphrontTagView',
Move PhabricatorHovercard to PHUIHovercard Summary: No UI changes, just some search and replace for UI consistency. Test Plan: Test person and object hovercards still work. UIExamples too. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15172
2016-02-03 17:26:30 +01:00
'PHUIHovercardUIExample' => 'PhabricatorUIExample',
Add ProjectCardView, use on Hovercards Summary: Builds a new ProjectCardView, starts basic Project Hovercard redesign (needs milestone, subproject support). Ref T10055 Test Plan: View all the colors. {F1092622} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T10055 Differential Revision: https://secure.phabricator.com/D15186
2016-02-05 05:11:36 +01:00
'PHUIHovercardView' => 'AphrontTagView',
PHUIIconCircleView Summary: Icon in a circle. Base class, not much in the way of color choices. Test Plan: UIExamples, Chrome. {F1062027} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15034
2016-01-16 06:37:36 +01:00
'PHUIIconCircleView' => 'AphrontTagView',
PHUIIconView Summary: Adds a base class for displaying images and icons. Test Plan: Tested giving and taking tokens, viewed action headers, uiexamples for icons, workboards. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5736
2013-04-20 02:44:20 +02:00
'PHUIIconExample' => 'PhabricatorUIExample',
Make PHUIIconView extend AprontTagView Summary: Less code, more options. Test Plan: Test UIExamples page (action headers, tokens, icons and images). No visible difference. Reviewers: epriestley, btrahan, vrana Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5742
2013-04-22 18:49:06 +02:00
'PHUIIconView' => 'AphrontTagView',
PHUIImageMask Summary: Adds a PHUI class for display images on a center point, with or without a mask. Test Plan: I am bad a math, so like, check that for me please. I tested using Photoshop. Class may need tweaked depending how we store the inline-comment coords. {F167829} Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D9614
2014-06-18 23:09:37 +02:00
'PHUIImageMaskExample' => 'PhabricatorUIExample',
'PHUIImageMaskView' => 'AphrontTagView',
Move PHUIErrorView to PHUIInfoView Summary: Since this element isn't strictly about errors, re-label as info view instead. Test Plan: Grepped for all callsites, tested UIExamples and a few other random pages. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: hach-que, Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11867
2015-03-01 23:45:56 +01:00
'PHUIInfoExample' => 'PhabricatorUIExample',
PHUIInfoPanel Summary: First cut of an 'info panel' for phabricator. Basic concept is for display a list of items with a bit more info and depth and an object item list. Projects could be a good first example. Test Plan: UIExamples Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7398
2013-10-25 20:09:06 +02:00
'PHUIInfoPanelExample' => 'PhabricatorUIExample',
'PHUIInfoPanelView' => 'AphrontView',
Move PHUIErrorView to PHUIInfoView Summary: Since this element isn't strictly about errors, re-label as info view instead. Test Plan: Grepped for all callsites, tested UIExamples and a few other random pages. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: hach-que, Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11867
2015-03-01 23:45:56 +01:00
'PHUIInfoView' => 'AphrontView',
PHUIListView Examples, CSS Summary: This adds examples and abstracts out CSS for common nav re-use. Test Plan: Tested DocumentExample and ListExample Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6138
2013-06-06 00:03:56 +02:00
'PHUIListExample' => 'PhabricatorUIExample',
PHUIList, PHUIDocument updates Summary: This diff covers a bit of ground. - PHUIDocumentExample has been added - PHUIDocument has been extended with new features - PhabricatorMenuView is now PHUIListView - PhabricatorMenuItemView is now PHUIItemListView Overall - I think I've gotten all the edges covered here. There is some derpi-ness that we can talk about, comments in the code. Responsive design is missing from the new features on PHUIDocument, will follow up later. Test Plan: Tested mobile and desktop menus, old phriction layout, new document views, new lists, and object lists. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6130
2013-06-05 17:41:43 +02:00
'PHUIListItemView' => 'AphrontTagView',
'PHUIListView' => 'AphrontTagView',
'PHUIListViewTestCase' => 'PhabricatorTestCase',
Begin modularizing main menu items Summary: Ref T10077. Ref T8918. The way the main menu is built is not very modular and fairly hacky. It assumes menus are provided by applications, but this isn't exactly true. Notably, the "Quick Create" menu is not per-application. The current method of building this menu is very inefficient (see T10077). Particularly, we have to build it //twice// because we need to build it once to render the item and then again to render the dropdown options. Start cleaning this up. This diff doesn't actually have any behavioral changes, since I can't swap the menu over until we get rid of all the other items and I haven't extended this to Notifications/Conpherence yet so it doesn't actually fix T8918. Test Plan: Viewed menus while logged in, logged out, in different applications, in desktop/mobile. Nothing appeared different. Reviewers: chad Reviewed By: chad Maniphest Tasks: T8918, T10077 Differential Revision: https://secure.phabricator.com/D14922
2016-01-01 13:26:36 +01:00
'PHUIMainMenuView' => 'AphrontView',
Convert PHUIObjectBoxView to AphrontTagView Summary: Attempting to clean PHUIObjectBoxView up a little as well as finally being able to `addClass` on the sucker. I'm running into some issue with `addTabs` though, which on Files isn't firing. Test Plan: Bounce around tons of screens. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15291
2016-02-17 21:43:38 +01:00
'PHUIObjectBoxView' => 'AphrontTagView',
Move PhabricatorObjectItem to PHUIObjectItem, add 'plain' setting for lists. Summary: Adds plain support for object lists that just look like lists Test Plan: review UIexamples and a number of other applications Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6922
2013-09-09 23:14:34 +02:00
'PHUIObjectItemListExample' => 'PhabricatorUIExample',
'PHUIObjectItemListView' => 'AphrontTagView',
'PHUIObjectItemView' => 'AphrontTagView',
Revamp Profile with new IconNav Summary: Revamps Profile to be like Projects, a mini portal and side nav with icons. Test Plan: Viewed my own profile, as well as others. Test seeing my commits, tasks, diffs, and upcoming events. Checked mobile navigation. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11547
2015-02-02 21:13:48 +01:00
'PHUIPagedFormView' => 'AphrontView',
[Redesign] PHUIPagerView Summary: Ref T8099, Moves AphrontPagerView to PHUIPagerView, converts to standard PHUIButtons and adds some additional features for icon placement on buttons. Test Plan: Tested Advanced Search and Searching files in Diffusion. Works as expected. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T8342, T8099 Differential Revision: https://secure.phabricator.com/D13092
2015-06-02 23:34:04 +02:00
'PHUIPagerView' => 'AphrontView',
Update pinboard view styles, move to PHUI Summary: Tightens up the CSS to display more items (4 wide on 15") and fixes some mobile CSS issues with appseach. Fixes T3614 Test Plan: Tested Pholio, Macros, mobile layouts Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3614 Differential Revision: https://secure.phabricator.com/D6694
2013-08-07 19:58:09 +02:00
'PHUIPinboardItemView' => 'AphrontView',
'PHUIPinboardView' => 'AphrontView',
PHUIPropertyListView Summary: This builds out and implements PHUIPropertyListView (container) and PHUIPropertyListItemView (section) as well as adding tabs. Test Plan: Tested each page I edited with the exception of Releeph and Phortune, though those changes look ok to me diff wise. Updated examples page with tabs. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7283
2013-10-11 16:53:56 +02:00
'PHUIPropertyGroupView' => 'AphrontTagView',
'PHUIPropertyListExample' => 'PhabricatorUIExample',
'PHUIPropertyListView' => 'AphrontView',
Partially generalize Remarkup previews and add support to Differential Summary: Ref T3671. A lot of applications have pretty ad-hoc preview code. Clean it up a bit and add Summary preview to Differential. After ApplicationTransactions we might want to try to serialize the whole form and show a preview of all the transactions, but this seems not very useful in most cases (I'd guess that Remarkup previews are 99% of the value) and tricky to get right (e.g., adding images which don't exist yet to Pholio mocks). I think I can add this in a few other places, too. Test Plan: Edited Maniphest Tasks and Differential Revisions, mashed some buttons. Verified previews rendered correctly. Grepped for removed CSS classes (no hits). {F52907} Reviewers: btrahan, Firehed Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T3671 Differential Revision: https://secure.phabricator.com/D6673
2013-08-05 19:46:39 +02:00
'PHUIRemarkupPreviewPanel' => 'AphrontTagView',
Introduce PHUIRemarkupView, a sane way to work with Remarkup Summary: Fixes T9273. Remarkup has reasonably good fundamentals but the API is a giant pain to work with. Provide a `PHUIRemarkupView` to make it easier. This object is way simpler to use by default. It's not currently as powerful, but we can expand the power level later by adding more setters. Eventually I'd expect to replace `PhabricatorRemarkupInterface` and `PhabricatorMarkupOneOff` with this, but no rush on those. I converted a few callsites as a sanity check that it works OK. Test Plan: - Viewed remarkup in Passphrase. - Viewed remarkup in Badges. - Viewed a Conduit method. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9273 Differential Revision: https://secure.phabricator.com/D14289
2015-10-15 19:20:19 +02:00
'PHUIRemarkupView' => 'AphrontView',
First cut of progress bars (PHUISegmentBarView) Summary: Ref T10288. I couldn't figure out how to reasonably get the interior right borders to round like the mock, but I think this is otherwise mostly faithful. Feel free to fix stuff. Test Plan: {F1100415} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10288 Differential Revision: https://secure.phabricator.com/D15219
2016-02-08 23:37:31 +01:00
'PHUISegmentBarSegmentView' => 'AphrontTagView',
'PHUISegmentBarView' => 'AphrontTagView',
Put Spaces on Hovercards and ObjectItemLists Summary: Ref T8449. Test Plan: {F474186} {F474187} Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T8449 Differential Revision: https://secure.phabricator.com/D13173
2015-06-05 23:20:25 +02:00
'PHUISpacesNamespaceContextView' => 'AphrontView',
Add PHUIStatusListView Summary: For Diffusion's auditors list, and Differential's reviewers list (eventually). An inline option might make more sense in Differential, but I want to use this in Diffusion first, and we need more information there. Test Plan: {F51424} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6559
2013-07-24 23:13:22 +02:00
'PHUIStatusItemView' => 'AphrontTagView',
'PHUIStatusListView' => 'AphrontTagView',
Move PhabricatorTagView to PHUITagView Summary: For consistency and great justice. Test Plan: tested audit, uiexamples, action headers Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7967
2014-01-14 23:09:52 +01:00
'PHUITagExample' => 'PhabricatorUIExample',
Use standard tag elements instead of "maniphest project tag" to show tags in list views Summary: Standardizes tag rendering in Maniphest and Maniphest/Diffusion list views. (This might need some size/spacing tweaks, I tried to make it look reasonable.) Test Plan: See screenshots. Reviewers: chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9741
2014-06-26 17:49:44 +02:00
'PHUITagView' => 'AphrontTagView',
PHUITimelineView Summary: Updates PhabricatorTimeline to PHUITimeline. Uses standard colors and spacing, softens up the actors, and reduces visual spacing of action-only events. - Also updated some 2x sprite images. Test Plan: Tested Tasks Paste and Pholio in my sandbox. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D8205
2014-02-12 18:02:05 +01:00
'PHUITimelineEventView' => 'AphrontView',
'PHUITimelineExample' => 'PhabricatorUIExample',
'PHUITimelineView' => 'AphrontView',
Add similiar questions sidebar to Ponder Summary: Ref T9099. Testing out a two column layout in Ponder, with the main idea being creating a more browsable, discoverable product. I'd like the side column though to be a little smarter and provide project based searching. Ideally, if I'm reading Resolved Maniphest questions, other Resolved Maniphest questions are likely interesting. Another scenario is if I'm answering questions, in which case browsing more Open questions would also be interesting. Ponder "Main Column" still needs to be redesigned. Test Plan: Browse open questions, resolved questions. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9099 Differential Revision: https://secure.phabricator.com/D13849
2015-08-10 23:55:43 +02:00
'PHUITwoColumnView' => 'AphrontTagView',
Make token UI stronger and more consistent Summary: Ref T4100. Overall: - Use token background color to communicate token type (blue = object, yellow = function, grey = disabled/closed, red = invalid). - Use token icon color to make color choices consistent (specifically, use project icon colors in project tokens). - For functions, use token icon to communicate function result type (e.g., viewer() has a user icon; members(...) has a group icon), since we don't need the icon to indicate "this is a function" anymore. Test Plan: {F374615} {F374616} {F374617} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12446
2015-04-17 16:00:43 +02:00
'PHUITypeaheadExample' => 'PhabricatorUIExample',
Send appropriate requests to the server when dragging cards on project boards Summary: Ref T1344. Makes requests to the server, which are received and ignored. Performs appropriate locking/unlocking/enabling/disabling on the client. Test Plan: Dragged stuff around, saw it enable/disable/send correctly. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7943
2014-01-13 21:24:36 +01:00
'PHUIWorkboardView' => 'AphrontTagView',
'PHUIWorkpanelView' => 'AphrontTagView',
Add "PassphraseKey" classes for code which needs to actually use credentials Summary: Ref T4122. These classes provide typed, checked access to credentials, so you can say "give me this password, and throw if anything is funky". Test Plan: Used in next revision. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7625
2013-11-23 00:23:10 +01:00
'PassphraseAbstractKey' => 'Phobject',
Implement `passphrase.query` for querying credentials Summary: Resolves T5868. This implements `passphrase.query` and a mechanism for allowing Conduit access to credentials. Test Plan: Tested locally. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: talshiri, epriestley, Korvin Maniphest Tasks: T5868 Differential Revision: https://secure.phabricator.com/D10262
2014-08-16 14:41:03 +02:00
'PassphraseConduitAPIMethod' => 'ConduitAPIMethod',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseController' => 'PhabricatorController',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PassphraseCredential' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PassphraseDAO',
Transactions - land buildTransactionTimeline in a bunch more apps Summary: Ref T4712. Specifically... - Dashboards - two objects needed PhabricatorApplicationTransactionInterface - Macros - Paste - Phlux - one object needed PhabricatorApplicationTransactionInterface - added setShouldTerminate(true) - Files - one object needed PhabricatorApplicationTransactionInterface - Passphrase - one object needed PhabricatorApplicationTransactionInterface - added setShouldTerminate(true) - Drydock - one object needed PhabricatorApplicationTransactionInterface - added setShouldTerminate(true) Test Plan: foreach application, verify that the timeline(s) showed up correctly, including with appropriate setShouldTerminate-ness Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10924
2014-12-03 22:16:15 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
Make Passphrase Credentials Flaggable Summary: Ref T8888, Makes Passphrase credentials flaggable. Test Plan: Flag a credential Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T8888 Differential Revision: https://secure.phabricator.com/D13655
2015-07-18 21:40:23 +02:00
'PhabricatorFlaggableInterface',
Add Subscribers to Passphrase Summary: Fixes T9078, Adds SubscribableInterface to Passphrase. Test Plan: Create a new passphrase, see myself subscribed. Subscribe to other Passphrases. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9078 Differential Revision: https://secure.phabricator.com/D13799
2015-08-05 20:59:38 +02:00
'PhabricatorSubscribableInterface',
Add UI for alternate board ordering rules Summary: Ref T4807. This doesn't actually do anything yet, but adds a dropdown menu for choosing an ordering and gets all the UI working correctly. This also fixes a bug where column hidden state wouldn't persist across filter changes. (I won't land this until it does something, but the next diff will probably be a mess so this seemed like a clean place to sever things.) Test Plan: {F187114} - Altered sort ordering. - Altered hidden state and filters, verified all states persisted correctly. - Added `phlog()` to edit/create and move controllers and verified they receive sort information. Reviewers: btrahan, chad Reviewed By: chad Subscribers: swisspol, chad, epriestley Maniphest Tasks: T4807 Differential Revision: https://secure.phabricator.com/D10178
2014-08-08 17:10:29 +02:00
'PhabricatorDestructibleInterface',
Support Spaces in Passphrase Summary: Ref T8493. This stuff mostly takes care of itself now. Test Plan: Shifted stuff between spaces, verified transactions/headers showed up correctly. Queried by space. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8493 Differential Revision: https://secure.phabricator.com/D13386
2015-06-22 20:28:54 +02:00
'PhabricatorSpacesInterface',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorFulltextInterface',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
),
Save authorPHID on Passphrase Credentials to support "Credential Author" object policy Summary: Fixes T5135. Currently, when you create a credential, we default the policies to your PHID. This means we can't have an application-level configurable default because there's no way to select "the actor's PHID" as a policy. Start tracking the credential author's PHID and add an object policy for it, so there is such a setting. Then, add policy defaults. This mostly unblocks T6787. This obsoletes T6860. Test Plan: - Created a credential with "Credential Author" policy. - Verified I can see/edit it, but other users can not. - Changed default policies to something else. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5135 Differential Revision: https://secure.phabricator.com/D13385
2015-06-22 20:28:33 +02:00
'PassphraseCredentialAuthorPolicyRule' => 'PhabricatorPolicyRule',
Implement `passphrase.query` for querying credentials Summary: Resolves T5868. This implements `passphrase.query` and a mechanism for allowing Conduit access to credentials. Test Plan: Tested locally. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: talshiri, epriestley, Korvin Maniphest Tasks: T5868 Differential Revision: https://secure.phabricator.com/D10262
2014-08-16 14:41:03 +02:00
'PassphraseCredentialConduitController' => 'PassphraseController',
Add a credential selection control to Passphrase Summary: Ref T4122. Adds a control for choosing credentials. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran, lsave Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7617
2013-11-21 21:35:36 +01:00
'PassphraseCredentialControl' => 'AphrontFormControl',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseCredentialCreateController' => 'PassphraseController',
'PassphraseCredentialDestroyController' => 'PassphraseController',
'PassphraseCredentialEditController' => 'PassphraseController',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PassphraseCredentialFulltextEngine' => 'PhabricatorFulltextEngine',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'PassphraseCredentialListController' => 'PassphraseController',
Add a "Lock Permanently" action to Passphrase Summary: Fixes T4931. Each new credential should come with the ability to lock the credential permanently, so that no one can ever edit again. Each existing credential must allow user to lock existing credential. Test Plan: Create new credential, verify that you can lock it before saving it. Open existing unlocked credential, verify that option to lock it exists. Once credential is locked, the option to reveal it should be disabled, and editing the credential won't allow username/password updates. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4931 Differential Revision: https://secure.phabricator.com/D8947
2014-05-03 03:05:19 +02:00
'PassphraseCredentialLockController' => 'PassphraseController',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PassphraseCredentialPHIDType' => 'PhabricatorPHIDType',
Allow Passphrase to generate SSH keypairs and extact public keys from private keys Summary: Ref T4587. - Add an option to generate a keypair. - Add an option to view the public keys for existing keypairs. Test Plan: - Generated keypairs. - Viewed public keys. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4587 Differential Revision: https://secure.phabricator.com/D8515
2014-03-13 02:58:25 +01:00
'PassphraseCredentialPublicController' => 'PassphraseController',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseCredentialQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PassphraseCredentialRevealController' => 'PassphraseController',
'PassphraseCredentialSearchEngine' => 'PhabricatorApplicationSearchEngine',
'PassphraseCredentialTransaction' => 'PhabricatorApplicationTransaction',
'PassphraseCredentialTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
'PassphraseCredentialTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'PassphraseCredentialType' => 'Phobject',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PassphraseCredentialTypeTestCase' => 'PhabricatorTestCase',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseCredentialViewController' => 'PassphraseController',
'PassphraseDAO' => 'PhabricatorLiskDAO',
Save authorPHID on Passphrase Credentials to support "Credential Author" object policy Summary: Fixes T5135. Currently, when you create a credential, we default the policies to your PHID. This means we can't have an application-level configurable default because there's no way to select "the actor's PHID" as a policy. Start tracking the credential author's PHID and add an object policy for it, so there is such a setting. Then, add policy defaults. This mostly unblocks T6787. This obsoletes T6860. Test Plan: - Created a credential with "Credential Author" policy. - Verified I can see/edit it, but other users can not. - Changed default policies to something else. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5135 Differential Revision: https://secure.phabricator.com/D13385
2015-06-22 20:28:33 +02:00
'PassphraseDefaultEditCapability' => 'PhabricatorPolicyCapability',
'PassphraseDefaultViewCapability' => 'PhabricatorPolicyCapability',
Added a Note Credential Type for Passphrase Summary: Closes T8481. Test Plan: Verify that in Passphrase > Create an option to create a Note credential exists and credentials of type Note are createable. Reviewers: epriestley, #blessed_reviewers, eadler, lpriestley Reviewed By: eadler Subscribers: joshuaspence, epriestley, Korvin Maniphest Tasks: T8481 Differential Revision: https://secure.phabricator.com/D13261
2015-06-16 22:44:51 +02:00
'PassphraseNoteCredentialType' => 'PassphraseCredentialType',
Rename PassphraseCredentialType subclasses for consistency Summary: Ref T5655. Test Plan: `arc unit` + `grep` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D13266
2015-06-14 06:11:55 +02:00
'PassphrasePasswordCredentialType' => 'PassphraseCredentialType',
Add "PassphraseKey" classes for code which needs to actually use credentials Summary: Ref T4122. These classes provide typed, checked access to credentials, so you can say "give me this password, and throw if anything is funky". Test Plan: Used in next revision. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7625
2013-11-23 00:23:10 +01:00
'PassphrasePasswordKey' => 'PassphraseAbstractKey',
Implement `passphrase.query` for querying credentials Summary: Resolves T5868. This implements `passphrase.query` and a mechanism for allowing Conduit access to credentials. Test Plan: Tested locally. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: talshiri, epriestley, Korvin Maniphest Tasks: T5868 Differential Revision: https://secure.phabricator.com/D10262
2014-08-16 14:41:03 +02:00
'PassphraseQueryConduitAPIMethod' => 'PassphraseConduitAPIMethod',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PassphraseRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Rename PassphraseCredentialType subclasses for consistency Summary: Ref T5655. Test Plan: `arc unit` + `grep` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D13266
2015-06-14 06:11:55 +02:00
'PassphraseSSHGeneratedKeyCredentialType' => 'PassphraseSSHPrivateKeyCredentialType',
Add "PassphraseKey" classes for code which needs to actually use credentials Summary: Ref T4122. These classes provide typed, checked access to credentials, so you can say "give me this password, and throw if anything is funky". Test Plan: Used in next revision. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7625
2013-11-23 00:23:10 +01:00
'PassphraseSSHKey' => 'PassphraseAbstractKey',
Rename PassphraseCredentialType subclasses for consistency Summary: Ref T5655. Test Plan: `arc unit` + `grep` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D13266
2015-06-14 06:11:55 +02:00
'PassphraseSSHPrivateKeyCredentialType' => 'PassphraseCredentialType',
'PassphraseSSHPrivateKeyFileCredentialType' => 'PassphraseSSHPrivateKeyCredentialType',
'PassphraseSSHPrivateKeyTextCredentialType' => 'PassphraseSSHPrivateKeyCredentialType',
Generate expected scheamta for Passphrase, Paste, Phlux, Phame Summary: Ref T1191. Nothing notable in these. Test Plan: Viewed web UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10528
2014-09-24 22:50:57 +02:00
'PassphraseSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseSecret' => 'PassphraseDAO',
Add a "Token" Credential type Summary: Ref T9456. This is just a convenience type for things like API tokens, to make it harder for users to make mistakes and keep SSH keys out of the dropdown for "choose your API token". Test Plan: {F879820} Reviewers: chad Reviewed By: chad Subscribers: joshuaspence Maniphest Tasks: T9456 Differential Revision: https://secure.phabricator.com/D14284
2015-10-15 03:34:55 +02:00
'PassphraseTokenCredentialType' => 'PassphraseCredentialType',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PasteConduitAPIMethod' => 'ConduitAPIMethod',
'PasteCreateConduitAPIMethod' => 'PasteConduitAPIMethod',
Add some create mail handlers for paste and files Summary: Fixes T1144. Though actually I think T1144 wanted some handy way to email from the command-line / arc, this is cooler. :D Test Plan: set conf properly and then ./bin/mail receive-test --as btrahan --to pasties@phabricator.dev | README --> it worked...! couldn't test files as easily but verified exception thrown when I tried to test. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1144 Differential Revision: https://secure.phabricator.com/D6622
2013-07-30 22:26:55 +02:00
'PasteCreateMailReceiver' => 'PhabricatorMailReceiver',
Paste: Add edit policy Summary: T5549 Test Plan: Set edit policy on paste, check that only users meeting the policy requirements can edit it. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5549 Differential Revision: https://secure.phabricator.com/D11097
2014-12-31 17:23:47 +01:00
'PasteDefaultEditCapability' => 'PhabricatorPolicyCapability',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'PasteDefaultViewCapability' => 'PhabricatorPolicyCapability',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PasteEditConduitAPIMethod' => 'PhabricatorEditEngineAPIMethod',
Paste embeds look super cool Summary: Make Paste embeds look super cool Test Plan: {F35387} Reviewers: epriestley CC: aran, Korvin, chad, btrahan, AnhNhan Maniphest Tasks: T1770 Differential Revision: https://secure.phabricator.com/D5323
2013-03-13 14:44:27 +01:00
'PasteEmbedView' => 'AphrontView',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PasteInfoConduitAPIMethod' => 'PasteConduitAPIMethod',
Lift common code for transaction-based reply handlers into parent class Summary: Ref T7199. Essentially all of the reply handlers now apply transactions to something which implements PhabricatorApplicationTransactionInterface. We can share code between them by lifting this stuff into a superclass. First, convert paste. Also rename `PasteMockMailReceiver` to `PasteMailReceiver` (this got mis-copied from Pholio at some point, I think). Test Plan: Used `bin/mail receive-test` to send comments + `!unsubscribe` to pastes. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12236
2015-04-01 17:39:21 +02:00
'PasteMailReceiver' => 'PhabricatorObjectMailReceiver',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PasteQueryConduitAPIMethod' => 'PasteConduitAPIMethod',
Lift common code for transaction-based reply handlers into parent class Summary: Ref T7199. Essentially all of the reply handlers now apply transactions to something which implements PhabricatorApplicationTransactionInterface. We can share code between them by lifting this stuff into a superclass. First, convert paste. Also rename `PasteMockMailReceiver` to `PasteMailReceiver` (this got mis-copied from Pholio at some point, I think). Test Plan: Used `bin/mail receive-test` to send comments + `!unsubscribe` to pastes. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12236
2015-04-01 17:39:21 +02:00
'PasteReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Implement a rough initial version of ApplicationSearch-driven Conduit read endpoints Summary: Ref T9964. See that task for some context and discussion. Ref T7715, which has the bigger picture here. Basically, I want Conduit read endpoints to be full-power, ApplicationSearch-driven endpoints, so that applications can: - Write one EditEngine and get web + conduit writes for free. - Write one SearchEngine and get web + conduit reads for free. I previously made some steps toward this, but this puts more of the structure in place. Test Plan: Viewed API console endpoint and read 20 pages of docs: {F1021961} Made various calls: with query keys, constraints, pagination, and limits. Viewed new {nav Config > Modules} page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7715, T9964 Differential Revision: https://secure.phabricator.com/D14743
2015-12-11 17:45:56 +01:00
'PasteSearchConduitAPIMethod' => 'PhabricatorSearchEngineAPIMethod',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'PeopleBrowseUserDirectoryCapability' => 'PhabricatorPolicyCapability',
People - add application policy on user creation Summary: Ref T6947. Test Plan: made the setting say only admin user a and noted admin user b lost access Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4137, T6947 Differential Revision: https://secure.phabricator.com/D11357
2015-01-13 00:18:16 +01:00
'PeopleCreateUsersCapability' => 'PhabricatorPolicyCapability',
Move PhabricatorHovercard to PHUIHovercard Summary: No UI changes, just some search and replace for UI consistency. Test Plan: Test person and object hovercards still work. UIExamples too. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15172
2016-02-03 17:26:30 +01:00
'PeopleHovercardEngineExtension' => 'PhabricatorHovercardEngineExtension',
Add a GC for user logs Summary: Fixes T4368. This is the last "obvious" table we have which we should be GC'ing but do not. It's about 1/12th of the data on `secure.phabricator.com`. This table stores logins, account creation, password resets, login attempts, etc, and is primarily useful if something sketchy happens so you can go back and review login activity. This data is not useful indefinitely, and there's no reason to retain it forever. Because you don't always know when something sketchy happened I've given this table a fairly long TTL (180 days), but we don't need limitless amounts of this data. Test Plan: Ran `phd debug garbage` and saw a reasonable amount of data get GC'd. This table already has an appropriate key. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4368 Differential Revision: https://secure.phabricator.com/D8128
2014-02-03 19:51:41 +01:00
'PeopleUserLogGarbageCollector' => 'PhabricatorGarbageCollector',
I guess this can support JS too.
2011-01-30 01:16:09 +01:00
'Phabricator404Controller' => 'PhabricatorController',
Add Disqus, Facebook, Google, GitHub auth config; AWS config Summary: Also improve behavior for the "unknown config" warning. Test Plan: Looked at configs, went through unknown config workflow. Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4310
2013-01-01 23:09:29 +01:00
'PhabricatorAWSConfigOptions' => 'PhabricatorApplicationConfigOptions',
Fix controller-level access rules Summary: Ref T603. I had to partially revert this earlier because it accidentally blocked access to Conduit and File data for installs without "policy.allow-public", since the applications are available to "all users" but some endpoints actually need to be available even when not logged in. This readjusts the gating in the controller to properly apply application visibility restrictions, and then adds a giant pile of unit test coverage to make sure it sticks and all the weird cases are covered. Test Plan: - Added and executed unit tests. - Executed most of the tests manually, by using logged in / admin / public / disabled users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7211
2013-10-04 04:05:47 +02:00
'PhabricatorAccessControlTestCase' => 'PhabricatorTestCase',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorAccessLog' => 'Phobject',
Add "Developer" and "Access Log" config option groups, some types Summary: - Add a "developer" option group. - Add an "access log" option group. - Render the types "bool", "int" and "string" in a more tailored way. - Add a config check for dead config. Right now this serves as a "TODO" list of things that need to be migrated. Test Plan: Looked at config options, setup issues. Edited bool, int, string options. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4308
2013-01-01 23:09:17 +01:00
'PhabricatorAccessLogConfigOptions' => 'PhabricatorApplicationConfigOptions',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorAccountSettingsPanel' => 'PhabricatorSettingsPanel',
Modernize Paste Summary: - Add a PhabricatorApplication. - Make most of the views work well on tablets / phones. The actual "Create" form doesn't, but everything else is good -- need to make device-friendly form layouts before I can do the form. Test Plan: Will attach screenshots. Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3293
2012-08-15 19:45:06 +02:00
'PhabricatorActionListView' => 'AphrontView',
'PhabricatorActionView' => 'AphrontView',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorActivitySettingsPanel' => 'PhabricatorSettingsPanel',
Rename `PhabricatorPolicyRule` subclasses for consistency Summary: Ref T5655. Fixes T6849. This is another take on D11131, which was missing the DB migration and was reverted in rP7c4de0f6be77ddaea593e1f41ae27211ec179a55. Test Plan: Ran `./bin/storage upgrade` and verified that the classes were renamed in the `phabricator_policy.policy` table. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6849, T5655 Differential Revision: https://secure.phabricator.com/D11166
2015-01-03 13:48:19 +01:00
'PhabricatorAdministratorsPolicyRule' => 'PhabricatorPolicyRule',
Modularize Aphront exception handling Summary: Ref T1806. Ref T7173. Depends on D14047. Currently, all exception handling is in this big messy clump in `AphrontDefaultApplicationConfiguration`. Split it out into modular classes. This will let a future change add new classes in the Phacility cluster which intercept particular exceptions we care about and replaces the default, generic responses with more useful, tailored responses. Test Plan: {F777391} - Hit a Conduit error (made a method throw). - Hit an Ajax error (made comment preview throw). - Hit a high security error (tried to edit TOTP). - Hit a rate limiting error (added a bunch of email addresses). - Hit a policy error (tried to look at something with no permission). - Hit an arbitrary exception (made a randomc ontroller throw). Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14049
2015-09-03 19:04:42 +02:00
'PhabricatorAjaxRequestExceptionHandler' => 'PhabricatorRequestExceptionHandler',
Implement storage of a host ID and a public key for authorizing Conduit between servers Summary: Ref T4209. This creates storage for public keys against authorized hosts, such that servers can be authorized to make Conduit calls as the omnipotent user. Servers are registered into this system by running the following command once: ``` bin/almanac register ``` NOTE: This doesn't implement authorization between servers, just the storage of public keys. Placing this against Almanac seemed like the most sensible place, since I'm imagining in future that the `register` command will accept more information (like the hostname of the server so it can be found in the service directory). Test Plan: Ran `bin/almanac register` and saw the host (and public key information) appear in the database. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4209 Differential Revision: https://secure.phabricator.com/D10400
2014-10-03 14:52:41 +02:00
'PhabricatorAlmanacApplication' => 'PhabricatorApplication',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorAmazonAuthProvider' => 'PhabricatorOAuth2AuthProvider',
Add local navigation to Differential Summary: Adds a flexible navigation menu to diffs that shows you your current position in the diff. Anticipating some "this is the best thing ever" and some "this is the wosrt thing ever" on this, but let's see how much pushback we get? It seems pretty good to me. Test Plan: Will attach screenshots. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1633, T1591 Differential Revision: https://secure.phabricator.com/D3355
2012-08-22 00:01:20 +02:00
'PhabricatorAnchorView' => 'AphrontView',
Make `./bin/aphlict` behave more like a service. Summary: Fixes T5126. Provide `start`, `stop`, `restart`, `debug` and `status` workflows for `./bin/aphlict`. This makes it easier to manage Aphlict as if it were a service. Test Plan: ``` > sudo ./bin/aphlict status Aphlict is not running. > sudo ./bin/aphlict stop Aphlict is not running. > sudo ./bin/aphlict start Aphlict Server started. > sudo ./bin/aphlict status Aphlict (12880) is running. > sudo ./bin/aphlict restart Stopping Aphlict Server (12880)... Aphlict Server (12880) exited normally. Aphlict Server started. > sudo ./bin/aphlict stop Stopping Aphlict Server (12895)... Aphlict Server (12895) exited normally. > sudo ./bin/aphlict debug Starting Aphlict server in foreground... Launching server: $ node '/usr/src/phabricator/src/applications/aphlict/management/../../../../support/aphlict/server/aphlict_server.js' --port='22280' --admin='22281' --host='localhost' --user='aphlict' [Fri May 30 2014 09:56:14 GMT+0000 (UTC)] Started Server (PID 12911) ``` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5126 Differential Revision: https://secure.phabricator.com/D9226
2014-06-05 21:13:44 +02:00
'PhabricatorAphlictManagementDebugWorkflow' => 'PhabricatorAphlictManagementWorkflow',
'PhabricatorAphlictManagementRestartWorkflow' => 'PhabricatorAphlictManagementWorkflow',
'PhabricatorAphlictManagementStartWorkflow' => 'PhabricatorAphlictManagementWorkflow',
'PhabricatorAphlictManagementStatusWorkflow' => 'PhabricatorAphlictManagementWorkflow',
'PhabricatorAphlictManagementStopWorkflow' => 'PhabricatorAphlictManagementWorkflow',
'PhabricatorAphlictManagementWorkflow' => 'PhabricatorManagementWorkflow',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorAphlictSetupCheck' => 'PhabricatorSetupCheck',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorAphrontBarUIExample' => 'PhabricatorUIExample',
Provide hasChildren() to replace isEmptyContent() Summary: Fixes T3698. Sometimes views need to render differently depending on whether they contain content or not. The existing approach for this is `isEmptyContent()`, which doesn't work well and is sort of hacky (it implies double-rendering content, which is not always free or side-effect free). Instead, provide a test for an element without children. This test is powerful enough to catch the easy cases of `null`, etc., and just do the expected thing, but will not catch a View which is reduced upon rendering. Since this is rare and we have no actual need for it today, just accept that as a limitation. Test Plan: Viewed Timeline and Feed UI examples. Viewed Feed (feed), Pholio (timelineview), and Differential (old transactionview). {F53915} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T3698 Differential Revision: https://secure.phabricator.com/D6718
2013-08-12 16:51:01 +02:00
'PhabricatorAphrontViewTestCase' => 'PhabricatorTestCase',
Use ApplicationSearch in Applications application Summary: Ref T603. OMG SO META Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7197
2013-10-02 22:13:07 +02:00
'PhabricatorAppSearchEngine' => 'PhabricatorApplicationSearchEngine',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorApplication' => array(
'Phobject',
'PhabricatorPolicyInterface',
),
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorApplicationApplicationPHIDType' => 'PhabricatorPHIDType',
Begin moving Phabricator configuration into PHP Summary: Ref T2255. Ref T2221. Lay the groundwork to move configuration into PHP, so we can show descriptions in the web UI, do typechecking, disable application options when an application is uninstalled, etc. Test Plan: {F28421} {F28420} {F28422} Reviewers: codeblock, btrahan, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221, T2255 Differential Revision: https://secure.phabricator.com/D4306
2012-12-31 00:36:06 +01:00
'PhabricatorApplicationConfigOptions' => 'Phobject',
Modularize application configuration panels Summary: Ref T7149. This is a few steps away, but: - Generally, I'd like to reduce the amount of "Config" configuration we have. - One good way to do this is to move it into UIs in Application configuration. We did this with email recently. - I think this was a great change and I'd like to keep moving in this direction. - T7149 touches configuration related to file storage engines. Although I'm not planning to fully move configuration into applications yet, it would be easier to debug and test if I could drop a read-only panel there to show engines. - So, modularize the config stuff so I can add a new panel without hard-coding it. Test Plan: - Added, edited, and deleted application emails. - Viewed non-email application detail pages. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12051
2015-03-12 21:28:37 +01:00
'PhabricatorApplicationConfigurationPanel' => 'Phobject',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorApplicationConfigurationPanelTestCase' => 'PhabricatorTestCase',
Modernize global search typeahead datasource Summary: Ref T4420. Bring the global search up to date. Test Plan: Typed various things into global search. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9889
2014-07-18 00:48:36 +02:00
'PhabricatorApplicationDatasource' => 'PhabricatorTypeaheadDatasource',
Application Detail View Summary: Added Applications Details View Applications Detail View Test Plan: In "Applications" application, clicked on each application to check whether the each application detail view is displayed. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4615
2013-01-24 21:13:31 +01:00
'PhabricatorApplicationDetailViewController' => 'PhabricatorApplicationsController',
Allow application policies to be edited Summary: Ref T603. Enables: - Application policies can be edited. - Applications can define custom policies (this will be used for setting defaults, like "what is the default visibiltiy of new tasks", and meta-policies, like "who can create a task?"). Test Plan: Edited application policies. A future diff does more with custom policies. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7205
2013-10-03 21:40:08 +02:00
'PhabricatorApplicationEditController' => 'PhabricatorApplicationsController',
Provide contextual documentation explaining how to prefill ApplicationEditor create forms Summary: Ref T9132. Although forms do generally support prefilling right now, you have to guess how to do it. Provide an explicit action showing you which values are supported and how to prefill them. This is generated automatically when an application switches to ApplicationEditor. Test Plan: {F939804} {F939805} {F939806} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14392
2015-11-03 14:38:06 +01:00
'PhabricatorApplicationEditHTTPParameterHelpView' => 'AphrontView',
Generate mail command documentation from active commands Summary: Ref T7199. This needs some polish and isn't reachable from the UI, but technically has all of the information. Test Plan: {F355899} {F355900} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12241
2015-04-01 16:36:16 +02:00
'PhabricatorApplicationEmailCommandsController' => 'PhabricatorApplicationsController',
Allow entire dashboards to be copied Summary: Further improve UX for dealing with policy rules on dashboards: - When in the "Manage" view of a dashboard you can not edit: - Don't show the panel management controls. - Show a notice that the board isn't editable, recommending you make a copy instead. - Add a "Copy Dashboard" action to create a copy which you //can// edit. Test Plan: Copied some dashboards. See screenshots. Reviewers: chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9508
2014-06-13 06:49:19 +02:00
'PhabricatorApplicationLaunchView' => 'AphrontTagView',
Modularize application configuration panels Summary: Ref T7149. This is a few steps away, but: - Generally, I'd like to reduce the amount of "Config" configuration we have. - One good way to do this is to move it into UIs in Application configuration. We did this with email recently. - I think this was a great change and I'd like to keep moving in this direction. - T7149 touches configuration related to file storage engines. Although I'm not planning to fully move configuration into applications yet, it would be easier to debug and test if I could drop a read-only panel there to show engines. - So, modularize the config stuff so I can add a new panel without hard-coding it. Test Plan: - Added, edited, and deleted application emails. - Viewed non-email application detail pages. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12051
2015-03-12 21:28:37 +01:00
'PhabricatorApplicationPanelController' => 'PhabricatorApplicationsController',
Use ApplicationSearch in Applications application Summary: Ref T603. OMG SO META Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7197
2013-10-02 22:13:07 +02:00
'PhabricatorApplicationQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Use delegation to generalize application search controllers Summary: Ref T2625. Lifts almost all of the search logic out of Paste controllers and into Search. This uses controller delegation for generalization. We use this in a few places, but don't use it very much yet. I think it's pretty reasonable as-is, but I might be able to make even more stuff free. There are some slightly rough edges around routes, still, but I want to hit Phame and Differential (which both have multiple application search engines) before trying to generalize that. Test Plan: Executed, browsed and managed Paste searches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6073
2013-05-30 23:09:02 +02:00
'PhabricatorApplicationSearchController' => 'PhabricatorSearchBaseController',
Begin modularizing fields in SearchEngines Summary: Ref T8441. Ref T7715. Add a layer of indirection to fields in search engines. This will allow us to: - Simplify SearchEngine code, which has collected a lot of duplication around expressing what is effectively field types. - Automatically add fields like "Spaces" and "Projects" (primary driver for T8441). - Reorder or hide fields (not sure if we really want to do this, but it seems plausible, and this will let us play around with it, at least). - Drive Conduit Query methods via SearchEngines, so the same code specifies both the search UI and the `application.query` endpoint (primary driver in T7715). Test Plan: - Searched for stuff in Paste, everything behaved exaclty like it used to (except that I removed the "no language" checkbox, which seemed like fluff from a bygone era). - Searched for stuff in other applications, saw no changes. - Hit date field errors. - Used query strings to specify values. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13169
2015-06-05 20:21:08 +02:00
'PhabricatorApplicationSearchEngine' => 'Phobject',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorApplicationSearchEngineTestCase' => 'PhabricatorTestCase',
[Redesign] PhabricatorApplicationSearchResultView Summary: Ref T8099. This adds a new class which all search engines return for layout. I thought about this a number of ways, and I think this is the cleanest path. Each Engine can return whatever UI bits they needs, and AppSearch or Dashboard picks and lays the bits out as needed. In the AppSearch case, interfaces like Notifications, Calendar, Legalpad all need more custom layouts. I think this also leaves a resonable path forward for NUX as well. Also, not sure I implemented the class correctly, but assume thats easy to fix? Test Plan: Review and do a search in each application changed. Grep for all call sites. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T8099 Differential Revision: https://secure.phabricator.com/D13332
2015-06-19 12:46:20 +02:00
'PhabricatorApplicationSearchResultView' => 'Phobject',
Add a meta-application Summary: - Adds a new "Applications" application. - Builds an application list via application config instead of via hard-coding, so we can move toward better concepts of installing/uninstalling applications, etc. - Applications indicate that they need attention with notice counts and brief status messages rathern than 50 giant tables of all sorts of app data. I want to try replacing the home screen with this screen, pretty much. Not sure if this is totally crazy or not. What does everyone else think? Test Plan: Will add screenshots. Reviewers: btrahan, chad, vrana, alanh Reviewed By: vrana CC: aran, davidreuss, champo Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3129
2012-08-02 23:07:21 +02:00
'PhabricatorApplicationStatusView' => 'AphrontView',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorApplicationTestCase' => 'PhabricatorTestCase',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorApplicationTransaction' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorLiskDAO',
'PhabricatorPolicyInterface',
'PhabricatorDestructibleInterface',
Add feed integration to generic transactions Summary: Publish feed stories, including from Pholio. Actual stories are somewhat garbage but it's all display-time; I'm going to do a pass on feed in general. Test Plan: {F26832} Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4140
2012-12-11 23:00:21 +01:00
),
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorApplicationTransactionComment' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorLiskDAO',
'PhabricatorMarkupInterface',
'PhabricatorPolicyInterface',
'PhabricatorDestructibleInterface',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
),
Allow ApplicationTransaction comments to be edited and deleted Summary: Allows you to edit or delete comments in appplications which support ApplicationTransactions. UI/UX stuff: - The dialogs are rough but I want to do a dialog design pass more generally, @chad has some mocks. - When you add new mentions via edit, they don't currently count as mentions. I'm not sure what I want to do about this. - When you edit or delete a comment, we do not publish any notifications about it. I think this is reasonable. - I didn't separate "delete" out versus "edit"; I assume it will be reasonably intuitive that deleting all the text deletes effectively deletes the comment. I also want to discourage deletion somewhat (we still show the transaction, just show that the comment has been deleted). Test Plan: Transaction view, note "Edit" and "Edited" links: {F26914} Edit view, has some design issues but I want to do a pass on dialogs in general: {F26915} History view: {F26913} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1082 Differential Revision: https://secure.phabricator.com/D4149
2012-12-11 23:01:51 +01:00
'PhabricatorApplicationTransactionCommentEditController' => 'PhabricatorApplicationTransactionController',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionCommentEditor' => 'PhabricatorEditor',
Allow ApplicationTransaction comments to be edited and deleted Summary: Allows you to edit or delete comments in appplications which support ApplicationTransactions. UI/UX stuff: - The dialogs are rough but I want to do a dialog design pass more generally, @chad has some mocks. - When you add new mentions via edit, they don't currently count as mentions. I'm not sure what I want to do about this. - When you edit or delete a comment, we do not publish any notifications about it. I think this is reasonable. - I didn't separate "delete" out versus "edit"; I assume it will be reasonably intuitive that deleting all the text deletes effectively deletes the comment. I also want to discourage deletion somewhat (we still show the transaction, just show that the comment has been deleted). Test Plan: Transaction view, note "Edit" and "Edited" links: {F26914} Edit view, has some design issues but I want to do a pass on dialogs in general: {F26915} History view: {F26913} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1082 Differential Revision: https://secure.phabricator.com/D4149
2012-12-11 23:01:51 +01:00
'PhabricatorApplicationTransactionCommentHistoryController' => 'PhabricatorApplicationTransactionController',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionCommentQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add a quote action to Differential and Maniphest Summary: Ref T4119. This is ugly for now, but technically works. The comment area and transaction log don't realy know about each other, so for the moment the linking is a bit manual. Differential/Maniphest are special cases anyway. Test Plan: {F149992} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4119 Differential Revision: https://secure.phabricator.com/D8957
2014-05-05 19:55:58 +02:00
'PhabricatorApplicationTransactionCommentQuoteController' => 'PhabricatorApplicationTransactionController',
Transactions - add "view raw" action Summary: Use cutlery icon for hilarity. Ref T5768. Test Plan: made something with remarkup in it, used 'view raw' and saw the remarkup raw in a nice little dialogue. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5768 Differential Revision: https://secure.phabricator.com/D10183
2014-08-08 00:21:32 +02:00
'PhabricatorApplicationTransactionCommentRawController' => 'PhabricatorApplicationTransactionController',
Allow users to remove their own comments, and administrators to remove any comment Summary: Fixes T4909. Adds a "remove" link next to the edit link, which permanently hides a comment. Addresses two use cases: - Allowing administrators to clean up spam. - Allowing users to try to put the genie back in the bottle if they post passwords or sensitive links, etc. The user who removed the comment is named in the removal text to enforce some level of administrative accountability. No data is deleted, but there's currently no method to restore these comments. We'll see if we need one. This is cheating a little bit by storing "removed" as "2" in the isDeleted field. This doesn't seem tooooo bad for now. Test Plan: - Removed some of my comments. - As an administrator, removed other users' comments. - Failed to view history of a removed comment. - Failed to edit a removed comment. - Failed to remove a removed comment. - Verified feed doesn't show the old comment after comment removal. Reviewers: btrahan Reviewed By: btrahan Subscribers: qgil, chad, epriestley Maniphest Tasks: T4909 Differential Revision: https://secure.phabricator.com/D8945
2014-05-05 19:55:32 +02:00
'PhabricatorApplicationTransactionCommentRemoveController' => 'PhabricatorApplicationTransactionController',
Add previews to ApplicationTransaction Summary: Implements previews for Macros and Pholio. (Design is nonfinal -- kind of split the difference between `diff_full_view.png`, laziness, and space concerns. Next couple diffs will add more stuff here.) Test Plan: {F28055} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, vrana Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4246
2012-12-21 14:51:33 +01:00
'PhabricatorApplicationTransactionCommentView' => 'AphrontView',
Allow ApplicationTransaction comments to be edited and deleted Summary: Allows you to edit or delete comments in appplications which support ApplicationTransactions. UI/UX stuff: - The dialogs are rough but I want to do a dialog design pass more generally, @chad has some mocks. - When you add new mentions via edit, they don't currently count as mentions. I'm not sure what I want to do about this. - When you edit or delete a comment, we do not publish any notifications about it. I think this is reasonable. - I didn't separate "delete" out versus "edit"; I assume it will be reasonably intuitive that deleting all the text deletes effectively deletes the comment. I also want to discourage deletion somewhat (we still show the transaction, just show that the comment has been deleted). Test Plan: Transaction view, note "Edit" and "Edited" links: {F26914} Edit view, has some design issues but I want to do a pass on dialogs in general: {F26915} History view: {F26913} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1082 Differential Revision: https://secure.phabricator.com/D4149
2012-12-11 23:01:51 +01:00
'PhabricatorApplicationTransactionController' => 'PhabricatorController',
Transactions - make the details stuff generic and ajaxy Summary: Fixes T2213 Test Plan: Updated a pholio mock description. Observed that when I first showed details there was a round trip made. Toggled show / hide noting no more trips made to server. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T2213 Differential Revision: https://secure.phabricator.com/D6801
2013-08-23 01:45:14 +02:00
'PhabricatorApplicationTransactionDetailController' => 'PhabricatorApplicationTransactionController',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionEditor' => 'PhabricatorEditor',
Add feed integration to generic transactions Summary: Publish feed stories, including from Pholio. Actual stories are somewhat garbage but it's all display-time; I'm going to do a pass on feed in general. Test Plan: {F26832} Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4140
2012-12-11 23:00:21 +01:00
'PhabricatorApplicationTransactionFeedStory' => 'PhabricatorFeedStory',
Add ApplicationTransaction handling for transactions with no effect Summary: When a user submits an action with no effect (like an empty comment, an "abandon" on an already-accepted revision, or a "close, resolved" on a closed task) we want to alert them that their action isn't effective. These warnings fall into two general buckets: - User is submitting two or more actions, and some aren't effective but some are. Prompt them to apply the effective actions only. - A special case of this is where the only effective action is a comment. We provide tailored text ("Post Comment") in this case. - User is submitting one action, which isn't effective. Tell them they're out of luck. - A special case of this is an empty comment. We provide tailored text in this case. By default, the transaction editor throws when transactions have no effect. The caller can then deal with this, or use `PhabricatorApplicationTransactionNoEffectResponse` to provide a standard dialog that gives the user information as above. For cases where we expect transactions to have no effect (notably, "edit" forms) we just continue on no-effect unconditionally. Also fix an issue where new, combined or filtered transactions would not be represented properly in the Ajax response (i.e., return final transactions from `applyTransactions()`), and translate some strings. Test Plan: - Submitted empty and nonempy comments in Macro and Pholio. - Submitted comments with new and existing "@mentions". - Submitted edits in both applications. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T912, T2104 Differential Revision: https://secure.phabricator.com/D4160
2012-12-12 02:27:40 +01:00
'PhabricatorApplicationTransactionNoEffectException' => 'Exception',
'PhabricatorApplicationTransactionNoEffectResponse' => 'AphrontProxyResponse',
Allow TransactionEditor to move publishing work to the daemons Summary: Ref T6367. This is similar to D11329, but not quite as ambitious. Allow Editors to implement `supportsWorkers()` and move their publishing work into a daemon. So far, only Paste supports this. Most of the complexity here is saving and restoring state across the barrier between the web process and the worker process, but I think this is ~90% of it and then we'll pick up a couple of random things in applications. I'm primarily trying to keep this as gradual as possible. Test Plan: - Published transactions with and without daemon support. - Looked at mail, feed. Reviewers: btrahan Reviewed By: btrahan Subscribers: fabe, epriestley Maniphest Tasks: T6367 Differential Revision: https://secure.phabricator.com/D13107
2015-06-02 02:16:27 +02:00
'PhabricatorApplicationTransactionPublishWorker' => 'PhabricatorWorker',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Put inline previews in remarkup textareas Summary: Ref T3967. This gives us a reasonable baseline for doing remarkup previews inline in all contexts, and works in weird/constrained context including: - inline comments; - conpherence; and - custom fields. It would be nicer to go beyond this in contexts like Phame posts, but this is a start, at least. Test Plan: {F1040877} {F1040878} Reviewers: chad Reviewed By: chad Maniphest Tasks: T3967 Differential Revision: https://secure.phabricator.com/D14855
2015-12-22 20:32:07 +01:00
'PhabricatorApplicationTransactionRemarkupPreviewController' => 'PhabricatorApplicationTransactionController',
Lift common code for transaction-based reply handlers into parent class Summary: Ref T7199. Essentially all of the reply handlers now apply transactions to something which implements PhabricatorApplicationTransactionInterface. We can share code between them by lifting this stuff into a superclass. First, convert paste. Also rename `PasteMockMailReceiver` to `PasteMailReceiver` (this got mis-copied from Pholio at some point, I think). Test Plan: Used `bin/mail receive-test` to send comments + `!unsubscribe` to pastes. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12236
2015-04-01 17:39:21 +02:00
'PhabricatorApplicationTransactionReplyHandler' => 'PhabricatorMailReplyHandler',
Render application transactions via Ajax Summary: When possible, render application transactions via Ajax. Instead of reloading the page when the response returns, append new transactions to the transaction view. Scroll the window to the new transactions, animate them in, and clear the form to make this interaction feel reasonable. When editing transactions, fade them in but do not scroll to them (i.e., don't disrupt the user's position). Test Plan: Edited and appended transactions via Ajax. Observed fade in animations and scroll behavior. Clicked anchors to verify proper anchor accounting. Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1960 Differential Revision: https://secure.phabricator.com/D4151
2012-12-11 23:02:29 +01:00
'PhabricatorApplicationTransactionResponse' => 'AphrontProxyResponse',
Transactions - add pagination to application transactions Summary: Ref T4712. This adds pagination. Future diffs will need to deploy `buildTransactionTimeline` everywhere and massage this stuff as necessary if we hit any special cases. Test Plan: Set page size to "5" to make it need to paginate often. Verified proper transactions loaded in and the javascript actions worked. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10887
2014-12-02 22:10:29 +01:00
'PhabricatorApplicationTransactionShowOlderController' => 'PhabricatorApplicationTransactionController',
Improve ApplicationTransaction behavior for poorly constructed transactions Summary: Ref T2222. Five very small improvements: - I hit this exception and it took a bit to understand which transaction was causing problems. Add an `Exception` subclass which does a better job of making the message debuggable. - The `oldValue` of a transaction may be `null`, legitimately (for example, changing the `repositoryPHID` for a revision from `null` to some valid PHID). Do a check to see if `setOldValue()` has been called, instead of a check for a `null` value. - Add an additional check for the other case (shouldn't have a value, but does). - When we're not generating a value, don't bother calling the code to generate it. The best case scenario is that it has no effect; any effect it might have (changing the value) is always wrong. - Maniphest didn't fall back to the parent correctly when computing this flag, so it got the wrong result for `CustomField` transactions. Test Plan: Resolved the issue I was hitting more easily, made updates to a `null`-valued custom field, and applied other normal sorts of transactions successfully. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4557, T2222 Differential Revision: https://secure.phabricator.com/D8401
2014-03-05 19:44:21 +01:00
'PhabricatorApplicationTransactionStructureException' => 'Exception',
Prepare TransactionCommentQuery for extension Summary: Ref T2009. Ref T1460. The way Diffusion and Differential load inlines is horrible garbage right now: - Differential does an ad-hoc query to get the PHIDs, then does a real load to policy check. - Diffusion completely fakes things. In practice this is not a policy violation, but it's dangerous. Make TransactionCommentQuery extensible so we can subclass it and get the query building correctly in the right Query layer. Specifically, the Diffusion and Differential subclasses of this Query will add appropriate `withX()` methods to let us express the query in SQL. Test Plan: Loaded, previewed, edited, and submitted inlines in Differential and Diffusion Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2009, T1460 Differential Revision: https://secure.phabricator.com/D12026
2015-03-09 20:15:54 +01:00
'PhabricatorApplicationTransactionTemplatedCommentQuery' => 'PhabricatorApplicationTransactionCommentQuery',
Implement basic transaction detail blocks Summary: Some transactions (like editing configuration values, task descriptions, or Conpherence images) can't be simply explained and need an additional larger element to show them fully (like a text diff). Support change details like this in ApplicationTransactions. Implements the element in Config, so you can see changes. Test Plan: {F32974} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2213 Differential Revision: https://secure.phabricator.com/D4984
2013-02-17 15:37:02 +01:00
'PhabricatorApplicationTransactionTextDiffDetailView' => 'AphrontView',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorApplicationTransactionTransactionPHIDType' => 'PhabricatorPHIDType',
Allow custom fields to have validation logic Summary: Ref T418. This is fairly messy, but basically: - Add a validation phase to TransactionEditor. - Add a validation phase to CustomField. - Bring it to StandardField. - Add validation logic for the int field. - Provide support in related classes. Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D7028
2013-09-19 00:31:58 +02:00
'PhabricatorApplicationTransactionValidationError' => 'Phobject',
'PhabricatorApplicationTransactionValidationException' => 'Exception',
Differential - return a better response for validation error cases Summary: Fixes T6989. Basically return a nice dialogue like we do for "NoEffect" transactions. This is a little prettier than the other dialogue was. Also, stop adding TYPE_EDGE as a transaction type as we end up having it 2x, which then makes the error get validated 2x. Test Plan: tried to add myself as a reviewer and got a nice error message. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6989 Differential Revision: https://secure.phabricator.com/D11448
2015-01-20 22:59:17 +01:00
'PhabricatorApplicationTransactionValidationResponse' => 'AphrontProxyResponse',
Policy Transactions - add a details view for custom policy Summary: 'cuz those can be complicated. Fixes T4738. I needed to do a fair amount of heavy lifting to get the policy stuff rendering correctly. For now, I made this end point very one purpose and tried to make that clear. Test Plan: looked at some custom policies. see screenshots. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4738 Differential Revision: https://secure.phabricator.com/D8890
2014-04-29 18:42:54 +02:00
'PhabricatorApplicationTransactionValueController' => 'PhabricatorApplicationTransactionController',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorApplicationTransactionView' => 'AphrontView',
Installation & Uninstallion of Applications Summary: Created Applications application which allows uninstallation & installation of application. Test Plan: In "Applications" application, clicked on uninstalled the application by cliking Uninstall and chekcing whether they are really uninstalled(Disabling URI & in appearance in the side pane). Then Clicked on the install button of the uninstalled application to check whether they are installed. Reviewers: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4715
2013-01-29 18:14:03 +01:00
'PhabricatorApplicationUninstallController' => 'PhabricatorApplicationsController',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorApplicationsApplication' => 'PhabricatorApplication',
Initial Commint Summary: Created "Applications" application which lists all the installed applications in phabricator. Test Plan: Navigated to localphabricatorinstall.com/applications and check whether it actually shows the list of all installed applications. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2352 Differential Revision: https://secure.phabricator.com/D4548
2013-01-19 22:46:48 +01:00
'PhabricatorApplicationsController' => 'PhabricatorController',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'PhabricatorApplicationsListController' => 'PhabricatorApplicationsController',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorAsanaAuthProvider' => 'PhabricatorOAuth2AuthProvider',
Initial Asana sync for Differential Summary: Ref T2852. This is highly incomplete but seems structurally sound. Some additional context is available in the Google doc. - Add a workspace ID configuration. Without it, nothing else activates. - Add a worker which reacts to feed stories. - Feed stories about things which aren't Differential objects are ignored. - We load the revision, or fail permanently if we can't. - We get all the related user PHIDs (author, reviewers, CCs). - We check if any of them have linked Asana accounts, or fail permanently if they don't. - We check for an "ASANATASK" edge from the revision. - If we do not find one, we create a new task. - If we do find one, we load the task. - If we succeed, we check the chronological key of the most recent synchronized feed story ("cursor"). - If this story is the same or newer, we update the task to synchronize it to the current state of the revision. - If we fail to load the task, we fail permanently ("asana task has been deleted"). - We then publish the actual story text to the task. Not in yet: - Updating followers requires separate API calls which we don't do yet. - No subtasks yet. - No sync of open/closed state. Test Plan: {F47546} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6302
2013-06-26 01:33:16 +02:00
'PhabricatorAsanaConfigOptions' => 'PhabricatorApplicationConfigOptions',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorAsanaSubtaskHasObjectEdgeType' => 'PhabricatorEdgeType',
'PhabricatorAsanaTaskHasObjectEdgeType' => 'PhabricatorEdgeType',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorAuditActionConstants' => 'Phobject',
Allow audit comments to be added from Diffusion Summary: This is intended to supplant the existing "audit edit" interface. I've changed them to both drive down the same write pathway, but the UIs are still different. I'll fully merge them in a future diff. Add a comment box (like Maniphest and Differential) to Diffusion. When users make comments, their comments appear on the commit. Any audits triggers they are responsible for are updated to reflect actions they take, as well. Currently, audits can only be triggered by packages, but I intend to allow them to be triggered by users and projects (via herald rules) in an upcoming diff. Thus some of the language like "projects, users or packages" when the code is clearly dealing only with "packagePHID". Test Plan: Made audit updates via commit interface and via existing edit interface. Verified both interfaces updated correctly, and that audit responsibility rules were applied properly. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1688
2012-02-25 00:04:53 +01:00
'PhabricatorAuditAddCommentController' => 'PhabricatorAuditController',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorAuditApplication' => 'PhabricatorApplication',
If users are on the email to Phabricator, do not send them the Phabricator reply. Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email. Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected. Reviewers: epriestley, vrana Reviewed By: vrana CC: aran, Korvin, vrana Maniphest Tasks: T1676 Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 19:18:23 +02:00
'PhabricatorAuditCommentEditor' => 'PhabricatorEditor',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorAuditCommitStatusConstants' => 'Phobject',
Add Basic Auditing Functionalities Summary: add basic auditing functionalities. For the related commits for a package, we detect the following conditions which might be suspicious to the owners of the package: * no revision specified * revision not found * author not match * reviewedby not match * owners not involved * commit author not recognized The owners of the package can change the status of the audit entries by accepting it or specify concern. The owner can turn on/off the auditing for a package. Test Plan: * verified that non-owner cannot see the details of the audit and cannot modify it * verified that all the audit reasons can be detected * tested dropdown filtering and package search * verified really normal change not detected * verified accept/concern a commit * tested enable/disable a package for auditing * verified one audit applies to all <commit, packages> to the packages the auditor owns * verified that re-parsing a commit won't have effect if there exists a relationship for <commit, package> already Reviewers: epriestley, nh Reviewed By: epriestley CC: aran, benmathews, btrahan, mpodobnik, prithvi, TomL, epriestley Differential Revision: 1242
2011-12-18 00:52:54 +01:00
'PhabricatorAuditController' => 'PhabricatorController',
Provide a transaction editor to perform Audit row writes Summary: Ref T4896. Replaces more custom stuff with standard stuff. In particular: - No more fake proxy writes; - no more fake detection of `@mentions`. For now, the old code still applies most of the effects and handles feed and email. Test Plan: - Added comments. - Added comments with inline comments. - Added just inline comments. - Added comments with Conduit. - Previewed comments. - Added CCs explicitly and with `@mentions`. - Added auditors. - Accepted a commit. Reviewers: joshuaspence, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4896 Differential Revision: https://secure.phabricator.com/D10109
2014-08-02 09:06:25 +02:00
'PhabricatorAuditEditor' => 'PhabricatorApplicationTransactionEditor',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorAuditInlineComment' => array(
'Phobject',
'PhabricatorInlineCommentInterface',
),
Move rendering to SearchEngine for Calendar Summary: Ref T4986. This one needs `getApplicationURI()` so make it a little beefier to deal with that. (It would be vaguely nice to somehow share the handle and application stuff between Controllers and Engine classes like this, but I don't immediately see a clean way to do it without traits. Not a big deal, in any case.) Test Plan: - Viewed Calendar. - Made a Calendar panel. - Viewed feed. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9012
2014-05-08 18:18:02 +02:00
'PhabricatorAuditListController' => 'PhabricatorAuditController',
Add a basic first-class audit UI Summary: Currently, audits are only accessible through the Owners tool. Start moving them to their own first-class tool in preparation for broader audit integration. - Lay some infrastructure groundwork (e.g. AuditQuery). - Build a basic /audit/ view. - Show audits on the commit page in Diffusion. This has some code duplication with stuff we've already got, but I'll merge everything together as we move forward on this. Test Plan: Looked at /audit/ and a commit. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1685
2012-02-24 22:02:14 +01:00
'PhabricatorAuditListView' => 'AphrontView',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorAuditMailReceiver' => 'PhabricatorObjectMailReceiver',
Provide a more flexible script for administrative management of audits Summary: Fixes T3679. This comes up every so often and the old script is extremely broad (nuke everything in a repository). Provide a more surgical tool. Test Plan: Ran a bunch of variations of the script and they all seemed to work OK. Reviewers: btrahan Reviewed By: btrahan CC: aran, staticshock Maniphest Tasks: T3679 Differential Revision: https://secure.phabricator.com/D6678
2013-08-05 19:35:01 +02:00
'PhabricatorAuditManagementDeleteWorkflow' => 'PhabricatorAuditManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorAuditManagementWorkflow' => 'PhabricatorManagementWorkflow',
Add preview and drafts to audits Summary: Add comment previews and saved drafts to audits, like Maniphest / Differential. Test Plan: Typed stuff into the box. Got a preview. Reloaded page. Stuff was still there. Submitted comment. Stuff is gone. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1699
2012-02-27 22:00:23 +01:00
'PhabricatorAuditPreviewController' => 'PhabricatorAuditController',
Subclass most ReplyHandlers from TransactionReplyHandler Summary: Ref T7199. Half of these aren't even reachable, but make some progress toward reducing the amount of nonsense and garbage in mail handling. Test Plan: Tested all reachable handlers with `bin/mail receive-test`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12237
2015-04-01 17:39:50 +02:00
'PhabricatorAuditReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorAuditStatusConstants' => 'Phobject',
Add storage for new audit transactions and comments Summary: Ref T4896. This adds the new storage, without any code changes. This storage is substantially identical to the Differential storage, except that `changesetID` has been replaced by `pathID`. I've retained the properties intended to be used to implement T1460. They might not be quite right, but at least we'll be able to make any fixes consistently to both applications. For now, these fields are empty and ignored. Test Plan: Ran `./bin/storage upgrade`. Nothing calls this code yet. Reviewers: btrahan, joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T4896 Differential Revision: https://secure.phabricator.com/D10017
2014-07-25 02:59:43 +02:00
'PhabricatorAuditTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorAuditTransactionComment' => 'PhabricatorApplicationTransactionComment',
'PhabricatorAuditTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Convert Audit comment rendering to standard infrastructure Summary: Ref T4896. Depends on D10055. This uses core rendering stuff for audit comments, and fixes all the wonkiness with inlines so we can actually land the migration. Test Plan: Viewed, previewed and edited various types of comments in Diffusion. Reviewers: chad, btrahan, joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T4896 Differential Revision: https://secure.phabricator.com/D10056
2014-07-29 00:01:43 +02:00
'PhabricatorAuditTransactionView' => 'PhabricatorApplicationTransactionView',
Show account cards for external accounts on "linked accounts" screen and "link new account" Summary: Ref T1536. These can probably use some design tweaking and there's a bit of a bug with profile images for some providers, but generally seems to be in the right ballpark. Test Plan: {F46604} {F46605} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6210
2013-06-17 16:08:50 +02:00
'PhabricatorAuthAccountView' => 'AphrontView',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorAuthApplication' => 'PhabricatorApplication',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorAuthAuthFactorPHIDType' => 'PhabricatorPHIDType',
Transactions - deploy buildTransactionTimeline against a few more applications Summary: Ref T4712. Thus far, it seems that most "non-standard" things can be done pretty easily in the controller. Aside from deploying, this diff had to fix a few bugs / missing implementations of stuff. (Notably, PhabricatorAuthProviderConfig, HeraldRule, PhabricatorSlowvotePoll, and AlmanacNetwork needed to implement PhabricatorApplicationTransactionInterface, PhabricatorAuthAuthProviderPHIDType had to be added, and a rendering bug in transactions of type PhabricatorOAuth2AuthProvider had to be fixed.) Test Plan: Almanac - looked at binding, device, network, and service view controllers and verified timeline displayed properly. Herald - looked at a rule and verified timeline. Slowvote - looked at a vote and verified timeline. Auth - looked at an auth provider (Facebook) and verified proper display of transactions within timeline. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10921
2014-12-02 23:33:59 +01:00
'PhabricatorAuthAuthProviderPHIDType' => 'PhabricatorPHIDType',
Add auth.querypublickeys to retrieve public keys Summary: Fixes T6484. I primarily need this to synchronize device public keys in the Phabricator cluster so the new stuff in T2783 works. Although, actually, maybe I don't really need it. But I wrote it anyway and it's desirable to have sooner or later. Test Plan: Ran method. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6484 Differential Revision: https://secure.phabricator.com/D11163
2015-02-11 00:44:21 +01:00
'PhabricatorAuthConduitAPIMethod' => 'ConduitAPIMethod',
Move all account link / unlink to new registration flow Summary: Ref T1536. Currently, we have separate panels for each link/unlink and separate controllers for OAuth vs LDAP. Instead, provide a single "External Accounts" panel which shows all linked accounts and allows you to link/unlink more easily. Move link/unlink over to a full externalaccount-based workflow. Test Plan: - Linked and unlinked OAuth accounts. - Linked and unlinked LDAP accounts. - Registered new accounts. - Exercised most/all of the error cases. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6189
2013-06-17 15:12:45 +02:00
'PhabricatorAuthConfirmLinkController' => 'PhabricatorAuthController',
Authentication
2011-01-26 22:21:12 +01:00
'PhabricatorAuthController' => 'PhabricatorController',
Add storage for Auth configuration in preparation for moving it into a web interface Summary: Ref T1536. Currently, we have about 40 auth-related configuration options. This is already roughly 20% of our config, and we want to add more providers. Additionally, we want to turn some of these auth options into multi-auth options (e.g., allow multiple Phabricator OAuth installs, or, theoretically multiple LDAP servers). I'm going to move this into a separate "Auth" tool with a minimal CLI (`bin/auth`) interface and a more full web interface. Roughly: - Administrators will use the app to manage authentication providers. - The `bin/auth` CLI will provide a safety hatch if you lock yourself out by disabling all usable providers somehow. - We'll migrate existing configuration into the app and remove it. General goals: - Make it much easier to configure authentication by providing an interface for it. - Make it easier to configure everything else by reducing the total number of available options. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6196
2013-06-17 19:48:41 +02:00
'PhabricatorAuthDAO' => 'PhabricatorLiskDAO',
Allow AuthenticationProviderConfig to be enabled and disabled Summary: Ref T1536. Nothing too exciting here, one TODO about tailoring error messages. Test Plan: {F46403} {F46404} {F46405} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6204
2013-06-17 19:54:08 +02:00
'PhabricatorAuthDisableController' => 'PhabricatorAuthProviderConfigController',
Add "High Security" mode to support multi-factor auth Summary: Ref T4398. This is roughly a "sudo" mode, like GitHub has for accessing SSH keys, or Facebook has for managing credit cards. GitHub actually calls theirs "sudo" mode, but I think that's too technical for big parts of our audience. I've gone with "high security mode". This doesn't actually get exposed in the UI yet (and we don't have any meaningful auth factors to prompt the user for) but the workflow works overall. I'll go through it in a comment, since I need to arrange some screenshots. Test Plan: See guided walkthrough. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8851
2014-04-28 02:31:11 +02:00
'PhabricatorAuthDowngradeSessionController' => 'PhabricatorAuthController',
Very rough edit workflow for AuthProvider configuration Summary: Ref T1536. Many rough / broken edges, but adds the rough skeleton of the provider edit workflow. Test Plan: {F46333} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6200
2013-06-17 19:52:38 +02:00
'PhabricatorAuthEditController' => 'PhabricatorAuthProviderConfigController',
Add multi-factor auth and TOTP support Summary: Ref T4398. This is still pretty rough and isn't exposed in the UI yet, but basically works. Some missing features / areas for improvement: - Rate limiting attempts (see TODO). - Marking tokens used after they're used once (see TODO), maybe. I can't think of ways an attacker could capture a token without also capturing a session, offhand. - Actually turning this on (see TODO). - This workflow is pretty wordy. It would be nice to calm it down a bit. - But also add more help/context to help users figure out what's going on here, I think it's not very obvious if you don't already know what "TOTP" is. - Add admin tool to strip auth factors off an account ("Help, I lost my phone and can't log in!"). - Add admin tool to show users who don't have multi-factor auth? (so you can pester them) - Generate QR codes to make the transfer process easier (they're fairly complicated). - Make the "entering hi-sec" workflow actually check for auth factors and use them correctly. - Turn this on so users can use it. - Adding SMS as an option would be nice eventually. - Adding "password" as an option, maybe? TOTP feels fairly good to me. I'll post a couple of screens... Test Plan: - Added TOTP token with Google Authenticator. - Added TOTP token with Authy. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8875
2014-04-28 18:27:11 +02:00
'PhabricatorAuthFactor' => 'Phobject',
'PhabricatorAuthFactorConfig' => 'PhabricatorAuthDAO',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorAuthFactorTestCase' => 'PhabricatorTestCase',
Require multiple auth factors to establish web sessions Summary: Ref T4398. This prompts users for multi-factor auth on login. Roughly, this introduces the idea of "partial" sessions, which we haven't finished constructing yet. In practice, this means the session has made it through primary auth but not through multi-factor auth. Add a workflow for bringing a partial session up to a full one. Test Plan: - Used Conduit. - Logged in as multi-factor user. - Logged in as no-factor user. - Tried to do non-login-things with a partial session. - Reviewed account activity logs. {F149295} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8922
2014-05-01 19:23:02 +02:00
'PhabricatorAuthFinishController' => 'PhabricatorAuthController',
Add "High Security" mode to support multi-factor auth Summary: Ref T4398. This is roughly a "sudo" mode, like GitHub has for accessing SSH keys, or Facebook has for managing credit cards. GitHub actually calls theirs "sudo" mode, but I think that's too technical for big parts of our audience. I've gone with "high security mode". This doesn't actually get exposed in the UI yet (and we don't have any meaningful auth factors to prompt the user for) but the workflow works overall. I'll go through it in a comment, since I need to arrange some screenshots. Test Plan: See guided walkthrough. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8851
2014-04-28 02:31:11 +02:00
'PhabricatorAuthHighSecurityRequiredException' => 'Exception',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorAuthHighSecurityToken' => 'Phobject',
Add administrative invite interfaces Summary: Ref T7152. This implements the administrative UI for the upstream email invite workflow. Pieces of this will be reused in Instances to implement the instance invite workflow, although some of it is probably going to be a bit copy/pastey. This doesn't actually create or send invites yet, and they still can't be carried through registration. Test Plan: {F290970} {F290971} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11733
2015-02-11 15:05:53 +01:00
'PhabricatorAuthInvite' => array(
'PhabricatorUserDAO',
'PhabricatorPolicyInterface',
),
Add email invites to Phabricator (logic only) Summary: Ref T7152. This builds the core of email invites and implements all the hard logic for them, covering it with a pile of tests. There's no UI to create these yet, so users can't actually get invites (and administrators can't send them). This stuff is a complicated mess because there are so many interactions between accounts, email addresses, email verification, email primary-ness, and user verification. However, I think I got it right and got test coverage everwhere. The degree to which this is exception-driven is a little icky, but I think it's a reasonable way to get the testability we want while still making it hard for callers to get the flow wrong. In particular, I expect there to be at least two callers (one invite flow in the upstream, and one derived invite flow in Instances) so I believe there is merit in burying as much of this logic inside the Engine as is reasonably possible. Test Plan: Unit tests only. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11723
2015-02-10 01:12:36 +01:00
'PhabricatorAuthInviteAccountException' => 'PhabricatorAuthInviteDialogException',
Add administrative invite interfaces Summary: Ref T7152. This implements the administrative UI for the upstream email invite workflow. Pieces of this will be reused in Instances to implement the instance invite workflow, although some of it is probably going to be a bit copy/pastey. This doesn't actually create or send invites yet, and they still can't be carried through registration. Test Plan: {F290970} {F290971} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11733
2015-02-11 15:05:53 +01:00
'PhabricatorAuthInviteAction' => 'Phobject',
'PhabricatorAuthInviteActionTableView' => 'AphrontView',
Add email invites to Phabricator (logic only) Summary: Ref T7152. This builds the core of email invites and implements all the hard logic for them, covering it with a pile of tests. There's no UI to create these yet, so users can't actually get invites (and administrators can't send them). This stuff is a complicated mess because there are so many interactions between accounts, email addresses, email verification, email primary-ness, and user verification. However, I think I got it right and got test coverage everwhere. The degree to which this is exception-driven is a little icky, but I think it's a reasonable way to get the testability we want while still making it hard for callers to get the flow wrong. In particular, I expect there to be at least two callers (one invite flow in the upstream, and one derived invite flow in Instances) so I believe there is merit in burying as much of this logic inside the Engine as is reasonably possible. Test Plan: Unit tests only. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11723
2015-02-10 01:12:36 +01:00
'PhabricatorAuthInviteController' => 'PhabricatorAuthController',
'PhabricatorAuthInviteDialogException' => 'PhabricatorAuthInviteException',
'PhabricatorAuthInviteEngine' => 'Phobject',
'PhabricatorAuthInviteException' => 'Exception',
'PhabricatorAuthInviteInvalidException' => 'PhabricatorAuthInviteDialogException',
'PhabricatorAuthInviteLoginException' => 'PhabricatorAuthInviteDialogException',
Add administrative invite interfaces Summary: Ref T7152. This implements the administrative UI for the upstream email invite workflow. Pieces of this will be reused in Instances to implement the instance invite workflow, although some of it is probably going to be a bit copy/pastey. This doesn't actually create or send invites yet, and they still can't be carried through registration. Test Plan: {F290970} {F290971} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11733
2015-02-11 15:05:53 +01:00
'PhabricatorAuthInvitePHIDType' => 'PhabricatorPHIDType',
'PhabricatorAuthInviteQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add email invites to Phabricator (logic only) Summary: Ref T7152. This builds the core of email invites and implements all the hard logic for them, covering it with a pile of tests. There's no UI to create these yet, so users can't actually get invites (and administrators can't send them). This stuff is a complicated mess because there are so many interactions between accounts, email addresses, email verification, email primary-ness, and user verification. However, I think I got it right and got test coverage everwhere. The degree to which this is exception-driven is a little icky, but I think it's a reasonable way to get the testability we want while still making it hard for callers to get the flow wrong. In particular, I expect there to be at least two callers (one invite flow in the upstream, and one derived invite flow in Instances) so I believe there is merit in burying as much of this logic inside the Engine as is reasonably possible. Test Plan: Unit tests only. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11723
2015-02-10 01:12:36 +01:00
'PhabricatorAuthInviteRegisteredException' => 'PhabricatorAuthInviteException',
Add administrative invite interfaces Summary: Ref T7152. This implements the administrative UI for the upstream email invite workflow. Pieces of this will be reused in Instances to implement the instance invite workflow, although some of it is probably going to be a bit copy/pastey. This doesn't actually create or send invites yet, and they still can't be carried through registration. Test Plan: {F290970} {F290971} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11733
2015-02-11 15:05:53 +01:00
'PhabricatorAuthInviteSearchEngine' => 'PhabricatorApplicationSearchEngine',
Add email invites to Phabricator (logic only) Summary: Ref T7152. This builds the core of email invites and implements all the hard logic for them, covering it with a pile of tests. There's no UI to create these yet, so users can't actually get invites (and administrators can't send them). This stuff is a complicated mess because there are so many interactions between accounts, email addresses, email verification, email primary-ness, and user verification. However, I think I got it right and got test coverage everwhere. The degree to which this is exception-driven is a little icky, but I think it's a reasonable way to get the testability we want while still making it hard for callers to get the flow wrong. In particular, I expect there to be at least two callers (one invite flow in the upstream, and one derived invite flow in Instances) so I believe there is merit in burying as much of this logic inside the Engine as is reasonably possible. Test Plan: Unit tests only. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11723
2015-02-10 01:12:36 +01:00
'PhabricatorAuthInviteTestCase' => 'PhabricatorTestCase',
'PhabricatorAuthInviteVerifyException' => 'PhabricatorAuthInviteDialogException',
Send emails for email invites Summary: Ref T7152. Ref T3554. - When an administrator clicks "send invites", queue tasks to send the invites. - Then, actually send the invites. - Make the links in the invites work properly. - Also provide `bin/worker execute` to make debugging one-off workers like this easier. - Clean up some UI, too. Test Plan: We now get as far as the exception which is a placeholder for a registration workflow. {F291213} {F291214} {F291215} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3554, T7152 Differential Revision: https://secure.phabricator.com/D11736
2015-02-11 15:06:09 +01:00
'PhabricatorAuthInviteWorker' => 'PhabricatorWorker',
Move all account link / unlink to new registration flow Summary: Ref T1536. Currently, we have separate panels for each link/unlink and separate controllers for OAuth vs LDAP. Instead, provide a single "External Accounts" panel which shows all linked accounts and allows you to link/unlink more easily. Move link/unlink over to a full externalaccount-based workflow. Test Plan: - Linked and unlinked OAuth accounts. - Linked and unlinked LDAP accounts. - Registered new accounts. - Exercised most/all of the error cases. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6189
2013-06-17 15:12:45 +02:00
'PhabricatorAuthLinkController' => 'PhabricatorAuthController',
Build out Auth UI a little bit Summary: Ref T1536. Make this UI a bit more human-friendly. Test Plan: {F46873} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6237
2013-06-20 00:00:37 +02:00
'PhabricatorAuthListController' => 'PhabricatorAuthProviderConfigController',
Generalize login flows for new registration Summary: Ref T1536. None of this code is reachable. `PhabricatorAuthLoginController` provides a completely generic login/link flow, similar to how D6155 provides a generic registration flow. `PhabricatorAuthProvider` wraps a `PhutilAuthAdapter` and glues the generic top-level flow to a concrete authentication provider. Test Plan: Static only, code isn't meaningfully reachable. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6159
2013-06-16 19:14:07 +02:00
'PhabricatorAuthLoginController' => 'PhabricatorAuthController',
Modularize generation of supplemental login messages Summary: Ref T9346. This mostly allows us to give users additional advice based on which instance they are trying to log in to in the Phacility cluster. It's also slightly more flexible than `auth.login-message` was, and maybe we'll add some more hooks here eventually. This feels like it's a sidegrade in complexity rather than really an improvement, but not too terrible. Test Plan: - Wrote the custom handler in T9346 to replicate old config functionality. - Wrote a smart handler for Phacility that can provide context-sensitive messages based on which OAuth client you're trying to use. See new message box at top (implementation in next diff): {F780375} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9346 Differential Revision: https://secure.phabricator.com/D14057
2015-09-04 19:34:39 +02:00
'PhabricatorAuthLoginHandler' => 'Phobject',
Implement "auth.logout" Conduit API method Summary: Ref T7303. Ref T7673. This implements an "auth.logout" which: - terminates all web sessions; - terminates the current OAuth token if called via OAuth; and - may always be called via OAuth. (Since it consumes an OAuth token, even a "malicious" OAuth application can't really be that much of a jerk with this: it can't continuously log you out, since calling the method once kills the token. The application would need to ask your permission again to get a fresh token.) The primary goal here is to let Phacility instances call this against the Phacility upstream, so that when you log out of an instance it also logs you out of your Phacility account (possibly with a checkbox or something). This also smooths over the session token code. Before this change, your sessions would get logged out but when you reloaded we'd tell you your session was invalid. Instead, try to clear the invalid session before telling the user there's an issue. I think that ssentially 100% of invalid sessions are a result of something in this vein (e.g., forced logout via Settings) nowadays, since the session code is generally stable and sane and has been for a long time. Test Plan: - Called `auth.logout` via console, got a reasonable logout experience. - Called `auth.logout` via OAuth. - Tried to make another call, verified OAuth token had been invalidated. - Verified web session had been invalidated. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7303, T7673 Differential Revision: https://secure.phabricator.com/D15594
2016-04-03 18:06:26 +02:00
'PhabricatorAuthLogoutConduitAPIMethod' => 'PhabricatorAuthConduitAPIMethod',
Begin modularizing main menu items Summary: Ref T10077. Ref T8918. The way the main menu is built is not very modular and fairly hacky. It assumes menus are provided by applications, but this isn't exactly true. Notably, the "Quick Create" menu is not per-application. The current method of building this menu is very inefficient (see T10077). Particularly, we have to build it //twice// because we need to build it once to render the item and then again to render the dropdown options. Start cleaning this up. This diff doesn't actually have any behavioral changes, since I can't swap the menu over until we get rid of all the other items and I haven't extended this to Notifications/Conpherence yet so it doesn't actually fix T8918. Test Plan: Viewed menus while logged in, logged out, in different applications, in desktop/mobile. Nothing appeared different. Reviewers: chad Reviewed By: chad Maniphest Tasks: T8918, T10077 Differential Revision: https://secure.phabricator.com/D14922
2016-01-01 13:26:36 +01:00
'PhabricatorAuthMainMenuBarExtension' => 'PhabricatorMainMenuBarExtension',
Work around lack of PKCS8 support in OSX ssh-keygen Summary: Ref T4209. Ref T6240. Ref T6238. See D10401 for original discussion. On OSX, `ssh-keygen` doesn't support PKCS8: - When we hit an issue with this, raise a more tailored message about it. - Allow the user to work around the problem with `auth cache-pkcs8 ...`, providing reasonable guidance / warnings. In practice, this only really matters very much for one key, which I'm just going to make the services extension cache automatically. So it's sort of moot, but good to have around for weird cases and to make testing easier. Test Plan: Hit error, cached key, got clean asymmetric auth. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4209, T6240, T6238 Differential Revision: https://secure.phabricator.com/D11021
2014-12-20 01:36:40 +01:00
'PhabricatorAuthManagementCachePKCS8Workflow' => 'PhabricatorAuthManagementWorkflow',
Provide `bin/auth ldap` for LDAP diagnostics Summary: Ref T1536. Test Plan: Ran `bin/auth ldap`. Reviewers: mbishopim3, chad Reviewed By: mbishopim3 CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6218
2013-06-17 22:26:25 +02:00
'PhabricatorAuthManagementLDAPWorkflow' => 'PhabricatorAuthManagementWorkflow',
Add `bin/auth list-factors` and `bin/auth strip` to remove multi-factor auth Summary: Ref T4398. The major goals here is to let administrators strip auth factors in two cases: - A user lost their phone and needs access restored to their account; or - an install previously used an API-based factor like SMS, but want to stop supporting it (this isn't possible today). Test Plan: - Used `bin/auth list-factors` to show installed factors. - Used `bin/auth strip` with various mixtures of flags to selectively choose and strip factors from accounts. - Also ran `bin/auth refresh` to verify refreshing OAuth tokens works (small `OAuth` vs `OAuth2` tweak). Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8909
2014-04-30 23:30:00 +02:00
'PhabricatorAuthManagementListFactorsWorkflow' => 'PhabricatorAuthManagementWorkflow',
Add very basic `bin/auth` tool Summary: Ref T1536. This script basically exists to restore access if/when users shoot themselves in the foot by disabling all auth providers and can no longer log in. Test Plan: {F46411} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6205
2013-06-17 19:55:05 +02:00
'PhabricatorAuthManagementRecoverWorkflow' => 'PhabricatorAuthManagementWorkflow',
Add `bin/auth refresh` for debugging OAuth token refresh issues Summary: Ref T2852. Provide a script for inspecting/debugging OAuth token refresh. Test Plan: Ran `bin/auth refresh` with various arguments, saw token refreshes. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6276
2013-06-25 00:55:41 +02:00
'PhabricatorAuthManagementRefreshWorkflow' => 'PhabricatorAuthManagementWorkflow',
Add `bin/auth list-factors` and `bin/auth strip` to remove multi-factor auth Summary: Ref T4398. The major goals here is to let administrators strip auth factors in two cases: - A user lost their phone and needs access restored to their account; or - an install previously used an API-based factor like SMS, but want to stop supporting it (this isn't possible today). Test Plan: - Used `bin/auth list-factors` to show installed factors. - Used `bin/auth strip` with various mixtures of flags to selectively choose and strip factors from accounts. - Also ran `bin/auth refresh` to verify refreshing OAuth tokens works (small `OAuth` vs `OAuth2` tweak). Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8909
2014-04-30 23:30:00 +02:00
'PhabricatorAuthManagementStripWorkflow' => 'PhabricatorAuthManagementWorkflow',
OAuth - add concept of "trusted" clients that get auto redirects Summary: Fixes T7153. Test Plan: used `bin/auth trust-oauth-client` and `bin/auth untrust-oauth-client` to set the bit and verify error states. registered via oauth with `bin/auth trust-oauth-client` set and I did not have the confirmation screen registered via oauth with `bin/auth untrust-oauth-client` set and I did have the confirmation screen Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7153 Differential Revision: https://secure.phabricator.com/D11724
2015-02-09 23:23:49 +01:00
'PhabricatorAuthManagementTrustOAuthClientWorkflow' => 'PhabricatorAuthManagementWorkflow',
Add `bin/auth unlimit` and clean up a TODO Summary: I stumbled across this TODO and was worried that there was a glaring hole in MFA that I'd somehow forgotten about, but the TODO is just out of date. These actions are rate limited properly by `PhabricatorAuthTryFactorAction`, which permits a maximum of 10 actions per hour. - Remove the TODO. - Add `bin/auth unlimit` to make it easier to reset rate limits if someone needs to do that for whatever reason. Test Plan: - Tried to brute force through MFA. - Got rate limited properly after 10 failures. - Reset rate limit with `bin/auth unlimit`. - Saw the expected number of actions clear. {F805288} Reviewers: chad Reviewed By: chad Subscribers: joshuaspence Differential Revision: https://secure.phabricator.com/D14105
2015-09-14 16:03:39 +02:00
'PhabricatorAuthManagementUnlimitWorkflow' => 'PhabricatorAuthManagementWorkflow',
OAuth - add concept of "trusted" clients that get auto redirects Summary: Fixes T7153. Test Plan: used `bin/auth trust-oauth-client` and `bin/auth untrust-oauth-client` to set the bit and verify error states. registered via oauth with `bin/auth trust-oauth-client` set and I did not have the confirmation screen registered via oauth with `bin/auth untrust-oauth-client` set and I did have the confirmation screen Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7153 Differential Revision: https://secure.phabricator.com/D11724
2015-02-09 23:23:49 +01:00
'PhabricatorAuthManagementUntrustOAuthClientWorkflow' => 'PhabricatorAuthManagementWorkflow',
Add a "did verify email" event to Phabricator Summary: Ref T7152. Gives us an event hook so we can go make users a member of any instance they've been invited to as soon as they verify an email address. Test Plan: - Used `bin/auth verify` to trigger the event. - Build out the invite flow in rSERVICES. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11752
2015-02-11 23:39:06 +01:00
'PhabricatorAuthManagementVerifyWorkflow' => 'PhabricatorAuthManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorAuthManagementWorkflow' => 'PhabricatorManagementWorkflow',
Implement most of the administrative UI for approval queues Summary: Nothing fancy here, just: - UI to show users needing approval. - "Approve" and "Disable" actions. - Send "Approved" email on approve. - "Approve" edit + log operations. - "Wait for Approval" state for users who need approval. There's still no natural way for users to end up not-approved -- you have to write directly to the database. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7573
2013-11-13 20:24:18 +01:00
'PhabricatorAuthNeedsApprovalController' => 'PhabricatorAuthController',
Allow installs to require multi-factor authentication for all users Summary: Ref T5089. Adds a `security.require-multi-factor-auth` which forces all users to enroll in MFA before they can use their accounts. Test Plan: Config: {F159750} Roadblock: {F159748} After configuration: {F159749} - Required MFA, got roadblocked, added MFA, got unblocked. - Removed MFA, got blocked again. - Used `bin/auth strip` to strip MFA, got blocked. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5089 Differential Revision: https://secure.phabricator.com/D9285
2014-06-04 01:50:27 +02:00
'PhabricatorAuthNeedsMultiFactorController' => 'PhabricatorAuthController',
Add initial create screen for auth providers Summary: Ref T1536. Adds an initial "choose a provider type" screen for adding a new provider. This doesn't go anywhere yet. Test Plan: {F46316} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6199
2013-06-17 19:51:35 +02:00
'PhabricatorAuthNewController' => 'PhabricatorAuthProviderConfigController',
Send old login code to the bottom of the sea Summary: Ref T1536. This is extremely reachable and changes the login code to the new stuff. Notes: - I've hard-disabled password registration since I want installs to explicitly flip it on via config if they want it. New installs will get it by default in the future, but old installs shouldn't have their auth options change. - Google doesn't let us change the redirect URI, so keep the old one working. - We need to keep a bit of LDAP around for now for LDAP import. - **Facebook:** This causes substantive changes in what login code is executed. Test Plan: - Logged in / logged out / registered, hit new flows. - Logged in with google. - Verified no password registration by default. Reviewers: btrahan, chad Reviewed By: chad CC: wez, nh, aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6222
2013-06-19 10:33:27 +02:00
'PhabricatorAuthOldOAuthRedirectController' => 'PhabricatorAuthController',
Make password reset emails use one-time tokens Summary: Ref T4398. This code hadn't been touched in a while and had a few crufty bits. **One Time Resets**: Currently, password reset (and similar links) are valid for about 48 hours, but we always use one token to generate them (it's bound to the account). This isn't horrible, but it could be better, and it produces a lot of false positives on HackerOne. Instead, use TemporaryTokens to make each link one-time only and good for no more than 24 hours. **Coupling of Email Verification and One-Time Login**: Currently, one-time login links ("password reset links") are tightly bound to an email address, and using a link verifies that email address. This is convenient for "Welcome" emails, so the user doesn't need to go through two rounds of checking email in order to login, then very their email, then actually get access to Phabricator. However, for other types of these links (like those generated by `bin/auth recover`) there's no need to do any email verification. Instead, make the email verification part optional, and use it on welcome links but not other types of links. **Message Customization**: These links can come out of several workflows: welcome, password reset, username change, or `bin/auth recover`. Add a hint to the URI so the text on the page can be customized a bit to help users through the workflow. **Reset Emails Going to Main Account Email**: Previously, we would send password reset email to the user's primary account email. However, since we verify email coming from reset links this isn't correct and could allow a user to verify an email without actually controlling it. Since the user needs a real account in the first place this does not seem useful on its own, but might be a component in some other attack. The user might also no longer have access to their primary account, in which case this wouldn't be wrong, but would not be very useful. Mitigate this in two ways: - First, send to the actual email address the user entered, not the primary account email address. - Second, don't let these links verify emails: they're just login links. This primarily makes it more difficult for an attacker to add someone else's email to their account, send them a reset link, get them to login and implicitly verify the email by not reading very carefully, and then figure out something interesting to do (there's currently no followup attack here, but allowing this does seem undesirable). **Password Reset Without Old Password**: After a user logs in via email, we send them to the password settings panel (if passwords are enabled) with a code that lets them set a new password without knowing the old one. Previously, this code was static and based on the email address. Instead, issue a one-time code. **Jump Into Hisec**: Normally, when a user who has multi-factor auth on their account logs in, we prompt them for factors but don't put them in high security. You usually don't want to go do high-security stuff immediately after login, and it would be confusing and annoying if normal logins gave you a "YOU ARE IN HIGH SECURITY" alert bubble. However, if we're taking you to the password reset screen, we //do// want to put the user in high security, since that screen requires high security. If we don't do this, the user gets two factor prompts in a row. To accomplish this, we set a cookie when we know we're sending the user into a high security workflow. This cookie makes login finalization upgrade all the way from "partial" to "high security", instead of stopping halfway at "normal". This is safe because the user has just passed a factor check; the only reason we don't normally do this is to reduce annoyance. **Some UI Cleanup**: Some of this was using really old UI. Modernize it a bit. Test Plan: - **One Time Resets** - Used a reset link. - Tried to reuse a reset link, got denied. - Verified each link is different. - **Coupling of Email Verification and One-Time Login** - Verified that `bin/auth`, password reset, and username change links do not have an email verifying URI component. - Tried to tack one on, got denied. - Used the welcome email link to login + verify. - Tried to mutate the URI to not verify, or verify something else: got denied. - **Message Customization** - Viewed messages on the different workflows. They seemed OK. - **Reset Emails Going to Main Account Email** - Sent password reset email to non-primary email. - Received email at specified address. - Verified it does not verify the address. - **Password Reset Without Old Password** - Reset password without knowledge of old one after email reset. - Tried to do that without a key, got denied. - Tried to reuse a key, got denied. - **Jump Into Hisec** - Logged in with MFA user, got factor'd, jumped directly into hisec. - Logged in with non-MFA user, no factors, normal password reset. - **Some UI Cleanup** - Viewed new UI. - **Misc** - Created accounts, logged in with welcome link, got verified. - Changed a username, used link to log back in. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D9252
2014-05-22 19:41:00 +02:00
'PhabricatorAuthOneTimeLoginController' => 'PhabricatorAuthController',
Modularize temporary token types Summary: Ref T10603. For LFS, we need to issue a new type of temporary token. This makes the temporary token code modular so applications can add new token types without modifying the Auth application. (I'm moving slowly here because it impacts authentication.) Test Plan: - Used `bin/auth recover` to get a one-time token from the CLI. - Used "Forgot your password?" to get a one-time token from the web UI. - Followed the web UI token to initiate a password reset, prompting generation of a password token. - Viewed these tokens in the web UI: {F1176908} - Revoked a token. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10603 Differential Revision: https://secure.phabricator.com/D15475
2016-03-16 13:17:41 +01:00
'PhabricatorAuthOneTimeLoginTemporaryTokenType' => 'PhabricatorAuthTemporaryTokenType',
'PhabricatorAuthPasswordResetTemporaryTokenType' => 'PhabricatorAuthTemporaryTokenType',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorAuthProvider' => 'Phobject',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorAuthProviderConfig' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorAuthDAO',
Transactions - deploy buildTransactionTimeline against a few more applications Summary: Ref T4712. Thus far, it seems that most "non-standard" things can be done pretty easily in the controller. Aside from deploying, this diff had to fix a few bugs / missing implementations of stuff. (Notably, PhabricatorAuthProviderConfig, HeraldRule, PhabricatorSlowvotePoll, and AlmanacNetwork needed to implement PhabricatorApplicationTransactionInterface, PhabricatorAuthAuthProviderPHIDType had to be added, and a rendering bug in transactions of type PhabricatorOAuth2AuthProvider had to be fixed.) Test Plan: Almanac - looked at binding, device, network, and service view controllers and verified timeline displayed properly. Herald - looked at a rule and verified timeline. Slowvote - looked at a vote and verified timeline. Auth - looked at an auth provider (Facebook) and verified proper display of transactions within timeline. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10921
2014-12-02 23:33:59 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
Add PhabricatorAuthProviderConfigQuery Summary: Ref T1536. See D6196. Code not called yet. Test Plan: Static checks only. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6197
2013-06-17 19:49:18 +02:00
),
Add List/ApplicationSearch to AuthProviderConfig Summary: Ref T1536. Adds a list controller and ApplicationSearch integration for listing providers. Test Plan: {F46308} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6198
2013-06-17 19:50:43 +02:00
'PhabricatorAuthProviderConfigController' => 'PhabricatorAuthController',
Very rough edit workflow for AuthProvider configuration Summary: Ref T1536. Many rough / broken edges, but adds the rough skeleton of the provider edit workflow. Test Plan: {F46333} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6200
2013-06-17 19:52:38 +02:00
'PhabricatorAuthProviderConfigEditor' => 'PhabricatorApplicationTransactionEditor',
Add PhabricatorAuthProviderConfigQuery Summary: Ref T1536. See D6196. Code not called yet. Test Plan: Static checks only. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6197
2013-06-17 19:49:18 +02:00
'PhabricatorAuthProviderConfigQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add storage for Auth configuration in preparation for moving it into a web interface Summary: Ref T1536. Currently, we have about 40 auth-related configuration options. This is already roughly 20% of our config, and we want to add more providers. Additionally, we want to turn some of these auth options into multi-auth options (e.g., allow multiple Phabricator OAuth installs, or, theoretically multiple LDAP servers). I'm going to move this into a separate "Auth" tool with a minimal CLI (`bin/auth`) interface and a more full web interface. Roughly: - Administrators will use the app to manage authentication providers. - The `bin/auth` CLI will provide a safety hatch if you lock yourself out by disabling all usable providers somehow. - We'll migrate existing configuration into the app and remove it. General goals: - Make it much easier to configure authentication by providing an interface for it. - Make it easier to configure everything else by reducing the total number of available options. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6196
2013-06-17 19:48:41 +02:00
'PhabricatorAuthProviderConfigTransaction' => 'PhabricatorApplicationTransaction',
Add PhabricatorAuthProviderConfigQuery Summary: Ref T1536. See D6196. Code not called yet. Test Plan: Static checks only. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6197
2013-06-17 19:49:18 +02:00
'PhabricatorAuthProviderConfigTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Add auth.querypublickeys to retrieve public keys Summary: Fixes T6484. I primarily need this to synchronize device public keys in the Phabricator cluster so the new stuff in T2783 works. Although, actually, maybe I don't really need it. But I wrote it anyway and it's desirable to have sooner or later. Test Plan: Ran method. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6484 Differential Revision: https://secure.phabricator.com/D11163
2015-02-11 00:44:21 +01:00
'PhabricatorAuthQueryPublicKeysConduitAPIMethod' => 'PhabricatorAuthConduitAPIMethod',
New Registration Workflow Summary: Currently, registration and authentication are pretty messy. Two concrete problems: - The `PhabricatorLDAPRegistrationController` and `PhabricatorOAuthDefaultRegistrationController` controllers are giant copy/pastes of one another. This is really bad. - We can't practically implement OpenID because we can't reissue the authentication request. Additionally, the OAuth registration controller can be replaced wholesale by config, which is a huge API surface area and a giant mess. Broadly, the problem right now is that registration does too much: we hand it some set of indirect credentials (like OAuth tokens) and expect it to take those the entire way to a registered user. Instead, break registration into smaller steps: - User authenticates with remote service. - Phabricator pulls information (remote account ID, username, email, real name, profile picture, etc) from the remote service and saves it as `PhabricatorUserCredentials`. - Phabricator hands the `PhabricatorUserCredentials` to the registration form, which is agnostic about where they originate from: it can process LDAP credentials, OAuth credentials, plain old email credentials, HTTP basic auth credentials, etc. This doesn't do anything yet -- there is no way to create credentials objects (and no storage patch), but I wanted to get any initial feedback, especially about the event call for T2394. In particular, I think the implementation would look something like this: $profile = $event->getValue('profile') $username = $profile->getDefaultUsername(); $is_employee = is_this_a_facebook_employee($username); if (!$is_employee) { throw new Exception("You are not employed at Facebook."); } $fbid = get_fbid_for_facebook_username($username); $profile->setDefaultEmail($fbid); $profile->setCanEditUsername(false); $profile->setCanEditEmail(false); $profile->setCanEditRealName(false); $profile->setShouldVerifyEmail(true); Seem reasonable? Test Plan: N/A yet, probably fatals. Reviewers: vrana, btrahan, codeblock, chad Reviewed By: btrahan CC: aran, asherkin, nh, wez Maniphest Tasks: T1536, T2394 Differential Revision: https://secure.phabricator.com/D4647
2013-06-16 19:13:49 +02:00
'PhabricatorAuthRegisterController' => 'PhabricatorAuthController',
Add an explicit temporary token management page to Settings Summary: Ref T5506. This makes it easier to understand and manage temporary tokens. Eventually this could be more user-friendly, since it's relatively difficult to understand what this screen means. My short-term goal is just to make the next change easier to implement and test. The next diff will close a small security weakness: if you change your email address, password reset links which were sent to the old address are still valid. Although an attacker would need substantial access to exploit this (essentially, it would just make it easier for them to re-compromise an already compromised account), it's a bit surprising. In the next diff, email address changes will invalidate outstanding password reset links. Test Plan: - Viewed outstanding tokens. - Added tokens to the list by making "Forgot your password?" requests. - Revoked tokens individually. - Revoked all tokens. - Tried to use a revoked token. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5506 Differential Revision: https://secure.phabricator.com/D10133
2014-08-04 21:04:13 +02:00
'PhabricatorAuthRevokeTokenController' => 'PhabricatorAuthController',
Move SSHKey table to Auth database Summary: Ref T5833. Since these will no longer be bound specifically to users, bring them to a more central location. Test Plan: - Edited SSH keys. - Ran `bin/ssh-auth` and `bin/ssh-auth-key`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10791
2014-11-06 21:37:22 +01:00
'PhabricatorAuthSSHKey' => array(
'PhabricatorAuthDAO',
'PhabricatorPolicyInterface',
Provide a more straightforward way to revoke SSH keys by finding and destroying the objects Summary: Ref T9967 Test Plan: Ran migrations. Verified database populated properly with PHIDs (SELECT * FROM auth_sshkey;). Ran auth.querypublickeys conduit method to see phids show up Ran bin/remove destroy <phid>. Viewed the test key was gone. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Maniphest Tasks: T9967 Differential Revision: https://secure.phabricator.com/D14823
2015-12-19 20:48:24 +01:00
'PhabricatorDestructibleInterface',
Move SSHKey table to Auth database Summary: Ref T5833. Since these will no longer be bound specifically to users, bring them to a more central location. Test Plan: - Edited SSH keys. - Ran `bin/ssh-auth` and `bin/ssh-auth-key`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10791
2014-11-06 21:37:22 +01:00
),
Separate SSH key management from the settings panel Summary: Ref T5833. I want to add SSH keys to Almanac devices, but the edit workflows for them are currently bound tightly to users. Instead, decouple key management from users and the settings panel. Test Plan: - Uploaded, generated, edited and deleted SSH keys. - Hit missing name, missing key, bad key format, duplicate key errors. - Edited/generated/deleted/etc keys for a bot user as an administrator. - Got HiSec'd on everything. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10824
2014-11-11 17:18:26 +01:00
'PhabricatorAuthSSHKeyController' => 'PhabricatorAuthController',
'PhabricatorAuthSSHKeyDeleteController' => 'PhabricatorAuthSSHKeyController',
'PhabricatorAuthSSHKeyEditController' => 'PhabricatorAuthSSHKeyController',
'PhabricatorAuthSSHKeyGenerateController' => 'PhabricatorAuthSSHKeyController',
Update library map.
2015-12-19 20:55:59 +01:00
'PhabricatorAuthSSHKeyPHIDType' => 'PhabricatorPHIDType',
Add a query/policy layer on top of SSH keys for Almanac Summary: Ref T5833. Currently, SSH keys are associated only with users, and are a bit un-modern. I want to let Almanac Devices have SSH keys so devices in a cluster can identify to one another. For example, with hosted installs, initialization will go something like this: - A request comes in for `company.phacility.com`. - A SiteSource (from D10787) makes a Conduit call to Almanac on the master install to check if `company` is a valid install and pull config if it is. - This call can be signed with an SSH key which identifies a trusted Almanac Device. In the cluster case, a web host can make an authenticated call to a repository host with similar key signing. To move toward this, put a proper Query class on top of SSH key access (this diff). In following diffs, I'll: - Rename `userPHID` to `objectPHID`. - Move this to the `auth` database. - Provide UI for device/key association. An alternative approach would be to build some kind of special token layer in Conduit, but I think that would be a lot harder to manage in the hosting case. This gives us a more direct attack on trusting requests from machines and recognizing machines as first (well, sort of second-class) actors without needing things like fake user accounts. Test Plan: - Added and removed SSH keys. - Added and removed SSH keys from a bot account. - Tried to edit an unonwned SSH key (denied). - Ran `bin/ssh-auth`, got sensible output. - Ran `bin/ssh-auth-key`, got sensible output. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10790
2014-11-06 21:37:02 +01:00
'PhabricatorAuthSSHKeyQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Allow Almanac devices to have SSH keys Summary: Ref T5833. Expose a key management interface for Almanac devices. Test Plan: {F231962} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10825
2014-11-11 17:20:08 +01:00
'PhabricatorAuthSSHKeyTableView' => 'AphrontView',
Add a query/policy layer on top of SSH keys for Almanac Summary: Ref T5833. Currently, SSH keys are associated only with users, and are a bit un-modern. I want to let Almanac Devices have SSH keys so devices in a cluster can identify to one another. For example, with hosted installs, initialization will go something like this: - A request comes in for `company.phacility.com`. - A SiteSource (from D10787) makes a Conduit call to Almanac on the master install to check if `company` is a valid install and pull config if it is. - This call can be signed with an SSH key which identifies a trusted Almanac Device. In the cluster case, a web host can make an authenticated call to a repository host with similar key signing. To move toward this, put a proper Query class on top of SSH key access (this diff). In following diffs, I'll: - Rename `userPHID` to `objectPHID`. - Move this to the `auth` database. - Provide UI for device/key association. An alternative approach would be to build some kind of special token layer in Conduit, but I think that would be a lot harder to manage in the hosting case. This gives us a more direct attack on trusting requests from machines and recognizing machines as first (well, sort of second-class) actors without needing things like fake user accounts. Test Plan: - Added and removed SSH keys. - Added and removed SSH keys from a bot account. - Tried to edit an unonwned SSH key (denied). - Ran `bin/ssh-auth`, got sensible output. - Ran `bin/ssh-auth-key`, got sensible output. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10790
2014-11-06 21:37:02 +01:00
'PhabricatorAuthSSHPublicKey' => 'Phobject',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorAuthSession' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorAuthDAO',
'PhabricatorPolicyInterface',
Add an "active login sessions" table to Settings Summary: Ref T4310. Ref T3720. Partly, this makes it easier for users to understand login sessions. Partly, it makes it easier for me to make changes to login sessions for T4310 / T3720 without messing anything up. Test Plan: {F101512} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3720, T4310 Differential Revision: https://secure.phabricator.com/D7954
2014-01-14 20:05:45 +01:00
),
Separate session management from PhabricatorUser Summary: Ref T4310. Ref T3720. Session operations are currently part of PhabricatorUser. This is more tightly coupled than needbe, and makes it difficult to establish login sessions for non-users. Move all the session management code to a `SessionEngine`. Test Plan: - Viewed sessions. - Regenerated Conduit certificate. - Verified Conduit sessions were destroyed. - Logged out. - Logged in. - Ran conduit commands. - Viewed sessions again. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4310, T3720 Differential Revision: https://secure.phabricator.com/D7962
2014-01-14 22:22:27 +01:00
'PhabricatorAuthSessionEngine' => 'Phobject',
Add a session engine extension point Summary: Ref T7673. This is really just so I can force admin.phacility.com logout when you log out of an instance, but there are a few other things we could move here eventually, like the WILLREGISTERUSER event. Test Plan: Logged out of an instance, got logged out of parent (see next change). Reviewers: chad Reviewed By: chad Maniphest Tasks: T7673 Differential Revision: https://secure.phabricator.com/D15629
2016-04-03 19:04:10 +02:00
'PhabricatorAuthSessionEngineExtension' => 'Phobject',
'PhabricatorAuthSessionEngineExtensionModule' => 'PhabricatorConfigModule',
Expire and garbage collect unused sessions Summary: Ref T3720. Ref T4310. Currently, we limit the maximum number of concurrent sessions of each type. This is primarily because sessions predate garbage collection and we had no way to prevent the session table from growing fairly quickly and without bound unless we did this. Now that we have GC (and it's modular!) we can just expire unused sessions after a while and throw them away: - Add a `sessionExpires` column to the table, with a key. - Add a GC for old sessions. - When we establish a session, set `sessionExpires` to the current time plus the session TTL. - When a user uses a session and has used up more than 20% of the time on it, extend the session. In addition to this, we could also rotate sessions, but I think that provides very little value. If we do want to implement it, we should hold it until after T3720 / T4310. Test Plan: - Ran schema changes. - Looked at database. - Tested GC: - Started GC. - Set expires on one row to the past. - Restarted GC. - Verified GC nuked the session. - Logged in. - Logged out. - Ran Conduit method. - Tested refresh: - Set threshold to 0.0001% instead of 20%. - Loaded page. - Saw a session extension ever few page loads. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4310, T3720 Differential Revision: https://secure.phabricator.com/D7976
2014-01-15 22:56:16 +01:00
'PhabricatorAuthSessionGarbageCollector' => 'PhabricatorGarbageCollector',
Add an "active login sessions" table to Settings Summary: Ref T4310. Ref T3720. Partly, this makes it easier for users to understand login sessions. Partly, it makes it easier for me to make changes to login sessions for T4310 / T3720 without messing anything up. Test Plan: {F101512} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3720, T4310 Differential Revision: https://secure.phabricator.com/D7954
2014-01-14 20:05:45 +01:00
'PhabricatorAuthSessionQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorAuthSetupCheck' => 'PhabricatorSetupCheck',
Provide start screen and full registration flow on the new auth stuff Summary: Ref T1536. Code is intentionally made unreachable (see PhabricatorAuthProviderOAuthFacebook->isEnabled()). This adds: - A provider-driven "start" screen (this has the list of ways you can login/register). - Registration actually works. - Facebook OAuth works. @chad, do you have any design ideas on the start screen? I think we poked at it before, but the big issue was that there were a limitless number of providers. Today, we have: - Password - LDAP - Facebook - GitHub - Phabricator - Disqus - Google We plan to add: - Asana - An arbitrary number of additional instances of Phabricator Users want to add: - OpenID - Custom providers And I'd like to have these at some point: - Stripe - WePay - Amazon - Bitbucket So basically any UI for this has to accommodate 300 zillion auth options. I don't think we need to solve any UX problems here (realistically, installs enable 1-2 auth options and users don't actually face an overwhelming number of choices) but making the login forms less ugly would be nice. No combination of prebuilt elements seems to look very good for this use case. Test Plan: Registered a new acount with Facebook. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6161
2013-06-16 19:15:16 +02:00
'PhabricatorAuthStartController' => 'PhabricatorAuthController',
Formally modularize MFA/TOTP tokens, provide a module panel for temporary tokens Summary: Ref T10603. We have a couple of sort of ad-hoc tokens, so start formalizing them. First up is MFA tokens. Also adds a new config module panel for these. Test Plan: - Added MFA. - Added MFA, intentionally fumbled the input, completed the workflow. - Removed MFA. - Viewed tokens, saw MFA sync tokens. - Viewed new module config panel. {F1177014} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10603 Differential Revision: https://secure.phabricator.com/D15479
2016-03-16 14:17:31 +01:00
'PhabricatorAuthTOTPKeyTemporaryTokenType' => 'PhabricatorAuthTemporaryTokenType',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorAuthTemporaryToken' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorAuthDAO',
'PhabricatorPolicyInterface',
Add "temporary tokens" to auth, for SMS codes, TOTP codes, reset codes, etc Summary: Ref T4398. We have several auth-related systems which require (or are improved by) the ability to hand out one-time codes which expire after a short period of time. In particular, these are: - SMS multi-factor: we need to be able to hand out one-time codes for this in order to prove the user has the phone. - Password reset emails: we use a time-based rotating token right now, but we could improve this with a one-time token, so once you reset your password the link is dead. - TOTP auth: we don't need to verify/invalidate keys, but can improve security by doing so. This adds a generic one-time code storage table, and strengthens the TOTP enrollment process by using it. Specifically, you can no longer edit the enrollment form (the one with a QR code) to force your own key as the TOTP key: only keys Phabricator generated are accepted. This has no practical security impact, but generally helps raise the barrier potential attackers face. Followup changes will use this for reset emails, then implement SMS multi-factor. Test Plan: - Enrolled in TOTP multi-factor auth. - Submitted an error in the form, saw the same key presented. - Edited the form with web tools to provide a different key, saw it reject and the server generate an alternate. - Change the expiration to 5 seconds instead of 1 hour, submitted the form over and over again, saw it cycle the key after 5 seconds. - Looked at the database and saw the tokens I expected. - Ran the GC and saw all the 5-second expiry tokens get cleaned up. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D9217
2014-05-20 20:43:45 +02:00
),
'PhabricatorAuthTemporaryTokenGarbageCollector' => 'PhabricatorGarbageCollector',
'PhabricatorAuthTemporaryTokenQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Modularize temporary token types Summary: Ref T10603. For LFS, we need to issue a new type of temporary token. This makes the temporary token code modular so applications can add new token types without modifying the Auth application. (I'm moving slowly here because it impacts authentication.) Test Plan: - Used `bin/auth recover` to get a one-time token from the CLI. - Used "Forgot your password?" to get a one-time token from the web UI. - Followed the web UI token to initiate a password reset, prompting generation of a password token. - Viewed these tokens in the web UI: {F1176908} - Revoked a token. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10603 Differential Revision: https://secure.phabricator.com/D15475
2016-03-16 13:17:41 +01:00
'PhabricatorAuthTemporaryTokenType' => 'Phobject',
Formally modularize MFA/TOTP tokens, provide a module panel for temporary tokens Summary: Ref T10603. We have a couple of sort of ad-hoc tokens, so start formalizing them. First up is MFA tokens. Also adds a new config module panel for these. Test Plan: - Added MFA. - Added MFA, intentionally fumbled the input, completed the workflow. - Removed MFA. - Viewed tokens, saw MFA sync tokens. - Viewed new module config panel. {F1177014} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10603 Differential Revision: https://secure.phabricator.com/D15479
2016-03-16 14:17:31 +01:00
'PhabricatorAuthTemporaryTokenTypeModule' => 'PhabricatorConfigModule',
Allow users to terminate login sessions Summary: This is partly a good feature, and partly should reduce false positives on HackerOne reporting things vaguely related to this. Allow a user to terminate login sessions from the settings panel. Test Plan: - Terminated a session. - Terminated all sessions. - Tried to terminate all sessions again. - Logged in with two browsers, terminated the other browser's session, reloaded, got kicked out. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8556
2014-03-17 23:02:01 +01:00
'PhabricatorAuthTerminateSessionController' => 'PhabricatorAuthController',
Rate limit multi-factor actions Summary: Ref T4398. Prevent users from brute forcing multi-factor auth by rate limiting attempts. This slightly refines the rate limiting to allow callers to check for a rate limit without adding points, and gives users credit for successfully completing an auth workflow. Test Plan: Tried to enter hisec with bad credentials 11 times in a row, got rate limited. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8911
2014-04-30 23:30:31 +02:00
'PhabricatorAuthTryFactorAction' => 'PhabricatorSystemAction',
Move all account link / unlink to new registration flow Summary: Ref T1536. Currently, we have separate panels for each link/unlink and separate controllers for OAuth vs LDAP. Instead, provide a single "External Accounts" panel which shows all linked accounts and allows you to link/unlink more easily. Move link/unlink over to a full externalaccount-based workflow. Test Plan: - Linked and unlinked OAuth accounts. - Linked and unlinked LDAP accounts. - Registered new accounts. - Exercised most/all of the error cases. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6189
2013-06-17 15:12:45 +02:00
'PhabricatorAuthUnlinkController' => 'PhabricatorAuthController',
Implement new auth login flow and login validation controller Summary: Ref T1536. None of this code is reachable. Implements new-auth login (so you can actually login) and login validation (which checks that cookies were set correctly). Test Plan: Manually enabled FB auth, went through the auth flow to login/logout. Manually hit most of the validation errors. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6162
2013-06-16 19:15:33 +02:00
'PhabricatorAuthValidateController' => 'PhabricatorAuthController',
First go at Authentication config options. Test Plan: Looked at them in the web UI. Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4355
2013-01-07 21:48:39 +01:00
'PhabricatorAuthenticationConfigOptions' => 'PhabricatorApplicationConfigOptions',
Make it much easier to add one-off event listeners Summary: Ref T4657. Right now, you have to muck with `events.listeners` to install listeners. Instead, automatically install all subclasses of AutoEventListener. Primarily, this makes it easier to resolve requests with "drop this file in `src/extensions/`, no warranty", which seems to have worked well so far in resolving things like custom remarkup rules, etc. Test Plan: - Added such a listener, had it autoregister. - Clicked around and saw the effects of normal listeners. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4657 Differential Revision: https://secure.phabricator.com/D9262
2014-05-23 00:19:28 +02:00
'PhabricatorAutoEventListener' => 'PhabricatorEventListener',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgeHasRecipientEdgeType' => 'PhabricatorEdgeType',
'PhabricatorBadgesApplication' => 'PhabricatorApplication',
Add PhabricatorBadgeArchiveController Summary: Allows archive and activate on badges from action list. Ref T9414 Test Plan: Archive, Activate, New, Edit Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9414 Differential Revision: https://secure.phabricator.com/D14727
2015-12-09 22:26:26 +01:00
'PhabricatorBadgesArchiveController' => 'PhabricatorBadgesController',
Converting badge recipients from Edge to BadgeAward table Summary: Ref T8996, Convert badge recipients from Edges to actual BadgeAward objects Test Plan: Create badge, award it to recipient. Make sure adding/removing recipients works. (Still need to migrate exisiting recipients to new table and need to create activity feed blurbs) Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: chad, Korvin Maniphest Tasks: T8996 Differential Revision: https://secure.phabricator.com/D15014
2016-01-13 20:33:46 +01:00
'PhabricatorBadgesAward' => array(
'PhabricatorBadgesDAO',
'PhabricatorDestructibleInterface',
'PhabricatorPolicyInterface',
),
Allow awarding Badges from the profile Summary: [WIP] Allows awarding a badge from a user profile. Unsure of the interactions here if a user can't award any badges, or if we should just hide this. Fixes T10688 Fixes T10318 Test Plan: Award some badges. Steal them back. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T10318, T10688 Differential Revision: https://secure.phabricator.com/D15544
2016-03-31 22:39:06 +02:00
'PhabricatorBadgesAwardController' => 'PhabricatorBadgesController',
Converting badge recipients from Edge to BadgeAward table Summary: Ref T8996, Convert badge recipients from Edges to actual BadgeAward objects Test Plan: Create badge, award it to recipient. Make sure adding/removing recipients works. (Still need to migrate exisiting recipients to new table and need to create activity feed blurbs) Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: chad, Korvin Maniphest Tasks: T8996 Differential Revision: https://secure.phabricator.com/D15014
2016-01-13 20:33:46 +01:00
'PhabricatorBadgesAwardQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesBadge' => array(
'PhabricatorBadgesDAO',
'PhabricatorPolicyInterface',
'PhabricatorApplicationTransactionInterface',
'PhabricatorSubscribableInterface',
Allow Tokens on Badge Summary: Might as well for consistency. Test Plan: Given a token to a badge. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13716
2015-07-28 16:57:15 +02:00
'PhabricatorTokenReceiverInterface',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorFlaggableInterface',
'PhabricatorDestructibleInterface',
Add `badges.edit` and `badges.search` to Conduit API Summary: Ref T10671 Test Plan: Open Conduit application, open `badges.edit` or `badges.search`, create, edit, or query for a badge. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T10671 Differential Revision: https://secure.phabricator.com/D15622
2016-04-05 20:21:44 +02:00
'PhabricatorConduitResultInterface',
Make badges searchable by name Summary: Closes T10690 Test Plan: Open Badges application, go to Advanced Search, search for a badge by its name and see result. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Maniphest Tasks: T10690 Differential Revision: https://secure.phabricator.com/D15656
2016-04-07 21:12:34 +02:00
'PhabricatorNgramsInterface',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
),
Make badges searchable by name Summary: Closes T10690 Test Plan: Open Badges application, go to Advanced Search, search for a badge by its name and see result. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Maniphest Tasks: T10690 Differential Revision: https://secure.phabricator.com/D15656
2016-04-07 21:12:34 +02:00
'PhabricatorBadgesBadgeNameNgrams' => 'PhabricatorSearchNgrams',
Add commenting to Badges Summary: Fixes T8949. Adds the ability to render honors on those who have fought and received badges of distinction and honor. Test Plan: Write 'asdf'. See 'asdf'. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T8949 Differential Revision: https://secure.phabricator.com/D13704
2015-07-24 19:56:08 +02:00
'PhabricatorBadgesCommentController' => 'PhabricatorBadgesController',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesController' => 'PhabricatorController',
'PhabricatorBadgesCreateCapability' => 'PhabricatorPolicyCapability',
'PhabricatorBadgesDAO' => 'PhabricatorLiskDAO',
First stab at a badges typeahead Summary: Ref T10702 Test Plan: Open a user profile, attempt to award an archived or previously awarded badge, badges dialog should provide a typeahead, and the suggestions should offer details about whether a badge is archived or already awarded. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T10702 Differential Revision: https://secure.phabricator.com/D15665
2016-04-09 20:40:02 +02:00
'PhabricatorBadgesDatasource' => 'PhabricatorTypeaheadDatasource',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesDefaultEditCapability' => 'PhabricatorPolicyCapability',
Add `badges.edit` and `badges.search` to Conduit API Summary: Ref T10671 Test Plan: Open Conduit application, open `badges.edit` or `badges.search`, create, edit, or query for a badge. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T10671 Differential Revision: https://secure.phabricator.com/D15622
2016-04-05 20:21:44 +02:00
'PhabricatorBadgesEditConduitAPIMethod' => 'PhabricatorEditEngineAPIMethod',
Fix badges edit form Summary: Make sure to subclass the right controller on badges. Test Plan: arc liberate, make a custom badges edit form. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14961
2016-01-06 22:13:52 +01:00
'PhabricatorBadgesEditController' => 'PhabricatorBadgesController',
Convert Badges to use EditEngine Summary: Moves Badges over to EditEngine Test Plan: Create a new Badge, Edit a Badge Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14771
2016-01-01 17:12:13 +01:00
'PhabricatorBadgesEditEngine' => 'PhabricatorEditEngine',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesEditRecipientsController' => 'PhabricatorBadgesController',
'PhabricatorBadgesEditor' => 'PhabricatorApplicationTransactionEditor',
Provide a "PHUIFormIconSetControl" Summary: Ref T9992. This is a step on the path to getting EditEngine working in Badges, Projects and Calendar. This doesn't add a new `EditField` for icons yet, just standardizes the old stuff. New stuff is more general and I saved 150 lines of code. I put the endpoint in Files because the similar "choose a profile picture" endpoint will definitely go there, and this endpoint might eventually feature, like, "draw your own icon~~" or something. Test Plan: - Created events, projects and badges with custom icons. - Edited events, projects and badges, changing their icons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9992 Differential Revision: https://secure.phabricator.com/D14799
2015-12-16 16:53:13 +01:00
'PhabricatorBadgesIconSet' => 'PhabricatorIconSet',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesListController' => 'PhabricatorBadgesController',
Add MAILTAGs to Badges Summary: Still doesn't mail yet, but the settings now show up. Test Plan: View email settings, see Badges options. Reviewers: eadler, epriestley Reviewed By: eadler, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13712
2015-07-25 22:34:43 +02:00
'PhabricatorBadgesMailReceiver' => 'PhabricatorObjectMailReceiver',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesPHIDType' => 'PhabricatorPHIDType',
Converting badge quality property from color to an integer representation for later sorting purposes Summary: Ref T9007 Test Plan: Create badges, update quality, search by quality without change of functionality. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T9007 Differential Revision: https://secure.phabricator.com/D15551
2016-03-31 02:07:27 +02:00
'PhabricatorBadgesQuality' => 'Phobject',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Update Badges for PHUITwoColumnView Summary: Updates the layout to two column, moves "Add Receipients" to dialog. Ref T10318 Test Plan: Give badges, revoke badges. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T10318 Differential Revision: https://secure.phabricator.com/D15382
2016-03-02 20:05:26 +01:00
'PhabricatorBadgesRecipientsListView' => 'AphrontView',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesRemoveRecipientsController' => 'PhabricatorBadgesController',
Add MAILTAGs to Badges Summary: Still doesn't mail yet, but the settings now show up. Test Plan: View email settings, see Badges options. Reviewers: eadler, epriestley Reviewed By: eadler, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13712
2015-07-25 22:34:43 +02:00
'PhabricatorBadgesReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Add `badges.edit` and `badges.search` to Conduit API Summary: Ref T10671 Test Plan: Open Conduit application, open `badges.edit` or `badges.search`, create, edit, or query for a badge. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T10671 Differential Revision: https://secure.phabricator.com/D15622
2016-04-05 20:21:44 +02:00
'PhabricatorBadgesSearchConduitAPIMethod' => 'PhabricatorSearchEngineAPIMethod',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesSearchEngine' => 'PhabricatorApplicationSearchEngine',
'PhabricatorBadgesTransaction' => 'PhabricatorApplicationTransaction',
Add commenting to Badges Summary: Fixes T8949. Adds the ability to render honors on those who have fought and received badges of distinction and honor. Test Plan: Write 'asdf'. See 'asdf'. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T8949 Differential Revision: https://secure.phabricator.com/D13704
2015-07-24 19:56:08 +02:00
'PhabricatorBadgesTransactionComment' => 'PhabricatorApplicationTransactionComment',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorBadgesTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'PhabricatorBadgesViewController' => 'PhabricatorBadgesController',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorBarePageUIExample' => 'PhabricatorUIExample',
Separate "PhabricatorBarePageView" out of "PhabricatorStandardPageView" Summary: For Phame, we really want more than a chromeless page -- it shouldn't have Javelin or Phabricator styles on it. Pull the bare infrastructure out of StandardPageView and make it available as BarePageView. Test Plan: Viewed bare page in UIExamples, various non-bare pages. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3711
2012-10-16 19:33:47 +02:00
'PhabricatorBarePageView' => 'AphrontPageView',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorBaseURISetupCheck' => 'PhabricatorSetupCheck',
Implement bcrypt hasher, transparent login upgrade, and explicit upgrade for passwords Summary: Ref T4443. - Add a `password_hash()`-based bcrypt hasher if `password_hash()` is available. - When a user logs in using a password, upgrade their password to the strongest available hash format. - On the password settings page: - Warn the user if their password uses any algorithm other than the strongest one. - Show the algorithm the password uses. - Show the best available algorithm. Test Plan: As an md5 user, viewed password settings page and saw a warning. Logged out. Logged in, got upgraded, no more warning. Changed password, verified database rehash. Logged out, logged in. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4443 Differential Revision: https://secure.phabricator.com/D8270
2014-02-18 20:03:56 +01:00
'PhabricatorBcryptPasswordHasher' => 'PhabricatorPasswordHasher',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorBinariesSetupCheck' => 'PhabricatorSetupCheck',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorBitbucketAuthProvider' => 'PhabricatorOAuth1AuthProvider',
Begin lifting column layout logic out of ColumnPositionQuery Summary: Ref T10010. This is a precursor to D15171, which I'll eventually rebuild on top of these changes. Currently, ColumnPositionQuery does a lot of "column layout" stuff that's very similar to the Milestone/Subproject stuff that needs to happen in D15171. The current approach there ended up splitting this layout stuff across two unrelated classes (ColumnPositionQuery + BoardViewController), neither of which is a particularly great place to do it -- the Query is too low-level, and the Controller is too high-level. Instead, introduce a new "LayoutEngine" which does all this layout stuff. Swap two of the four places that we query this stuff over to the new engine: - "Project (Column)" on tasks. - Transaction generation when moving cards. These sites aren't swapped by this diff, but will be by the next one: - Actually applying transactions. - Main layout for boards (this could swap easily now, but applying transactions currently relies on position writes having taken place, so it can't swap until the other one swaps). Once everything is swapped over, I should be able to add the D15171 logic to LayoutEngine instead of BoardViewController and end up with a cleaner approach overall. One particularly benefit is that //looking// at a board won't do a bunch of position writes anymore, which wasn't a big deal, but which I was a bit uneasy with. Test Plan: - Viewed tasks that are on boards, saw column annotations in project list. - Moved cards between columns on a board. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D15174
2016-02-03 18:39:17 +01:00
'PhabricatorBoardLayoutEngine' => 'Phobject',
Add storage and read logic for workboard card cover photos Summary: No way to set photos yet, but if you magic them in they work. Primarily, this consolidates rendering logic so the move + edit + view controllers all run the same code to do tags / cover photos. Test Plan: {F1095870} Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15201
2016-02-06 22:02:13 +01:00
'PhabricatorBoardRenderingEngine' => 'Phobject',
Rewrite workboards to have way more bugs Summary: Ref T4900. Briefly: - Much more layout and rendering is now done in Javascript. - This should otherwise be identical to the behavior at HEAD, except that: - editing a task and removing the current board from it no longer removes the task; and - points still don't work. However, this can now plausibly support realtime workboard updates and other complex state-based behaviors like points calculations in a future change. Test Plan: - Changed card covers. - Moved cards. - Sorted board by priority and natural. - Added new cards. - Edited cards in place. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4900 Differential Revision: https://secure.phabricator.com/D15234
2016-02-10 14:59:46 +01:00
'PhabricatorBoardResponseEngine' => 'Phobject',
Port "Allow Dangerous Changes" to new Manage UI Summary: Ref T10748. Brings this forward in the UI and EditEngine. Test Plan: - Edited via Conduit. - Viewed via Manage UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15805
2016-04-27 01:02:57 +02:00
'PhabricatorBoolEditField' => 'PhabricatorEditField',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorBot' => 'PhabricatorDaemon',
Formalize targets (users and channel) into objects Summary: Make users/channels/rooms into objects, so we can later sort out stuff like Campfire user IDs, Phabricator vs chat accounts, etc. The only change here is that I removed output buffering from the macro handler. We should move throttling/buffering to adapters instead and have it apply globally. Test Plan: Ran IRC and Campfire bots and interacted with them. Reviewers: indiefan Reviewed By: indiefan CC: aran Differential Revision: https://secure.phabricator.com/D4924
2013-02-14 14:13:38 +01:00
'PhabricatorBotChannel' => 'PhabricatorBotTarget',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorBotDebugLogHandler' => 'PhabricatorBotHandler',
'PhabricatorBotFeedNotificationHandler' => 'PhabricatorBotHandler',
Rename protocol adapter classes Summary: Ref T5655. Rename protocol adapter classes to remove `Base` from the class name. Test Plan: Unit tests still pass. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D12563
2015-05-18 00:20:11 +02:00
'PhabricatorBotFlowdockProtocolAdapter' => 'PhabricatorStreamingProtocolAdapter',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorBotHandler' => 'Phobject',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorBotLogHandler' => 'PhabricatorBotHandler',
'PhabricatorBotMacroHandler' => 'PhabricatorBotHandler',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorBotMessage' => 'Phobject',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorBotObjectNameHandler' => 'PhabricatorBotHandler',
'PhabricatorBotSymbolHandler' => 'PhabricatorBotHandler',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorBotTarget' => 'Phobject',
Formalize targets (users and channel) into objects Summary: Make users/channels/rooms into objects, so we can later sort out stuff like Campfire user IDs, Phabricator vs chat accounts, etc. The only change here is that I removed output buffering from the macro handler. We should move throttling/buffering to adapters instead and have it apply globally. Test Plan: Ran IRC and Campfire bots and interacted with them. Reviewers: indiefan Reviewed By: indiefan CC: aran Differential Revision: https://secure.phabricator.com/D4924
2013-02-14 14:13:38 +01:00
'PhabricatorBotUser' => 'PhabricatorBotTarget',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorBotWhatsNewHandler' => 'PhabricatorBotHandler',
Update Phabricator to work with more modular translations Summary: Ref T7152. Ref T1139. This updates Phabricator so third-party libraries can translate their own stuff. Also: - Hide "All Caps" when not in development mode, since some users have found this a little confusing. - With other changes, adds a "Raw Strings" mode (development mode only). - Add an example silly translation to make sure the serious business flag works. - Add a basic British English translation. - Simplify handling of translation overrides. Test Plan: - Flipped serious business / development on and off and saw silly/development translations drop off. - Switched to "All Caps" and saw all caps. - Switched to Very English, Wow! - Switched to British english and saw "colour". Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152, T1139 Differential Revision: https://secure.phabricator.com/D11747
2015-02-11 22:02:35 +01:00
'PhabricatorBritishEnglishTranslation' => 'PhutilTranslation',
Make SQL patch management DAG-based and provide namespace support Summary: This addresses three issues with the current patch management system: # Two people developing at the same time often pick the same SQL patch number, and then have to go rename it. The system catches this, but it's silly. # Second/third-party developers can't use the same system to manage auxiliary storage they may want to add. # There's no way to build mock databases for unit tests that need to do reads. To resolve these things, you can now name your patches whatever you want and conflicts are just merge conflicts, which are less of a pain to fix than filename conflicts. Dependencies are now a DAG, with implicit dependencies created on the prior patch if no dependencies are specified. Developers can add new concrete subclasses of `PhabricatorSQLPatchList` to add storage management, and define the dependency branchpoint of their patches so they apply in the correct order (although, generally, they should not depend on the mainline patches, presumably). The commands `storage upgrade --namespace test1234` and `storage destroy --namespace test1234` will allow unit tests to build and destroy MySQL storage. A "quickstart" mode allows an upgrade from scratch in ~1200ms. Destruction takes about 200ms. These seem like fairily reasonable costs to actually use in tests. Building from scratch patch-by-patch takes about 6000ms. Test Plan: - Created new databases from scratch with and without quickstart in a separate test namespace. Pointed the webapp at the test namespaces, browsed around, everything looked good. - Compared quickstart and no-quickstart dump states, they're identical except for mysqldump timestamps and a few similar things. - Upgraded a legacy database to the new storage format. - Destroyed / dumped storage. Reviewers: edward, vrana, btrahan, jungejason Reviewed By: btrahan CC: aran, nh Maniphest Tasks: T140, T345 Differential Revision: https://secure.phabricator.com/D2323
2012-04-30 16:54:00 +02:00
'PhabricatorBuiltinPatchList' => 'PhabricatorSQLPatchList',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorBulkContentSource' => 'PhabricatorContentSource',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorBusyUIExample' => 'PhabricatorUIExample',
Add a generic multistep Markup cache Summary: The immediate issue this addresses is T1366, adding a rendering cache to Phriction. For wiki pages with code blocks especially, rerendering them each time is expensive. The broader issue is that out markup caches aren't very good right now. They have three major problems: **Problem 1: the data is stored in the wrong place.** We currently store remarkup caches on objects. This means we're always loading it and passing it around even when we don't need it, can't genericize cache management code (e.g., have one simple script to drop/GC caches), need to update authoritative rows to clear caches, and can't genericize rendering code since each object is different. To solve this, I created a dedicated cache database that I plan to move all markup caches to use. **Problem 2: time-variant rules break when cached.** Some rules like `**bold**` are time-invariant and always produce the same output, but some rules like `{Tnnn}` and `@username` are variant and may render differently (because a task was closed or a user is on vacation). Currently, we cache the raw output, so these time-variant rules get locked at whatever values they had when they were first rendered. This is the main reason Phriction doesn't have a cache right now -- I wanted `{Tnnn}` rules to reflect open/closed tasks. To solve this, I split markup into a "preprocessing" phase (which does all the parsing and evaluates all time-invariant rules) and a "postprocessing" phase (which evaluates time-variant rules only). The preprocessing phase is most of the expense (and, notably, includes syntax highlighting) so this is nearly as good as caching the final output. I did most of the work here in D737 / D738, but we never moved to use it in Phabricator -- we currently just do the two operations serially in all cases. This diff splits them apart and caches the output of preprocessing only, so we benefit from caching but also get accurate time-variant rendering. **Problem 3: cache access isn't batched/pipelined optimally.** When we're rendering a list of markup blocks, we should be able to batch datafetching better than we do. D738 helped with this (fetching is batched within a single hunk of markup) and this improves batching on cache access. We could still do better here, but this is at least a step forward. Also fixes a bug with generating a link in the Phriction history interface ($uri gets clobbered). I'm using PHP serialization instead of JSON serialization because Remarkup does some stuff with non-ascii characters that might not survive JSON. Test Plan: - Created a Phriction document and verified that previews don't go to cache (no rows appear in the cache table). - Verified that published documents come out of cache. - Verified that caches generate/regenerate correctly, time-variant rules render properly and old documents hit the right caches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1366 Differential Revision: https://secure.phabricator.com/D2945
2012-07-10 00:20:56 +02:00
'PhabricatorCacheDAO' => 'PhabricatorLiskDAO',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorCacheGeneralGarbageCollector' => 'PhabricatorGarbageCollector',
Make all bin/* scripts locate their workflows dynamically Summary: Ref T2015. Not directly related to Drydock, but I bumped into this. All these scripts currently enumerate their workflows explicitly. Instead, use `PhutilSymbolLoader` to automatically discover workflows. This reduces code duplication and errors (see all the bad `extends` this diff fixes) and lets third parties add new workflows (not clearly valuable?). Test Plan: Ran `bin/x help` for each modified script. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7840
2013-12-27 22:15:48 +01:00
'PhabricatorCacheManagementPurgeWorkflow' => 'PhabricatorCacheManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorCacheManagementWorkflow' => 'PhabricatorManagementWorkflow',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorCacheMarkupGarbageCollector' => 'PhabricatorGarbageCollector',
Generate reasonable expected schemata for Cache tables Summary: Ref T1191. Notable: - Rename `blob` to `bytes` for clarity. - Introduce raw schema specs. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10501
2014-09-18 17:36:22 +02:00
'PhabricatorCacheSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Emit cache setup issues from cache specs Summary: Ref T5501. Currently, we emit some bad warnings about, e.g., "apc.stat" on PHP 5.5+ systems with OPcache, where the warnings are not relevant. Generate and raise warnings out of the CacheSpec pipeline so we only run relevant code. Test Plan: Faked various warnings and saw them render correctly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5501 Differential Revision: https://secure.phabricator.com/D12318
2015-04-08 20:31:01 +02:00
'PhabricatorCacheSetupCheck' => 'PhabricatorSetupCheck',
Restructure cache checks to improve modularity Summary: Ref T5501. This code was headed down a bad road; dump an indirection layer between rendering and data gatehring. In particular, this will make it much easier to lift these issues into setup warnings eventually. Test Plan: Viewed cache status page. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5501 Differential Revision: https://secure.phabricator.com/D12315
2015-04-07 23:38:03 +02:00
'PhabricatorCacheSpec' => 'Phobject',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorCacheTTLGarbageCollector' => 'PhabricatorGarbageCollector',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorCaches' => 'Phobject',
Introduce a request cache mechanism Summary: Ref T8424. This adds a standard KeyValueCache to serve as a request cache. In particular, I need to cache Spaces (they are frequently accessed, sometimes by multiple viewers) but not have them survive longer than the scope of one request. This request cache is explicitly destroyed by each web request and each daemon request. In the very long term, building this kind of construct supports reusing PHP interpreters to run web requests (see some discussion in T2312). Test Plan: - Added and executed unit tests. - Ran every daemon. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8424 Differential Revision: https://secure.phabricator.com/D13153
2015-06-05 02:27:31 +02:00
'PhabricatorCachesTestCase' => 'PhabricatorTestCase',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorCalendarApplication' => 'PhabricatorApplication',
Build a basic calendar view Summary: This is a very small step toward building a Status and possibly an Oncall tool. Build a calendar view which renders months. Much of my hesitance to bang these tools out is that dealing with dates/calendaring is basically horrible, so I'm trying to ease into it. This calendar is locale-aware and all that jazz. Test Plan: - See: https://secure.phabricator.com/file/view/PHID-FILE-c07a9c663a7d040d2529/ - Verified that months have the right number of days, today is the right day of the week, months begin on the day after previous months end on, etc. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran Commenters: cwbeck, jungejason CC: blair, aran, epriestley, cwbeck, jungejason Differential Revision: 791
2011-08-08 03:26:31 +02:00
'PhabricatorCalendarController' => 'PhabricatorController',
Display holidays Summary: We will need it for two purposes: - Status tool. - Nagging tool - @aran suggested using "3 business days" and I don't want it to fall on New Year's Eve or such. I don't plan working on any interface for editing this as this kind of data should be always imported. Test Plan: `bin/storage upgrade` `scripts/calendar/import_us_holidays.php` /calendar/ Reviewers: epriestley Reviewed By: epriestley CC: aran, Koolvin Differential Revision: https://secure.phabricator.com/D2375
2012-05-03 09:21:47 +02:00
'PhabricatorCalendarDAO' => 'PhabricatorLiskDAO',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorCalendarEvent' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorCalendarDAO',
'PhabricatorPolicyInterface',
Refactor Calendar Search, and implement Projects on events Summary: Ref T7950, Refactor Calendar Search, and implement Projects on events Test Plan: Verify that all queries in Calendar search still work, and that events can now have associated Projects that you can search by in Calendar Search. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T7950 Differential Revision: https://secure.phabricator.com/D13393
2015-06-22 22:27:37 +02:00
'PhabricatorProjectInterface',
Calendar event monograms, part 3. Remarkup for calendar event monograms. Summary: Ref T7928, Calendar event monograms, part 3. Remarkup for calendar event monograms. Test Plan: Create calendar event, open a maniphest task, add 'E{id}' and preview should show a hovertag for event that links to event. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7928 Differential Revision: https://secure.phabricator.com/D12580
2015-04-27 23:27:34 +02:00
'PhabricatorMarkupInterface',
T5464, ApplicationTransactions for calendar events Summary: Closes T5464, Implement ApplicationTransactions in Calendar. Test Plan: Create a calendar event, update calendar event, detail view of event should show update history. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: johnny-bit, Korvin, epriestley Maniphest Tasks: T5464 Differential Revision: https://secure.phabricator.com/D12586
2015-04-28 15:26:48 +02:00
'PhabricatorApplicationTransactionInterface',
Implement very rough message context for Conpherence search Summary: Ref T3165. This is pretty awful looking, but should pull the correct data. Test Plan: {F387567} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3165 Differential Revision: https://secure.phabricator.com/D12589
2015-04-28 20:43:56 +02:00
'PhabricatorSubscribableInterface',
Canceling calendar events should deactivate the event Summary: Closes T7943, Canceling calendar event should deactivate the event instead of destroying data. Test Plan: Create an event, cancel it, see changed status icon, query for active events, event should not appear, query for deactivated events, event should appear in results. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7943 Differential Revision: https://secure.phabricator.com/D12604
2015-04-29 17:39:39 +02:00
'PhabricatorTokenReceiverInterface',
'PhabricatorDestructibleInterface',
'PhabricatorMentionableInterface',
'PhabricatorFlaggableInterface',
Events should offer Spaces as the view policy options Summary: Ref T8687, Events should offer Spaces as the view policy options Test Plan: Create event, choose default Space, save, edit, choose different Space, save, new policy should be reflected on Event. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T8687 Differential Revision: https://secure.phabricator.com/D13459
2015-06-27 19:26:24 +02:00
'PhabricatorSpacesInterface',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorFulltextInterface',
Use a modern query object to query Calendar events Summary: Ref T4375. Calendar uses oldschool `loadOneWhere()` calls. Make CalendarEvent policy-aware, do the edit/delete policy checks through the policy framework, and use modern query infrastructure. Test Plan: - Viewed calendar; - created, edited, deleted event; - viewed calendar tab in Conpherence. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8146
2014-02-06 19:07:42 +01:00
),
Canceling calendar events should deactivate the event Summary: Closes T7943, Canceling calendar event should deactivate the event instead of destroying data. Test Plan: Create an event, cancel it, see changed status icon, query for active events, event should not appear, query for deactivated events, event should appear in results. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7943 Differential Revision: https://secure.phabricator.com/D12604
2015-04-29 17:39:39 +02:00
'PhabricatorCalendarEventCancelController' => 'PhabricatorCalendarController',
Calendar events should support comments Summary: Closes T7956, Calendar events should support comments. Test Plan: Open event, add comment, save, comment should appear in timeline. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7956 Differential Revision: https://secure.phabricator.com/D12640
2015-05-01 02:38:04 +02:00
'PhabricatorCalendarEventCommentController' => 'PhabricatorCalendarController',
Rescheduling events by dragging them in day view Summary: Ref T8300, Rescheduling events by dragging them in day view Test Plan: Open day view, drag events, observe them reschedule. Reviewers: chad, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T8300 Differential Revision: https://secure.phabricator.com/D12988
2015-05-24 04:47:23 +02:00
'PhabricatorCalendarEventDragController' => 'PhabricatorCalendarController',
Rename "status" to "event" in most URIs / classes / etc Summary: Ref T4375. This doesn't get everything (I figure I'll clean up the actual UI strings when I touch the UIs) but should get the bulk of the URIs and class names and stuff. Test Plan: Clicked every calendar-related link I could find/grep, they all still seem to work. URIs now say "event". Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8147
2014-02-06 19:10:07 +01:00
'PhabricatorCalendarEventEditController' => 'PhabricatorCalendarController',
T5464, ApplicationTransactions for calendar events Summary: Closes T5464, Implement ApplicationTransactions in Calendar. Test Plan: Create a calendar event, update calendar event, detail view of event should show update history. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: johnny-bit, Korvin, epriestley Maniphest Tasks: T5464 Differential Revision: https://secure.phabricator.com/D12586
2015-04-28 15:26:48 +02:00
'PhabricatorCalendarEventEditor' => 'PhabricatorApplicationTransactionEditor',
Users should be able to rsvp to event via email Summary: Closes T7957, Users should be able to rsvp to event via email. Test Plan: Create event, open invitee email, reply to email w/ !rsvp yes, refresh event, invitee should show as attending. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7957 Differential Revision: https://secure.phabricator.com/D12651
2015-05-02 04:01:29 +02:00
'PhabricatorCalendarEventEmailCommand' => 'MetaMTAEmailTransactionCommand',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorCalendarEventFulltextEngine' => 'PhabricatorFulltextEngine',
Calendar events should now auto-invite the creator Summary: Closes T7935, Calendar events should now auto-invite the creator. Test Plan: Create event, save, event should now show creator as an invitee. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7935 Differential Revision: https://secure.phabricator.com/D12613
2015-04-29 22:51:09 +02:00
'PhabricatorCalendarEventInvitee' => array(
'PhabricatorCalendarDAO',
'PhabricatorPolicyInterface',
),
'PhabricatorCalendarEventInviteeQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Ability to join or decline an event Summary: Ref T7986, Ability to join or decline an event. Test Plan: Open Calendar event, join event, Invitee list should update. Decline event, invitee list should remove you. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7986 Differential Revision: https://secure.phabricator.com/D12618
2015-04-30 03:18:27 +02:00
'PhabricatorCalendarEventJoinController' => 'PhabricatorCalendarController',
Move rendering to SearchEngine for Calendar Summary: Ref T4986. This one needs `getApplicationURI()` so make it a little beefier to deal with that. (It would be vaguely nice to somehow share the handle and application stuff between Controllers and Engine classes like this, but I don't immediately see a clean way to do it without traits. Not a big deal, in any case.) Test Plan: - Viewed Calendar. - Made a Calendar panel. - Viewed feed. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9012
2014-05-08 18:18:02 +02:00
'PhabricatorCalendarEventListController' => 'PhabricatorCalendarController',
Calendar event transaction emails without reply handling Summary: Ref T7957, Calendar event transaction emails without reply handling. Test Plan: Create event, invitees should get email. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7957 Differential Revision: https://secure.phabricator.com/D12645
2015-05-01 22:26:07 +02:00
'PhabricatorCalendarEventMailReceiver' => 'PhabricatorObjectMailReceiver',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorCalendarEventPHIDType' => 'PhabricatorPHIDType',
Use a modern query object to query Calendar events Summary: Ref T4375. Calendar uses oldschool `loadOneWhere()` calls. Make CalendarEvent policy-aware, do the edit/delete policy checks through the policy framework, and use modern query infrastructure. Test Plan: - Viewed calendar; - created, edited, deleted event; - viewed calendar tab in Conpherence. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8146
2014-02-06 19:07:42 +01:00
'PhabricatorCalendarEventQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Users should be able to rsvp to event via email Summary: Closes T7957, Users should be able to rsvp to event via email. Test Plan: Create event, open invitee email, reply to email w/ !rsvp yes, refresh event, invitee should show as attending. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7957 Differential Revision: https://secure.phabricator.com/D12651
2015-05-02 04:01:29 +02:00
'PhabricatorCalendarEventRSVPEmailCommand' => 'PhabricatorCalendarEventEmailCommand',
Use ApplicationSearch in the calendar event list view Summary: Ref T4375. Basic ApplicationSearch integration to power this more flexibly. Test Plan: {F108762} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8148
2014-02-06 19:10:18 +01:00
'PhabricatorCalendarEventSearchEngine' => 'PhabricatorApplicationSearchEngine',
T5464, ApplicationTransactions for calendar events Summary: Closes T5464, Implement ApplicationTransactions in Calendar. Test Plan: Create a calendar event, update calendar event, detail view of event should show update history. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: johnny-bit, Korvin, epriestley Maniphest Tasks: T5464 Differential Revision: https://secure.phabricator.com/D12586
2015-04-28 15:26:48 +02:00
'PhabricatorCalendarEventTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorCalendarEventTransactionComment' => 'PhabricatorApplicationTransactionComment',
'PhabricatorCalendarEventTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Differential - add DifferentialDraft to track whether revisions have draft feedback or not Summary: ...do it somewhat generically, so we could fairly easily add this to other applications. Fixes T3496. I got a wee bit lazy and decided not to migrate existing drafts. My excuses aside from laziness are doing it this way will let us see if anyone complains, we can always do a migration later if people do complain, and there's likely to be a lot of garbage data for older / bigger installs, and the migration didn't seem worth itgiven it would also likely be expensive in these cases. Test Plan: made a draft inline comment on DX and observed DX had a note icon on Differential home page. made a draft comment on DX and observed DX had a note icon on Differential home page. deleted a draft inline comment and noted icon disappeared from Differential homepage. Submitted a draft comment + inline comment and noted icon disappeared. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T3496 Differential Revision: https://secure.phabricator.com/D8275
2014-02-19 01:25:16 +01:00
'PhabricatorCalendarEventViewController' => 'PhabricatorCalendarController',
Display holidays Summary: We will need it for two purposes: - Status tool. - Nagging tool - @aran suggested using "3 business days" and I don't want it to fall on New Year's Eve or such. I don't plan working on any interface for editing this as this kind of data should be always imported. Test Plan: `bin/storage upgrade` `scripts/calendar/import_us_holidays.php` /calendar/ Reviewers: epriestley Reviewed By: epriestley CC: aran, Koolvin Differential Revision: https://secure.phabricator.com/D2375
2012-05-03 09:21:47 +02:00
'PhabricatorCalendarHoliday' => 'PhabricatorCalendarDAO',
Implement getNthBusinessDay() Summary: I will need it for nagging tool. Test Plan: None yet. Please suggest me how to create a testing database (I need to insert some data in the table). I guess that it is now possible? There is also probably some bug in `arc unit` - `setEnvConfig()` is not called before `getEnvConfig()` resulting in fatal error. Reviewers: epriestley Reviewed By: epriestley CC: aran, Koolvin Differential Revision: https://secure.phabricator.com/D2376
2012-05-03 21:16:09 +02:00
'PhabricatorCalendarHolidayTestCase' => 'PhabricatorTestCase',
Provide a "PHUIFormIconSetControl" Summary: Ref T9992. This is a step on the path to getting EditEngine working in Badges, Projects and Calendar. This doesn't add a new `EditField` for icons yet, just standardizes the old stuff. New stuff is more general and I saved 150 lines of code. I put the endpoint in Files because the similar "choose a profile picture" endpoint will definitely go there, and this endpoint might eventually feature, like, "draw your own icon~~" or something. Test Plan: - Created events, projects and badges with custom icons. - Edited events, projects and badges, changing their icons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9992 Differential Revision: https://secure.phabricator.com/D14799
2015-12-16 16:53:13 +01:00
'PhabricatorCalendarIconSet' => 'PhabricatorIconSet',
Calendar event monograms, part 3. Remarkup for calendar event monograms. Summary: Ref T7928, Calendar event monograms, part 3. Remarkup for calendar event monograms. Test Plan: Create calendar event, open a maniphest task, add 'E{id}' and preview should show a hovertag for event that links to event. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7928 Differential Revision: https://secure.phabricator.com/D12580
2015-04-27 23:27:34 +02:00
'PhabricatorCalendarRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Calendar event transaction emails without reply handling Summary: Ref T7957, Calendar event transaction emails without reply handling. Test Plan: Create event, invitees should get email. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7957 Differential Revision: https://secure.phabricator.com/D12645
2015-05-01 22:26:07 +02:00
'PhabricatorCalendarReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Create Edge tables in phabricator_calendar db. Summary: Closes T7945, phabricator_calendar db should now have Edge tables. Test Plan: Use phabricator_calendar db in mysql, show create table edge, verify edge tables are present. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7945 Differential Revision: https://secure.phabricator.com/D12584
2015-04-28 01:35:55 +02:00
'PhabricatorCalendarSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Rename protocol adapter classes Summary: Ref T5655. Rename protocol adapter classes to remove `Base` from the class name. Test Plan: Unit tests still pass. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D12563
2015-05-18 00:20:11 +02:00
'PhabricatorCampfireProtocolAdapter' => 'PhabricatorStreamingProtocolAdapter',
Make Celerity a real application Summary: Ref T5702. This primarily gets URI routing out of Aphront and into an Application, for consistency. Test Plan: Loaded some pages, got static resources. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D10696
2014-10-13 20:17:23 +02:00
'PhabricatorCelerityApplication' => 'PhabricatorApplication',
Add an acceptance test for Celerity maps Summary: Fixes T5374. Add an acceptance test to the `PhabricatorInfrastructureTestCase` class which fails if a Celerity map is not up-to-date. In order to achieve this, a lot of code used to generate Celerity maps was transferred from `CelerityManagementMapWorkflow` to `CelerityResourceMap` and `CelerityResourceMapGenerator`. Test Plan: Ran `arc unit` and noticed that all tests passed. Modified a JavaScript file and ran `arc unit` again (without running `./bin/celerity map`)... this time the test failed, as expected. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5374 Differential Revision: https://secure.phabricator.com/D9817
2014-09-22 10:50:20 +02:00
'PhabricatorCelerityTestCase' => 'PhabricatorTestCase',
Add unit tests for Git change parsers Summary: Ref T4327. Adds some basic tests to the Git parser for a set of common operations (add, change, move, copy, directory, symlink, propchange). Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D8012
2014-01-20 22:14:04 +01:00
'PhabricatorChangeParserTestCase' => 'PhabricatorWorkingCopyTestCase',
Minor, formalize changeset response class.
2012-03-13 05:39:05 +01:00
'PhabricatorChangesetResponse' => 'AphrontProxyResponse',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorChatLogApplication' => 'PhabricatorApplication',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorChatLogChannel' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorChatLogDAO',
'PhabricatorPolicyInterface',
Added a new storage object Summary: Added a new storage object. Created PhabricatorChagLogChannel Test Plan: Will be specified by Evan :P Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4943
2013-02-14 13:10:42 +01:00
),
Add a basic chatlog Summary: This is pretty simple and unpolished, but it's getting pretty big and it seems like a reasonable starting point. - Log chat in various "channels". - Conduit record and query methods. - IRCBot integration for IRC logging Major TODO: - Web UI is really unpolished and has no search, paging, anchor-linking, etc. Basically all presentation stuff, though. - I think the bot should have a map of channels to log with channel aliases? - The "channels" should probably be in a separate table. - The "authors" should probably be correlated to Phabricator accounts somehow, where possible. Test Plan: Used phabotlocal to log #phabricator. Reviewers: kdeggelman, btrahan, Koolvin Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T837 Differential Revision: https://secure.phabricator.com/D1625
2012-02-17 19:21:38 +01:00
'PhabricatorChatLogChannelListController' => 'PhabricatorChatLogController',
'PhabricatorChatLogChannelLogController' => 'PhabricatorChatLogController',
Moving code off channel Summary: Deleted code which used channel. Created PhabricatorChatLogChannelQuery.php Test Plan: By manually checking in the chatlog application. Reviewers: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5010
2013-02-22 15:59:17 +01:00
'PhabricatorChatLogChannelQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add a basic chatlog Summary: This is pretty simple and unpolished, but it's getting pretty big and it seems like a reasonable starting point. - Log chat in various "channels". - Conduit record and query methods. - IRCBot integration for IRC logging Major TODO: - Web UI is really unpolished and has no search, paging, anchor-linking, etc. Basically all presentation stuff, though. - I think the bot should have a map of channels to log with channel aliases? - The "channels" should probably be in a separate table. - The "authors" should probably be correlated to Phabricator accounts somehow, where possible. Test Plan: Used phabotlocal to log #phabricator. Reviewers: kdeggelman, btrahan, Koolvin Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T837 Differential Revision: https://secure.phabricator.com/D1625
2012-02-17 19:21:38 +01:00
'PhabricatorChatLogController' => 'PhabricatorController',
'PhabricatorChatLogDAO' => 'PhabricatorLiskDAO',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorChatLogEvent' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorChatLogDAO',
'PhabricatorPolicyInterface',
Make chatlog a bit less awful Summary: - Default to showing the newest page of chat. - Reformat for greater readability. - Add permalinks to specific lines. - Enable jump-to-date. Test Plan: {F12200} Reviewers: Koolvin, vrana, btrahan Reviewed By: btrahan CC: kdeggelman, aran Maniphest Tasks: T837, T1065 Differential Revision: https://secure.phabricator.com/D2641
2012-06-02 23:00:08 +02:00
),
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorChatLogQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add a chunking storage engine for files Summary: Ref T7149. This isn't complete and isn't active yet, but does basically work. I'll shore it up in the next few diffs. The new workflow goes like this: > Client, file.allocate(): I'd like to upload a file with length L, metadata M, and hash H. Then the server returns `upload` (a boolean) and `filePHID` (a PHID). These mean: | upload | filePHID | means | |---|---|---| | false | false | Server can't accept file. | false | true | File data already known, file created from hash. | true | false | Just upload normally. | true | true | Query chunks to start or resume a chunked upload. All but the last case are uninteresting and work like exising uploads with `file.uploadhash` (which we can eventually deprecate). In the last case: > Client, file.querychunks(): Give me a list of chunks that I should upload. This returns all the chunks for the file. Chunks have a start byte, an end byte, and a "complete" flag to indicate that the server already has the data. Then, the client fills in chunks by sending them: > Client, file.uploadchunk(): Here is the data for one chunk. This stuff doesn't work yet or has some caveats: - I haven't tested resume much. - Files need an "isPartial()" flag for partial uploads, and the UI needs to respect it. - The JS client needs to become chunk-aware. - Chunk size is set crazy low to make testing easier. - Some debugging flags that I'll remove soon-ish. - Downloading works, but still streams the whole file into memory. - This storage engine is disabled by default (hardcoded as a unit test engine) because it's still sketchy. - Need some code to remove the "isParital" flag when the last chunk is uploaded. - Maybe do checksumming on chunks. Test Plan: - Hacked up `arc upload` (see next diff) to be chunk-aware and uploaded a readme in 18 32-byte chunks. Then downloaded it. Got the same file back that I uploaded. - File UI now shows some basic chunk info for chunked files: {F336434} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12060
2015-03-13 19:30:02 +01:00
'PhabricatorChunkedFileStorageEngine' => 'PhabricatorFileStorageEngine',
Add `cluster.addresses` and require membership before accepting cluster authentication tokens Summary: Ref T2783. Ref T6706. - Add `cluster.addresses`. This is a whitelist of CIDR blocks which define cluster hosts. - When we recieve a request that has a cluster-based authentication token, require the cluster to be configured and require the remote address to be a cluster member before we accept it. - This provides a general layer of security for these mechanisms. - In particular, it means they do not work by default on unconfigured hosts. - When cluster addresses are configured, and we receive a request //to// an address not on the list, reject it. - This provides a general layer of security for getting the Ops side of cluster configuration correct. - If cluster nodes have public IPs and are listening on them, we'll reject requests. - Basically, this means that any requests which bypass the LB get rejected. Test Plan: - With addresses not configured, tried to make requests; rejected for using a cluster auth mechanism. - With addresses configred wrong, tried to make requests; rejected for sending from (or to) an address outside of the cluster. - With addresses configured correctly, made valid requests. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6706, T2783 Differential Revision: https://secure.phabricator.com/D11159
2015-01-03 00:13:41 +01:00
'PhabricatorClusterConfigOptions' => 'PhabricatorApplicationConfigOptions',
Lay `cluster.databases` configuration groundwork for database clustering Summary: Ref T4571. This adds a new option which allows you to upgrade your one-host configuration to a multi-host configuration by configuring it. Doing this currently does nothing. I wrote a lot of words about what it is //supposed// to do in the future, though. Test Plan: - Tried to configure the option in all the possible bad ways, got errors. - Read documentation. Reviewers: chad Reviewed By: chad Subscribers: eadler Maniphest Tasks: T4571 Differential Revision: https://secure.phabricator.com/D15663
2016-04-09 14:41:08 +02:00
'PhabricatorClusterDatabasesConfigOptionType' => 'PhabricatorConfigJSONOptionType',
When no master database is configured, automatically degrade to read-only mode Summary: Ref T4571. If `cluster.databases` is configured but only has replicas, implicitly drop to read-only mode and send writes to a replica. Test Plan: - Disabled the `master`, saw Phabricator automatically degrade into read-only mode against replicas. - (Also tested: explicit read-only mode, non-cluster mode, properly configured cluster mode). Reviewers: chad Reviewed By: chad Maniphest Tasks: T4571 Differential Revision: https://secure.phabricator.com/D15672
2016-04-10 14:10:06 +02:00
'PhabricatorClusterException' => 'Exception',
'PhabricatorClusterExceptionHandler' => 'PhabricatorRequestExceptionHandler',
Automatically degrade to read-only mode when unable to connect to the master Summary: Ref T4571. If we fail to connect to the master, automatically try to degrade into a temporary read-only mode ("UNREACHABLE") for the remainder of the request, if possible. If the request was something like "load the homepage", that'll work fine. If it was something like "submit a comment", there's nothing we can do and we just have to fail. Detecting this condition imposes a performance penalty: every request checks the connection and gives the database a long time to respond, since we don't want to drop writes unless we have to. So the degraded mode works, but it's really slow, and may perpetuate the problem if the root issue is load-related. This lays the groundwork for improving this case by degrading futher into a "SEVERED" mode which will persist across requests. In the future, if several requests in a short period of time fail, we'll sever the database host and refuse to try to connect to it for a little while, connecting directly to replicas instead (basically, we're "health checking" the master, like a load balancer would health check a web application server). This will give us a better (much faster) degraded mode in a major service disruption, and reduce load on the master if the root cause is load-related, giving it a better chance of recovering on its own. Test Plan: - Disabled master in config by changing the host/username, got degraded automatically to UNREACAHBLE mode immediately. - Faked full SEVERED mode, requests hit replicas and put me in the mode properly. - Made stuff work, hit some good pages. - Hit some non-cluster pages. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4571 Differential Revision: https://secure.phabricator.com/D15674
2016-04-10 14:51:34 +02:00
'PhabricatorClusterImpossibleWriteException' => 'PhabricatorClusterException',
When no master database is configured, automatically degrade to read-only mode Summary: Ref T4571. If `cluster.databases` is configured but only has replicas, implicitly drop to read-only mode and send writes to a replica. Test Plan: - Disabled the `master`, saw Phabricator automatically degrade into read-only mode against replicas. - (Also tested: explicit read-only mode, non-cluster mode, properly configured cluster mode). Reviewers: chad Reviewed By: chad Maniphest Tasks: T4571 Differential Revision: https://secure.phabricator.com/D15672
2016-04-10 14:10:06 +02:00
'PhabricatorClusterImproperWriteException' => 'PhabricatorClusterException',
Automatically degrade to read-only mode when unable to connect to the master Summary: Ref T4571. If we fail to connect to the master, automatically try to degrade into a temporary read-only mode ("UNREACHABLE") for the remainder of the request, if possible. If the request was something like "load the homepage", that'll work fine. If it was something like "submit a comment", there's nothing we can do and we just have to fail. Detecting this condition imposes a performance penalty: every request checks the connection and gives the database a long time to respond, since we don't want to drop writes unless we have to. So the degraded mode works, but it's really slow, and may perpetuate the problem if the root issue is load-related. This lays the groundwork for improving this case by degrading futher into a "SEVERED" mode which will persist across requests. In the future, if several requests in a short period of time fail, we'll sever the database host and refuse to try to connect to it for a little while, connecting directly to replicas instead (basically, we're "health checking" the master, like a load balancer would health check a web application server). This will give us a better (much faster) degraded mode in a major service disruption, and reduce load on the master if the root cause is load-related, giving it a better chance of recovering on its own. Test Plan: - Disabled master in config by changing the host/username, got degraded automatically to UNREACAHBLE mode immediately. - Faked full SEVERED mode, requests hit replicas and put me in the mode properly. - Made stuff work, hit some good pages. - Hit some non-cluster pages. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4571 Differential Revision: https://secure.phabricator.com/D15674
2016-04-10 14:51:34 +02:00
'PhabricatorClusterStrandedException' => 'PhabricatorClusterException',
Expose column positions via maniphest.edit Summary: Ref T5214. Fixes T10486. Ref T6027. This exposes the `TYPE_COLUMNS` transaction in a usable way via API, and fixes the interactions via prefilling. Test Plan: - Created tasks directly into columns via API. - Moved tasks between columns via API. - Used `?column=...` to try to create a template task with valid and bogus column PHIDs. Reviewers: chad Reviewed By: chad Subscribers: AmyLewis Maniphest Tasks: T5214, T6027, T10486 Differential Revision: https://secure.phabricator.com/D15636
2016-04-06 13:37:01 +02:00
'PhabricatorColumnsEditField' => 'PhabricatorPHIDListEditField',
Modularize application extensions to EditEngine Summary: Ref T9132. Currently, EditEngine had some branchy-`instanceof` code like this: ``` if ($object instanceof Whatever) { do_magic(); } if ($object instanceof SomethingElse) { do_other_magic(); } ``` ...where `Whatever` and `SomethingElse` are first-party applications like ProjectsInterface and SubscribersInterface. This kind of code is generally bad because third-parties can't add new stuff, and it suggest something is kind of hacky in its architecture. Ideally, we would eventually get rid of almost all of this. T9789 is a similar discussion of this for the next layer down (`TransactionEditor`) and plans to get rid of branchy-instanceofs there too. Since I'm about to add more stuff here (for Custom Fields), split it out first so I'm not digging us any deeper than I already dug us. Broadly, this allows third-party extensions to add fields to every EditEngine UI if they want, like we do for Policies, Subscribers, Projects and Comments today (and CustomFields soon). Test Plan: {F1007575} - Observed that all fields still appear on the form and seem to work correctly. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14599
2015-11-29 19:05:41 +01:00
'PhabricatorCommentEditEngineExtension' => 'PhabricatorEditEngineExtension',
Support comments as an EditEngine field Summary: Ref T9132. This adds an automatic "Comments" field, like the Subscribers/Projects/Policy fields. The primary goals here are: - Allow users to make comments via Conduit. - In the future, get stackable action support. As a side effect, this also allows you to put comments on create forms. This is a little silly but seems fine, and may be relevant on edit forms (which I'm not 100% sure how I want to handle yet). I've just hidden them by default for now. Test Plan: {F976036} {F976037} {F976038} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14515
2015-11-18 23:11:21 +01:00
'PhabricatorCommentEditField' => 'PhabricatorEditField',
'PhabricatorCommentEditType' => 'PhabricatorEditType',
Add CustomField to Diffusion and add a "branches" field Summary: Ref T4588. Request from @zeeg. Adds a "BRANCHES" field to commit emails, so the branches the commit appears on are shown. I've implemented this with CustomField, but in a very light way. Test Plan: Used `scripts/repository/reparse.php --herald` to generate mail, got a BRANCHES section where applicable. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley, zeeg Maniphest Tasks: T4588 Differential Revision: https://secure.phabricator.com/D8501
2014-03-12 19:30:33 +01:00
'PhabricatorCommitBranchesField' => 'PhabricatorCommitCustomField',
'PhabricatorCommitCustomField' => 'PhabricatorCustomField',
show merged commits in herald emails for merge commits Summary: Includes a new Block in Herad emails which tells the user about which commits were merged in a merge commit Otherwise the email would just say "Merge branch XYZ". Ref T8295 Test Plan: imported various commits (and merges) and watched resulting herald emails for all of them Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T8295 Differential Revision: https://secure.phabricator.com/D12993
2015-05-25 13:49:12 +02:00
'PhabricatorCommitMergedCommitsField' => 'PhabricatorCommitCustomField',
Add repository to audit emails Summary: This is vaguely related to T5791. Add a "REPOSITORY" header to audit emails so that they can be filtered in Gmail. Test Plan: Commented on an audit and used `./bin/mail show-outbound` to inspect outbound email. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: fabe, Korvin, epriestley Differential Revision: https://secure.phabricator.com/D12997
2015-05-25 14:43:42 +02:00
'PhabricatorCommitRepositoryField' => 'PhabricatorCommitCustomField',
Audit - move over to application search Summary: ...also kills off "PhabricatorAuditCommitQuery" and "PhabricatorAuditQuery", by moving the work to "DiffusionCommitQuery". Generally cleans up some code around the joint on this too. Also provides policies for audit requests, which is basically the policy for the underlying commit. Fixes T4715. (For the TODO I added about files, I just grabbed T4713.) Test Plan: Audit: verified the three default views all showed the correct things, including highligthing. did some custom queries and got the correct results. Diffusion: verified "blame view" still worked. verified paths were highlighted for packages i owned. Home: verified audit boxes showed up with proper commits w/ audits bin/audit: played around with it via --dry-run and got the right audits back Reviewers: epriestley Reviewed By: epriestley Subscribers: chad, epriestley, Korvin Maniphest Tasks: T4715 Differential Revision: https://secure.phabricator.com/D8805
2014-04-27 18:43:05 +02:00
'PhabricatorCommitSearchEngine' => 'PhabricatorApplicationSearchEngine',
Add a "tags" field to Diffusion commit Summary: - Fixes T4588. - See D8501. - Adds a "Tags" field for Herald commit emails. - Fixes a bug in `tagsquery` when filtering by commit name. - Make `tagsquery` just return nothing instead of fataling against Mercurial/Subversion. Test Plan: Used `bin/repository/reparse.php --herald` to exercise this code. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4588 Differential Revision: https://secure.phabricator.com/D8502
2014-03-12 19:30:52 +01:00
'PhabricatorCommitTagsField' => 'PhabricatorCommitCustomField',
Add a common password blacklist Summary: Fixes T4143. This mitigates the "use a botnet to slowly try to login to every user account using the passwords '1234', 'password', 'asdfasdf', ..." attack, like the one that hit GitHub. (I also donated some money to Openwall as a thanks for compiling this wordlist.) Test Plan: - Tried to register with a weak password; registered with a strong password. - Tried to set VCS password to a weak password; set VCS password to a strong password. - Tried to change password to a weak password; changed password to a strong password. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T4143 Differential Revision: https://secure.phabricator.com/D8048
2014-01-23 23:01:18 +01:00
'PhabricatorCommonPasswords' => 'Phobject',
Conduit server-side basics.
2011-01-24 18:00:29 +01:00
'PhabricatorConduitAPIController' => 'PhabricatorConduitController',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorConduitApplication' => 'PhabricatorApplication',
"arc install-certificate", server-side components Summary: Provides a new workflow for making it non-horrible to install certificates. Basically you run "arc install-certificate" and then copy/paste a short token off a webpage and it does the ~/.arcrc edits for you. Test Plan: Installed certificates, used bad tokens, hit rate limiting. Reviewed By: aran Reviewers: aran, jungejason, tuomaspelkonen CC: aran Differential Revision: 460
2011-06-14 21:17:14 +02:00
'PhabricatorConduitCertificateToken' => 'PhabricatorConduitDAO',
Write some basic "dealing with Conduit changes" documentation Summary: Ref T9980. No magic here, just write a little bit about how to find outdated callers. Update the technical doc. Also: - Fix an unrelated bug where you couldn't leave comments if an object had missing, required, custom fields. - Restore the ConduitConnectionLog table so `bin/storage adjust` doesn't complain. Test Plan: Read docs. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9980 Differential Revision: https://secure.phabricator.com/D14784
2015-12-14 23:36:47 +01:00
'PhabricatorConduitConnectionLog' => 'PhabricatorConduitDAO',
Conduit server-side basics.
2011-01-24 18:00:29 +01:00
'PhabricatorConduitConsoleController' => 'PhabricatorConduitController',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorConduitContentSource' => 'PhabricatorContentSource',
Conduit server-side basics.
2011-01-24 18:00:29 +01:00
'PhabricatorConduitController' => 'PhabricatorController',
'PhabricatorConduitDAO' => 'PhabricatorLiskDAO',
Support editing statuses and paths in Owners via Conduit API Summary: Ref T9964. Fixes T9752. Provides API access to enable/disable packages and change their paths. Test Plan: - Changed status via Conduit. - Changed paths via Conduit. - Tried to change a path use a nonsense/bogus repository PHID, got an error. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9752, T9964 Differential Revision: https://secure.phabricator.com/D14790
2015-12-15 18:11:11 +01:00
'PhabricatorConduitEditField' => 'PhabricatorEditField',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'PhabricatorConduitListController' => 'PhabricatorConduitController',
Conduit server-side basics.
2011-01-24 18:00:29 +01:00
'PhabricatorConduitLogController' => 'PhabricatorConduitController',
Mostly modernize Conduit logs Summary: - Add GC support to conduit logs. - Add Query support to conduit logs. - Record the actual user PHID. - Show client name. - Support querying by specific method, so I can link to this from a setup issue. @wez, this migration may not be fast. It took about 8 seconds for me to migrate 800,000 rows in the `conduit_methodcalllog` table. This adds a GC which should keep the table at a more manageable size in the future. You can safely delete all data older than 30 days from this table, although you should do it by `id` instead of `dateCreated` since there's no key on `dateCreated` until this patch. Test Plan: - Ran GC. - Looked at log UI. - Ran Conduit methods. Reviewers: btrahan Reviewed By: btrahan CC: wez, aran Differential Revision: https://secure.phabricator.com/D6332
2013-07-01 21:37:34 +02:00
'PhabricatorConduitLogQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Move ConduitLogs to ApplicationSearch Summary: Ref T9980. Start making this UI more useful and powerful so we can give administrators a better toolset for reacting to API changes. Fixes T9755. We were logging the caller, just not rendering it properly. Test Plan: {F1025799} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9755, T9980 Differential Revision: https://secure.phabricator.com/D14779
2015-12-14 21:27:57 +01:00
'PhabricatorConduitLogSearchEngine' => 'PhabricatorApplicationSearchEngine',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorConduitMethodCallLog' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorConduitDAO',
'PhabricatorPolicyInterface',
Mostly modernize Conduit logs Summary: - Add GC support to conduit logs. - Add Query support to conduit logs. - Record the actual user PHID. - Show client name. - Support querying by specific method, so I can link to this from a setup issue. @wez, this migration may not be fast. It took about 8 seconds for me to migrate 800,000 rows in the `conduit_methodcalllog` table. This adds a GC which should keep the table at a more manageable size in the future. You can safely delete all data older than 30 days from this table, although you should do it by `id` instead of `dateCreated` since there's no key on `dateCreated` until this patch. Test Plan: - Ran GC. - Looked at log UI. - Ran Conduit methods. Reviewers: btrahan Reviewed By: btrahan CC: wez, aran Differential Revision: https://secure.phabricator.com/D6332
2013-07-01 21:37:34 +02:00
),
Modernize most Conduit console interfaces Summary: Ref T603. Ref T2625. Long chain of "doing the right thing" here: I want to clean this up, so I can clean up the Conduit logs, so I can add a setup issue for deprecated method calls, so I can remove deprecated methods, so I can get rid of `DifferentialRevisionListData`, so I can make Differntial policy-aware. Adds modern infrastructure and UI to all of the Conduit interfaces (except only partially for the logs, that will be the next diff). Test Plan: {F48201} {F48202} {F48203} {F48204} {F48206} This will get further updates in the next diff: {F48205} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6331
2013-07-01 21:36:34 +02:00
'PhabricatorConduitMethodQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Modularize Aphront exception handling Summary: Ref T1806. Ref T7173. Depends on D14047. Currently, all exception handling is in this big messy clump in `AphrontDefaultApplicationConfiguration`. Split it out into modular classes. This will let a future change add new classes in the Phacility cluster which intercept particular exceptions we care about and replaces the default, generic responses with more useful, tailored responses. Test Plan: {F777391} - Hit a Conduit error (made a method throw). - Hit an Ajax error (made comment preview throw). - Hit a high security error (tried to edit TOTP). - Hit a rate limiting error (added a bunch of email addresses). - Hit a policy error (tried to look at something with no permission). - Hit an arbitrary exception (made a randomc ontroller throw). Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14049
2015-09-03 19:04:42 +02:00
'PhabricatorConduitRequestExceptionHandler' => 'PhabricatorRequestExceptionHandler',
Implement a rough initial version of ApplicationSearch-driven Conduit read endpoints Summary: Ref T9964. See that task for some context and discussion. Ref T7715, which has the bigger picture here. Basically, I want Conduit read endpoints to be full-power, ApplicationSearch-driven endpoints, so that applications can: - Write one EditEngine and get web + conduit writes for free. - Write one SearchEngine and get web + conduit reads for free. I previously made some steps toward this, but this puts more of the structure in place. Test Plan: Viewed API console endpoint and read 20 pages of docs: {F1021961} Made various calls: with query keys, constraints, pagination, and limits. Viewed new {nav Config > Modules} page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7715, T9964 Differential Revision: https://secure.phabricator.com/D14743
2015-12-11 17:45:56 +01:00
'PhabricatorConduitResultInterface' => 'PhabricatorPHIDInterface',
Modernize most Conduit console interfaces Summary: Ref T603. Ref T2625. Long chain of "doing the right thing" here: I want to clean this up, so I can clean up the Conduit logs, so I can add a setup issue for deprecated method calls, so I can remove deprecated methods, so I can get rid of `DifferentialRevisionListData`, so I can make Differntial policy-aware. Adds modern infrastructure and UI to all of the Conduit interfaces (except only partially for the logs, that will be the next diff). Test Plan: {F48201} {F48202} {F48203} {F48204} {F48206} This will get further updates in the next diff: {F48205} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6331
2013-07-01 21:36:34 +02:00
'PhabricatorConduitSearchEngine' => 'PhabricatorApplicationSearchEngine',
Formalize custom Conduit fields on objects Summary: Ref T9964. This just adds more structure to application fields, to make it harder to make typos and easier to validate them later. Test Plan: Viewed APIs, called some APIs, saw good documentation and correct results. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14776
2015-12-14 15:42:21 +01:00
'PhabricatorConduitSearchFieldSpecification' => 'Phobject',
Accept Conduit tokens as an authentication mechanism Summary: - Ref T5955. Accept the tokens introduced in D10985 as an authentication token. - Ref T3628. Permit simple `curl`-compatible decoding of parameters. Test Plan: - Ran some sensible `curl` API commands: ``` epriestley@orbital ~/dev/phabricator $ curl -g "http://local.phacility.com/api/user.whoami?api.token=api-f7dfpoyelk4mmz6vxcueb6hcbtbk" ; echo {"result":{"phid":"PHID-USER-cvfydnwadpdj7vdon36z","userName":"admin","realName":"asdf","image":"http:\/\/local.phacility.com\/res\/1410737307T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/local.phacility.com\/p\/admin\/","roles":["admin","verified","approved","activated"]},"error_code":null,"error_info":null} ``` ``` epriestley@orbital ~/dev/phabricator $ curl -g "http://local.phacility.com/api/differential.query?api.token=api-f7dfpoyelk4mmz6vxcueb6hcbtbk&ids[]=1" ; echo {"result":[{"id":"1","phid":"PHID-DREV-v3a67ixww3ccg5lqbxee","title":"zxcb","uri":"http:\/\/local.phacility.com\/D1","dateCreated":"1418405590","dateModified":"1418405590","authorPHID":"PHID-USER-cvfydnwadpdj7vdon36z","status":"0","statusName":"Needs Review","branch":null,"summary":"","testPlan":"zxcb","lineCount":"6","activeDiffPHID":"PHID-DIFF-pzbtc5rw6pe5j2kxtlr2","diffs":["1"],"commits":[],"reviewers":[],"ccs":[],"hashes":[],"auxiliary":{"phabricator:projects":[],"phabricator:depends-on":[],"organization.sqlmigration":null},"arcanistProjectPHID":null,"repositoryPHID":null,"sourcePath":null}],"error_code":null,"error_info":null} ``` - Ran older-style commands like `arc list` against the local install. - Ran commands via web console. - Added and ran a unit test to make sure nothing is using forbidden parameter names. - Terminated a token and verified it no longer works. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3628, T5955 Differential Revision: https://secure.phabricator.com/D10986
2014-12-15 20:14:41 +01:00
'PhabricatorConduitTestCase' => 'PhabricatorTestCase',
Add Conduit Tokens to make authentication in Conduit somewhat more sane Summary: Ref T5955. Summary of intended changes: **Improve Granularity of Authorization**: Currently, users have one Conduit Certificate. This isn't very flexible, and means that you can't ever generate an API token with limited permissions or IP block controls (see T6706). This moves toward a world where you can generate multiple tokens, revoke them individually, and assign disparate privileges to them. **Standardize Token Management**: This moves Conduit to work the same way that sessions, OAuth authorizations, and temporary tokens already work, instead of being this crazy bizarre mess. **Make Authentication Faster**: Authentication currently requires a handshake (conduit.connect) to establish a session, like the web UI. This is unnecessary from a security point of view and puts an extra round trip in front of all Conduit activity. Essentially no other API anywhere works like this. **Make Authentication Simpler**: The handshake is complex, and involves deriving hashes. The session is also complex, and creates issues like T4377. Handshake and session management require different inputs. **Make Token Management Simpler**: The certificate is this huge long thing right now, which is not necessary from a security perspective. There are separate Arcanist handshake tokens, but they have a different set of issues. We can move forward to a token management world where neither of these problems exist. **Lower Protocol Barrier**: The simplest possible API client is very complex right now. It should be `curl`. Simplifying authentication is a necessary step toward this. **Unblock T2783**: T2783 is blocked on nodes in the cluster making authenticated API calls to other nodes. This provides a simpler way forward than the handshake mess (or enormous-hack-mess) which would currently be required. Test Plan: - Generated tokens. - Generated tokens for a bot account. - Terminated tokens (and for a bot account). - Terminated all tokens (and for a bot account). - Ran GC and saw it reap all the expired tokens. NOTE: These tokens can not actually be used to authenticate yet! {F249658} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5955 Differential Revision: https://secure.phabricator.com/D10985
2014-12-15 20:14:23 +01:00
'PhabricatorConduitToken' => array(
'PhabricatorConduitDAO',
'PhabricatorPolicyInterface',
),
"arc install-certificate", server-side components Summary: Provides a new workflow for making it non-horrible to install certificates. Basically you run "arc install-certificate" and then copy/paste a short token off a webpage and it does the ~/.arcrc edits for you. Test Plan: Installed certificates, used bad tokens, hit rate limiting. Reviewed By: aran Reviewers: aran, jungejason, tuomaspelkonen CC: aran Differential Revision: 460
2011-06-14 21:17:14 +02:00
'PhabricatorConduitTokenController' => 'PhabricatorConduitController',
Add Conduit Tokens to make authentication in Conduit somewhat more sane Summary: Ref T5955. Summary of intended changes: **Improve Granularity of Authorization**: Currently, users have one Conduit Certificate. This isn't very flexible, and means that you can't ever generate an API token with limited permissions or IP block controls (see T6706). This moves toward a world where you can generate multiple tokens, revoke them individually, and assign disparate privileges to them. **Standardize Token Management**: This moves Conduit to work the same way that sessions, OAuth authorizations, and temporary tokens already work, instead of being this crazy bizarre mess. **Make Authentication Faster**: Authentication currently requires a handshake (conduit.connect) to establish a session, like the web UI. This is unnecessary from a security point of view and puts an extra round trip in front of all Conduit activity. Essentially no other API anywhere works like this. **Make Authentication Simpler**: The handshake is complex, and involves deriving hashes. The session is also complex, and creates issues like T4377. Handshake and session management require different inputs. **Make Token Management Simpler**: The certificate is this huge long thing right now, which is not necessary from a security perspective. There are separate Arcanist handshake tokens, but they have a different set of issues. We can move forward to a token management world where neither of these problems exist. **Lower Protocol Barrier**: The simplest possible API client is very complex right now. It should be `curl`. Simplifying authentication is a necessary step toward this. **Unblock T2783**: T2783 is blocked on nodes in the cluster making authenticated API calls to other nodes. This provides a simpler way forward than the handshake mess (or enormous-hack-mess) which would currently be required. Test Plan: - Generated tokens. - Generated tokens for a bot account. - Terminated tokens (and for a bot account). - Terminated all tokens (and for a bot account). - Ran GC and saw it reap all the expired tokens. NOTE: These tokens can not actually be used to authenticate yet! {F249658} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5955 Differential Revision: https://secure.phabricator.com/D10985
2014-12-15 20:14:23 +01:00
'PhabricatorConduitTokenEditController' => 'PhabricatorConduitController',
Add conduit.getcapabilities and a modern CLI handshake workflow Summary: Ref T5955. - Add `conduit.getcapabilities` to help arc (and other clients) determine formats, protocols, etc., the server supports. - Fixes T3117. Add a more modern version of the handshake workflow that allows all generated tokens to remain valid for an hour. - Generally, add a CLI token type. This token type expires after an hour when generated, then becomes permanent if used. Test Plan: - See D10988. - Ran `conduit.getcapabilities` and inspected output. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3117, T5955 Differential Revision: https://secure.phabricator.com/D10989
2014-12-15 20:14:53 +01:00
'PhabricatorConduitTokenHandshakeController' => 'PhabricatorConduitController',
Add Conduit Tokens to make authentication in Conduit somewhat more sane Summary: Ref T5955. Summary of intended changes: **Improve Granularity of Authorization**: Currently, users have one Conduit Certificate. This isn't very flexible, and means that you can't ever generate an API token with limited permissions or IP block controls (see T6706). This moves toward a world where you can generate multiple tokens, revoke them individually, and assign disparate privileges to them. **Standardize Token Management**: This moves Conduit to work the same way that sessions, OAuth authorizations, and temporary tokens already work, instead of being this crazy bizarre mess. **Make Authentication Faster**: Authentication currently requires a handshake (conduit.connect) to establish a session, like the web UI. This is unnecessary from a security point of view and puts an extra round trip in front of all Conduit activity. Essentially no other API anywhere works like this. **Make Authentication Simpler**: The handshake is complex, and involves deriving hashes. The session is also complex, and creates issues like T4377. Handshake and session management require different inputs. **Make Token Management Simpler**: The certificate is this huge long thing right now, which is not necessary from a security perspective. There are separate Arcanist handshake tokens, but they have a different set of issues. We can move forward to a token management world where neither of these problems exist. **Lower Protocol Barrier**: The simplest possible API client is very complex right now. It should be `curl`. Simplifying authentication is a necessary step toward this. **Unblock T2783**: T2783 is blocked on nodes in the cluster making authenticated API calls to other nodes. This provides a simpler way forward than the handshake mess (or enormous-hack-mess) which would currently be required. Test Plan: - Generated tokens. - Generated tokens for a bot account. - Terminated tokens (and for a bot account). - Terminated all tokens (and for a bot account). - Ran GC and saw it reap all the expired tokens. NOTE: These tokens can not actually be used to authenticate yet! {F249658} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5955 Differential Revision: https://secure.phabricator.com/D10985
2014-12-15 20:14:23 +01:00
'PhabricatorConduitTokenQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhabricatorConduitTokenTerminateController' => 'PhabricatorConduitController',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorConduitTokensSettingsPanel' => 'PhabricatorSettingsPanel',
Move "show all config" from DarkConsole to /config/ Summary: Currently, we have a "config" panel in DarkConsole. It's useful to have a table of all effective config values, but it doesn't need to be in DarkConsole. Move it to Config instead. Basically: - You don't need to activate DarkConsole to see it anymore; - now visible only to admins; - respects config mask/hide; - somewhat prettier; - links to config edit; - no longer ships down on every DarkConsole request with a giant table of rarely-used data. Test Plan: Looked at the table. Looked at lack of table in darkconsole. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4473
2013-01-16 20:10:41 +01:00
'PhabricatorConfigAllController' => 'PhabricatorConfigController',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorConfigApplication' => 'PhabricatorApplication',
Add a very basic cache status page Summary: Ref T5501. This is just getting version detection and availability right, probably. Eventually, this will get lifted up a bit and "$remedy" will turn into setup issues (or maybe one setup issue saying "your cache setup is messed up, click here to understand why"). Test Plan: {F362935} I intend to shove these up to production one-by-one since production is APC and local is Opcache + APCu. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5501 Differential Revision: https://secure.phabricator.com/D12314
2015-04-07 23:28:20 +02:00
'PhabricatorConfigCacheController' => 'PhabricatorConfigController',
Add a "Database Cluster Status" console in Config Summary: Ref T4571. The configuration option still doesn't do anything, but add a status panel for basic setup monitoring. Test Plan: Here's what a good version looks like: {F1212291} Also faked most of the errors it can detect and got helpful diagnostic messages like this: {F1212292} Reviewers: chad Reviewed By: chad Maniphest Tasks: T4571 Differential Revision: https://secure.phabricator.com/D15667
2016-04-10 00:21:29 +02:00
'PhabricatorConfigClusterDatabasesController' => 'PhabricatorConfigController',
Complete modernization of Aphlict configuration Summary: Fixes T10697. This finishes bringing the rest of the config up to cluster power levels. Phabricator is now given an arbitrarily long list of notification servers. Each Aphlict server is given an arbitrarily long list of ports to run services on. Users are free to make them meet in the middle by proxying whatever they want to whatever else they want. This should also accommodate clustering fairly easily in the future. Also rewrote the status UI and changed a million other things. :boar: Test Plan: {F1217864} {F1217865} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10697 Differential Revision: https://secure.phabricator.com/D15703
2016-04-13 21:07:48 +02:00
'PhabricatorConfigClusterNotificationsController' => 'PhabricatorConfigController',
Add a "Repository Servers" cluster administration panel Summary: Ref T4292. This adds a new high-level overview panel. Test Plan: {F1238854} Reviewers: chad Reviewed By: chad Maniphest Tasks: T4292 Differential Revision: https://secure.phabricator.com/D15772
2016-04-20 20:06:13 +02:00
'PhabricatorConfigClusterRepositoriesController' => 'PhabricatorConfigController',
Begin standardizing garbage collectors Summary: Ref T9494. Improve support infrastructure for garbage collectors. Test Plan: - Ran `bin/phd debug trigger`, saw collectors execute. {F857852} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9494 Differential Revision: https://secure.phabricator.com/D14218
2015-10-02 01:58:43 +02:00
'PhabricatorConfigCollectorsModule' => 'PhabricatorConfigModule',
Generate expected and comparison schemata Summary: Ref T1191. This builds on the "view of the database as it exists" by building a view of the database as it is expected to exist (this is mostly empty for now) and comparing the two. We now render a view of the "comparison schema", which is the actual schema merged with the expected schema and annotated with the differences. (I'm merging them like this because it makes it easier to handle both "missing" and "surpulus" warnings in a consistent way. If we tried to annotate just the actual or expected schema, the absence of components which are expected to exist is messy to handle.) Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10496
2014-09-18 17:22:54 +02:00
'PhabricatorConfigColumnSchema' => 'PhabricatorConfigStorageSchema',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorConfigConfigPHIDType' => 'PhabricatorPHIDType',
Start of a config web interface. Summary: This is somewhat clowny, particularly in how it handles JSON encode/decode, but I've commented why I did things the way I did. The goal is to store minified JSON but show pretty-printed JSON where possible, to the user editing it. Test Plan: * Went to /config/ and saw a list of keys from the `default` config. * Clicked on one of them, submitted the default value successfully. * Changed the value to invalid JSON and got a decent error. * Changed the value to valid JSON and checked the DB to confirm it saved. * Confirmed the DB values were minified. * Confirmed the user-facing values were pretty-printed where they could be. * Confirmed that PHIDs were getting assigned properly and that isDeleted properly defaulted to false/0. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2246 Differential Revision: https://secure.phabricator.com/D4290
2012-12-28 00:20:09 +01:00
'PhabricatorConfigController' => 'PhabricatorController',
Automatically build all Lisk schemata Summary: Ref T1191. Now that the whole database is covered, we don't need to do as much work to build expected schemata. Doing them database-by-database was helpful in converting, but is just reudndant work now. Instead of requiring every application to build its Lisk objects, just build all Lisk objects. I removed `harbormaster.lisk_counter` because it is unused. It would be nice to autogenerate edge schemata, too, but that's a little trickier. Test Plan: Database setup issues are all green. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley, hach-que Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10620
2014-10-02 18:51:20 +02:00
'PhabricatorConfigCoreSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Add a UI for reviewing database schemata Summary: Ref T1191. Plan here is: - Build a tool showing the current schemata status (this diff). - Have it compare the current status to the desired status (partly here, mostly in future diffs). - Then add a migration tool, and eventually a setup issue to tell people to run it. Test Plan: Reviewed current schemata. {F204492} {F204493} {F204494} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10494
2014-09-18 17:22:18 +02:00
'PhabricatorConfigDatabaseController' => 'PhabricatorConfigController',
Load all keys, support unique keys, and provide an "all issues" view Summary: Ref T1191. Three parts: - The old way of getting key information only got primary / unique / foreign keys, not all keys. Use `SHOW INDEXES` to get all keys instead. - Track key uniqueness and raise warnings about it. - Add a new "all issues" view to show an expanded, flat view of all issues. This is just an easier way to get a list so you don't have to dig around in the hierarchical view. Test Plan: {F206351} {F206352} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10525
2014-09-19 20:46:30 +02:00
'PhabricatorConfigDatabaseIssueController' => 'PhabricatorConfigDatabaseController',
Generate expected and comparison schemata Summary: Ref T1191. This builds on the "view of the database as it exists" by building a view of the database as it is expected to exist (this is mostly empty for now) and comparing the two. We now render a view of the "comparison schema", which is the actual schema merged with the expected schema and annotated with the differences. (I'm merging them like this because it makes it easier to handle both "missing" and "surpulus" warnings in a consistent way. If we tried to annotate just the actual or expected schema, the absence of components which are expected to exist is messy to handle.) Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10496
2014-09-18 17:22:54 +02:00
'PhabricatorConfigDatabaseSchema' => 'PhabricatorConfigStorageSchema',
Add database configuration source to the source stack Summary: Read configuration from the new database source. This adds an extra MySQL connect + query to every page. They're very cheap so I think we can suffer them for now, but I'd like to put cache in front of this at some point. The difficulties are: - If we use APC, multi-frontend installs (Facebook) can't dirty it (major problem), and the CLI can't dirty it (fine for now, maybe a major problem later). - If we use Memcache, we need to add config stuff. - We could use APC in all non-Facebook installs if we can make it dirtyable from the CLI, but I don't see a reasonable way to do that. - We don't have any other caches which are faster than the database. So I'll probably implement Memcache support at some point, although this is a lame excuse for it. Test Plan: Added some config values via web UI, saw them active on the install. Reviewers: btrahan, codeblock, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221 Differential Revision: https://secure.phabricator.com/D4296
2013-01-18 00:10:21 +01:00
'PhabricatorConfigDatabaseSource' => 'PhabricatorConfigProxySource',
Load all keys, support unique keys, and provide an "all issues" view Summary: Ref T1191. Three parts: - The old way of getting key information only got primary / unique / foreign keys, not all keys. Use `SHOW INDEXES` to get all keys instead. - Track key uniqueness and raise warnings about it. - Add a new "all issues" view to show an expanded, flat view of all issues. This is just an easier way to get a list so you don't have to dig around in the hierarchical view. Test Plan: {F206351} {F206352} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10525
2014-09-19 20:46:30 +02:00
'PhabricatorConfigDatabaseStatusController' => 'PhabricatorConfigDatabaseController',
Show all configuration defaults when editing configuration Summary: Show the value for all loaded configuration sources. Test Plan: {F28469} {F28470} {F28471} Reviewers: btrahan, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4312
2013-01-01 23:10:33 +01:00
'PhabricatorConfigDefaultSource' => 'PhabricatorConfigProxySource',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorConfigDictionarySource' => 'PhabricatorConfigSource',
Modularize config modules + add edges, phid modules Summary: Fixes T6859. Adds a readout in `/config/` of installed edge and PHID types. See also D13626. Test Plan: {F643222} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T6859 Differential Revision: https://secure.phabricator.com/D13662
2015-07-21 02:08:37 +02:00
'PhabricatorConfigEdgeModule' => 'PhabricatorConfigModule',
Start of a config web interface. Summary: This is somewhat clowny, particularly in how it handles JSON encode/decode, but I've commented why I did things the way I did. The goal is to store minified JSON but show pretty-printed JSON where possible, to the user editing it. Test Plan: * Went to /config/ and saw a list of keys from the `default` config. * Clicked on one of them, submitted the default value successfully. * Changed the value to invalid JSON and got a decent error. * Changed the value to valid JSON and checked the DB to confirm it saved. * Confirmed the DB values were minified. * Confirmed the user-facing values were pretty-printed where they could be. * Confirmed that PHIDs were getting assigned properly and that isDeleted properly defaulted to false/0. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2246 Differential Revision: https://secure.phabricator.com/D4290
2012-12-28 00:20:09 +01:00
'PhabricatorConfigEditController' => 'PhabricatorConfigController',
Use transactions to show edit history for Configuration Summary: Use ApplicationTransactions in Config to create an edit history. Resolves T2256. Test Plan: {F28477} Reviewers: btrahan, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2256 Differential Revision: https://secure.phabricator.com/D4314
2013-01-02 03:14:41 +01:00
'PhabricatorConfigEditor' => 'PhabricatorApplicationTransactionEditor',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorConfigEntry' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorConfigEntryDAO',
Transactions - deploy buildTransactionTimeline against Config, Pholio, and Projects Summary: Ref T4712. These are a bit time consuming to test so might as well send off a batch now and again. Test Plan: foreach impacted controller, made sure the timeline rendered as it did before. for project column and config, noted the "should terminate" UI was also rendered unlike before. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10923
2014-12-03 21:28:53 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
Convert config to application PHIDs Summary: Ref T2715. Test Plan: Used `phid.query` to load config entries. Edited config entries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6520
2013-07-22 00:04:21 +02:00
),
Start of a config web interface. Summary: This is somewhat clowny, particularly in how it handles JSON encode/decode, but I've commented why I did things the way I did. The goal is to store minified JSON but show pretty-printed JSON where possible, to the user editing it. Test Plan: * Went to /config/ and saw a list of keys from the `default` config. * Clicked on one of them, submitted the default value successfully. * Changed the value to invalid JSON and got a decent error. * Changed the value to valid JSON and checked the DB to confirm it saved. * Confirmed the DB values were minified. * Confirmed the user-facing values were pretty-printed where they could be. * Confirmed that PHIDs were getting assigned properly and that isDeleted properly defaulted to false/0. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2246 Differential Revision: https://secure.phabricator.com/D4290
2012-12-28 00:20:09 +01:00
'PhabricatorConfigEntryDAO' => 'PhabricatorLiskDAO',
Convert config to application PHIDs Summary: Ref T2715. Test Plan: Used `phid.query` to load config entries. Edited config entries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6520
2013-07-22 00:04:21 +02:00
'PhabricatorConfigEntryQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorConfigFileSource' => 'PhabricatorConfigProxySource',
Begin moving Phabricator configuration into PHP Summary: Ref T2255. Ref T2221. Lay the groundwork to move configuration into PHP, so we can show descriptions in the web UI, do typechecking, disable application options when an application is uninstalled, etc. Test Plan: {F28421} {F28420} {F28422} Reviewers: codeblock, btrahan, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221, T2255 Differential Revision: https://secure.phabricator.com/D4306
2012-12-31 00:36:06 +01:00
'PhabricatorConfigGroupController' => 'PhabricatorConfigController',
Modularize complex HTTP parameter types Summary: Ref T9132. We have several places in the code that sometimes need to parse complex types. For example, we accept all of these in ApplicationSearch and now in ApplicationEditor: > /?subscribers=cat,dog > /?subscribers=PHID-USER-1111 > /?subscribers[]=cat&subscribers[]=PHID-USER-2222 ..etc. The logic to parse this stuff isn't too complex, but it isn't trivial either. Right now it lives in some odd places. Notably, `PhabricatorApplicationSearchEngine` has some weird helper methods for this stuff. Rather than give `EditEngine` the same set of weird helper methods, pull all this stuff out into "HTTPParameterTypes". Future diffs will add "Projects" and "Users" types where all the custom parsing/lookup logic can live. Then eventually the Search stuff can reuse these. Generally, this just breaks the code up into smaller pieces that have more specific responsibilities. Test Plan: {F944142} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14402
2015-11-04 14:05:10 +01:00
'PhabricatorConfigHTTPParameterTypesModule' => 'PhabricatorConfigModule',
Settings History Summary: Shows a timeline of all modified settings Fixes T6545 Will show all settings (no pagination, should be not so difficult to add if needed but most installs won't have hundreds of settings changes) I'm not happy by how the PhabricatorConfigTransaction object is instructed to render the config keys but i don't see any other reasonable way. We could always show the keys though. Test Plan: Changed settings and called the history page Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6545 Differential Revision: https://secure.phabricator.com/D11088
2015-01-01 15:51:44 +01:00
'PhabricatorConfigHistoryController' => 'PhabricatorConfigController',
Document the adjustment workflow and warn users about adjusting old MySQL Summary: Ref T1191. Explain the adjustment workflow, how to resolve common errors, etc. Test Plan: Read it, clicked doc links. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10758
2014-11-01 16:25:05 +01:00
'PhabricatorConfigIgnoreController' => 'PhabricatorConfigController',
Detect and raise setup warnings from within Phabricator Summary: This is basicaly a light version of D4286. The major problem with D4286 is that it's a huge leap and completely replaces the setup process in one step. Instead, I want to do this: - Add the post-setup warnings (yellow bar with "6 unresolved warnings..."). - Copy all setup checks into post-setup warnings (so every check has an old-style check and a new-style check). - Run that for a little bit and make sure it's stable. - Implement fatal post-setup checks (the red screen, vs the yellow bar). - Run that for a little bit. - Nuke setup mode and delete all the old checks. This should give us a bunch of very gradual steps toward the brave new world of simpler setup. Test Plan: - Faked APC setup failures, saw warnings raise. - Verified that this runs after restart (get + set). - Verified that this costs us only one cache hit after first-run (get only). Reviewers: btrahan, codeblock, vrana, chad Reviewed By: codeblock CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4295
2012-12-30 15:37:49 +01:00
'PhabricatorConfigIssueListController' => 'PhabricatorConfigController',
'PhabricatorConfigIssueViewController' => 'PhabricatorConfigController',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorConfigJSON' => 'Phobject',
Make Maniphest task statuses user configurable Summary: Fixes T1812. Moves the internal configuration into public space and documents it. Test Plan: - Tried to set it to some invalid stuff. - Set it to various valid things. - Browsed around, changed statuses, filtered statuses, viewed statuses, merged duplictes, examined transaction record, created tasks. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1812 Differential Revision: https://secure.phabricator.com/D8585
2014-03-25 22:05:36 +01:00
'PhabricatorConfigJSONOptionType' => 'PhabricatorConfigOptionType',
Support key schemata and column nullability Summary: Ref T1191. The major issue motivation here is that InnoDB keys have a maximum length of 767 bytes. When we move `utf8` colums to `utf8mb4` columns, they'll jump from 3 bytes per character to 4 bytes per character, which may make some indexes too long. Add key schema to help spot this. Also add nullability since it doesn't hurt. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10499
2014-09-18 17:32:21 +02:00
'PhabricatorConfigKeySchema' => 'PhabricatorConfigStorageSchema',
Start of a config web interface. Summary: This is somewhat clowny, particularly in how it handles JSON encode/decode, but I've commented why I did things the way I did. The goal is to store minified JSON but show pretty-printed JSON where possible, to the user editing it. Test Plan: * Went to /config/ and saw a list of keys from the `default` config. * Clicked on one of them, submitted the default value successfully. * Changed the value to invalid JSON and got a decent error. * Changed the value to valid JSON and checked the DB to confirm it saved. * Confirmed the DB values were minified. * Confirmed the user-facing values were pretty-printed where they could be. * Confirmed that PHIDs were getting assigned properly and that isDeleted properly defaulted to false/0. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2246 Differential Revision: https://secure.phabricator.com/D4290
2012-12-28 00:20:09 +01:00
'PhabricatorConfigListController' => 'PhabricatorConfigController',
Add a local configuration source and a non-environmental ENV config source Summary: See discussion in T2221. Before we can move configuration to the database, we have a bootstrapping problem: we need database credentials to live //somewhere// if we can't guess them (and we can only really guess localhost / root / no password). Some options for this are: - Have them live in ENV variables. - These are often somewhat unfamiliar to users. - Scripts would become a huge pain -- you'd have to dump a bunch of stuff into ENV. - Some environments have limited ability to set ENV vars. - SSH is also a pain. - Have them live in a normal config file. - This probably isn't really too awful, but: - Since we deploy/upgrade with git, we can't currently let them edit a file which already exists, or their working copy will become dirty. - So they have to copy or create a file, then edit it. - The biggest issue I have with this is that it will be difficult to give specific, easily-followed directions from Setup. The instructions need to be like "Copy template.conf.php to real.conf.php, then edit these keys: x, y, z". This isn't as easy to follow as "run script Y". - Have them live in an abnormal config file with script access (this diff). - I think this is a little better than a normal config file, because we can tell users 'run phabricator/bin/config set mysql.user phabricator' and such, which is easier to follow than editing a config file. I think this is only a marginal improvement over a normal config file and am open to arguments against this approach, but I think it will be a little easier for users to deal with than a normal config file. In most cases they should only need to store three values in this file -- db user/host/pass -- since once we have those we can bootstrap everything else. Normal config files also aren't going away for more advanced users, we're just offering a simple alternative for most users. This also adds an ENVIRONMENT file as an alternative to PHABRICATOR_ENV. This is just a simple way to specify the environment if you don't have convenient access to env vars. Test Plan: Ran `config set x y`, verified writes. Wrote to ENVIRONMENT, ran `PHABRICATOR_ENV= ./bin/repository`. Reviewers: btrahan, vrana, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2221 Differential Revision: https://secure.phabricator.com/D4294
2012-12-30 15:16:15 +01:00
'PhabricatorConfigLocalSource' => 'PhabricatorConfigProxySource',
Increase the power of `bin/config` Summary: Fixes T2254. Make the CLI for config more powerful: - Add validation for `set`. - Add `get`. - Add `list`. - Add `delete`. The `get` command produces fairly verbose JSON to support flags like `--all`, or `--source database` later. The other commands are straightforward. Test Plan: Tested `config set`: $ ./bin/config set Usage Exception: Specify a configuration key and a value to set it to. $ ./bin/config set x Usage Exception: Specify a value to set the key 'x' to. $ ./bin/config set phabricator.base-uri Usage Exception: Specify a value to set the key 'phabricator.base-uri' to. $ ./bin/config set phabricator.base-uri x Usage Exception: Config option 'phabricator.base-uri' is invalid. The URI must start with 'http://' or 'https://'. $ ./bin/config set phabricator.base-uri http://x Usage Exception: Config option 'phabricator.base-uri' is invalid. The URI must contain a dot ('.'), like 'http://example.com/', not just a bare name like 'http://example/'. Some web browsers will not set cookies on domains with no TLD. $ ./bin/config set phabricator.base-uri http://x.com Set 'phabricator.base-uri' in local configuration. $ Tested `config get`: $ ./bin/config get pygments.enabled { "config" : [] } $ ./bin/config set pygments.enabled true Set 'pygments.enabled' in local configuration. $ ./bin/config get pygments.enabled { "config" : [ { "key" : "pygments.enabled", "source" : "local", "value" : true } ] } $ Tested `config delete`: $ ./bin/config delete Usage Exception: Specify a configuration key to delete. $ ./bin/config delete x x Usage Exception: Too many arguments: expected one key. $ ./bin/config delete x Usage Exception: No such configuration key 'x'! Use `config list` to list all keys. $ ./bin/config delete pygments.enabled Deleted 'pygments.enabled' from local configuration. $ ./bin/config delete pygments.enabled Usage Exception: Configuration key 'pygments.enabled' is not set in local configuration! $ Tested `config list`: $ ./bin/config list account.editable account.minimum-password-length amazon-ec2.access-key amazon-ec2.secret-key amazon-s3.access-key amazon-s3.endpoint amazon-s3.secret-key amazon-ses.access-key amazon-ses.secret-key aphront.default-application-configuration-class audit.can-author-close-audit auth.email-domains auth.login-message auth.password-auth-enabled auth.require-email-verification auth.sessions.conduit auth.sessions.web auth.sshkeys.enabled cache.enable-deflate celerity.force-disk-reads celerity.minify celerity.resource-hash celerity.resource-path config.hide config.lock config.mask controller.oauth-registration darkconsole.always-on darkconsole.enabled debug.profile-rate debug.stop-on-redirect differential.allow-reopen differential.allow-self-accept differential.always-allow-close differential.anonymous-access differential.custom-remarkup-block-rules differential.custom-remarkup-rules differential.days-fresh differential.days-stale differential.enable-email-accept differential.expose-emails-prudently differential.field-selector differential.generated-paths differential.require-test-plan-field differential.revision-custom-detail-renderer differential.show-host-field differential.show-test-plan-field differential.whitespace-matters disqus.application-id disqus.application-secret disqus.auth-enabled disqus.auth-permanent disqus.registration-enabled disqus.shortname environment.append-paths events.listeners facebook.application-id facebook.application-secret facebook.auth-enabled facebook.auth-permanent facebook.registration-enabled facebook.require-https-auth feed.http-hooks feed.public files.image-mime-types files.viewable-mime-types gcdaemon.ttl.daemon-logs gcdaemon.ttl.differential-parse-cache gcdaemon.ttl.general-cache gcdaemon.ttl.herald-transcripts gcdaemon.ttl.markup-cache gcdaemon.ttl.task-archive github.application-id github.application-secret github.auth-enabled github.auth-permanent github.registration-enabled google.application-id google.application-secret google.auth-enabled google.auth-permanent google.registration-enabled ldap.activedirectory_domain ldap.anonymous-user-name ldap.anonymous-user-password ldap.auth-enabled ldap.base_dn ldap.hostname ldap.port ldap.real_name_attributes ldap.referrals ldap.search-first ldap.search_attribute ldap.start-tls ldap.username-attribute ldap.version load-libraries log.access.format log.access.path maniphest.custom-fields maniphest.custom-task-extensions-class maniphest.default-priority maniphest.enabled metamta.can-send-as-user metamta.default-address metamta.differential.attach-patches metamta.differential.inline-patches metamta.differential.patch-format metamta.differential.reply-handler metamta.differential.reply-handler-domain metamta.differential.subject-prefix metamta.differential.unified-comment-context metamta.diffusion.attach-patches metamta.diffusion.byte-limit metamta.diffusion.inline-patches metamta.diffusion.reply-handler metamta.diffusion.reply-handler-domain metamta.diffusion.subject-prefix metamta.diffusion.time-limit metamta.domain metamta.herald.show-hints metamta.insecure-auth-with-reply-to metamta.macro.reply-handler-domain metamta.macro.subject-prefix metamta.mail-adapter metamta.maniphest.default-public-author metamta.maniphest.public-create-email metamta.maniphest.reply-handler metamta.maniphest.reply-handler-domain metamta.maniphest.subject-prefix metamta.one-mail-per-recipient metamta.package.reply-handler metamta.package.subject-prefix metamta.pholio.reply-handler-domain metamta.pholio.subject-prefix metamta.placeholder-to-recipient metamta.precedence-bulk metamta.public-replies metamta.re-prefix metamta.recipients.show-hints metamta.reply.show-hints metamta.send-immediately metamta.single-reply-handler-prefix metamta.user-address-format metamta.vary-subjects mysql.configuration-provider mysql.host mysql.implementation mysql.pass mysql.user notification.client-uri notification.debug notification.enabled notification.log notification.pidfile notification.server-uri notification.user phabricator.application-id phabricator.application-secret phabricator.auth-enabled phabricator.auth-permanent phabricator.base-uri phabricator.csrf-key phabricator.env phabricator.mail-key phabricator.oauth-uri phabricator.production-uri phabricator.registration-enabled phabricator.serious-business phabricator.setup phabricator.show-beta-applications phabricator.show-error-callout phabricator.show-stack-traces phabricator.timezone phame.skins phd.log-directory phd.pid-directory phd.start-taskmasters phd.trace phd.verbose phid.external-loaders phpmailer.mailer phpmailer.smtp-host phpmailer.smtp-password phpmailer.smtp-port phpmailer.smtp-protocol phpmailer.smtp-user phriction.enabled policy.allow-public pygments.dropdown-choices pygments.enabled recaptcha.enabled recaptcha.private-key recaptcha.public-key remarkup.enable-embedded-youtube repository.default-local-path search.elastic.host search.engine-selector security.alternate-file-domain security.hmac-key security.require-https sendgrid.api-key sendgrid.api-user storage.default-namespace storage.engine-selector storage.local-disk.path storage.mysql-engine.max-size storage.s3.bucket storage.upload-size-limit style.monospace syntax-highlighter.engine syntax.filemap test.value tokenizer.ondemand translation.override translation.provider uri.allowed-protocols $ Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2254 Differential Revision: https://secure.phabricator.com/D4570
2013-01-22 00:27:42 +01:00
'PhabricatorConfigManagementDeleteWorkflow' => 'PhabricatorConfigManagementWorkflow',
'PhabricatorConfigManagementGetWorkflow' => 'PhabricatorConfigManagementWorkflow',
'PhabricatorConfigManagementListWorkflow' => 'PhabricatorConfigManagementWorkflow',
Allow bin/config to affect database configuration and migrate between local and database configuration Summary: Fixes T4018. Basically hits the bullet points in that task description except the "ideally" one. Test Plan: ran bin/config migrate and saw sensible output. ``` ~> ./bin/config migrate Migrating file-based config to more modern config... Skipping config of source type PhabricatorConfigDatabaseSource... Skipping config of source type PhabricatorConfigLocalSource... Skipping config of source type PhabricatorConfigDefaultSource... Done. Migrated 0 keys. ``` Reviewers: epriestley Reviewed By: epriestley Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T4018 Differential Revision: https://secure.phabricator.com/D10490
2014-10-09 01:15:05 +02:00
'PhabricatorConfigManagementMigrateWorkflow' => 'PhabricatorConfigManagementWorkflow',
Add a local configuration source and a non-environmental ENV config source Summary: See discussion in T2221. Before we can move configuration to the database, we have a bootstrapping problem: we need database credentials to live //somewhere// if we can't guess them (and we can only really guess localhost / root / no password). Some options for this are: - Have them live in ENV variables. - These are often somewhat unfamiliar to users. - Scripts would become a huge pain -- you'd have to dump a bunch of stuff into ENV. - Some environments have limited ability to set ENV vars. - SSH is also a pain. - Have them live in a normal config file. - This probably isn't really too awful, but: - Since we deploy/upgrade with git, we can't currently let them edit a file which already exists, or their working copy will become dirty. - So they have to copy or create a file, then edit it. - The biggest issue I have with this is that it will be difficult to give specific, easily-followed directions from Setup. The instructions need to be like "Copy template.conf.php to real.conf.php, then edit these keys: x, y, z". This isn't as easy to follow as "run script Y". - Have them live in an abnormal config file with script access (this diff). - I think this is a little better than a normal config file, because we can tell users 'run phabricator/bin/config set mysql.user phabricator' and such, which is easier to follow than editing a config file. I think this is only a marginal improvement over a normal config file and am open to arguments against this approach, but I think it will be a little easier for users to deal with than a normal config file. In most cases they should only need to store three values in this file -- db user/host/pass -- since once we have those we can bootstrap everything else. Normal config files also aren't going away for more advanced users, we're just offering a simple alternative for most users. This also adds an ENVIRONMENT file as an alternative to PHABRICATOR_ENV. This is just a simple way to specify the environment if you don't have convenient access to env vars. Test Plan: Ran `config set x y`, verified writes. Wrote to ENVIRONMENT, ran `PHABRICATOR_ENV= ./bin/repository`. Reviewers: btrahan, vrana, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2221 Differential Revision: https://secure.phabricator.com/D4294
2012-12-30 15:16:15 +01:00
'PhabricatorConfigManagementSetWorkflow' => 'PhabricatorConfigManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorConfigManagementWorkflow' => 'PhabricatorManagementWorkflow',
Modularize config modules + add edges, phid modules Summary: Fixes T6859. Adds a readout in `/config/` of installed edge and PHID types. See also D13626. Test Plan: {F643222} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T6859 Differential Revision: https://secure.phabricator.com/D13662
2015-07-21 02:08:37 +02:00
'PhabricatorConfigModule' => 'Phobject',
'PhabricatorConfigModuleController' => 'PhabricatorConfigController',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorConfigOption' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'Phobject',
'PhabricatorMarkupInterface',
Add Disqus, Facebook, Google, GitHub auth config; AWS config Summary: Also improve behavior for the "unknown config" warning. Test Plan: Looked at configs, went through unknown config workflow. Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4310
2013-01-01 23:09:29 +01:00
),
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorConfigOptionType' => 'Phobject',
Modularize config modules + add edges, phid modules Summary: Fixes T6859. Adds a readout in `/config/` of installed edge and PHID types. See also D13626. Test Plan: {F643222} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T6859 Differential Revision: https://secure.phabricator.com/D13662
2015-07-21 02:08:37 +02:00
'PhabricatorConfigPHIDModule' => 'PhabricatorConfigModule',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorConfigProxySource' => 'PhabricatorConfigSource',
Add dialog to purge opcode/data caches Summary: Reachable via the cache config page, restricted to admins only. This makes it convenient to hotfix phabricator without requiring a restart. Test Plan: - Local dev machine doesn't have apc, so I get the not installed message. - Faked the name and isEnabled parameters, verified dialog shows up as expected. - Didn't test clear code Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: tycho.tatitscheff, joshuaspence, Korvin Differential Revision: https://secure.phabricator.com/D14064
2015-09-10 23:18:52 +02:00
'PhabricatorConfigPurgeCacheController' => 'PhabricatorConfigController',
Modularize Aphront exception handling Summary: Ref T1806. Ref T7173. Depends on D14047. Currently, all exception handling is in this big messy clump in `AphrontDefaultApplicationConfiguration`. Split it out into modular classes. This will let a future change add new classes in the Phacility cluster which intercept particular exceptions we care about and replaces the default, generic responses with more useful, tailored responses. Test Plan: {F777391} - Hit a Conduit error (made a method throw). - Hit an Ajax error (made comment preview throw). - Hit a high security error (tried to edit TOTP). - Hit a rate limiting error (added a bunch of email addresses). - Hit a policy error (tried to look at something with no permission). - Hit an arbitrary exception (made a randomc ontroller throw). Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14049
2015-09-03 19:04:42 +02:00
'PhabricatorConfigRequestExceptionHandlerModule' => 'PhabricatorConfigModule',
Improve top-level exception handling Summary: Fixes T6692. Addresses two main issues: - The write guard would sometimes not get disposed of on exception pathways, generating an unnecessary secondary error which was just a symptom of the original root error. - This was generally confusing and reduced the quality of reports we received because users would report the symptomatic error sometimes instead of the real error. - Instead, reflow the handling so that we always dispose of the write guard if we create one. - If we missed the Controller-level error page generation (normally, a nice page with full CSS, etc), we'd jump straight to Startup-level error page generation (very basic plain text). - A large class of errors occur too early or too late to be handled by Controller-level pages, but many of these errors are not fundamental, and the plain text page is excessively severe. - Provide a mid-level simple HTML error page for errors which can't get full CSS, but also aren't so fundamental that we have no recourse but plain text. Test Plan: Mid-level errors now produce an intentional-looking error page: {F259885} Verified that setup errors still render properly. @chad, feel free to tweak the exception page -- I just did a rough pass on it. Like the setup error stuff, it doesn't have Celerity, so we can't use `{$colors}` and no other CSS will be loaded. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley, chad Maniphest Tasks: T6692 Differential Revision: https://secure.phabricator.com/D11126
2015-01-02 19:49:27 +01:00
'PhabricatorConfigResponse' => 'AphrontStandaloneHTMLResponse',
Add a UI for reviewing database schemata Summary: Ref T1191. Plan here is: - Build a tool showing the current schemata status (this diff). - Have it compare the current status to the desired status (partly here, mostly in future diffs). - Then add a migration tool, and eventually a setup issue to tell people to run it. Test Plan: Reviewed current schemata. {F204492} {F204493} {F204494} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10494
2014-09-18 17:22:18 +02:00
'PhabricatorConfigSchemaQuery' => 'Phobject',
Generate expected and comparison schemata Summary: Ref T1191. This builds on the "view of the database as it exists" by building a view of the database as it is expected to exist (this is mostly empty for now) and comparing the two. We now render a view of the "comparison schema", which is the actual schema merged with the expected schema and annotated with the differences. (I'm merging them like this because it makes it easier to handle both "missing" and "surpulus" warnings in a consistent way. If we tried to annotate just the actual or expected schema, the absence of components which are expected to exist is messy to handle.) Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10496
2014-09-18 17:22:54 +02:00
'PhabricatorConfigSchemaSpec' => 'Phobject',
'PhabricatorConfigServerSchema' => 'PhabricatorConfigStorageSchema',
Modularize config modules + add edges, phid modules Summary: Fixes T6859. Adds a readout in `/config/` of installed edge and PHID types. See also D13626. Test Plan: {F643222} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T6859 Differential Revision: https://secure.phabricator.com/D13662
2015-07-21 02:08:37 +02:00
'PhabricatorConfigSiteModule' => 'PhabricatorConfigModule',
Add an extensible "SiteSource" for configuration Summary: Fixes T2792. This adds a pluggable configuration layer between all the stuff on disk (local/file) and the runtime configurable stuff (database). An install can subclass this source and: - For Phacility, query a remote service (like Almanac) to retrieve hostname-based configuration, allowing one install to serve multiple instances. - Maybe for Phacility, query a remote service (like Phlux) to retrieve sitevar-like configuration (e.g., put everything in readonly mode to deal with a maintenance issue?). Not sure if we'll do this or not. We might just nuke Phlux since Almanac is sort-of-a-superset of it for our purposes. - For third parties, query some other remote service if that makes config management easier. In particular, it would theoretically let you put locked config in Zookeeper or whatever else you want. Test Plan: Added a fake source and saw it inject configuration. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2792 Differential Revision: https://secure.phabricator.com/D10787
2014-11-06 00:30:40 +01:00
'PhabricatorConfigSiteSource' => 'PhabricatorConfigProxySource',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorConfigSource' => 'Phobject',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorConfigStackSource' => 'PhabricatorConfigSource',
Generate expected and comparison schemata Summary: Ref T1191. This builds on the "view of the database as it exists" by building a view of the database as it is expected to exist (this is mostly empty for now) and comparing the two. We now render a view of the "comparison schema", which is the actual schema merged with the expected schema and annotated with the differences. (I'm merging them like this because it makes it easier to handle both "missing" and "surpulus" warnings in a consistent way. If we tried to annotate just the actual or expected schema, the absence of components which are expected to exist is messy to handle.) Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10496
2014-09-18 17:22:54 +02:00
'PhabricatorConfigStorageSchema' => 'Phobject',
'PhabricatorConfigTableSchema' => 'PhabricatorConfigStorageSchema',
Use transactions to show edit history for Configuration Summary: Use ApplicationTransactions in Config to create an edit history. Resolves T2256. Test Plan: {F28477} Reviewers: btrahan, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2256 Differential Revision: https://secure.phabricator.com/D4314
2013-01-02 03:14:41 +01:00
'PhabricatorConfigTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorConfigTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Allow configuration to be explicitly validated, including validation of complex attributes Summary: - Allows us to implement setup warnings for edits which don't go through the web UI, e.g. "you edited a config file and set value X to something goofy". - Allows us to implement more sophisticated validations, beyond basic type checks (e.g., "phabricator.base-uri" must be a URI). - Fixes T358 (or, close enough -- fixes it for all options which have been migrated as per T2255. Test Plan: Set "darkconsole.enabled" to "xyz" in my config, observed setup warning. Added fake validation, observed web UI edit error. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255, T358 Differential Revision: https://secure.phabricator.com/D4315
2013-01-02 03:15:03 +01:00
'PhabricatorConfigValidationException' => 'Exception',
Move version numbers to a dedicated "Versions" panel Summary: Currently, Version numbers are sort of randomly shown on "All Settings" beacuse we didn't have any better place to put them. Now that we have modules, expose them as a config module. Test Plan: {F906426} Grepped for "all settings" to look for other references to the old location, but didn't get any relevant hits. Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D14327
2015-10-24 17:13:22 +02:00
'PhabricatorConfigVersionsModule' => 'PhabricatorConfigModule',
First version of "Quest Tracker" Home NUX Summary: Ref T5317. General idea here is that Dashboards are replacing the home page soon. We think they'll do a good job for normal users, but they aren't very good for new administrators who have just completed an install. In this case, any dashboard we put there by default will be empty and not very useful or helpful. It's also technically a bit messy to build objects by default. Instead, give new administrators a "Quest Tracker" UI to help them get through things. When they're done with setup steps, they build a dashboard and install it to replace the home page. They can add install-specific welcome messages during this process, so hopefully this will also ease onboarding for non-administrator users. For now, you have to go to Config > Welcome Screen explicitly to see this UI. We can tweak/test it for a bit before replacing the home page. Test Plan: {F169226} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T5317 Differential Revision: https://secure.phabricator.com/D9660
2014-06-23 18:37:51 +02:00
'PhabricatorConfigWelcomeController' => 'PhabricatorConfigController',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorConpherenceApplication' => 'PhabricatorApplication',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorConpherencePreferencesSettingsPanel' => 'PhabricatorSettingsPanel',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorConpherenceThreadPHIDType' => 'PhabricatorPHIDType',
Move DarkConsole to an application Summary: Ref T5702. Primarily, this gets the custom DarkConsole URI routes out of the Aphront core and into an Application, like almost all other routes. Test Plan: Used DarkConsole. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D10695
2014-10-13 20:17:09 +02:00
'PhabricatorConsoleApplication' => 'PhabricatorApplication',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorConsoleContentSource' => 'PhabricatorContentSource',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorContentSource' => 'Phobject',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorContentSourceModule' => 'PhabricatorConfigModule',
Track content sources (email, web, conduit, mobile) for replies Summary: When an object is updated, record the content source for the update. This mostly isn't terribly useful but one concrete thing I want to do with it is let admins audit via-email replies more easily since there are a bunch of options which let you do hyjinx if you intentionally configure them insecurely. I think having a little more auditability around this feature is generally good. At some point I'm going to turn this into a link admins can click to see details. It also allows us to see how frequently different mechanisms are used, and lets you see if someone is at their desk or on a mobile or whatever, at least indirectly. The "tablet" and "mobile" sources are currently unused but I figured I'd throw them in anyway. SMS support should definitely happen at some point. Not 100% sure about the design for this, I might change it to plain text at some point. Test Plan: Updated objects and saw update sources rendered. Reviewers: jungejason, tuomaspelkonen, aran Reviewed By: jungejason CC: aran, epriestley, jungejason Differential Revision: 844
2011-08-22 19:25:45 +02:00
'PhabricatorContentSourceView' => 'AphrontView',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorContributedToObjectEdgeType' => 'PhabricatorEdgeType',
More phabricator organizational stuff.
2011-01-23 02:48:55 +01:00
'PhabricatorController' => 'AphrontController',
Consolidate use of magical cookie name strings Summary: Ref T4339. We have more magical cookie names than we should, move them all to a central location. Test Plan: Registered, logged in, linked account, logged out. See inlines. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4339 Differential Revision: https://secure.phabricator.com/D8041
2014-01-23 23:01:35 +01:00
'PhabricatorCookies' => 'Phobject',
Add "Core" config, with complex validation Summary: This is more or less a copy of the validation which lives in `webroot/index.php` right now, but I don't want to wipe that out just yet because there's no way for normal users to see this new validation. Test Plan: Tried to set "phabricator.base-uri" to crazy nonsense, was harshly rebuffed. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4316
2013-01-02 03:22:48 +01:00
'PhabricatorCoreConfigOptions' => 'PhabricatorApplicationConfigOptions',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorCountdown' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorCountdownDAO',
'PhabricatorPolicyInterface',
Make Countdown Flaggable Summary: Ref T8888. Cool man, like, more flags. Test Plan: Flag it, Tag it, and Bag it. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T8888 Differential Revision: https://secure.phabricator.com/D13653
2015-07-18 21:19:32 +02:00
'PhabricatorFlaggableInterface',
Moderize Countdown Summary: [DRAFT] Ref T8895. Makes a reasonable attempt at: - Project Support - Timeline / History - Better Search - Better ObjectItemLists Test Plan: Needs better testing (I'm sleepy) Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: eadler, epriestley, Korvin Maniphest Tasks: T8895 Differential Revision: https://secure.phabricator.com/D13660
2015-07-22 22:35:34 +02:00
'PhabricatorSubscribableInterface',
'PhabricatorApplicationTransactionInterface',
Mmmm, Countdown Tokens Summary: Allow Countdowns to reveive tokens Test Plan: Give token, see token. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13688
2015-07-23 19:56:00 +02:00
'PhabricatorTokenReceiverInterface',
Implementing Spaces in Countdown Summary: Implements T8734 Test Plan: Verify that countdowns can have spaces associated with them. Verify that non-default spaces are displayed in the header of the countdowns in the result of the query. Reviewers: lpriestley, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13634
2015-07-15 19:17:51 +02:00
'PhabricatorSpacesInterface',
Moderize Countdown Summary: [DRAFT] Ref T8895. Makes a reasonable attempt at: - Project Support - Timeline / History - Better Search - Better ObjectItemLists Test Plan: Needs better testing (I'm sleepy) Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: eadler, epriestley, Korvin Maniphest Tasks: T8895 Differential Revision: https://secure.phabricator.com/D13660
2015-07-22 22:35:34 +02:00
'PhabricatorProjectInterface',
Countdown revamp 2 Summary: Now has policy support (not really) Now uses CountdownQuery Now has handles Now uses common way for remarkup Remarkup still looks terrible Test Plan: Added countdowns, edited countdowns. Did even embed some. Couldn't break it Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2624 Differential Revision: https://secure.phabricator.com/D6012
2013-05-23 15:47:54 +02:00
),
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorCountdownApplication' => 'PhabricatorApplication',
Countdown Summary: Addon that allows you to create a live countdown page to some event. Here is the ticket that this code is based on https://secure.phabricator.com/T36 Test Plan: Tested by manually setting dates in the timer.js file and checking if they made sense. I'm not sure if it works across different timezones though. Reviewers: epriestley CC: Differential Revision: 436
2011-06-13 01:06:17 +02:00
'PhabricatorCountdownController' => 'PhabricatorController',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorCountdownCountdownPHIDType' => 'PhabricatorPHIDType',
Countdown Summary: Addon that allows you to create a live countdown page to some event. Here is the ticket that this code is based on https://secure.phabricator.com/T36 Test Plan: Tested by manually setting dates in the timer.js file and checking if they made sense. I'm not sure if it works across different timezones though. Reviewers: epriestley CC: Differential Revision: 436
2011-06-13 01:06:17 +02:00
'PhabricatorCountdownDAO' => 'PhabricatorLiskDAO',
Moderize Countdown Summary: [DRAFT] Ref T8895. Makes a reasonable attempt at: - Project Support - Timeline / History - Better Search - Better ObjectItemLists Test Plan: Needs better testing (I'm sleepy) Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: eadler, epriestley, Korvin Maniphest Tasks: T8895 Differential Revision: https://secure.phabricator.com/D13660
2015-07-22 22:35:34 +02:00
'PhabricatorCountdownDefaultEditCapability' => 'PhabricatorPolicyCapability',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'PhabricatorCountdownDefaultViewCapability' => 'PhabricatorPolicyCapability',
Countdown Summary: Addon that allows you to create a live countdown page to some event. Here is the ticket that this code is based on https://secure.phabricator.com/T36 Test Plan: Tested by manually setting dates in the timer.js file and checking if they made sense. I'm not sure if it works across different timezones though. Reviewers: epriestley CC: Differential Revision: 436
2011-06-13 01:06:17 +02:00
'PhabricatorCountdownDeleteController' => 'PhabricatorCountdownController',
'PhabricatorCountdownEditController' => 'PhabricatorCountdownController',
Convert Countdown to EditEngine Summary: Fixes T10684. Fixes T10520. This primarily implements a date/epoch field, and then does a bunch of standard plumbing. Test Plan: - Created countdowns. - Edited countdowns. - Used HTTP prefilling. - Created a countdown ending on "Christmas Morning", etc. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10520, T10684 Differential Revision: https://secure.phabricator.com/D15655
2016-04-07 20:06:26 +02:00
'PhabricatorCountdownEditEngine' => 'PhabricatorEditEngine',
Moderize Countdown Summary: [DRAFT] Ref T8895. Makes a reasonable attempt at: - Project Support - Timeline / History - Better Search - Better ObjectItemLists Test Plan: Needs better testing (I'm sleepy) Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: eadler, epriestley, Korvin Maniphest Tasks: T8895 Differential Revision: https://secure.phabricator.com/D13660
2015-07-22 22:35:34 +02:00
'PhabricatorCountdownEditor' => 'PhabricatorApplicationTransactionEditor',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'PhabricatorCountdownListController' => 'PhabricatorCountdownController',
Add mailKeys to Countdown Summary: Adds mailkeys and reply handler support Test Plan: Edit Countdown, New Countdown, no errors. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13713
2015-07-26 00:47:07 +02:00
'PhabricatorCountdownMailReceiver' => 'PhabricatorObjectMailReceiver',
Use application PHIDs in countdown Summary: Ref T2715. Swap countdown to application PHIDs. Test Plan: Used `phid.lookup`; `phid.query`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6532
2013-07-22 23:42:25 +02:00
'PhabricatorCountdownQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhabricatorCountdownRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Moderize Countdown Summary: [DRAFT] Ref T8895. Makes a reasonable attempt at: - Project Support - Timeline / History - Better Search - Better ObjectItemLists Test Plan: Needs better testing (I'm sleepy) Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: eadler, epriestley, Korvin Maniphest Tasks: T8895 Differential Revision: https://secure.phabricator.com/D13660
2015-07-22 22:35:34 +02:00
'PhabricatorCountdownReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
'PhabricatorCountdownSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Modernize Countdown somewhat Summary: Far from perfect, but better? Test Plan: {F51153} {F51154} {F51155} Reviewers: btrahan, chad Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6533
2013-07-23 15:16:19 +02:00
'PhabricatorCountdownSearchEngine' => 'PhabricatorApplicationSearchEngine',
Moderize Countdown Summary: [DRAFT] Ref T8895. Makes a reasonable attempt at: - Project Support - Timeline / History - Better Search - Better ObjectItemLists Test Plan: Needs better testing (I'm sleepy) Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: eadler, epriestley, Korvin Maniphest Tasks: T8895 Differential Revision: https://secure.phabricator.com/D13660
2015-07-22 22:35:34 +02:00
'PhabricatorCountdownTransaction' => 'PhabricatorApplicationTransaction',
Add Comments to Countdown Summary: 3, 2, 1, Liftoff! (Adds basic commenting to countdown) Test Plan: asdf asdf asdf Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T8895 Differential Revision: https://secure.phabricator.com/D13707
2015-07-25 00:40:55 +02:00
'PhabricatorCountdownTransactionComment' => 'PhabricatorApplicationTransactionComment',
Moderize Countdown Summary: [DRAFT] Ref T8895. Makes a reasonable attempt at: - Project Support - Timeline / History - Better Search - Better ObjectItemLists Test Plan: Needs better testing (I'm sleepy) Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: eadler, epriestley, Korvin Maniphest Tasks: T8895 Differential Revision: https://secure.phabricator.com/D13660
2015-07-22 22:35:34 +02:00
'PhabricatorCountdownTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Solidify PHUITwoColumnView as a page layout Summary: Rolls out a new "Object Page" design with PHUITwoColumnView. This is reasonably polished, but wanted to post it up for you now for feedback before chasing down minor bugs. This implements TwoColumn in the following applications: - Ponder - Paste - Slowvote - Countdown - Projects - Profile - Passphrase This helped track down display issues and inconsistencies and make sure the layout was flexible for different pages. Test Plan: Test each of the applications on mobile, tablet, and desktop breakpoints. {F1135705} {F1135706} {F1135707} {F1135708} {F1135709} {F1135710} {F1135711} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15366
2016-02-26 23:34:51 +01:00
'PhabricatorCountdownView' => 'AphrontView',
Countdown Summary: Addon that allows you to create a live countdown page to some event. Here is the ticket that this code is based on https://secure.phabricator.com/T36 Test Plan: Tested by manually setting dates in the timer.js file and checking if they made sense. I'm not sure if it works across different timezones though. Reviewers: epriestley CC: Differential Revision: 436
2011-06-13 01:06:17 +02:00
'PhabricatorCountdownViewController' => 'PhabricatorCountdownController',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorCredentialsUsedByObjectEdgeType' => 'PhabricatorEdgeType',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorCursorPagedPolicyAwareQuery' => 'PhabricatorPolicyAwareQuery',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorCustomField' => 'Phobject',
'PhabricatorCustomFieldAttachment' => 'Phobject',
Allow configuration to have custom UI types Summary: Ref T1703. This sets the stage for (but does not yet implement) custom UI types for config. In particular, a draggable list for custom fields. I might make all the builtin types go through this at some point too, but don't really want to bother for the moment. It would be very slightly cleaner but woudn't get us much of anything. Test Plan: UI now renders via custom code, although that code does nothing (produces an unadorned text field): {F45693} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6154
2013-06-07 21:36:18 +02:00
'PhabricatorCustomFieldConfigOptionType' => 'PhabricatorConfigOptionType',
Begin generalizing custom fields Summary: Ref T1703. We have currently have two custom field implementations (Maniphest, Differential) and are about to add a third (User, see D6122). I'd like to generalize custom fields before doing a third implementation, so we don't back ourselves into the ApplicationTransactions corner we have with Maniphest/Differential/Audit. For the most part, the existing custom fields work well and can be directly generalized. There are three specific things I want to improve, though: - Integration with ApplicationSearch: Custom fields aren't indexable. ApplicationSearch is now online and seems stable and good. D5278 provides a template for a backend which can integrate with ApplicationSearch, and ApplicationSearch solves many of the other UI problems implied by exposing custom fields into search (principally, giant pages full of query fields). Generally, I want to provide stronger builtin integration between custom fields and ApplicationSearch. - Integration with ApplicationTransactions: Likewise, custom fields should support more native integrations with ApplicationTransactions, which are also online and seem stable and well designed. - Selection and sorting: Selecting and sorting custom fields is a huge mess right now. I want to move this into config now that we have the UI to support it, and move away from requiring users to subclass a ton of stuff just to add a field. For ApplicationSearch, I've adopted and generalized D5278. For ApplicationTransactions, I haven't made any specific affordances yet. For selection and sorting, I've partially implemented config-based selection and sorting. It will work like this: - We add a new configuration value, like `differential.fields`. In the UI, this is a draggable list of supported fields. Fields can be reordered, and most fields can be disabled. - We load every avialable field to populate this list. New fields will appear at the bottom. - There are two downsides to this approach: - If we add fields in the upstream at a later date, they will appear at the end of the list if an install has customized list order or disabled fields, even if we insert them elsewhere in the upstream. - If we reorder fields in the upstream, the reordering will not be reflected in install which have customized the order/availability. - I think these are both acceptable costs. We only incur them if an admin edits this config, which implies they'll know how to fix it if they want to. - We can fix both of these problems with a straightforward configuration migration if we want to bother. - There are numerous upsides to this approach: - We can delete a bunch of code and replace it with simple configuration. - In general, we don't need the "selector" classes anymore. - Users can enable available-but-disabled fields with one click. - Users can add fields by putting their implementations in `src/extensions/` with zero subclassing or libphutil stuff. - Generally, it's super easy for users to understand. This doesn't actually do anything yet and will probably see some adjustments before anything starts running it. Test Plan: Static checks only, this code isn't reachable yet. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6147
2013-06-06 23:52:40 +02:00
'PhabricatorCustomFieldDataNotAvailableException' => 'Exception',
Partially support CustomFields in EditEngine Summary: Ref T9132. This isn't perfect, but doesn't break any existing functionality. This stuff works: - Editing values. - Reordering fields. - All builtin field tyepes. This stuff may not work yet: - Assigning custom field defaults. - Some conduit stuff. - Fully custom fields? - Locking/hiding fields? Didn't actually test this one. I'll keep chipping away at that stuff. In some cases, it may be easier to convert all the CustomField apps first, although Differential might be a fair bit of work. Test Plan: Created a bunch of custom fields of every avialable type and edited them. {F1008789} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14617
2015-11-29 19:47:16 +01:00
'PhabricatorCustomFieldEditEngineExtension' => 'PhabricatorEditEngineExtension',
'PhabricatorCustomFieldEditField' => 'PhabricatorEditField',
'PhabricatorCustomFieldEditType' => 'PhabricatorEditType',
Modularize fulltext indexing of Projects, Subscriptions and Custom Fields Summary: Ref T9979. This is going to become `FulltextEngine`, but pave the way for that by pulling extensions out of it. Test Plan: {F1036624} - Used `bin/search index Txxx`, saw projects, subscribers and custom fields rebuild in the index. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14835
2015-12-21 15:31:31 +01:00
'PhabricatorCustomFieldFulltextEngineExtension' => 'PhabricatorFulltextEngineExtension',
Make Herald custom field integration modular Summary: Ref T8726. The existing implementation is largely made redundant by the newer modular implementation. Test Plan: Created a custom field rule, set custom field to various values until it matched, saw effect and proper transcripts. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13497
2015-07-06 22:15:58 +02:00
'PhabricatorCustomFieldHeraldField' => 'HeraldField',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'PhabricatorCustomFieldHeraldFieldGroup' => 'HeraldFieldGroup',
Begin generalizing custom fields Summary: Ref T1703. We have currently have two custom field implementations (Maniphest, Differential) and are about to add a third (User, see D6122). I'd like to generalize custom fields before doing a third implementation, so we don't back ourselves into the ApplicationTransactions corner we have with Maniphest/Differential/Audit. For the most part, the existing custom fields work well and can be directly generalized. There are three specific things I want to improve, though: - Integration with ApplicationSearch: Custom fields aren't indexable. ApplicationSearch is now online and seems stable and good. D5278 provides a template for a backend which can integrate with ApplicationSearch, and ApplicationSearch solves many of the other UI problems implied by exposing custom fields into search (principally, giant pages full of query fields). Generally, I want to provide stronger builtin integration between custom fields and ApplicationSearch. - Integration with ApplicationTransactions: Likewise, custom fields should support more native integrations with ApplicationTransactions, which are also online and seem stable and well designed. - Selection and sorting: Selecting and sorting custom fields is a huge mess right now. I want to move this into config now that we have the UI to support it, and move away from requiring users to subclass a ton of stuff just to add a field. For ApplicationSearch, I've adopted and generalized D5278. For ApplicationTransactions, I haven't made any specific affordances yet. For selection and sorting, I've partially implemented config-based selection and sorting. It will work like this: - We add a new configuration value, like `differential.fields`. In the UI, this is a draggable list of supported fields. Fields can be reordered, and most fields can be disabled. - We load every avialable field to populate this list. New fields will appear at the bottom. - There are two downsides to this approach: - If we add fields in the upstream at a later date, they will appear at the end of the list if an install has customized list order or disabled fields, even if we insert them elsewhere in the upstream. - If we reorder fields in the upstream, the reordering will not be reflected in install which have customized the order/availability. - I think these are both acceptable costs. We only incur them if an admin edits this config, which implies they'll know how to fix it if they want to. - We can fix both of these problems with a straightforward configuration migration if we want to bother. - There are numerous upsides to this approach: - We can delete a bunch of code and replace it with simple configuration. - In general, we don't need the "selector" classes anymore. - Users can enable available-but-disabled fields with one click. - Users can add fields by putting their implementations in `src/extensions/` with zero subclassing or libphutil stuff. - Generally, it's super easy for users to understand. This doesn't actually do anything yet and will probably see some adjustments before anything starts running it. Test Plan: Static checks only, this code isn't reachable yet. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6147
2013-06-06 23:52:40 +02:00
'PhabricatorCustomFieldImplementationIncompleteException' => 'Exception',
'PhabricatorCustomFieldIndexStorage' => 'PhabricatorLiskDAO',
Support configuration-driven custom fields Summary: Ref T1702. Ref T3718. There are a couple of things going on here: **PhabricatorCustomFieldList**: I added `PhabricatorCustomFieldList`, which is just a convenience class for dealing with lists of fields. Often, current field code does something like this inline in a Controller: foreach ($fields as $field) { // do some junk } Often, that junk has some slightly subtle implications. Move all of it to `$list->doSomeJunk()` methods (like `appendFieldsToForm()`, `loadFieldsFromStorage()`) to reduce code duplication and prevent errors. This additionally moves an existing list-convenience method there, out of `PhabricatorPropertyListView`. **PhabricatorUserConfiguredCustomFieldStorage**: Adds `PhabricatorUserConfiguredCustomFieldStorage` for storing custom field data (like "ICQ Handle", "Phone Number", "Desk", "Favorite Flower", etc). **Configuration-Driven Custom Fields**: Previously, I was thinking about doing these with interfaces, but as I thought about it more I started to dislike that approach. Instead, I built proxies into `PhabricatorCustomField`. Basically, this means that fields (like a custom, configuration-driven "Favorite Flower" field) can just use some other Field to actually provide their implementation (like a "standard" field which knows how to render text areas). The previous approach would have involed subclasssing the "standard" field and implementing an interface, but that would mean that every application would have at least two "base" fields and generally just seemed bleh as I worked through it. The cost of this approach is that we need a bunch of `proxy` junk in the base class, but that's a one-time cost and I think it simplifies all the implementations and makes them a lot less magical (e.g., all of the custom fields now extend the right base field classes). **Fixed Some Bugs**: Some of this code hadn't really been run yet and had minor bugs. Test Plan: {F54240} {F54241} {F54242} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1702, T1703, T3718 Differential Revision: https://secure.phabricator.com/D6749
2013-08-14 17:10:16 +02:00
'PhabricatorCustomFieldList' => 'Phobject',
Modularize parser for "Closes task X as Y" Summary: Ref T3886. Ref T3872. Ref T1812. We have several parsers which look for textual references to other objects, like: Closes Tx. Depends on Dy. Reverts Dz. Currently, these are pretty hard coded, don't get all the edge cases right, and don't generalize well. They're also implemented in the middle of Differential's field code. So I want to: - Share more code so that, e.g., "Tx, Ty" always works (only some rules support it right now); - fix bugs in the parser, like T3872; - make this a modular, extensible process which runs against custom fields, not a builtin part of fields; - make the internals more flexible to accommodate custom stuff like T1812. This implements the "Verbs optional-noun Object, Optional Other Objects optional-as-something." grammar in a general way so subclasses can just plug in their keywords. Runtime code doesn't touch this yet. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3872, T1812, T3886 Differential Revision: https://secure.phabricator.com/D8261
2014-02-18 00:53:47 +01:00
'PhabricatorCustomFieldMonogramParser' => 'Phobject',
Flesh out ApplicationTransactions/CustomField integration Summary: None of this code is reachable yet. See discussion in D6147. Ref T1703. Provide tighter integration between ApplicationTransactions and CustomField. Basically, I'm just trying to get all the shared stuff into the base implementation. Test Plan: Code not reachable. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6149
2013-06-06 23:53:07 +02:00
'PhabricatorCustomFieldNotAttachedException' => 'Exception',
Support configuration-driven custom fields Summary: Ref T1702. Ref T3718. There are a couple of things going on here: **PhabricatorCustomFieldList**: I added `PhabricatorCustomFieldList`, which is just a convenience class for dealing with lists of fields. Often, current field code does something like this inline in a Controller: foreach ($fields as $field) { // do some junk } Often, that junk has some slightly subtle implications. Move all of it to `$list->doSomeJunk()` methods (like `appendFieldsToForm()`, `loadFieldsFromStorage()`) to reduce code duplication and prevent errors. This additionally moves an existing list-convenience method there, out of `PhabricatorPropertyListView`. **PhabricatorUserConfiguredCustomFieldStorage**: Adds `PhabricatorUserConfiguredCustomFieldStorage` for storing custom field data (like "ICQ Handle", "Phone Number", "Desk", "Favorite Flower", etc). **Configuration-Driven Custom Fields**: Previously, I was thinking about doing these with interfaces, but as I thought about it more I started to dislike that approach. Instead, I built proxies into `PhabricatorCustomField`. Basically, this means that fields (like a custom, configuration-driven "Favorite Flower" field) can just use some other Field to actually provide their implementation (like a "standard" field which knows how to render text areas). The previous approach would have involed subclasssing the "standard" field and implementing an interface, but that would mean that every application would have at least two "base" fields and generally just seemed bleh as I worked through it. The cost of this approach is that we need a bunch of `proxy` junk in the base class, but that's a one-time cost and I think it simplifies all the implementations and makes them a lot less magical (e.g., all of the custom fields now extend the right base field classes). **Fixed Some Bugs**: Some of this code hadn't really been run yet and had minor bugs. Test Plan: {F54240} {F54241} {F54242} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1702, T1703, T3718 Differential Revision: https://secure.phabricator.com/D6749
2013-08-14 17:10:16 +02:00
'PhabricatorCustomFieldNotProxyException' => 'Exception',
Begin generalizing custom fields Summary: Ref T1703. We have currently have two custom field implementations (Maniphest, Differential) and are about to add a third (User, see D6122). I'd like to generalize custom fields before doing a third implementation, so we don't back ourselves into the ApplicationTransactions corner we have with Maniphest/Differential/Audit. For the most part, the existing custom fields work well and can be directly generalized. There are three specific things I want to improve, though: - Integration with ApplicationSearch: Custom fields aren't indexable. ApplicationSearch is now online and seems stable and good. D5278 provides a template for a backend which can integrate with ApplicationSearch, and ApplicationSearch solves many of the other UI problems implied by exposing custom fields into search (principally, giant pages full of query fields). Generally, I want to provide stronger builtin integration between custom fields and ApplicationSearch. - Integration with ApplicationTransactions: Likewise, custom fields should support more native integrations with ApplicationTransactions, which are also online and seem stable and well designed. - Selection and sorting: Selecting and sorting custom fields is a huge mess right now. I want to move this into config now that we have the UI to support it, and move away from requiring users to subclass a ton of stuff just to add a field. For ApplicationSearch, I've adopted and generalized D5278. For ApplicationTransactions, I haven't made any specific affordances yet. For selection and sorting, I've partially implemented config-based selection and sorting. It will work like this: - We add a new configuration value, like `differential.fields`. In the UI, this is a draggable list of supported fields. Fields can be reordered, and most fields can be disabled. - We load every avialable field to populate this list. New fields will appear at the bottom. - There are two downsides to this approach: - If we add fields in the upstream at a later date, they will appear at the end of the list if an install has customized list order or disabled fields, even if we insert them elsewhere in the upstream. - If we reorder fields in the upstream, the reordering will not be reflected in install which have customized the order/availability. - I think these are both acceptable costs. We only incur them if an admin edits this config, which implies they'll know how to fix it if they want to. - We can fix both of these problems with a straightforward configuration migration if we want to bother. - There are numerous upsides to this approach: - We can delete a bunch of code and replace it with simple configuration. - In general, we don't need the "selector" classes anymore. - Users can enable available-but-disabled fields with one click. - Users can add fields by putting their implementations in `src/extensions/` with zero subclassing or libphutil stuff. - Generally, it's super easy for users to understand. This doesn't actually do anything yet and will probably see some adjustments before anything starts running it. Test Plan: Static checks only, this code isn't reachable yet. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6147
2013-06-06 23:52:40 +02:00
'PhabricatorCustomFieldNumericIndexStorage' => 'PhabricatorCustomFieldIndexStorage',
Add "owners.search" Conduit API endpoint, with CustomField support Summary: Ref T9964. Adds a new-style "owners.search" endpoint, and an extension for customfields. Puts enough indirection in place to give us nice, consistent "custom.key" user-facing keys instead of "std:custom:owners:na0shf9a8dfdsafl" junk. Test Plan: - Searched Owners via API. - Searched by ID. - Ordered by custom fields. - Reviewed API docs. - Used normal search with ordering. - Viewed custom field values in search results. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14758
2015-12-13 01:25:51 +01:00
'PhabricatorCustomFieldSearchEngineExtension' => 'PhabricatorSearchEngineExtension',
Begin generalizing custom fields Summary: Ref T1703. We have currently have two custom field implementations (Maniphest, Differential) and are about to add a third (User, see D6122). I'd like to generalize custom fields before doing a third implementation, so we don't back ourselves into the ApplicationTransactions corner we have with Maniphest/Differential/Audit. For the most part, the existing custom fields work well and can be directly generalized. There are three specific things I want to improve, though: - Integration with ApplicationSearch: Custom fields aren't indexable. ApplicationSearch is now online and seems stable and good. D5278 provides a template for a backend which can integrate with ApplicationSearch, and ApplicationSearch solves many of the other UI problems implied by exposing custom fields into search (principally, giant pages full of query fields). Generally, I want to provide stronger builtin integration between custom fields and ApplicationSearch. - Integration with ApplicationTransactions: Likewise, custom fields should support more native integrations with ApplicationTransactions, which are also online and seem stable and well designed. - Selection and sorting: Selecting and sorting custom fields is a huge mess right now. I want to move this into config now that we have the UI to support it, and move away from requiring users to subclass a ton of stuff just to add a field. For ApplicationSearch, I've adopted and generalized D5278. For ApplicationTransactions, I haven't made any specific affordances yet. For selection and sorting, I've partially implemented config-based selection and sorting. It will work like this: - We add a new configuration value, like `differential.fields`. In the UI, this is a draggable list of supported fields. Fields can be reordered, and most fields can be disabled. - We load every avialable field to populate this list. New fields will appear at the bottom. - There are two downsides to this approach: - If we add fields in the upstream at a later date, they will appear at the end of the list if an install has customized list order or disabled fields, even if we insert them elsewhere in the upstream. - If we reorder fields in the upstream, the reordering will not be reflected in install which have customized the order/availability. - I think these are both acceptable costs. We only incur them if an admin edits this config, which implies they'll know how to fix it if they want to. - We can fix both of these problems with a straightforward configuration migration if we want to bother. - There are numerous upsides to this approach: - We can delete a bunch of code and replace it with simple configuration. - In general, we don't need the "selector" classes anymore. - Users can enable available-but-disabled fields with one click. - Users can add fields by putting their implementations in `src/extensions/` with zero subclassing or libphutil stuff. - Generally, it's super easy for users to understand. This doesn't actually do anything yet and will probably see some adjustments before anything starts running it. Test Plan: Static checks only, this code isn't reachable yet. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6147
2013-06-06 23:52:40 +02:00
'PhabricatorCustomFieldStorage' => 'PhabricatorLiskDAO',
'PhabricatorCustomFieldStringIndexStorage' => 'PhabricatorCustomFieldIndexStorage',
UI - add ability to customize header logo Summary: Fixes T7165. Let users specify a file phid in config, and then use that file via an inline style tag. Also, cache the URI so that we don't have to query the file on every page load. Test Plan: {F319050} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7165 Differential Revision: https://secure.phabricator.com/D11886
2015-02-25 21:00:36 +01:00
'PhabricatorCustomHeaderConfigType' => 'PhabricatorConfigOptionType',
Rough cut of repository tracking Summary: Basic scaffolding for repository tracking, plus daemon infrastructure (Timelines, Cursors) and some fixes (memory usage, mysql_connect() junk). Test Plan: parsed Javelin git commit history via daemon Reviewers: CC:
2011-03-07 07:29:22 +01:00
'PhabricatorDaemon' => 'PhutilDaemon',
Improve daemon console for daemons on multiple hosts Summary: Ref T10756. This: - Fixes T7307. This UI is now admin-only. - Makes the main "running daemons" table more useful for multi-host setups (show where daemons are running). - Removes logs from the web UI: these are sometimes vaguely sensitive and shouldn't be visible. The UI tells you how to get them with `bin/phd log`. - Minor modernization. Test Plan: - As a non-admin, viewed daemons (access error) and bulk jobs (worked great). - Browsed bulk job pages. - Ran a bulk job. - Viewed daemon console. - Viewed task detail / daemon detail / daemon list pages. {F1220516} Reviewers: chad Reviewed By: chad Maniphest Tasks: T7307, T10756 Differential Revision: https://secure.phabricator.com/D15724
2016-04-15 21:00:34 +02:00
'PhabricatorDaemonBulkJobController' => 'PhabricatorDaemonController',
'PhabricatorDaemonBulkJobListController' => 'PhabricatorDaemonBulkJobController',
'PhabricatorDaemonBulkJobMonitorController' => 'PhabricatorDaemonBulkJobController',
'PhabricatorDaemonBulkJobViewController' => 'PhabricatorDaemonBulkJobController',
Rough cut of Workers Summary: workers do work, provided I have written them correctly. perhaps it is so. Test Plan: Reviewers: CC:
2011-03-10 22:48:29 +01:00
'PhabricatorDaemonConsoleController' => 'PhabricatorDaemonController',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorDaemonContentSource' => 'PhabricatorContentSource',
Rough cut of Workers Summary: workers do work, provided I have written them correctly. perhaps it is so. Test Plan: Reviewers: CC:
2011-03-10 22:48:29 +01:00
'PhabricatorDaemonController' => 'PhabricatorController',
Diffusion/phd/console improvements.
2011-03-15 21:38:14 +01:00
'PhabricatorDaemonDAO' => 'PhabricatorLiskDAO',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'PhabricatorDaemonEventListener' => 'PhabricatorEventListener',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorDaemonLog' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorDaemonDAO',
'PhabricatorPolicyInterface',
Use a real Query class to load daemon information Summary: Ref T3557. This stuff does a bunch of nonsense in the View right now. Instead, do it in a real Query class. Fixes a long-standing bug which prevented "all daemons" from showing more than 3 days' worth of data. Test Plan: Viewed `/daemon/`, viewed "All Daemons". Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3557 Differential Revision: https://secure.phabricator.com/D6544
2013-07-23 21:11:34 +02:00
),
Diffusion/phd/console improvements.
2011-03-15 21:38:14 +01:00
'PhabricatorDaemonLogEvent' => 'PhabricatorDaemonDAO',
Garbage collect daemon logs Summary: We already have GC for daemon log events, but not for daemon logs themselves. Collect old daemon logs which aren't still running. Test Plan: Ran `phd debug garbage`, observed old logs get cleaned up. Started some daemons, re-ran garbage, made sure they stuck around. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9610
2014-06-18 00:33:08 +02:00
'PhabricatorDaemonLogEventGarbageCollector' => 'PhabricatorGarbageCollector',
Allow long daemon log messages to be expanded Summary: Ref T3557. We summarize long messages, but don't let you see the entire message. This is occasionally inconvenient, and I'm planning to add more prefix junk to some messages for T2569. Provide a link you can click to see the full message. This isn't javascripted because a ton of these can make the page ridiculously enormous and it seems unlikely you'd care much about all of them. Test Plan: {F51261} {F51262} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T3557 Differential Revision: https://secure.phabricator.com/D6546
2013-07-23 21:30:58 +02:00
'PhabricatorDaemonLogEventViewController' => 'PhabricatorDaemonController',
Improve web tools for viewing daemons Summary: - Provides an "all daemons" view to look at more than the first 15 daemons. - Provides a "combined log" view with a large page size, to quickly look at the log across all the daemons, making it easier to find issues when you have a bunch of the same daemon and only one is having issues. - When viewing the web console on the same host as a daemon, show whether it's running or not. Test Plan: Clicked the various daemon log interfaces. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran CC: aran Differential Revision: 215
2011-05-03 02:05:22 +02:00
'PhabricatorDaemonLogEventsView' => 'AphrontView',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorDaemonLogGarbageCollector' => 'PhabricatorGarbageCollector',
Improve web tools for viewing daemons Summary: - Provides an "all daemons" view to look at more than the first 15 daemons. - Provides a "combined log" view with a large page size, to quickly look at the log across all the daemons, making it easier to find issues when you have a bunch of the same daemon and only one is having issues. - When viewing the web console on the same host as a daemon, show whether it's running or not. Test Plan: Clicked the various daemon log interfaces. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran CC: aran Differential Revision: 215
2011-05-03 02:05:22 +02:00
'PhabricatorDaemonLogListController' => 'PhabricatorDaemonController',
'PhabricatorDaemonLogListView' => 'AphrontView',
Use a real Query class to load daemon information Summary: Ref T3557. This stuff does a bunch of nonsense in the View right now. Instead, do it in a real Query class. Fixes a long-standing bug which prevented "all daemons" from showing more than 3 days' worth of data. Test Plan: Viewed `/daemon/`, viewed "All Daemons". Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3557 Differential Revision: https://secure.phabricator.com/D6544
2013-07-23 21:11:34 +02:00
'PhabricatorDaemonLogQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Diffusion/phd/console improvements.
2011-03-15 21:38:14 +01:00
'PhabricatorDaemonLogViewController' => 'PhabricatorDaemonController',
Modernize architecture of `phd` Summary: Ref T1670. Mostly, use PhutilArgumentParser. This breaks up the mismash of functional stuff and PhabriatorDaemonControl into proper argumentparser Workflows. There are no functional changes, except that I removed the "pingConduit()" call prior to starting daemons, because I intend to remove all Conduit integration. Test Plan: - Ran `phd list`. - Ran `phd status` (running daemons). - Ran `phd status` (no running daemons). - Ran `phd stop <pid>` (dead task). - Ran `phd stop <pid>` (live task). - Ran `phd stop zebra` (invalid PID). - Ran `phd stop 1` (bad PID). - Ran `phd stop`. - Ran `phd debug zebra` (no match). - Ran `phd debug e` (ambiguous). - Ran `phd debug task`. - Ran `phd launch task`. - Ran `phd launch 0 task` (invalid arg). - Ran `phd launch 2 task`. - Ran `phd help`. - Ran `phd help list`. - Ran `phd start`. - Ran `phd restart`. - Looked at Repositories (daemon running). - Looked at Repositories (daemon not running). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1670 Differential Revision: https://secure.phabricator.com/D6490
2013-07-19 00:28:56 +02:00
'PhabricatorDaemonManagementDebugWorkflow' => 'PhabricatorDaemonManagementWorkflow',
'PhabricatorDaemonManagementLaunchWorkflow' => 'PhabricatorDaemonManagementWorkflow',
'PhabricatorDaemonManagementListWorkflow' => 'PhabricatorDaemonManagementWorkflow',
Add `bin/phd log <id>` to dump all logs to the CLI Summary: Ref T3557. Make it easier to access full daemon logs from the CLI. Test Plan: {F51265} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3557 Differential Revision: https://secure.phabricator.com/D6547
2013-07-23 21:48:45 +02:00
'PhabricatorDaemonManagementLogWorkflow' => 'PhabricatorDaemonManagementWorkflow',
Add `phd reload` to send SIGHUP to overseers Summary: Ref T7384. This just sends SIGHUP to specified overseers in a nice package. Test Plan: See D11898. Reviewers: hach-que, btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T7384 Differential Revision: https://secure.phabricator.com/D11899
2015-02-27 20:38:42 +01:00
'PhabricatorDaemonManagementReloadWorkflow' => 'PhabricatorDaemonManagementWorkflow',
Modernize architecture of `phd` Summary: Ref T1670. Mostly, use PhutilArgumentParser. This breaks up the mismash of functional stuff and PhabriatorDaemonControl into proper argumentparser Workflows. There are no functional changes, except that I removed the "pingConduit()" call prior to starting daemons, because I intend to remove all Conduit integration. Test Plan: - Ran `phd list`. - Ran `phd status` (running daemons). - Ran `phd status` (no running daemons). - Ran `phd stop <pid>` (dead task). - Ran `phd stop <pid>` (live task). - Ran `phd stop zebra` (invalid PID). - Ran `phd stop 1` (bad PID). - Ran `phd stop`. - Ran `phd debug zebra` (no match). - Ran `phd debug e` (ambiguous). - Ran `phd debug task`. - Ran `phd launch task`. - Ran `phd launch 0 task` (invalid arg). - Ran `phd launch 2 task`. - Ran `phd help`. - Ran `phd help list`. - Ran `phd start`. - Ran `phd restart`. - Looked at Repositories (daemon running). - Looked at Repositories (daemon not running). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1670 Differential Revision: https://secure.phabricator.com/D6490
2013-07-19 00:28:56 +02:00
'PhabricatorDaemonManagementRestartWorkflow' => 'PhabricatorDaemonManagementWorkflow',
'PhabricatorDaemonManagementStartWorkflow' => 'PhabricatorDaemonManagementWorkflow',
'PhabricatorDaemonManagementStatusWorkflow' => 'PhabricatorDaemonManagementWorkflow',
'PhabricatorDaemonManagementStopWorkflow' => 'PhabricatorDaemonManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorDaemonManagementWorkflow' => 'PhabricatorManagementWorkflow',
Add a daemon overseer module to restart daemons when config changes Summary: Fixes T7053. Depends on D14452. Test Plan: Created a custom daemon which dumps out the config hash (by querying `PhabricatorEnv::calculateEnvironmentHash()`). Ran this daemon with `./bin/phd debug PhabricatorDebugDaemon` and saw the config hash update within 30 seconds. {P1886} Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Maniphest Tasks: T7053 Differential Revision: https://secure.phabricator.com/D14458
2015-11-10 22:34:34 +01:00
'PhabricatorDaemonOverseerModule' => 'PhutilDaemonOverseerModule',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorDaemonReference' => 'Phobject',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorDaemonTaskGarbageCollector' => 'PhabricatorGarbageCollector',
Separate daemon task table rendering into a standalone class Summary: Ref T5402, T6238. Pull this out into a class so the Instances app can embed task views. Test Plan: Loaded `/daemon/` and examined the content in the tables. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T6238, T5402 Differential Revision: https://secure.phabricator.com/D11090
2014-12-30 19:00:06 +01:00
'PhabricatorDaemonTasksTableView' => 'AphrontView',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorDaemonsApplication' => 'PhabricatorApplication',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorDaemonsSetupCheck' => 'PhabricatorSetupCheck',
Add a "daily routine" trigger clock for backups, etc. Summary: Ref T6881. Before implementing subscriptions, I'm going to vet triggers by using them to do backups. Each instance will get a daily trigger for backups, and that should give us a smaller-scale test to catch issues and limitations, with more opportunities for something to go wrong since it fires more often. Test Plan: Added unit tests. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11427
2015-01-20 01:54:23 +01:00
'PhabricatorDailyRoutineTriggerClock' => 'PhabricatorTriggerClock',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorDashboard' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorDashboardDAO',
Transactions - land buildTransactionTimeline in a bunch more apps Summary: Ref T4712. Specifically... - Dashboards - two objects needed PhabricatorApplicationTransactionInterface - Macros - Paste - Phlux - one object needed PhabricatorApplicationTransactionInterface - added setShouldTerminate(true) - Files - one object needed PhabricatorApplicationTransactionInterface - Passphrase - one object needed PhabricatorApplicationTransactionInterface - added setShouldTerminate(true) - Drydock - one object needed PhabricatorApplicationTransactionInterface - added setShouldTerminate(true) Test Plan: foreach application, verify that the timeline(s) showed up correctly, including with appropriate setShouldTerminate-ness Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10924
2014-12-03 22:16:15 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
Make Dashboards and Panels Flaggable Summary: Ref T8888, makes these two objects flaggable. Test Plan: Set Flag, See Flag. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T8888 Differential Revision: https://secure.phabricator.com/D13652
2015-07-18 21:19:17 +02:00
'PhabricatorFlaggableInterface',
Implement DestructibleInterface for dashboards and panels Summary: Fixes T5471. Test Plan: Used `bin/remove destroy` to destroy a dashboard and a panel. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5471 Differential Revision: https://secure.phabricator.com/D10283
2014-08-18 22:15:13 +02:00
'PhabricatorDestructibleInterface',
Add Projects to Dashboards and Panels Summary: 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. Test Plan: Assign a Project to a Dashboard and a Panel, see Project show up, edit it, see transactions. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13656
2015-07-21 21:01:19 +02:00
'PhabricatorProjectInterface',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
),
Allow panels to appear on dashboards Summary: Ref T3583. Adds edges, query relationships, etc. Lots of debugging/temporary UI. My general intent here is to use edges to track where panels appear, and then put additional data on the dashboard itself to control layout, positioning, etc. Dashboards don't actually render yet so this is still pretty boring. Test Plan: {F149175} {F149176} {F149177} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8916
2014-04-30 23:28:55 +02:00
'PhabricatorDashboardAddPanelController' => 'PhabricatorDashboardController',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorDashboardApplication' => 'PhabricatorApplication',
Add DashboardArchiveController Summary: So Fancy, Much JavaScript. Ref T9414 Test Plan: Archive a Dashboard, Activate a Dashboard, Edit a Dashboard Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9414 Differential Revision: https://secure.phabricator.com/D14725
2015-12-09 21:17:03 +01:00
'PhabricatorDashboardArchiveController' => 'PhabricatorDashboardController',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardController' => 'PhabricatorController',
Allow entire dashboards to be copied Summary: Further improve UX for dealing with policy rules on dashboards: - When in the "Manage" view of a dashboard you can not edit: - Don't show the panel management controls. - Show a notice that the board isn't editable, recommending you make a copy instead. - Add a "Copy Dashboard" action to create a copy which you //can// edit. Test Plan: Copied some dashboards. See screenshots. Reviewers: chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9508
2014-06-13 06:49:19 +02:00
'PhabricatorDashboardCopyController' => 'PhabricatorDashboardController',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardDAO' => 'PhabricatorLiskDAO',
Modernize Dashboard edges Summary: Modernize Dashboard edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Attached a panel to a dashboard, observed the expected comment in the transaction view (both ways). Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11114
2015-01-02 00:11:59 +01:00
'PhabricatorDashboardDashboardHasPanelEdgeType' => 'PhabricatorEdgeType',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorDashboardDashboardPHIDType' => 'PhabricatorPHIDType',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardEditController' => 'PhabricatorDashboardController',
Dashboards - add ability to install dashboard as home Summary: See title. Adds PhabricatorDashboardInstall data object which scopes installs to objectPHID + applicationClass. This is because we already have a collision for user home pages and user profiles. Assume only one dashboard per objectPHID + applicationClass though at the database level. Fixes T5076. Test Plan: From dashboard view, installed a dashboard - success! Went back to dashboard view and uninstalled it! Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5076 Differential Revision: https://secure.phabricator.com/D9206
2014-05-20 01:09:31 +02:00
'PhabricatorDashboardInstall' => 'PhabricatorDashboardDAO',
'PhabricatorDashboardInstallController' => 'PhabricatorDashboardController',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorDashboardLayoutConfig' => 'Phobject',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'PhabricatorDashboardListController' => 'PhabricatorDashboardController',
Make the default view of dashboards be just the dashboard Summary: Fixes T4985, add manage page, change view page to show only panels. Arguably, PhabricatorDashboardArrangeController is no longer necessary. Also, still trying to figure out if I updated all flows that involve "arrange/{id}". Probably missed some. Also not sure of the Manage Dashboard icon. Please advise. Test Plan: Create dashboard, add panels, "view/{id}" should show just panels, Manage Dashboard should show timeline and edit links. Reviewers: #blessed_reviewers, epriestley, chad Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4985 Differential Revision: https://secure.phabricator.com/D9258
2014-05-22 19:59:46 +02:00
'PhabricatorDashboardManageController' => 'PhabricatorDashboardController',
Dashboards - add layout mode to dashboards Summary: This gets us the ability to specify a "layout mode" and which column a panel should appear in at panel add time. Changing the layout mode from a multi column view to a single column view or vice versa will reset all panels to the left most column. You can also drag and drop where columns appear via the "arrange" mode. We also have a new dashboard create flow. Create dashboard -> arrange mode. (As opposed to view mode.) This could all possibly use massaging. Fixes T4996. Test Plan: made a dashboard with panels in multiple columns. verified correct widths for various layout modes re-arranged collumns like whoa. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4996 Differential Revision: https://secure.phabricator.com/D9031
2014-05-16 04:12:40 +02:00
'PhabricatorDashboardMovePanelController' => 'PhabricatorDashboardController',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorDashboardPanel' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorDashboardDAO',
Transactions - land buildTransactionTimeline in a bunch more apps Summary: Ref T4712. Specifically... - Dashboards - two objects needed PhabricatorApplicationTransactionInterface - Macros - Paste - Phlux - one object needed PhabricatorApplicationTransactionInterface - added setShouldTerminate(true) - Files - one object needed PhabricatorApplicationTransactionInterface - Passphrase - one object needed PhabricatorApplicationTransactionInterface - added setShouldTerminate(true) - Drydock - one object needed PhabricatorApplicationTransactionInterface - added setShouldTerminate(true) Test Plan: foreach application, verify that the timeline(s) showed up correctly, including with appropriate setShouldTerminate-ness Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10924
2014-12-03 22:16:15 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
'PhabricatorCustomFieldInterface',
Make Dashboards and Panels Flaggable Summary: Ref T8888, makes these two objects flaggable. Test Plan: Set Flag, See Flag. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T8888 Differential Revision: https://secure.phabricator.com/D13652
2015-07-18 21:19:17 +02:00
'PhabricatorFlaggableInterface',
Add Projects to Dashboards and Panels Summary: 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. Test Plan: Assign a Project to a Dashboard and a Panel, see Project show up, edit it, see transactions. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13656
2015-07-21 21:01:19 +02:00
'PhabricatorProjectInterface',
Implement DestructibleInterface for dashboards and panels Summary: Fixes T5471. Test Plan: Used `bin/remove destroy` to destroy a dashboard and a panel. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5471 Differential Revision: https://secure.phabricator.com/D10283
2014-08-18 22:15:13 +02:00
'PhabricatorDestructibleInterface',
Let dashboard panel types use customfield to manage editing Summary: Ref T3583. Use the same approach Harbormaster does to give panels cheap forms. Test Plan: {F149218} {F149219} {F149220} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8919
2014-04-30 23:29:41 +02:00
),
Allow dashboard panels to be archived Summary: Ref T5471. Adds an archived state for panels. Archived panels don't show up in the default query view or in the "Add Existing Panel" workflow. Test Plan: - Archived a panel. - Activated a panel. - Viewed / searched for archived/active panels. - Popped "Add Existing Panel" dropdown and saw it omit archived panels. Reviewers: chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T5471 Differential Revision: https://secure.phabricator.com/D9779
2014-07-02 02:50:28 +02:00
'PhabricatorDashboardPanelArchiveController' => 'PhabricatorDashboardController',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorDashboardPanelCoreCustomField' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorDashboardPanelCustomField',
'PhabricatorStandardCustomFieldInterface',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
),
Let dashboard panel types use customfield to manage editing Summary: Ref T3583. Use the same approach Harbormaster does to give panels cheap forms. Test Plan: {F149218} {F149219} {F149220} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8919
2014-04-30 23:29:41 +02:00
'PhabricatorDashboardPanelCustomField' => 'PhabricatorCustomField',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardPanelEditController' => 'PhabricatorDashboardController',
Modernize Dashboard edges Summary: Modernize Dashboard edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Attached a panel to a dashboard, observed the expected comment in the transaction view (both ways). Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11114
2015-01-02 00:11:59 +01:00
'PhabricatorDashboardPanelHasDashboardEdgeType' => 'PhabricatorEdgeType',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'PhabricatorDashboardPanelListController' => 'PhabricatorDashboardController',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorDashboardPanelPHIDType' => 'PhabricatorPHIDType',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardPanelQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Let dashboard panels render in a very basic way Summary: Ref T3583. This implements very primitive panel rendering on the panel detail page, and an ajaxable standalone view. Test Plan: {F149135} {F149136} {F149137} {F149138} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8913
2014-04-30 23:28:37 +02:00
'PhabricatorDashboardPanelRenderController' => 'PhabricatorDashboardController',
'PhabricatorDashboardPanelRenderingEngine' => 'Phobject',
Allow users to select QueryPanel search engines from a list Summary: Ref T4986. Instead of requiring users to know the name of an application search engine class, let them select from a list. Test Plan: Created a new panel. {F165468} Reviewers: chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9500
2014-06-12 22:22:20 +02:00
'PhabricatorDashboardPanelSearchApplicationCustomField' => 'PhabricatorStandardCustomField',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardPanelSearchEngine' => 'PhabricatorApplicationSearchEngine',
Make query panels editable by normal humans Summary: Ref T4986. Instead of requiring you to know engine class names and copy/paste URLs, provide select dropdowns that use SCARY JAVASCRIPT to do magical things. I think this is mostly reasonable, the only issue is that it's hard to create a panel out of a completely ad-hoc query (you'd have to save it, then create a panel out of the saved query, then remove the saved query). Once we develop T5307 we can do a better job of this. Test Plan: See screenshots. Reviewers: chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9572
2014-06-16 21:27:12 +02:00
'PhabricatorDashboardPanelSearchQueryCustomField' => 'PhabricatorStandardCustomField',
Make Dashboard tab panels editable by humans Summary: Fixes T5335. This is not pretty, but should reasonably let normal humans create tab panels. Test Plan: See screenshot. Reviewers: chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T5335 Differential Revision: https://secure.phabricator.com/D9600
2014-06-18 00:32:55 +02:00
'PhabricatorDashboardPanelTabsCustomField' => 'PhabricatorStandardCustomField',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardPanelTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorDashboardPanelTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
'PhabricatorDashboardPanelTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Add dashboard panel types Summary: Ref T3583. These will be the primary class carrying panel implementations. Test Plan: {F149125} {F149126} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8912
2014-04-30 23:28:20 +02:00
'PhabricatorDashboardPanelType' => 'Phobject',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardPanelViewController' => 'PhabricatorDashboardController',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Rename `PhabricatorDashboardPanelType` subclasses for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11182
2015-01-04 20:32:07 +01:00
'PhabricatorDashboardQueryPanelType' => 'PhabricatorDashboardPanelType',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhabricatorDashboardRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Dashboards - add remove functionality Summary: To get there, upgrade "headerless" to "headerMode". Add a new removepanel controller. Fixes T5084. Test Plan: removed some panels to much success Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5078, T5084 Differential Revision: https://secure.phabricator.com/D9156
2014-05-19 23:04:26 +02:00
'PhabricatorDashboardRemovePanelController' => 'PhabricatorDashboardController',
Give dashboards basic rendering and Ajax support Summary: Ref T3583. Let dashboards "render", sorta. Test Plan: {F149187} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8917
2014-04-30 23:29:14 +02:00
'PhabricatorDashboardRenderingEngine' => 'Phobject',
Generate expected schemata for Dashboards and Conpherence Summary: Ref T1191. - Add edge schemata generation. - Hit a couple of mostly-minor issues (T6128, T6129, T6130). Test Plan: Viewed schema in web UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10518
2014-09-18 20:15:38 +02:00
'PhabricatorDashboardSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardSearchEngine' => 'PhabricatorApplicationSearchEngine',
Rename `PhabricatorDashboardPanelType` subclasses for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11182
2015-01-04 20:32:07 +01:00
'PhabricatorDashboardTabsPanelType' => 'PhabricatorDashboardPanelType',
'PhabricatorDashboardTextPanelType' => 'PhabricatorDashboardPanelType',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorDashboardTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
'PhabricatorDashboardTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Dashboards - add ability to install dashboard as home Summary: See title. Adds PhabricatorDashboardInstall data object which scopes installs to objectPHID + applicationClass. This is because we already have a collision for user home pages and user profiles. Assume only one dashboard per objectPHID + applicationClass though at the database level. Fixes T5076. Test Plan: From dashboard view, installed a dashboard - success! Went back to dashboard view and uninstalled it! Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5076 Differential Revision: https://secure.phabricator.com/D9206
2014-05-20 01:09:31 +02:00
'PhabricatorDashboardUninstallController' => 'PhabricatorDashboardController',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardViewController' => 'PhabricatorDashboardController',
Restructure cache checks to improve modularity Summary: Ref T5501. This code was headed down a bad road; dump an indirection layer between rendering and data gatehring. In particular, this will make it much easier to lift these issues into setup warnings eventually. Test Plan: Viewed cache status page. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5501 Differential Revision: https://secure.phabricator.com/D12315
2015-04-07 23:38:03 +02:00
'PhabricatorDataCacheSpec' => 'PhabricatorCacheSpec',
Use application PHIDs in Releeph, plus more Summary: Ref T2715. Ref T3551. Ref T603. This does a few things, but they're all sort of small: - We commonly use a `getX()` / `attachX()` pattern, but have very similar code in the `getX()` method every time. Provide a convenience method to make this pattern easier to write. - We use `willFilterPage()` in many queries, but it currently is called with zero or more results. This means we have a lot of "if no results, return nothing" boilerplate. Make it call only for one or more results. - Implement `PhabricatorPolicyInterface` on `ReleephBranch`. A branch has the same policy as its project. - Implement `ReleephBranchQuery`. - Move the branch PHID type to application PHID infrastructure. Test Plan: Browsed Releeph. Used `phid.query` to query branch PHIDs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2715, T3551 Differential Revision: https://secure.phabricator.com/D6512
2013-07-21 18:27:00 +02:00
'PhabricatorDataNotAttachedException' => 'Exception',
Automatically sever databases after prolonged unreachability Summary: Ref T4571. When a database goes down briefly, we fall back to replicas. However, this fallback is slow (not good for users) and keeps sending a lot of traffic to the master (might be bad if the root cause is load-related). Keep track of recent connections and fully degrade into "severed" mode if we see a sequence of failures over a reasonable period of time. In this mode, we send much less traffic to the master (faster for users; less load for the database). We do send a little bit of traffic still, and if the master recovers we'll recover back into normal mode seeing several connections in a row succeed. This is similar to what most load balancers do when pulling web servers in and out of pools. For now, the specific numbers are: - We do at most one health check every 3 seconds. - If 5 checks in a row fail or succeed, we sever or un-sever the database (so it takes about 15 seconds to switch modes). - If the database is currently marked unhealthy, we reduce timeouts and retries when connecting to it. Test Plan: - Configured a bad `master`. - Browsed around for a bit, initially saw "unrechable master" errors. - After about 15 seconds, saw "major interruption" errors instead. - Fixed the config for `master`. - Browsed around for a while longer. - After about 15 seconds, things recovered. - Used "Cluster Databases" console to keep an eye on health checks: it now shows how many recent health checks were good: {F1213397} Reviewers: chad Reviewed By: chad Maniphest Tasks: T4571 Differential Revision: https://secure.phabricator.com/D15677
2016-04-10 23:18:09 +02:00
'PhabricatorDatabaseHealthRecord' => 'Phobject',
Add a "Database Cluster Status" console in Config Summary: Ref T4571. The configuration option still doesn't do anything, but add a status panel for basic setup monitoring. Test Plan: Here's what a good version looks like: {F1212291} Also faked most of the errors it can detect and got helpful diagnostic messages like this: {F1212292} Reviewers: chad Reviewed By: chad Maniphest Tasks: T4571 Differential Revision: https://secure.phabricator.com/D15667
2016-04-10 00:21:29 +02:00
'PhabricatorDatabaseRef' => 'Phobject',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorDatabaseSetupCheck' => 'PhabricatorSetupCheck',
Implement a basic version of ApplicationEditor in Paste Summary: Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste. This mostly looks and works like ApplicationSearch, and is heavily modeled on it. Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else. This has no functional changes, except: - I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it. - Subscribers are now editable. - Form field order is a little goofy (this will be fixed in a future diff). - Subscribers and projects are now race-resistant. The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits. Test Plan: - Created pastes. - Created pastes via API. - Edited pastes. - Edited every field. - Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4768, T9132 Differential Revision: https://secure.phabricator.com/D14390
2015-11-03 03:58:32 +01:00
'PhabricatorDatasourceEditField' => 'PhabricatorTokenizerEditField',
Make "Assign / Claim" stacked action work properly in Maniphest Summary: Ref T9132. This is kind of a mess because the tokenizer rewrite left rendering tokenizers in Javascript a little rough. This causes bugs like icons not showing up on tokens in the "Policy" dialog, which there's a task for somewhere I think. I think I've fixed it enough that the beahavior is now correct (i.e., icons show up properly), but some of the code is a bit iffy. I'll eventually clean this up properly, but it's fairly well contained for now. Test Plan: - Reassigned a task. - Put a task up for grabs. - No reassign on closed tasks. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14669
2015-12-04 18:30:53 +01:00
'PhabricatorDatasourceEditType' => 'PhabricatorPHIDListEditType',
Split up settings into "Date and Time Settings" and everything else. Summary: Ref T8176, Split up settings into "Date and Time Settings" and everything else. Test Plan: Open /settings, Account Settings should now have two tabs: "Account" and "Date and Time" Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T8176 Differential Revision: https://secure.phabricator.com/D12881
2015-05-17 02:21:37 +02:00
'PhabricatorDateTimeSettingsPanel' => 'PhabricatorSettingsPanel',
Add a user-accessible hook for dumping debug code into an install Summary: Currently, there's no easy way for me to tell a user "run this code from the webserver and tell me what it says". Sometimes installs can add new .php files to, e.g., `webroot/rsrc/`, but this is setup-dependent and not universal. Generally I resort to saying "put this into index.php", but that's error prone and not acceptable on active installs. Add a "debug" controller so I can instead say "put this into support/debug.php, then visit /debug/". Test Plan: Visited /debug/ with and without support/debug.php files. Visited /staus/. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5212
2013-03-04 22:45:51 +01:00
'PhabricatorDebugController' => 'PhabricatorController',
Modularize Aphront exception handling Summary: Ref T1806. Ref T7173. Depends on D14047. Currently, all exception handling is in this big messy clump in `AphrontDefaultApplicationConfiguration`. Split it out into modular classes. This will let a future change add new classes in the Phacility cluster which intercept particular exceptions we care about and replaces the default, generic responses with more useful, tailored responses. Test Plan: {F777391} - Hit a Conduit error (made a method throw). - Hit an Ajax error (made comment preview throw). - Hit a high security error (tried to edit TOTP). - Hit a rate limiting error (added a bunch of email addresses). - Hit a policy error (tried to look at something with no permission). - Hit an arbitrary exception (made a randomc ontroller throw). Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14049
2015-09-03 19:04:42 +02:00
'PhabricatorDefaultRequestExceptionHandler' => 'PhabricatorRequestExceptionHandler',
Generate syntax highlighting CSS from a reusable map Summary: Ref T9790. This prepares the syntax color rules to be reused in mail. This goes about halfway toward T5701 by sort-of supporting different styles but not really. Test Plan: - Ran `bin/celerity syntax` to regenerate syntax map. - Viewed some highlighted code, didn't see any differences. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9790 Differential Revision: https://secure.phabricator.com/D15846
2016-05-05 03:24:59 +02:00
'PhabricatorDefaultSyntaxStyle' => 'PhabricatorSyntaxStyle',
Desktop Notification support Summary: Fixes T4139. Adds a "Desktop Notifications" panel to settings. For now, we start with "Send Desktop Notifications Too" functionality. We can try to be fancy later and only send desktop notifications if the web app doesn't have focus, etc. Test Plan: Made some comments as a test user on a task and got purdy desktop notifications using Chrome. Then did it again with Firefox. Played around with permissions form with Chrome and got helpful information about what was up. Played around with Firefox and got similar results, except canceling the dialogue didn't invoke my handler code somehow. Oh Firefox! Reviewers: epriestley Reviewed By: epriestley Subscribers: rbalik, tycho.tatitscheff, joshuaspence, epriestley, Korvin Maniphest Tasks: T4139 Differential Revision: https://secure.phabricator.com/D13219
2015-06-22 22:11:37 +02:00
'PhabricatorDesktopNotificationsSettingsPanel' => 'PhabricatorSettingsPanel',
Implement bin/remove, for structured destruction of objects Summary: Ref T4749. Ref T3265. Ref T4909. Several goals here: - Move user destruction to the CLI to limit the power of rogue admins. - Start consolidating all "destroy named object" scripts into a single UI, to make it easier to know how to destroy things. - Structure object destruction so we can do a better and more automatic job of cleaning up transactions, edges, search indexes, etc. - Log when we destroy objects so there's a record if data goes missing. Test Plan: Used `bin/remove destroy` to destroy several users. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3265, T4749, T4909 Differential Revision: https://secure.phabricator.com/D8940
2014-05-02 03:23:31 +02:00
'PhabricatorDestructionEngine' => 'Phobject',
Prepare DestructionEngine to be modularized Summary: Ref T9979. The general shape of "engine" code feels pretty good, and I plan to move indexing to be more in line with other modern engines, with the ultimate goal of supporting subprojects (T10010) and several intermediate goals. Before moving indexing, clean up Destruction, since some of the new indexes will need destruction hooks and destruction currently has a lot of `instanceof` stuff that should be easy to fix by applying more modern approaches. Test Plan: - Used `bin/remove destroy` to destory an Almanac device. - Verified that properties for the device were destroyed. - Viewed module panel in UI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14831
2015-12-20 16:44:03 +01:00
'PhabricatorDestructionEngineExtension' => 'Phobject',
'PhabricatorDestructionEngineExtensionModule' => 'PhabricatorConfigModule',
Add "Developer" and "Access Log" config option groups, some types Summary: - Add a "developer" option group. - Add an "access log" option group. - Render the types "bool", "int" and "string" in a more tailored way. - Add a config check for dead config. Right now this serves as a "TODO" list of things that need to be migrated. Test Plan: Looked at config options, setup issues. Edited bool, int, string options. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4308
2013-01-01 23:09:17 +01:00
'PhabricatorDeveloperConfigOptions' => 'PhabricatorApplicationConfigOptions',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorDeveloperPreferencesSettingsPanel' => 'PhabricatorSettingsPanel',
Extend TransactionCommentQuery for Differential Summary: Ref T2009. Ref T1460. Replace hard-coded garbage with a real Query-layer query. Test Plan: Submitted inline comments in Differential. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2009, T1460 Differential Revision: https://secure.phabricator.com/D12027
2015-03-09 20:40:29 +01:00
'PhabricatorDiffInlineCommentQuery' => 'PhabricatorApplicationTransactionCommentQuery',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorDiffPreferencesSettingsPanel' => 'PhabricatorSettingsPanel',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorDifferenceEngine' => 'Phobject',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorDifferentialApplication' => 'PhabricatorApplication',
Move commit attachment to a separate CLI command Summary: Ref T9319. See D14967. As before, this is making a deeply-buried, complex operation easier to test by providing a CLI command. This adds `bin/differential attach-commit rXnnnn Dnnnn` to pretend that `rXnnnn` was just committed and matched `Dnnnn`. Test Plan: - Ran `bin/differential attach-commit X Y` for several different values, saw updates in the UI. - Faked the message parser to make sure stuff still worked there. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9319 Differential Revision: https://secure.phabricator.com/D14968
2016-01-08 13:59:31 +01:00
'PhabricatorDifferentialAttachCommitWorkflow' => 'PhabricatorDifferentialManagementWorkflow',
Begin moving Phabricator configuration into PHP Summary: Ref T2255. Ref T2221. Lay the groundwork to move configuration into PHP, so we can show descriptions in the web UI, do typechecking, disable application options when an application is uninstalled, etc. Test Plan: {F28421} {F28420} {F28422} Reviewers: codeblock, btrahan, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221, T2255 Differential Revision: https://secure.phabricator.com/D4306
2012-12-31 00:36:06 +01:00
'PhabricatorDifferentialConfigOptions' => 'PhabricatorApplicationConfigOptions',
Move diff extraction from commits to a separate test with a CLI command Summary: Ref T9319. When we discover a commit, we sometimes update the corresponding revision with a "this is the actual committed change" diff and send out a link to the changes between review and commit. This is currently very difficult to test, because it only happens the first time and you have to either go set up a bunch of objects or add a bunch of special casing to the parser to hit the workflow. I'm making some changes to how it pulls file content. To make those changes easier to test, first start extracting this stuff so the code can be run with `bin/differential extract ...` instead of needing to do a bunch of more complicated setup steps. Test Plan: - Ran `bin/differential extract ...` to extract diffs from commits. - Forced my way through the daemon workflow by faking out a bunch of flags, got a clean extract + attach + update. After this patch, this should rarely be necessary. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9319 Differential Revision: https://secure.phabricator.com/D14967
2016-01-08 13:35:17 +01:00
'PhabricatorDifferentialExtractWorkflow' => 'PhabricatorDifferentialManagementWorkflow',
'PhabricatorDifferentialManagementWorkflow' => 'PhabricatorManagementWorkflow',
xDiffs and Revisions Generating Summary: Ref T2903 Test Plan: Revisions and Diffs are visually being generated Reviewers: epriestley, xask.linus Reviewed By: epriestley CC: AnhNhan, aran, Korvin Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5835
2013-05-06 23:11:26 +02:00
'PhabricatorDifferentialRevisionTestDataGenerator' => 'PhabricatorTestDataGenerator',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorDiffusionApplication' => 'PhabricatorApplication',
Diffusion / MetaMTA options Summary: Implement Diffusion MetaMTA options. Also make the fake '{{config.option}}' rule work, and use Remarkup to render summaries as well as descriptions. Test Plan: Looked at Diffusion rules, edited some, looked at setup issues, verified '{{config.option}}' linked to the right option. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4466
2013-01-16 18:08:13 +01:00
'PhabricatorDiffusionConfigOptions' => 'PhabricatorApplicationConfigOptions',
Admin and disabled flags for users Summary: Provide an "isAdmin" flag for users, to designate administrative users. Restore the account editing interface and allow it to set role flags and reset passwords. Provide an "isDisabled" flag for users and shut down all system access for them. Test Plan: Created "admin" and "disabled" users. Did administrative things with the admin user. Tried to do stuff with the disabled user and was rebuffed. Tried to access administrative interfaces with a normal non-admin user and was denied. Reviewed By: aran Reviewers: tuomaspelkonen, jungejason, aran CC: ccheever, aran Differential Revision: 278
2011-05-12 19:06:54 +02:00
'PhabricatorDisabledUserController' => 'PhabricatorAuthController',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorDisplayPreferencesSettingsPanel' => 'PhabricatorSettingsPanel',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorDisqusAuthProvider' => 'PhabricatorOAuth2AuthProvider',
Add a visual divider element to profile menus Summary: Ref T10054. Test Plan: {F1061529} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15024
2016-01-14 23:34:21 +01:00
'PhabricatorDividerProfilePanel' => 'PhabricatorProfilePanel',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorDivinerApplication' => 'PhabricatorApplication',
'PhabricatorDoorkeeperApplication' => 'PhabricatorApplication',
Revision comment drafts.
2011-02-06 01:57:21 +01:00
'PhabricatorDraft' => 'PhabricatorDraftDAO',
'PhabricatorDraftDAO' => 'PhabricatorLiskDAO',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorDrydockApplication' => 'PhabricatorApplication',
Add an assocations-like "Edges" framework Summary: We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems: - We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant. - Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks. - I want to add more of these and don't want to continue building custom stuff. - UIs like the "attach stuff to other stuff" UI need custom branches for each object type. - Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage. Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences: - I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook. - I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type. This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904. Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation. Reviewers: btrahan Reviewed By: btrahan CC: aran, 20after4 Differential Revision: https://secure.phabricator.com/D2088
2012-04-05 00:30:21 +02:00
'PhabricatorEdgeConfig' => 'PhabricatorEdgeConstants',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorEdgeConstants' => 'Phobject',
Allow edges to be configured to prevent cycles Summary: Certain types of things we should be storing in edges (notably, Task X depends on Task Y) should always be acyclic. Allow `PhabricatorEdgeEditor` to enforce this, since we can't correctly enforce it outside of the editor without being vulnerable to races. Each edge type can be marked acyclic. If an edge type is acyclic, we perform additional steps when writing new edges of that type: - We acquire a global lock on the edge type before performing any reads or writes. This ensures we can't produce a cycle as a result of a race where two edits add edges which independently do not produce a cycle, but do produce a cycle when combined. - After performing writes but before committing transactions, we load the edge graph for each acyclic type and verify that it is, in fact, acyclic. If we detect cycles, we abort the edit. - When we're done, we release the edge type locks. This is a relatively high-complexity change, but gives us a simple way to flag an edge type as acyclic in a robust way. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D2940
2012-07-09 19:39:38 +02:00
'PhabricatorEdgeCycleException' => 'Exception',
Make "Assign / Claim" stacked action work properly in Maniphest Summary: Ref T9132. This is kind of a mess because the tokenizer rewrite left rendering tokenizers in Javascript a little rough. This causes bugs like icons not showing up on tokens in the "Policy" dialog, which there's a task for somewhere I think. I think I've fixed it enough that the beahavior is now correct (i.e., icons show up properly), but some of the code is a bit iffy. I'll eventually clean this up properly, but it's fairly well contained for now. Test Plan: - Reassigned a task. - Put a task up for grabs. - No reassign on closed tasks. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14669
2015-12-04 18:30:53 +01:00
'PhabricatorEdgeEditType' => 'PhabricatorPHIDListEditType',
Remove all edge events Summary: Ref T5245. These were a bad idea. We no longer need actors for edge edits either, so remove those. Generally, edges have fit into the policy model as pure/low-level infrastructure, and they do not have any policy or capability information in and of themselves. Test Plan: `grep` Reviewers: chad, btrahan, joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5245 Differential Revision: https://secure.phabricator.com/D9840
2014-07-18 00:41:42 +02:00
'PhabricatorEdgeEditor' => 'Phobject',
Allow edges to be configured to prevent cycles Summary: Certain types of things we should be storing in edges (notably, Task X depends on Task Y) should always be acyclic. Allow `PhabricatorEdgeEditor` to enforce this, since we can't correctly enforce it outside of the editor without being vulnerable to races. Each edge type can be marked acyclic. If an edge type is acyclic, we perform additional steps when writing new edges of that type: - We acquire a global lock on the edge type before performing any reads or writes. This ensures we can't produce a cycle as a result of a race where two edits add edges which independently do not produce a cycle, but do produce a cycle when combined. - After performing writes but before committing transactions, we load the edge graph for each acyclic type and verify that it is, in fact, acyclic. If we detect cycles, we abort the edit. - When we're done, we release the edge type locks. This is a relatively high-complexity change, but gives us a simple way to flag an edge type as acyclic in a robust way. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D2940
2012-07-09 19:39:38 +02:00
'PhabricatorEdgeGraph' => 'AbstractDirectedGraph',
Add an assocations-like "Edges" framework Summary: We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems: - We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant. - Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks. - I want to add more of these and don't want to continue building custom stuff. - UIs like the "attach stuff to other stuff" UI need custom branches for each object type. - Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage. Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences: - I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook. - I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type. This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904. Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation. Reviewers: btrahan Reviewed By: btrahan CC: aran, 20after4 Differential Revision: https://secure.phabricator.com/D2088
2012-04-05 00:30:21 +02:00
'PhabricatorEdgeQuery' => 'PhabricatorQuery',
Allow edges to be configured to prevent cycles Summary: Certain types of things we should be storing in edges (notably, Task X depends on Task Y) should always be acyclic. Allow `PhabricatorEdgeEditor` to enforce this, since we can't correctly enforce it outside of the editor without being vulnerable to races. Each edge type can be marked acyclic. If an edge type is acyclic, we perform additional steps when writing new edges of that type: - We acquire a global lock on the edge type before performing any reads or writes. This ensures we can't produce a cycle as a result of a race where two edits add edges which independently do not produce a cycle, but do produce a cycle when combined. - After performing writes but before committing transactions, we load the edge graph for each acyclic type and verify that it is, in fact, acyclic. If we detect cycles, we abort the edit. - When we're done, we release the edge type locks. This is a relatively high-complexity change, but gives us a simple way to flag an edge type as acyclic in a robust way. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D2940
2012-07-09 19:39:38 +02:00
'PhabricatorEdgeTestCase' => 'PhabricatorTestCase',
Make edge types modular Summary: Ref T5245. I want to add a new capability to edge types, which is a good opportunity to move away from `PhabricatorEdgeConfig`, which isn't modular. This is basically the same as the modularization of PHID types, which has worked well. Add `PhabricatorEdgeType` and provide an adaption layer for the existing code. This has no runtime changes, except the fixed edge constant. Test Plan: Ran `var_dump(PhabricatorEdgeType::getAllTypes())` and got reasonable looking output. Reviewers: chad, btrahan, joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5245 Differential Revision: https://secure.phabricator.com/D9837
2014-07-18 00:40:37 +02:00
'PhabricatorEdgeType' => 'Phobject',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorEdgeTypeTestCase' => 'PhabricatorTestCase',
Fully modularize DestructionEngine Summary: Ref T9979. Convert all DestructionEngine behaviors to extensions. Test Plan: {F1033244} Destroyed an object, verifying: - Herald transcripts were destroyed; - edges were destroyed; - flags were destroyed; - tokens were destroyed; - transactions were destroyed; - worker tasks were cancelled. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14832
2015-12-20 17:11:59 +01:00
'PhabricatorEdgesDestructionEngineExtension' => 'PhabricatorDestructionEngineExtension',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorEditEngine' => array(
'Phobject',
'PhabricatorPolicyInterface',
),
'PhabricatorEditEngineAPIMethod' => 'ConduitAPIMethod',
Implement a rough optgroup-based "Move on Workboard" stacked action Summary: Ref T6027. Try this out and see how it feels? Clear issues: - This definitely shouldn't be at the top. - You should probably be able to select it multiple times? - Some of the "which columns show up" rules might need adjustment? - Diamond marker maybe not great? Not sure I love this but it doesn't feel //terrible//... Test Plan: {F1207891} Reviewers: chad Reviewed By: chad Maniphest Tasks: T6027 Differential Revision: https://secure.phabricator.com/D15638
2016-04-06 14:59:09 +02:00
'PhabricatorEditEngineColumnsCommentAction' => 'PhabricatorEditEngineCommentAction',
Provide "Change Projects" and "Change Subscribers" (instead of "Add ...") in comment actions Summary: Ref T9908. Fixes T6205. This is largely some refactoring to improve the code. The new structure is: - Each EditField has zero or one "submit" (normal edit form) controls. - Each EditField has zero or one "comment" (stacked actions) controls. - If we want more than one in the future, we'd just add two fields. - Each EditField can have multiple EditTypes which provide Conduit transactions. - EditTypes are now lower-level and less involved on the Submit/Comment pathways. Test Plan: - Added and removed projects and subscribers. - Changed task statuses. - In two windows: added some subscribers in one, removed different ones in the other. The changes did not conflict. - Applied changes via Conduit. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6205, T9908 Differential Revision: https://secure.phabricator.com/D14789
2015-12-15 15:57:32 +01:00
'PhabricatorEditEngineCommentAction' => 'Phobject',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorEditEngineConfiguration' => array(
'PhabricatorSearchDAO',
'PhabricatorApplicationTransactionInterface',
'PhabricatorPolicyInterface',
),
Allow EditEngine configurations to be disabled and marked as "Default" Summary: Ref T9132. Let configurations be enabled/disabled. This doesn't do much right now. Let configurations be marked as default entries in the application "Create" menu. This makes them show up in the application in a dropdown, so you can replace the default form and/or provide several forms. In Maniphest, we'll do this to provide a menu something like this: - New Bug Report - New Feature Request - ADVANCED TASK CREATION!!11~ (only available for Community members) Test Plan: {F1005679} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14584
2015-11-19 23:16:44 +01:00
'PhabricatorEditEngineConfigurationDefaultCreateController' => 'PhabricatorEditEngineController',
Allow EditEngine forms to have defaults assigned Summary: Ref T9132. Allow form configurations to include defaults (like default projects, spaces, policies, etc). Test Plan: Defaulted "Language" to "Rainbow", plus other adjustments: {F975746} {F975747} {F975748} {F975749} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14508
2015-11-18 19:38:12 +01:00
'PhabricatorEditEngineConfigurationDefaultsController' => 'PhabricatorEditEngineController',
Allow EditEngine configurations to be disabled and marked as "Default" Summary: Ref T9132. Let configurations be enabled/disabled. This doesn't do much right now. Let configurations be marked as default entries in the application "Create" menu. This makes them show up in the application in a dropdown, so you can replace the default form and/or provide several forms. In Maniphest, we'll do this to provide a menu something like this: - New Bug Report - New Feature Request - ADVANCED TASK CREATION!!11~ (only available for Community members) Test Plan: {F1005679} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14584
2015-11-19 23:16:44 +01:00
'PhabricatorEditEngineConfigurationDisableController' => 'PhabricatorEditEngineController',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorEditEngineConfigurationEditController' => 'PhabricatorEditEngineController',
'PhabricatorEditEngineConfigurationEditEngine' => 'PhabricatorEditEngine',
'PhabricatorEditEngineConfigurationEditor' => 'PhabricatorApplicationTransactionEditor',
Allow EditEngine forms to be marked as "edit" forms Summary: Ref T9132. Ref T9908. This attempts to move us forward on answering this question: > Which form gets used when a user clicks "Edit Task"? One answer is "the same form that was used to create the task". There are several problems with that: - The form might not exist anymore. - The user might not have permission to see it. - Some of the fields might be hidden, essentially preventing them from being edited. - We have to store the value somewhere and old tasks won't have a value. - Any instructions on the form probably don't apply to edits. One answer is "force the default, full form". That's not as problematic, but it means we have no ability to create limited access users who see fewer fields. The answer in this diff is: - Forms can be marked as "edit forms". - We take the user to the first edit form they have permission to see, from a master list. This allows you to create several forms like: - Advanced Edit Form (say, all fields -- visible to administrators). - Basic Edit Form (say, no policies -- visible to trusted users). - Noob Edit Form (say, no policies, priorities, or status -- visible to everyone). Then you can give everyone access to "noob", some people access to "basic", and a few people access to "advanced". This might only be part of the answer. In particular, you can still //use// any edit form you can see, so we could do these things in the future: - Give you an option to switch to a different form if you want. - Save the form the task was created with, and use that form by default. If we do pursue those, we can fall back to this behavior if there's a problem with them (e.g., original form doesn't exist or wasn't recorded). There's also no "reorder" UI yet, that'll be coming in the next diff. I'm also going to try to probably make the "create" and "edit" stuff a little more consistent / less weird in a bit. Test Plan: Marked various forms as edit forms or not edit forms, made edits, hit permissions errors, etc. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132, T9908 Differential Revision: https://secure.phabricator.com/D14702
2015-12-08 02:11:35 +01:00
'PhabricatorEditEngineConfigurationIsEditController' => 'PhabricatorEditEngineController',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorEditEngineConfigurationListController' => 'PhabricatorEditEngineController',
Allow EditEngine form fields to be locked and hidden Summary: Ref T9132. Allows fields to be locked (shown, but not modifiable) and hidden (not shown). In both cases, default values are still respected. This lets you do things like create a form that generates objects with specific projects, policies, etc. Test Plan: - Set defaults. - Locked and hid a bunch of fields. - Created new objects using the resulting form. {F975801} {F975802} {F975803} {F975804} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14509
2015-11-18 19:50:09 +01:00
'PhabricatorEditEngineConfigurationLockController' => 'PhabricatorEditEngineController',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorEditEngineConfigurationPHIDType' => 'PhabricatorPHIDType',
'PhabricatorEditEngineConfigurationQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Allow form configurations to retitle and reorder forms and add preambles Summary: Ref T9132. This just makes edited forms do //something//, albeit not anything very useful yet. You can now edit a form and: - Retitle it; - add a preamble (instructions on top of the form); and - reorder the form's fields. Test Plan: {F974632} {F974633} {F974634} {F974635} {F974636} Reviewers: chad Reviewed By: chad Subscribers: hach-que Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14503
2015-11-17 18:33:06 +01:00
'PhabricatorEditEngineConfigurationReorderController' => 'PhabricatorEditEngineController',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorEditEngineConfigurationSaveController' => 'PhabricatorEditEngineController',
'PhabricatorEditEngineConfigurationSearchEngine' => 'PhabricatorApplicationSearchEngine',
Allow EditEngine create and edit forms to be reordered Summary: Ref T9132. Ref T9908. Puts reordering UI in place: - For create forms, this just lets you pick a UI display order other than alphabetical. Seems nice to have. - For edit forms, this lets you create a hierarchy of advanced-to-basic forms and give them different visibility policies, if you want. Test Plan: {F1017842} - Verified that "Edit Thing" now takes me to the highest-ranked edit form. - Verified that create menu and quick create menu reflect application order. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132, T9908 Differential Revision: https://secure.phabricator.com/D14704
2015-12-08 15:14:47 +01:00
'PhabricatorEditEngineConfigurationSortController' => 'PhabricatorEditEngineController',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorEditEngineConfigurationTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorEditEngineConfigurationTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'PhabricatorEditEngineConfigurationViewController' => 'PhabricatorEditEngineController',
'PhabricatorEditEngineController' => 'PhabricatorApplicationTransactionController',
Modularize application extensions to EditEngine Summary: Ref T9132. Currently, EditEngine had some branchy-`instanceof` code like this: ``` if ($object instanceof Whatever) { do_magic(); } if ($object instanceof SomethingElse) { do_other_magic(); } ``` ...where `Whatever` and `SomethingElse` are first-party applications like ProjectsInterface and SubscribersInterface. This kind of code is generally bad because third-parties can't add new stuff, and it suggest something is kind of hacky in its architecture. Ideally, we would eventually get rid of almost all of this. T9789 is a similar discussion of this for the next layer down (`TransactionEditor`) and plans to get rid of branchy-instanceofs there too. Since I'm about to add more stuff here (for Custom Fields), split it out first so I'm not digging us any deeper than I already dug us. Broadly, this allows third-party extensions to add fields to every EditEngine UI if they want, like we do for Policies, Subscribers, Projects and Comments today (and CustomFields soon). Test Plan: {F1007575} - Observed that all fields still appear on the form and seem to work correctly. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14599
2015-11-29 19:05:41 +01:00
'PhabricatorEditEngineExtension' => 'Phobject',
'PhabricatorEditEngineExtensionModule' => 'PhabricatorConfigModule',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorEditEngineListController' => 'PhabricatorEditEngineController',
Support enabling a formal points field in Maniphest Summary: Ref T4427. - New config option for labels, enabling, etc., but no UI/niceness yet. - When enabled, add a field. - Allow nonnegative values, including fractional values. - EditEngine is nice and Conduit / actions basically just work with a tiny bit of extra support code. Test Plan: - Edited points via "Edit". - Edited points via Conduit. - Edited points via stacked actions. - Tried to set "zebra" points. - Tried to set -1 points. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4427 Differential Revision: https://secure.phabricator.com/D15220
2016-02-09 00:24:52 +01:00
'PhabricatorEditEnginePointsCommentAction' => 'PhabricatorEditEngineCommentAction',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorEditEngineQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhabricatorEditEngineSearchEngine' => 'PhabricatorApplicationSearchEngine',
Provide "Change Projects" and "Change Subscribers" (instead of "Add ...") in comment actions Summary: Ref T9908. Fixes T6205. This is largely some refactoring to improve the code. The new structure is: - Each EditField has zero or one "submit" (normal edit form) controls. - Each EditField has zero or one "comment" (stacked actions) controls. - If we want more than one in the future, we'd just add two fields. - Each EditField can have multiple EditTypes which provide Conduit transactions. - EditTypes are now lower-level and less involved on the Submit/Comment pathways. Test Plan: - Added and removed projects and subscribers. - Changed task statuses. - In two windows: added some subscribers in one, removed different ones in the other. The changes did not conflict. - Applied changes via Conduit. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6205, T9908 Differential Revision: https://secure.phabricator.com/D14789
2015-12-15 15:57:32 +01:00
'PhabricatorEditEngineSelectCommentAction' => 'PhabricatorEditEngineCommentAction',
'PhabricatorEditEngineTokenizerCommentAction' => 'PhabricatorEditEngineCommentAction',
Implement a basic version of ApplicationEditor in Paste Summary: Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste. This mostly looks and works like ApplicationSearch, and is heavily modeled on it. Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else. This has no functional changes, except: - I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it. - Subscribers are now editable. - Form field order is a little goofy (this will be fixed in a future diff). - Subscribers and projects are now race-resistant. The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits. Test Plan: - Created pastes. - Created pastes via API. - Edited pastes. - Edited every field. - Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4768, T9132 Differential Revision: https://secure.phabricator.com/D14390
2015-11-03 03:58:32 +01:00
'PhabricatorEditField' => 'Phobject',
Split Repository EditEngine form into smaller pages Summary: Ref T10748. This allows an EditEngine form to be broken up into pages. This is less powerful than `PHUIPagedFormView`, because the pages are not sequential / stateful. Each form saves immediately once it's submitted, and can not take you to a new form or back/forward in a series of forms. For example, you can't create a workflow where the user fills out 5 pages of information before we create an object, like the current repository workflow does. However, the only place we've ever wanted to do this is repositories and it's fairly bad there, so I feel reasonably confident we aren't going to miss this in the future. (We do "choose a type of service/repository/rule -> fill out one page of info" fairly often, but can do this without the full-power paging stuff.) Test Plan: - Created a repository usin the new Manage UI, filling out only a handful of fields. - Edited a repository using the new Manage UI. - All forms are now EditEngine forms offering paged views of the big huge underlying form: {F1254371} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15832
2016-05-02 14:35:05 +02:00
'PhabricatorEditPage' => 'Phobject',
Roughly generate transaction-oriented API methods from EditEngines Summary: Ref T5873. Ref T9132. This is really rough and feels pretty flimsy at the edges (missing validation, generality, modularity, clean error handling, etc) but gets us most of the way toward generating plausible "whatever.edit" Conduit API methods from EditEngines. These methods are full-power methods which can do everything the edit form can, automatically support the same range of operations, and update when new fields are added. Test Plan: - Used new `paste.edit` to create a new Paste. - Used new `paste.edit` to update an existing paste. - Applied a variety of different transactions. - Hit a reasonable set of errors. {F941144} {F941145} {F941146} {F941147} Reviewers: chad Reviewed By: chad Maniphest Tasks: T5873, T9132 Differential Revision: https://secure.phabricator.com/D14393
2015-11-03 17:45:00 +01:00
'PhabricatorEditType' => 'Phobject',
Introduce lightbox view for images Summary: images attached to maniphest tasks and mentioned in remarkup anywhere now invoke a lightbox control that lets the user page through all the images. lightbox includes a download button, next / prev buttons, and if we're not at the tippy toppy of hte page an "X" or close button. we also respond to left, right, and esc for navigating. next time we should get non-images working in here...! Test Plan: played with maniphest - looks good made comments with images. looks good. made sure multiple image comments worked. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad Maniphest Tasks: T1896 Differential Revision: https://secure.phabricator.com/D3705
2012-10-23 04:06:56 +02:00
'PhabricatorEditor' => 'Phobject',
Rename "SearchEngine" to "FulltextStorageEngine" Summary: Ref T9979. I picked this name long before the advent of modern "Engine" architecture and it ended up being pretty confusing. Rename "SearchEngine" (currently: mysql or elasticsearch, used to store and query fulltext indexes) to "FulltextStorageEngine" to make it more clear what it does and disambituate it from ApplicationSearch, which also has a bunch of stuff called "SearchEngine", "SearchEngineExtension", etc. Test Plan: Grepped for `phabricatorsearchengine`. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14843
2015-12-21 19:25:28 +01:00
'PhabricatorElasticFulltextStorageEngine' => 'PhabricatorFulltextStorageEngine',
Modernize search engine selection Summary: Remove the `PhabricatorDefaultSearchEngineSelector` class. This is quite similar to D12053. Test Plan: Went to `/view/PhabricatorSearchApplication/` and saw the storage engine configuration. Set `search.elastic.host` and saw the highlighted storage engine change. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D12670
2015-05-19 22:59:58 +02:00
'PhabricatorElasticSearchSetupCheck' => 'PhabricatorSetupCheck',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorEmailAddressesSettingsPanel' => 'PhabricatorSettingsPanel',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorEmailContentSource' => 'PhabricatorContentSource',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorEmailFormatSettingsPanel' => 'PhabricatorSettingsPanel',
PhabricatorEnv 'infratructure' -> 'infrastructure' (rofl) Recaptcha Email Login / Forgot Password Password Reset
2011-01-31 20:55:26 +01:00
'PhabricatorEmailLoginController' => 'PhabricatorAuthController',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorEmailPreferencesSettingsPanel' => 'PhabricatorSettingsPanel',
Modernize email verification page Summary: Fixes T3517. Moves the email verification page out of People and into Auth. Makes it look less awful. Test Plan: {F49636} {F49637} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3517 Differential Revision: https://secure.phabricator.com/D6425
2013-07-11 03:53:09 +02:00
'PhabricatorEmailVerificationController' => 'PhabricatorAuthController',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhabricatorEmbedFileRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Support `:emoji:` in Remarkup Summary: Ref T1191. This actually works without T1191, but makes emoji use on the desktop easier. Test Plan: {F210416} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10605
2014-09-29 17:31:00 +02:00
'PhabricatorEmojiRemarkupRule' => 'PhutilRemarkupRule',
Introduce PhabricatorEmptyQueryException Summary: It's dumb to execute a query which we know will return an empty result. Test Plan: Looked at comment preview with "11", didn't see "1 = 0" in DarkConsole. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5177
2013-03-01 20:28:02 +01:00
'PhabricatorEmptyQueryException' => 'Exception',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorEnv' => 'Phobject',
Lock down accepted next URI values for redirect after login Summary: I locked this down a little bit recently, but make double-extra-super-sure that we aren't sending the user anywhere suspicious or open-redirecty. This also locks down protocol-relative URIs (//evil.com/path) although I don't think any browsers do bad stuff with them in this context, and header injection URIs (although I don't think any of the modern PHP runtimes are vulnerable). Test Plan: - Ran tests. - Hit redirect page with valid and invalid next URIs; was punted to / for invalid ones and to the right place for valid ones. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: arice, aran, epriestley, btrahan Differential Revision: https://secure.phabricator.com/D1369
2012-01-12 01:07:36 +01:00
'PhabricatorEnvTestCase' => 'PhabricatorTestCase',
Convert Countdown to EditEngine Summary: Fixes T10684. Fixes T10520. This primarily implements a date/epoch field, and then does a bunch of standard plumbing. Test Plan: - Created countdowns. - Edited countdowns. - Used HTTP prefilling. - Created a countdown ending on "Christmas Morning", etc. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10520, T10684 Differential Revision: https://secure.phabricator.com/D15655
2016-04-07 20:06:26 +02:00
'PhabricatorEpochEditField' => 'PhabricatorEditField',
Move event framework from Phabricator to libphutil Summary: Move event framework from Phabricator to libphutil so it can be used in other phutil projects, such as Arcanist. Test plan: Use along with path to libphutil, events should work as expected. Reviewers: epriestley Differential Revision: 1098
2011-11-10 02:23:33 +01:00
'PhabricatorEvent' => 'PhutilEvent',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorEventEngine' => 'Phobject',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'PhabricatorEventListener' => 'PhutilEventListener',
Move event framework from Phabricator to libphutil Summary: Move event framework from Phabricator to libphutil so it can be used in other phutil projects, such as Arcanist. Test plan: Use along with path to libphutil, events should work as expected. Reviewers: epriestley Differential Revision: 1098
2011-11-10 02:23:33 +01:00
'PhabricatorEventType' => 'PhutilEventType',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'PhabricatorExampleEventListener' => 'PhabricatorEventListener',
Allow diffusion.filecontentquery to load data for arbitrarily large files Summary: Fixes T10186. After D14970, `diffusion.filecontentquery` puts the content in a file and returns the file PHID. However, it does this in a way that doesn't go through the chunking engine, so it will fail for files larger than the chunk threshold (generally, 8MB). Instead, stream the file from the underlying command directly into chunked storage. Test Plan: - Made a commit including a really big file: https://github.com/epriestley/poems/commit/4dcd4c492b31d82f0fec6f447cf3719b9cc079e0 - Used `diffusion.filecontentquery` to load file content. - Parsed/imported commit locally. - Used `diffusion.filecontentquery` to load content for smaller files (README, etc). Reviewers: chad Reviewed By: chad Maniphest Tasks: T10186 Differential Revision: https://secure.phabricator.com/D15072
2016-01-21 13:25:38 +01:00
'PhabricatorExecFutureFileUploadSource' => 'PhabricatorFileUploadSource',
Add the "Extending Phabricator" config group. Summary: Refs T2255 and takes care of the "EXTENDING PHABRICATOR" group thereof. Test Plan: Looked at each of the new options. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4325
2013-01-03 00:52:30 +01:00
'PhabricatorExtendingPhabricatorConfigOptions' => 'PhabricatorApplicationConfigOptions',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorExtensionsSetupCheck' => 'PhabricatorSetupCheck',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorExternalAccount' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorUserDAO',
'PhabricatorPolicyInterface',
Clean up image loading for ExternalAccounts Summary: Ref T1536. This gets the single queries out of the View and builds a propery Query class for ExternalAccount. Test Plan: Linked/unlinked accounts, logged out, logged in. Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6212
2013-06-17 21:14:00 +02:00
),
'PhabricatorExternalAccountQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorExternalAccountsSettingsPanel' => 'PhabricatorSettingsPanel',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorExtraConfigSetupCheck' => 'PhabricatorSetupCheck',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorFacebookAuthProvider' => 'PhabricatorOAuth2AuthProvider',
Add aggregated facts to the Facts application Summary: Some facts are aggregations of other facts. For example, we may compute how many times each macro is used in each object as a "raw fact": Dnnn uses macro "psyduck" 6 times. But we want to present this data in aggregate form, e.g. "order macros by popularity". We can do this at runtime and it probably won't be too awful a query, but we can also aggregate it cheaply: Macro "psyduck" is used 3920 times across all objects. ...and then do a query like "select macros ordered by usage". "Aggregate" facts support facts like this. The aggregate facts I've implemented are: - Count of all objects. - Count of objects of type X. - Last time facts were updated. These clearly fit the "aggregate" facts template well. I'm not 100% sure macros do. We can use this table to answer a question like "What are the most popular macros, ordered by use?" We can also use it to answer a question like "What are the most popular macros in the last 6 months?", if we build a specific fact for that. But we can't use it to answer a question like "What are the most popular macros between times X and Y?". Maybe that's important; maybe not. This seems like a good fit for at least some types of facts. I'll de-magic the keys a bit in the next diff. Test Plan: Ran the engines and got some aggregated facts about other facts. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3089
2012-07-27 22:46:01 +02:00
'PhabricatorFactAggregate' => 'PhabricatorFactDAO',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorFactApplication' => 'PhabricatorApplication',
Allow Fact app to draw charts Summary: For any count fact, allow a chart to be drawn. INCREDIBLY POWERFUL DATA ANALYSIS PLATFORM. Test Plan: Drew a chart of object counts. Drew the Maniphest burn chart. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3099
2012-07-30 19:44:08 +02:00
'PhabricatorFactChartController' => 'PhabricatorFactController',
Add aggregated facts to the Facts application Summary: Some facts are aggregations of other facts. For example, we may compute how many times each macro is used in each object as a "raw fact": Dnnn uses macro "psyduck" 6 times. But we want to present this data in aggregate form, e.g. "order macros by popularity". We can do this at runtime and it probably won't be too awful a query, but we can also aggregate it cheaply: Macro "psyduck" is used 3920 times across all objects. ...and then do a query like "select macros ordered by usage". "Aggregate" facts support facts like this. The aggregate facts I've implemented are: - Count of all objects. - Count of objects of type X. - Last time facts were updated. These clearly fit the "aggregate" facts template well. I'm not 100% sure macros do. We can use this table to answer a question like "What are the most popular macros, ordered by use?" We can also use it to answer a question like "What are the most popular macros in the last 6 months?", if we build a specific fact for that. But we can't use it to answer a question like "What are the most popular macros between times X and Y?". Maybe that's important; maybe not. This seems like a good fit for at least some types of facts. I'll de-magic the keys a bit in the next diff. Test Plan: Ran the engines and got some aggregated facts about other facts. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3089
2012-07-27 22:46:01 +02:00
'PhabricatorFactController' => 'PhabricatorController',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactCountEngine' => 'PhabricatorFactEngine',
Add FactCursors and application fact datasources Summary: - Add PhabricatorApplication. This is a general class that I have grand designs for, but used here to allow applications to provide objects for analysis by the facts appliction. - Add FactCursors, to keep track of where iterators are. - Make the daemon do something sort of useful. - Add `bin/fact cursors` for showing and managing objects and cursors. - Add some options to `bin/fact analyze`. Test Plan: - `bin/fact cursors`, `bin/fact cursors --reset DifferentialRevision`, `bin/fact cursors --reset X` - `bin/fact analyze`, `bin/fact analyze --all`, `bin/fact analyze --iterator DifferentialRevision --skip-aggregates` - `bin/phd debug fact` Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3098
2012-07-30 19:43:49 +02:00
'PhabricatorFactCursor' => 'PhabricatorFactDAO',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactDAO' => 'PhabricatorLiskDAO',
'PhabricatorFactDaemon' => 'PhabricatorDaemon',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorFactEngine' => 'Phobject',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorFactEngineTestCase' => 'PhabricatorTestCase',
Add aggregated facts to the Facts application Summary: Some facts are aggregations of other facts. For example, we may compute how many times each macro is used in each object as a "raw fact": Dnnn uses macro "psyduck" 6 times. But we want to present this data in aggregate form, e.g. "order macros by popularity". We can do this at runtime and it probably won't be too awful a query, but we can also aggregate it cheaply: Macro "psyduck" is used 3920 times across all objects. ...and then do a query like "select macros ordered by usage". "Aggregate" facts support facts like this. The aggregate facts I've implemented are: - Count of all objects. - Count of objects of type X. - Last time facts were updated. These clearly fit the "aggregate" facts template well. I'm not 100% sure macros do. We can use this table to answer a question like "What are the most popular macros, ordered by use?" We can also use it to answer a question like "What are the most popular macros in the last 6 months?", if we build a specific fact for that. But we can't use it to answer a question like "What are the most popular macros between times X and Y?". Maybe that's important; maybe not. This seems like a good fit for at least some types of facts. I'll de-magic the keys a bit in the next diff. Test Plan: Ran the engines and got some aggregated facts about other facts. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3089
2012-07-27 22:46:01 +02:00
'PhabricatorFactHomeController' => 'PhabricatorFactController',
'PhabricatorFactLastUpdatedEngine' => 'PhabricatorFactEngine',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactManagementAnalyzeWorkflow' => 'PhabricatorFactManagementWorkflow',
Add FactCursors and application fact datasources Summary: - Add PhabricatorApplication. This is a general class that I have grand designs for, but used here to allow applications to provide objects for analysis by the facts appliction. - Add FactCursors, to keep track of where iterators are. - Make the daemon do something sort of useful. - Add `bin/fact cursors` for showing and managing objects and cursors. - Add some options to `bin/fact analyze`. Test Plan: - `bin/fact cursors`, `bin/fact cursors --reset DifferentialRevision`, `bin/fact cursors --reset X` - `bin/fact analyze`, `bin/fact analyze --all`, `bin/fact analyze --iterator DifferentialRevision --skip-aggregates` - `bin/phd debug fact` Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3098
2012-07-30 19:43:49 +02:00
'PhabricatorFactManagementCursorsWorkflow' => 'PhabricatorFactManagementWorkflow',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactManagementDestroyWorkflow' => 'PhabricatorFactManagementWorkflow',
'PhabricatorFactManagementListWorkflow' => 'PhabricatorFactManagementWorkflow',
'PhabricatorFactManagementStatusWorkflow' => 'PhabricatorFactManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorFactManagementWorkflow' => 'PhabricatorManagementWorkflow',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactRaw' => 'PhabricatorFactDAO',
Add FactCursors and application fact datasources Summary: - Add PhabricatorApplication. This is a general class that I have grand designs for, but used here to allow applications to provide objects for analysis by the facts appliction. - Add FactCursors, to keep track of where iterators are. - Make the daemon do something sort of useful. - Add `bin/fact cursors` for showing and managing objects and cursors. - Add some options to `bin/fact analyze`. Test Plan: - `bin/fact cursors`, `bin/fact cursors --reset DifferentialRevision`, `bin/fact cursors --reset X` - `bin/fact analyze`, `bin/fact analyze --all`, `bin/fact analyze --iterator DifferentialRevision --skip-aggregates` - `bin/phd debug fact` Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3098
2012-07-30 19:43:49 +02:00
'PhabricatorFactSimpleSpec' => 'PhabricatorFactSpec',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorFactSpec' => 'Phobject',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactUpdateIterator' => 'PhutilBufferedIterator',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorFaxContentSource' => 'PhabricatorContentSource',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorFeedApplication' => 'PhabricatorApplication',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorFeedBuilder' => 'Phobject',
Feed options. Test Plan: Looked at them. Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4434
2013-01-15 02:49:32 +01:00
'PhabricatorFeedConfigOptions' => 'PhabricatorApplicationConfigOptions',
Build basic infrastructure for an activity feed Summary: This defines an extremely basic version of an activity feed, like Facebook's news feed. It doesn't do much of interest yet. Test Plan: Published some feed stories: https://secure.phabricator.com/file/view/PHID-FILE-5061aa72105bbdc05b21/ Reviewed By: tuomaspelkonen Reviewers: jungejason, tuomaspelkonen, aran Commenters: codeblock, jungejason CC: aran, epriestley, codeblock, tuomaspelkonen, jungejason Differential Revision: 593
2011-07-05 17:35:18 +02:00
'PhabricatorFeedController' => 'PhabricatorController',
'PhabricatorFeedDAO' => 'PhabricatorLiskDAO',
Add a feed detail/permalink page for feed stories Summary: Ref T2852. Asana has one bug which I'm having a little trouble figuring out. I want to get more information to debug it, but I'll need them to run `bin/feed republish <story_id>` to get that data. Right now, it's incredibly hard to figure out the story ID for feed stories. So mostly this is to make that easier (click permalink; pull it out of the URL), but it also adds a little functionality and cleans the code up a bit. The page itself could be prettier and maybe some day we'll add comments or whatever, but it seems reasonably functionalish. Test Plan: {F49962} - Also loaded many pages of feed history to check that nothing broke. Reviewers: btrahan, chad Reviewed By: chad CC: chad, aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6440
2013-07-13 02:04:02 +02:00
'PhabricatorFeedDetailController' => 'PhabricatorFeedController',
Let feed panels render something meaningful-ish Summary: Ref T4986. We need to introduce alternate views to make this more pleasant, but let rendering move to engines so it can be shared between panels and controllers. I also moved some of the pagination logic in to avoid duplicating that. So far, only Feed works. I'm going to do these gradually since we have ~40-50 of them. Test Plan: - Used global search to check for collateral damage. - Used not-global search too. - Used normal feed. {F151541} Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9008
2014-05-08 17:24:47 +02:00
'PhabricatorFeedListController' => 'PhabricatorFeedController',
Push feed publishing deeper into the task queue Summary: Ref T2852. I want to model Asana integration as a response to feed events. Currently, we queue one feed event for each HTTP hook. Instead, always queue one feed event and then have it queue any necessary followup events (now, http hooks; soon, asana). Add a script to make it easy to reproducibly fire feed event publishing. Test Plan: Republished a feed event and verified it hit configured HTTP hooks correctly. $ ./bin/feed republish 5765774156541908292 --trace >>> [2] <connect> phabricator2_feed <<< [2] <connect> 1,660 us >>> [3] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [3] <query> 595 us >>> [4] <connect> phabricator2_differential <<< [4] <connect> 760 us >>> [5] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [5] <query> 478 us >>> [6] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [6] <query> 449 us >>> [7] <connect> phabricator2_user <<< [7] <connect> 1,062 us >>> [8] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [8] <query> 540 us >>> [9] <connect> phabricator2_file <<< [9] <connect> 951 us >>> [10] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [10] <query> 498 us >>> [11] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [11] <query> 507 us Republishing story... >>> [12] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [12] <query> 685 us >>> [13] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [13] <query> 489 us >>> [14] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [14] <query> 512 us >>> [15] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [15] <query> 601 us >>> [16] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [16] <query> 405 us >>> [17] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [17] <query> 551 us >>> [18] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [18] <query> 507 us >>> [19] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [19] <query> 428 us >>> [20] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [20] <query> 419 us >>> [21] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [21] <query> 591 us >>> [22] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [22] <query> 406 us >>> [23] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [23] <query> 593 us >>> [24] <http> http://127.0.0.1/derp/ <<< [24] <http> 746,157 us [2013-06-24 20:23:26] EXCEPTION: (HTTPFutureResponseStatusHTTP) [HTTP/500] Internal Server Error Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6291
2013-06-26 01:29:47 +02:00
'PhabricatorFeedManagementRepublishWorkflow' => 'PhabricatorFeedManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorFeedManagementWorkflow' => 'PhabricatorManagementWorkflow',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorFeedQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Use ApplicationSearch in Feed Summary: Ref T2625. This doesn't do anything fancy, but gives feed a little more flexibility. Test Plan: Viewed `/feed/`. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6681
2013-08-05 23:10:41 +02:00
'PhabricatorFeedSearchEngine' => 'PhabricatorApplicationSearchEngine',
Render remarkup in feed in a mostly reasonable way Summary: Fixes T4057. This sort of sidesteps the trickiest (but very rare) case of things like embedded slowvotes. We might be able to refine that later. In the common bad case (macros, large images) it gets reasonable results by using `overflow: hidden` with `max-height`. We use `PhabriatorMarkupEngine::summarize()` to try to just render the first paragraph. Test Plan: {F195093} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4057 Differential Revision: https://secure.phabricator.com/D10355
2014-08-26 23:36:35 +02:00
'PhabricatorFeedStory' => array(
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'Phobject',
Render remarkup in feed in a mostly reasonable way Summary: Fixes T4057. This sort of sidesteps the trickiest (but very rare) case of things like embedded slowvotes. We might be able to refine that later. In the common bad case (macros, large images) it gets reasonable results by using `overflow: hidden` with `max-height`. We use `PhabriatorMarkupEngine::summarize()` to try to just render the first paragraph. Test Plan: {F195093} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4057 Differential Revision: https://secure.phabricator.com/D10355
2014-08-26 23:36:35 +02:00
'PhabricatorPolicyInterface',
'PhabricatorMarkupInterface',
),
Build basic infrastructure for an activity feed Summary: This defines an extremely basic version of an activity feed, like Facebook's news feed. It doesn't do much of interest yet. Test Plan: Published some feed stories: https://secure.phabricator.com/file/view/PHID-FILE-5061aa72105bbdc05b21/ Reviewed By: tuomaspelkonen Reviewers: jungejason, tuomaspelkonen, aran Commenters: codeblock, jungejason CC: aran, epriestley, codeblock, tuomaspelkonen, jungejason Differential Revision: 593
2011-07-05 17:35:18 +02:00
'PhabricatorFeedStoryData' => 'PhabricatorFeedDAO',
Adds base notification application Summary: First diff in a series of diffs to add notifications to Phabricator. This is the notification application ONLY. This commit does not include the changes to other applications that makes them add notifications. As such, no notifications will be generated beyond the initial database import. Test Plan: This is part of the notifications architecture which has been running on http://theoryphabricator.com for the past several months. Reviewers: epriestley, btrahan, ddfisher Reviewed By: epriestley CC: allenjohnashton, keebuhm, aran, Korvin, jungejason, nh Maniphest Tasks: T974 Differential Revision: https://secure.phabricator.com/D2571
2012-06-08 15:31:30 +02:00
'PhabricatorFeedStoryNotification' => 'PhabricatorFeedDAO',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorFeedStoryPublisher' => 'Phobject',
Build basic infrastructure for an activity feed Summary: This defines an extremely basic version of an activity feed, like Facebook's news feed. It doesn't do much of interest yet. Test Plan: Published some feed stories: https://secure.phabricator.com/file/view/PHID-FILE-5061aa72105bbdc05b21/ Reviewed By: tuomaspelkonen Reviewers: jungejason, tuomaspelkonen, aran Commenters: codeblock, jungejason CC: aran, epriestley, codeblock, tuomaspelkonen, jungejason Differential Revision: 593
2011-07-05 17:35:18 +02:00
'PhabricatorFeedStoryReference' => 'PhabricatorFeedDAO',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorFile' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorFileDAO',
Transactions - land buildTransactionTimeline in a bunch more apps Summary: Ref T4712. Specifically... - Dashboards - two objects needed PhabricatorApplicationTransactionInterface - Macros - Paste - Phlux - one object needed PhabricatorApplicationTransactionInterface - added setShouldTerminate(true) - Files - one object needed PhabricatorApplicationTransactionInterface - Passphrase - one object needed PhabricatorApplicationTransactionInterface - added setShouldTerminate(true) - Drydock - one object needed PhabricatorApplicationTransactionInterface - added setShouldTerminate(true) Test Plan: foreach application, verify that the timeline(s) showed up correctly, including with appropriate setShouldTerminate-ness Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10924
2014-12-03 22:16:15 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorTokenReceiverInterface',
'PhabricatorSubscribableInterface',
'PhabricatorFlaggableInterface',
'PhabricatorPolicyInterface',
Cover redirects to files in more cases Summary: Ref T5894. We have a couple more similar cases. Make them all do a decision-based redirect for now. Test Plan: Did "View Raw File" and such, and also made sure thumbnails still work. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T5894 Differential Revision: https://secure.phabricator.com/D10301
2014-08-20 00:53:15 +02:00
'PhabricatorDestructibleInterface',
Add PhabricatorFileQuery Summary: This doesn't do anything useful yet but Pholio needs to access Files and I wanted to get the groundwork in place for eventual policy-awareness. Test Plan: Will use in Pholio. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3829
2012-10-31 17:57:46 +01:00
),
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorFileBundleLoader' => 'Phobject',
Add a chunking storage engine for files Summary: Ref T7149. This isn't complete and isn't active yet, but does basically work. I'll shore it up in the next few diffs. The new workflow goes like this: > Client, file.allocate(): I'd like to upload a file with length L, metadata M, and hash H. Then the server returns `upload` (a boolean) and `filePHID` (a PHID). These mean: | upload | filePHID | means | |---|---|---| | false | false | Server can't accept file. | false | true | File data already known, file created from hash. | true | false | Just upload normally. | true | true | Query chunks to start or resume a chunked upload. All but the last case are uninteresting and work like exising uploads with `file.uploadhash` (which we can eventually deprecate). In the last case: > Client, file.querychunks(): Give me a list of chunks that I should upload. This returns all the chunks for the file. Chunks have a start byte, an end byte, and a "complete" flag to indicate that the server already has the data. Then, the client fills in chunks by sending them: > Client, file.uploadchunk(): Here is the data for one chunk. This stuff doesn't work yet or has some caveats: - I haven't tested resume much. - Files need an "isPartial()" flag for partial uploads, and the UI needs to respect it. - The JS client needs to become chunk-aware. - Chunk size is set crazy low to make testing easier. - Some debugging flags that I'll remove soon-ish. - Downloading works, but still streams the whole file into memory. - This storage engine is disabled by default (hardcoded as a unit test engine) because it's still sketchy. - Need some code to remove the "isParital" flag when the last chunk is uploaded. - Maybe do checksumming on chunks. Test Plan: - Hacked up `arc upload` (see next diff) to be chunk-aware and uploaded a readme in 18 32-byte chunks. Then downloaded it. Got the same file back that I uploaded. - File UI now shows some basic chunk info for chunked files: {F336434} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12060
2015-03-13 19:30:02 +01:00
'PhabricatorFileChunk' => array(
'PhabricatorFileDAO',
'PhabricatorPolicyInterface',
'PhabricatorDestructibleInterface',
),
Stream chunks when sending chunked files Summary: Ref T7149. Return a real iterator from the Chunk engine, which processes chunks sequentially. Test Plan: This is a bit hard to read, but shows the underlying chunks being accessed one at a time and only some being accessed when requesting a range of a file: ``` $ ./bin/files cat F878 --trace --begin 100 --end 256 ... >>> [10] <query> SELECT * FROM `file_storageblob` WHERE `id` = 85 <<< [10] <query> 240 us better software. Phabricat>>> [11] <query> SELECT * FROM `file_storageblob` WHERE `id` = 84 <<< [11] <query> 205 us or includes applications for: >>> [12] <query> SELECT * FROM `file_storageblob` WHERE `id` = 83 <<< [12] <query> 226 us - reviewing and auditing source>>> [13] <query> SELECT * FROM `file_storageblob` WHERE `id` = 82 <<< [13] <query> 203 us code; - hosting and browsing >>> [14] <query> SELECT * FROM `file_storageblob` WHERE `id` = 81 <<< [14] <query> 231 us repositories; - tracking bugs; ``` Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12073
2015-03-14 16:29:30 +01:00
'PhabricatorFileChunkIterator' => array(
'Phobject',
'Iterator',
),
Add a chunking storage engine for files Summary: Ref T7149. This isn't complete and isn't active yet, but does basically work. I'll shore it up in the next few diffs. The new workflow goes like this: > Client, file.allocate(): I'd like to upload a file with length L, metadata M, and hash H. Then the server returns `upload` (a boolean) and `filePHID` (a PHID). These mean: | upload | filePHID | means | |---|---|---| | false | false | Server can't accept file. | false | true | File data already known, file created from hash. | true | false | Just upload normally. | true | true | Query chunks to start or resume a chunked upload. All but the last case are uninteresting and work like exising uploads with `file.uploadhash` (which we can eventually deprecate). In the last case: > Client, file.querychunks(): Give me a list of chunks that I should upload. This returns all the chunks for the file. Chunks have a start byte, an end byte, and a "complete" flag to indicate that the server already has the data. Then, the client fills in chunks by sending them: > Client, file.uploadchunk(): Here is the data for one chunk. This stuff doesn't work yet or has some caveats: - I haven't tested resume much. - Files need an "isPartial()" flag for partial uploads, and the UI needs to respect it. - The JS client needs to become chunk-aware. - Chunk size is set crazy low to make testing easier. - Some debugging flags that I'll remove soon-ish. - Downloading works, but still streams the whole file into memory. - This storage engine is disabled by default (hardcoded as a unit test engine) because it's still sketchy. - Need some code to remove the "isParital" flag when the last chunk is uploaded. - Maybe do checksumming on chunks. Test Plan: - Hacked up `arc upload` (see next diff) to be chunk-aware and uploaded a readme in 18 32-byte chunks. Then downloaded it. Got the same file back that I uploaded. - File UI now shows some basic chunk info for chunked files: {F336434} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12060
2015-03-13 19:30:02 +01:00
'PhabricatorFileChunkQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
'PhabricatorFileCommentController' => 'PhabricatorFileController',
Add an icon+background selector for project images Summary: Makes it easy to choose distinctive icons for projects. Test Plan: {F71018} {F71020} {F71019} {F71021} Reviewers: btrahan, chad Reviewed By: chad CC: chad, aran Differential Revision: https://secure.phabricator.com/D7333
2013-10-17 18:32:34 +02:00
'PhabricatorFileComposeController' => 'PhabricatorFileController',
Phabricator file upload application.
2011-01-23 03:33:00 +01:00
'PhabricatorFileController' => 'PhabricatorController',
'PhabricatorFileDAO' => 'PhabricatorLiskDAO',
Move ALL files to serve from the alternate file domain, not just files without "Content-Disposition: attachment" Summary: We currently serve some files off the primary domain (with "Content-Disposition: attachment" + a CSRF check) and some files off the alternate domain (without either). This is not sufficient, because some UAs (like the iPad) ignore "Content-Disposition: attachment". So there's an attack that goes like this: - Alice uploads xss.html - Alice says to Bob "hey download this file on your iPad" - Bob clicks "Download" on Phabricator on his iPad, gets XSS'd. NOTE: This removes the CSRF check for downloading files. The check is nice to have but only raises the barrier to entry slightly. Between iPad / sniffing / flash bytecode attacks, single-domain installs are simply insecure. We could restore the check at some point in conjunction with a derived authentication cookie (i.e., a mini-session-token which is only useful for downloading files), but that's a lot of complexity to drop all at once. (Because files are now authenticated only by knowing the PHID and secret key, this also fixes the "no profile pictures in public feed while logged out" issue.) Test Plan: Viewed, info'd, and downloaded files Reviewers: btrahan, arice, alok Reviewed By: arice CC: aran, epriestley Maniphest Tasks: T843 Differential Revision: https://secure.phabricator.com/D1608
2012-02-14 23:52:27 +01:00
'PhabricatorFileDataController' => 'PhabricatorFileController',
Allow files to be deleted Summary: A couple of people mentioned that they've had users accidentally upload sensitive files. Allow files to be deleted. (At some point it might be nice to keep the file handle around and log who deleted it, but this addresses the immediate problem without needing too much work.) Test Plan: Deleted some files. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T780 Differential Revision: https://secure.phabricator.com/D1423
2012-01-16 22:26:44 +01:00
'PhabricatorFileDeleteController' => 'PhabricatorFileController',
Drag-and-drop upload for Maniphest Summary: This needs a bunch of UI polish (critically, it's totally undiscoverable) but it basically works correctly. I'll clean it up in some followups. Test Plan: Uploaded some files via drag-and-drop, made comments, etc. Reviewed By: aran Reviewers: tomo, aran, jungejason, tuomaspelkonen CC: anjali, aran Differential Revision: 332
2011-05-22 20:55:10 +02:00
'PhabricatorFileDropUploadController' => 'PhabricatorFileController',
Allow users to set view policies on files explicitly Summary: Ref T4589. Allow users to adjust visibility settings on files explicitly. This makes it easier to understand and manage upcoming changes in T4589. Test Plan: Changed the view policy for a file several times. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4589 Differential Revision: https://secure.phabricator.com/D10129
2014-08-02 23:45:50 +02:00
'PhabricatorFileEditController' => 'PhabricatorFileController',
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
'PhabricatorFileEditor' => 'PhabricatorApplicationTransactionEditor',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorFileFilePHIDType' => 'PhabricatorPHIDType',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorFileHasObjectEdgeType' => 'PhabricatorEdgeType',
Provide a "PHUIFormIconSetControl" Summary: Ref T9992. This is a step on the path to getting EditEngine working in Badges, Projects and Calendar. This doesn't add a new `EditField` for icons yet, just standardizes the old stuff. New stuff is more general and I saved 150 lines of code. I put the endpoint in Files because the similar "choose a profile picture" endpoint will definitely go there, and this endpoint might eventually feature, like, "draw your own icon~~" or something. Test Plan: - Created events, projects and badges with custom icons. - Edited events, projects and badges, changing their icons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9992 Differential Revision: https://secure.phabricator.com/D14799
2015-12-16 16:53:13 +01:00
'PhabricatorFileIconSetSelectController' => 'PhabricatorFileController',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorFileImageMacro' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorFileDAO',
'PhabricatorSubscribableInterface',
'PhabricatorApplicationTransactionInterface',
'PhabricatorFlaggableInterface',
Add tokens to Macro Summary: A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. Test Plan: Award a token to a macro. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13725
2015-07-27 16:51:37 +02:00
'PhabricatorTokenReceiverInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
),
Modularize file transforms and provide a "transforms" UI Summary: Ref T7707. Available transforms are currently relatively hard-coded and don't really have any support UI. Modularize them so we can build some support UI. This doesn't actually //use// any of the new stuff yet: I want to make a clean cutover once I fix the aspect ratio stuff so I can pick up a cachekey/URI change as a side effect. Test Plan: {F400524} Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T7707 Differential Revision: https://secure.phabricator.com/D12808
2015-05-12 15:16:18 +02:00
'PhabricatorFileImageTransform' => 'PhabricatorFileTransform',
Move ALL files to serve from the alternate file domain, not just files without "Content-Disposition: attachment" Summary: We currently serve some files off the primary domain (with "Content-Disposition: attachment" + a CSRF check) and some files off the alternate domain (without either). This is not sufficient, because some UAs (like the iPad) ignore "Content-Disposition: attachment". So there's an attack that goes like this: - Alice uploads xss.html - Alice says to Bob "hey download this file on your iPad" - Bob clicks "Download" on Phabricator on his iPad, gets XSS'd. NOTE: This removes the CSRF check for downloading files. The check is nice to have but only raises the barrier to entry slightly. Between iPad / sniffing / flash bytecode attacks, single-domain installs are simply insecure. We could restore the check at some point in conjunction with a derived authentication cookie (i.e., a mini-session-token which is only useful for downloading files), but that's a lot of complexity to drop all at once. (Because files are now authenticated only by knowing the PHID and secret key, this also fixes the "no profile pictures in public feed while logged out" issue.) Test Plan: Viewed, info'd, and downloaded files Reviewers: btrahan, arice, alok Reviewed By: arice CC: aran, epriestley Maniphest Tasks: T843 Differential Revision: https://secure.phabricator.com/D1608
2012-02-14 23:52:27 +01:00
'PhabricatorFileInfoController' => 'PhabricatorFileController',
Introduce lightbox view for images Summary: images attached to maniphest tasks and mentioned in remarkup anywhere now invoke a lightbox control that lets the user page through all the images. lightbox includes a download button, next / prev buttons, and if we're not at the tippy toppy of hte page an "X" or close button. we also respond to left, right, and esc for navigating. next time we should get non-images working in here...! Test Plan: played with maniphest - looks good made comments with images. looks good. made sure multiple image comments worked. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad Maniphest Tasks: T1896 Differential Revision: https://secure.phabricator.com/D3705
2012-10-23 04:06:56 +02:00
'PhabricatorFileLinkView' => 'AphrontView',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'PhabricatorFileListController' => 'PhabricatorFileController',
Add PhabricatorFileQuery Summary: This doesn't do anything useful yet but Pholio needs to access Files and I wanted to get the groundwork in place for eventual policy-awareness. Test Plan: Will use in Pholio. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3829
2012-10-31 17:57:46 +01:00
'PhabricatorFileQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add expected schemata for Fund, Files, Flags and Legalpad Summary: Ref T1191. Nothing too exciting in these. Test Plan: Saw more blue in UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10521
2014-09-19 14:44:40 +02:00
'PhabricatorFileSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Implement ApplicationSearch in Files Summary: Ref T2625. Ref T1163. A couple of small generalization nudges, but this is almost entirely straightforward. Test Plan: Executed various File queries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1163, T2625 Differential Revision: https://secure.phabricator.com/D6091
2013-05-31 19:51:05 +02:00
'PhabricatorFileSearchEngine' => 'PhabricatorApplicationSearchEngine',
Phabricator file upload application.
2011-01-23 03:33:00 +01:00
'PhabricatorFileStorageBlob' => 'PhabricatorFileDAO',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'PhabricatorFileStorageConfigurationException' => 'Exception',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorFileStorageEngine' => 'Phobject',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorFileStorageEngineTestCase' => 'PhabricatorTestCase',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorFileTemporaryGarbageCollector' => 'PhabricatorGarbageCollector',
Make file storage more testable Summary: Fixes T2474. Adds a storage dummy storage engine for unit tests, and adds a couple of simple tests for basic file storage. Test Plan: Ran `arc unit` to execute unit tests. Reviewers: kwadwon Reviewed By: kwadwon CC: aran Maniphest Tasks: T2474 Differential Revision: https://secure.phabricator.com/D4777
2013-02-06 22:37:42 +01:00
'PhabricatorFileTestCase' => 'PhabricatorTestCase',
Files Generating Summary: Ref T2903 Test Plan: Files are being generating, albeit temporary. Reviewers: epriestley, AnhNhan Reviewed By: AnhNhan CC: aran, Korvin, AnhNhan, chad Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5801
2013-05-06 19:30:24 +02:00
'PhabricatorFileTestDataGenerator' => 'PhabricatorTestDataGenerator',
Modularize file transforms and provide a "transforms" UI Summary: Ref T7707. Available transforms are currently relatively hard-coded and don't really have any support UI. Modularize them so we can build some support UI. This doesn't actually //use// any of the new stuff yet: I want to make a clean cutover once I fix the aspect ratio stuff so I can pick up a cachekey/URI change as a side effect. Test Plan: {F400524} Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T7707 Differential Revision: https://secure.phabricator.com/D12808
2015-05-12 15:16:18 +02:00
'PhabricatorFileThumbnailTransform' => 'PhabricatorFileImageTransform',
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
'PhabricatorFileTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorFileTransactionComment' => 'PhabricatorApplicationTransactionComment',
'PhabricatorFileTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Modularize file transforms and provide a "transforms" UI Summary: Ref T7707. Available transforms are currently relatively hard-coded and don't really have any support UI. Modularize them so we can build some support UI. This doesn't actually //use// any of the new stuff yet: I want to make a clean cutover once I fix the aspect ratio stuff so I can pick up a cachekey/URI change as a side effect. Test Plan: {F400524} Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T7707 Differential Revision: https://secure.phabricator.com/D12808
2015-05-12 15:16:18 +02:00
'PhabricatorFileTransform' => 'Phobject',
Basic image thumbnailing Summary: This is still very rough but provides basic support for generating image thumbnails. I need to separate stuff out a bit but I'm going to integrate into Maniphest before I hit the profile stuff so this seems like a reasonable starting point. Test Plan: Generated some image thumbnails in various sizes. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran CC: aran Differential Revision: 333
2011-05-22 23:40:51 +02:00
'PhabricatorFileTransformController' => 'PhabricatorFileController',
Modularize file transforms and provide a "transforms" UI Summary: Ref T7707. Available transforms are currently relatively hard-coded and don't really have any support UI. Modularize them so we can build some support UI. This doesn't actually //use// any of the new stuff yet: I want to make a clean cutover once I fix the aspect ratio stuff so I can pick up a cachekey/URI change as a side effect. Test Plan: {F400524} Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T7707 Differential Revision: https://secure.phabricator.com/D12808
2015-05-12 15:16:18 +02:00
'PhabricatorFileTransformListController' => 'PhabricatorFileController',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorFileTransformTestCase' => 'PhabricatorTestCase',
Phabricator file upload application.
2011-01-23 03:33:00 +01:00
'PhabricatorFileUploadController' => 'PhabricatorFileController',
Move Maniphest attached files section into textbox. Summary: Add a button to the Remarkup area that explains how to attach an image and remove the separate upload field. Test Plan: Check that the dialog pops up correctly and that dropping images onto the Remarkup area works. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T879 Differential Revision: https://secure.phabricator.com/D6049
2013-05-26 22:45:24 +02:00
'PhabricatorFileUploadDialogController' => 'PhabricatorFileController',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'PhabricatorFileUploadException' => 'Exception',
Allow diffusion.filecontentquery to load data for arbitrarily large files Summary: Fixes T10186. After D14970, `diffusion.filecontentquery` puts the content in a file and returns the file PHID. However, it does this in a way that doesn't go through the chunking engine, so it will fail for files larger than the chunk threshold (generally, 8MB). Instead, stream the file from the underlying command directly into chunked storage. Test Plan: - Made a commit including a really big file: https://github.com/epriestley/poems/commit/4dcd4c492b31d82f0fec6f447cf3719b9cc079e0 - Used `diffusion.filecontentquery` to load file content. - Parsed/imported commit locally. - Used `diffusion.filecontentquery` to load content for smaller files (README, etc). Reviewers: chad Reviewed By: chad Maniphest Tasks: T10186 Differential Revision: https://secure.phabricator.com/D15072
2016-01-21 13:25:38 +01:00
'PhabricatorFileUploadSource' => 'Phobject',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorFileinfoSetupCheck' => 'PhabricatorSetupCheck',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorFilesApplication' => 'PhabricatorApplication',
Modernize file storage engine selection Summary: Fixes T5843. File storage engines use a very old "selector" mechanism which makes them difficult to extend. This mechanism predates widespread use of `PhutilSymbolLoader` to discover available implementations at runtime. Runtime discovery has generally proven more flexible and easier to use than explicit selection (although it sometimes needs more UI to support it in cases where order or enabled/disabled flags can not be directly determined). Use a modern runtime discovery mechanism instead of an explicit selector. This might break any installs which subclassed the `Selector`, but I believe almost no such installs exist, and they'll receive a meaningful exception upon upgrading (any custom engines will no longer implement all of the required methods). Looking forward, this modernizes infrastructure to prepare for new "virtual" chunked-storage engines, with the eventual goal of supporting very large file uploads and data import into the Phacility cluster. This uses D12051 to add UI to make it easier to understand the state of storage engines. Test Plan: Used new UI panel to assess storage engines: {F336270} - Uploaded a small file, saw it go to MySQL engine. - Uploaded a larger file, saw it go to S3 engine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5843 Differential Revision: https://secure.phabricator.com/D12053
2015-03-12 21:28:53 +01:00
'PhabricatorFilesApplicationStorageEnginePanel' => 'PhabricatorApplicationConfigurationPanel',
Update project profile image composer for new IconSet code Summary: Fixes T6856. Fixes T10164. - Make the profile image composer code use the underlying icon name instead of the top-level icon key, so it works instead of 404'ing. - Change the button to show a preview of the profile icon instead of the text "Use Icon and Color". - When creating a new non-milestone project, automatically set the profile image to the icon + color image. Test Plan: - Created several new projects, saw appropriate default icons. - Edited projects, saw icon previews. - Clicked icon buttons to set icons. - Poked around other applications which use builtins (Pholio, user profiles) to look for anything I broke, but everything seemed fine. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6856, T10164 Differential Revision: https://secure.phabricator.com/D15050
2016-01-18 21:58:19 +01:00
'PhabricatorFilesBuiltinFile' => 'Phobject',
'PhabricatorFilesComposeIconBuiltinFile' => 'PhabricatorFilesBuiltinFile',
First go at Files settings. Summary: Based on @epriestley's https://secure.phabricator.com/differential/diff/9186/ plus others that seemed like they belong here. Test Plan: Saw the new settings show up in the web interface. Reviewers: epriestley, btrahan, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4425
2013-01-14 02:01:00 +01:00
'PhabricatorFilesConfigOptions' => 'PhabricatorApplicationConfigOptions',
Add `bin/files cat` to print a file to stdout Summary: Ref T7149. This makes debugging some of this stuff a bit easier by removing the HTTP part in the middle. Particularly, I anticipate having this stream data chunk-by-chunk in the near future. Test Plan: Ran `files cat F23`, got output. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12062
2015-03-13 19:30:13 +01:00
'PhabricatorFilesManagementCatWorkflow' => 'PhabricatorFilesManagementWorkflow',
Add `bin/files compact` for sharing file data storage Summary: Fixes T5912. When we write files, we attempt to share storage if two files have the same content. In some cases, we may not share storage. Examples include: - Files migrated with `bin/files migrate` (it's simpler not to try to dedupe them). - Old files, from before storage was sharable (the mechanism did not exist). - Files broken by the bug fixed in T5912. Add a script to compact files by pointing files with the same content hash at the same file contnet. In the particular case of files broken by the bug in T5912, we know the hash of the file's content and will only point them at a file that we can load the data for, so this fixes them. Compaction is not hugely useful in general, but this script isn't too complex and the ability to fix damage from the bug in T5912 is desirable. We could remove this capability eventually. Test Plan: - Ran `files compact --all --dry-run` and sanity checked a bunch of the duplicates for actually being duplicates. - Migrated individual files with `files compact Fnnn --trace` and verified the storage compacted and all files survived the process. - Verified unused storage was correctly destroyed after removing the last reference to it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5912 Differential Revision: https://secure.phabricator.com/D10327
2014-08-21 20:47:59 +02:00
'PhabricatorFilesManagementCompactWorkflow' => 'PhabricatorFilesManagementWorkflow',
Add a script to migrate files between storage engines Summary: Quora requested this (moving to S3) but it's also clearly a good idea. Test Plan: Ran with various valid/invalid options to test options. Error/sanity checking seemed OK. Migrated individual local files. Migrated all my local files back and forth between engines several times. Uploaded some new files. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran Maniphest Tasks: T1950 Differential Revision: https://secure.phabricator.com/D3808
2012-10-25 20:36:38 +02:00
'PhabricatorFilesManagementEnginesWorkflow' => 'PhabricatorFilesManagementWorkflow',
'PhabricatorFilesManagementMigrateWorkflow' => 'PhabricatorFilesManagementWorkflow',
Add a `bin/files purge` workflow Summary: We can lose file data through various means; one reasonable way is if files get deleted from disk with 'local-disk' storage. If data goes missing, Ref T3265. Also, reduce some code duplication. Test Plan: Ran `bin/files purge`, `bin/files migrate`, `bin/files rebuild` with various args. Deleted a file with "local-disk" storage, ran `bin/files purge`, made sure it got picked up. Reviewers: dctrwatson, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3265 Differential Revision: https://secure.phabricator.com/D6068
2013-05-29 15:28:57 +02:00
'PhabricatorFilesManagementPurgeWorkflow' => 'PhabricatorFilesManagementWorkflow',
Rename `bin/files metadata` to `bin/files rebuild` and let it rebuild MIME information Summary: See <https://github.com/facebook/phabricator/issues/320>. Files can end up with a bad MIME type, and we don't update it when uploading another copy of the file since obviously the new copy has the same data and thus the same MIME type. - Rename `bin/files metadata` to `bin/files rebuild` to make it a more consistent verb. - Let it rebuild MIME types so users who hit issues like this can run `bin/files rebuild --all --rebuild-mime` to straighten things out. Test Plan: Ran `bin/files` in various modes, examined output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5951
2013-05-17 19:00:31 +02:00
'PhabricatorFilesManagementRebuildWorkflow' => 'PhabricatorFilesManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorFilesManagementWorkflow' => 'PhabricatorManagementWorkflow',
Update project profile image composer for new IconSet code Summary: Fixes T6856. Fixes T10164. - Make the profile image composer code use the underlying icon name instead of the top-level icon key, so it works instead of 404'ing. - Change the button to show a preview of the profile icon instead of the text "Use Icon and Color". - When creating a new non-milestone project, automatically set the profile image to the icon + color image. Test Plan: - Created several new projects, saw appropriate default icons. - Edited projects, saw icon previews. - Clicked icon buttons to set icons. - Poked around other applications which use builtins (Pholio, user profiles) to look for anything I broke, but everything seemed fine. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6856, T10164 Differential Revision: https://secure.phabricator.com/D15050
2016-01-18 21:58:19 +01:00
'PhabricatorFilesOnDiskBuiltinFile' => 'PhabricatorFilesBuiltinFile',
Rate limit outbound requests in Macros Summary: Ref T6755. Although we do not return response bodies, it is possible to perform crude portscanning if you can execute a DNS rebinding attack (which, for now, remains theoretical). Limit users to 60 requests / hour to make it less feasible. This would require ~30 years to portscan all ports on a `/32` netblock. Users who can guess that services may exist can confirm their existence more quickly than this, but if the attacker already had a very small set of candidate services it seems unlikely that portscanning would be of much use in executing the attack. This protection should eventually be applied to T4190, too (that task also has other considerations). Test Plan: Set rate limit very low, hit rate limit. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6755 Differential Revision: https://secure.phabricator.com/D12168
2015-03-26 19:11:52 +01:00
'PhabricatorFilesOutboundRequestAction' => 'PhabricatorSystemAction',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorFlag' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorFlagDAO',
'PhabricatorPolicyInterface',
Make Flags policy aware Summary: Ref T1809. Ref T603. Ref T3599. Makes flags policy aware. This change reduces the utility of flag search/browse; the next change will switch it to ApplicationSearch to restore utility. Representing all that ordering in terms of cursor paging is also a giant pain. Test Plan: Viewed Differential, Flags, etc. Grepped for all PhabricatorFlagQuery callsites. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T1809, T3599 Differential Revision: https://secure.phabricator.com/D6746
2013-08-14 01:17:42 +02:00
),
Modularize Herald "flag" action, plus update transcripts Summary: Ref T8726. This modularizes "Mark with flag", plus rebuilds transcripts in a more modern/flexible way. The big transcript stuff is: - Transcripts are now translatable. - Transcripts can now show multiple outputs from a single action. For example, an action like "add A, B, C to subscribers" can now say "added A; B is invalid; C was already subscribed". Test Plan: {F637784} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: joshuaspence, eadler, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13649
2015-07-18 14:54:26 +02:00
'PhabricatorFlagAddFlagHeraldAction' => 'HeraldAction',
Add "Flags" to allow users to collect the things they love Summary: Flags are a personal collection of things you want to take a look at later. You can use several different colors and add notes. Not really sure if this is actually a good idea or not but it was easy to build. Planned features: - Allow Herald rules to add flags. - In the "edit flag" dialog, have a "[x] Subscribe Me" checkbox that CCs you. - Support Diffusion. - Support Phriction. - Always show flags on an object if you have them (in every view)? - Edit dialog feels a little heavy? - More filtering in /flag/ tool. - Add a top-level links somewhere? Test Plan: Added, edited and removed flags from things. Viewed flags in flag view. Reviewers: aran, btrahan Reviewed By: btrahan CC: aran, epriestley, Koolvin Maniphest Tasks: T1041 Differential Revision: https://secure.phabricator.com/D2024
2012-03-28 01:22:40 +02:00
'PhabricatorFlagColor' => 'PhabricatorFlagConstants',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorFlagConstants' => 'Phobject',
Add "Flags" to allow users to collect the things they love Summary: Flags are a personal collection of things you want to take a look at later. You can use several different colors and add notes. Not really sure if this is actually a good idea or not but it was easy to build. Planned features: - Allow Herald rules to add flags. - In the "edit flag" dialog, have a "[x] Subscribe Me" checkbox that CCs you. - Support Diffusion. - Support Phriction. - Always show flags on an object if you have them (in every view)? - Edit dialog feels a little heavy? - More filtering in /flag/ tool. - Add a top-level links somewhere? Test Plan: Added, edited and removed flags from things. Viewed flags in flag view. Reviewers: aran, btrahan Reviewed By: btrahan CC: aran, epriestley, Koolvin Maniphest Tasks: T1041 Differential Revision: https://secure.phabricator.com/D2024
2012-03-28 01:22:40 +02:00
'PhabricatorFlagController' => 'PhabricatorController',
'PhabricatorFlagDAO' => 'PhabricatorLiskDAO',
'PhabricatorFlagDeleteController' => 'PhabricatorFlagController',
Fully modularize DestructionEngine Summary: Ref T9979. Convert all DestructionEngine behaviors to extensions. Test Plan: {F1033244} Destroyed an object, verifying: - Herald transcripts were destroyed; - edges were destroyed; - flags were destroyed; - tokens were destroyed; - transactions were destroyed; - worker tasks were cancelled. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14832
2015-12-20 17:11:59 +01:00
'PhabricatorFlagDestructionEngineExtension' => 'PhabricatorDestructionEngineExtension',
Add "Flags" to allow users to collect the things they love Summary: Flags are a personal collection of things you want to take a look at later. You can use several different colors and add notes. Not really sure if this is actually a good idea or not but it was easy to build. Planned features: - Allow Herald rules to add flags. - In the "edit flag" dialog, have a "[x] Subscribe Me" checkbox that CCs you. - Support Diffusion. - Support Phriction. - Always show flags on an object if you have them (in every view)? - Edit dialog feels a little heavy? - More filtering in /flag/ tool. - Add a top-level links somewhere? Test Plan: Added, edited and removed flags from things. Viewed flags in flag view. Reviewers: aran, btrahan Reviewed By: btrahan CC: aran, epriestley, Koolvin Maniphest Tasks: T1041 Differential Revision: https://secure.phabricator.com/D2024
2012-03-28 01:22:40 +02:00
'PhabricatorFlagEditController' => 'PhabricatorFlagController',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'PhabricatorFlagListController' => 'PhabricatorFlagController',
Make Flags policy aware Summary: Ref T1809. Ref T603. Ref T3599. Makes flags policy aware. This change reduces the utility of flag search/browse; the next change will switch it to ApplicationSearch to restore utility. Representing all that ordering in terms of cursor paging is also a giant pain. Test Plan: Viewed Differential, Flags, etc. Grepped for all PhabricatorFlagQuery callsites. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T1809, T3599 Differential Revision: https://secure.phabricator.com/D6746
2013-08-14 01:17:42 +02:00
'PhabricatorFlagQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Implement ApplicationSearch in Flags Summary: Ref T1809. Provide ApplicationSearch to Flags and allow the user to select flags by color. @chad might have some design feedback on my control. Test Plan: {F54131} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D6747
2013-08-14 01:27:26 +02:00
'PhabricatorFlagSearchEngine' => 'PhabricatorApplicationSearchEngine',
'PhabricatorFlagSelectControl' => 'AphrontFormControl',
Work around a bug in PHP 5.3-ish with abstract methods in interfaces Summary: @chad is hitting an issue described in P961, which I think is this bug in PHP: https://bugs.php.net/bug.php?id=43200 Work around it by defining a "PHIDInterface" and having both "Flaggable" and "Policy" extend it, so that there is only one `getPHID()` declaration. Test Plan: shrug~ Reviewers: chad, btrahan Reviewed By: chad CC: chad, aran Differential Revision: https://secure.phabricator.com/D7408
2013-10-26 00:58:17 +02:00
'PhabricatorFlaggableInterface' => 'PhabricatorPHIDInterface',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorFlagsApplication' => 'PhabricatorApplication',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'PhabricatorFlagsUIEventListener' => 'PhabricatorEventListener',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorFulltextEngine' => 'Phobject',
Modularize fulltext indexing of Projects, Subscriptions and Custom Fields Summary: Ref T9979. This is going to become `FulltextEngine`, but pave the way for that by pulling extensions out of it. Test Plan: {F1036624} - Used `bin/search index Txxx`, saw projects, subscribers and custom fields rebuild in the index. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14835
2015-12-21 15:31:31 +01:00
'PhabricatorFulltextEngineExtension' => 'Phobject',
'PhabricatorFulltextEngineExtensionModule' => 'PhabricatorConfigModule',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorFulltextIndexEngineExtension' => 'PhabricatorIndexEngineExtension',
Rename "SearchEngine" to "FulltextStorageEngine" Summary: Ref T9979. I picked this name long before the advent of modern "Engine" architecture and it ended up being pretty confusing. Rename "SearchEngine" (currently: mysql or elasticsearch, used to store and query fulltext indexes) to "FulltextStorageEngine" to make it more clear what it does and disambituate it from ApplicationSearch, which also has a bunch of stuff called "SearchEngine", "SearchEngineExtension", etc. Test Plan: Grepped for `phabricatorsearchengine`. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14843
2015-12-21 19:25:28 +01:00
'PhabricatorFulltextStorageEngine' => 'Phobject',
Scaffolding for Fund Summary: Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet. You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc). Only notable decisions: - Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative. - I think that's it? Test Plan: - Created an initiative. - Edited an initiative. - Changed application policy defaults. - Searched for initiatives. - Subscribed to an initiative. - Opened/closed an initiative. - Used `I123` and `{I123}` in remarkup. - Destroyed an initiative. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5835 Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
'PhabricatorFundApplication' => 'PhabricatorApplication',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorGDSetupCheck' => 'PhabricatorSetupCheck',
Modularize the Garbage Collector Summary: The GC is a big block of hard-coded application GCs right now. Among other things, this means third parties can't tap into the infrastructure. Modularize it into `GarbageCollector` classes. This implements only one to prove the new stuff works; I'll followup with the rest in the next diff or few depending on how much mess I run into. Test Plan: Used `bin/phd debug garbage` to run the collector in debug mode, observed reasonable output and behavior. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7970
2014-01-15 19:02:24 +01:00
'PhabricatorGarbageCollector' => 'Phobject',
Provide `bin/garbage` for interacting with garbage collection Summary: Fixes T9494. This: - Removes all the random GC.x.y.z config. - Puts it all in one place that's locked and which you use `bin/garbage set-policy ...` to adjust. - Makes every TTL-based GC configurable. - Simplifies the code in the actual GCs. Test Plan: - Ran `bin/garbage collect` to collect some garbage, until it stopped collecting. - Ran `bin/garbage set-policy ...` to shorten policy. Saw change in web UI. Ran `bin/garbage collect` again and saw it collect more garbage. - Set policy to indefinite and saw it not collect garabge. - Set policy to default and saw it reflected in web UI / `collect`. - Ran `bin/phd debug trigger` and saw all GCs fire with reasonable looking queries. - Read new docs. {F857928} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9494 Differential Revision: https://secure.phabricator.com/D14219
2015-10-02 18:17:24 +02:00
'PhabricatorGarbageCollectorManagementCollectWorkflow' => 'PhabricatorGarbageCollectorManagementWorkflow',
'PhabricatorGarbageCollectorManagementSetPolicyWorkflow' => 'PhabricatorGarbageCollectorManagementWorkflow',
'PhabricatorGarbageCollectorManagementWorkflow' => 'PhabricatorManagementWorkflow',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorGestureUIExample' => 'PhabricatorUIExample',
Move Git discovery into DiscoveryEngine Summary: Ref T4327. Consolidates and simplifies infrastructure: - Moves Git discovery into DiscoveryEngine. - Collapses a bunch of the Git and Mercurial code related to stream discovery. - Removes all cach code from PullLocal daemon (it's no longer called). - Adds basic unit tests for Git and Mercurial discovery. Various cleanup: - Makes GitStream and MercurialStream extend a common base. - Improves performance of MercurialStream in some cases, by requiring fewer commits be output and parsed. - Makes mirroring exceptions easier to debug. - Fixes discovery of Mercurial repositories with multiple branch heads. - Adds some missing `pht()`. Test Plan: I tested this fairly throughly because I think this phase is complete: - Made new repositories in multiple VCSes and did full imports. - Particularly, I reimported Arcanist to make sure that TODO was resolved. I think it was related to the toposort stuff. - Pushed commits to multiple VCSes. - Pushed commits to a non-close branch, then pushed a merge commit. Observed commits import initially as non-close, then get flagged for close. - Started full daemons and resolved various minor issues that showed up in the daemon log until everything ran cleanly. - Basically spent about 30 minutes banging on this in every way I could think of to try to break it. I found and fixed some minor stuff, but it seems solid. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7987
2014-01-17 00:31:52 +01:00
'PhabricatorGitGraphStream' => 'PhabricatorRepositoryGraphStream',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorGitHubAuthProvider' => 'PhabricatorOAuth2AuthProvider',
Implement a MySQL-backed global lock Summary: Implementation is a little crazy but this seems to work as advertised. Test Plan: Acquired locks with "lock.php". Verified they held as long as the process reamined open and released properly on kill -9, ^C, etc. Reviewers: nh, jungejason, vrana, btrahan, Girish, edward Reviewed By: btrahan CC: aran Maniphest Tasks: T1400 Differential Revision: https://secure.phabricator.com/D2864
2012-06-27 22:59:12 +02:00
'PhabricatorGlobalLock' => 'PhutilLock',
Modernize file uploads Summary: Modernizes file uploads. In particular: - Adds a mobile menu, with an "Upload File" item. - Adds crumbs to the list view, detail view and upload view. - Adds "Upload File" action to crumbs. - Moves upload file to a separate page. - Removes the combined upload file + recent files page. - Makes upload file use a normal file control by default (works on mobile). - Home page, file list and file upload page are now global drop targets which accept files dropped anywhere on them. Dragging a file into the window shows a mask and an instructional message. - User education on this is a little weak but I think that's a big can of worms? - Fixes a bug where dropping multiple files into a Remarkup text area produced bad results (resolves T2190). T879 is related, although it's specifically about Maniphest. I've declined to make global drop targets yet there because there are multiple drop targets on the page with different meanings. That UI needs updating in general. @chad, do we have an "upload" icon (counterpart to "download")? Test Plan: Uploaded files in Maniphest, Differential, Files, and from Home. Dragged and dropped multiple files into Differential. Used crumbs, mobile. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2190 Differential Revision: https://secure.phabricator.com/D4200
2012-12-17 01:34:01 +01:00
'PhabricatorGlobalUploadTargetView' => 'AphrontView',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorGoogleAuthProvider' => 'PhabricatorOAuth2AuthProvider',
Modularize complex HTTP parameter types Summary: Ref T9132. We have several places in the code that sometimes need to parse complex types. For example, we accept all of these in ApplicationSearch and now in ApplicationEditor: > /?subscribers=cat,dog > /?subscribers=PHID-USER-1111 > /?subscribers[]=cat&subscribers[]=PHID-USER-2222 ..etc. The logic to parse this stuff isn't too complex, but it isn't trivial either. Right now it lives in some odd places. Notably, `PhabricatorApplicationSearchEngine` has some weird helper methods for this stuff. Rather than give `EditEngine` the same set of weird helper methods, pull all this stuff out into "HTTPParameterTypes". Future diffs will add "Projects" and "Users" types where all the custom parsing/lookup logic can live. Then eventually the Search stuff can reuse these. Generally, this just breaks the code up into smaller pieces that have more specific responsibilities. Test Plan: {F944142} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14402
2015-11-04 14:05:10 +01:00
'PhabricatorHTTPParameterTypeTableView' => 'AphrontView',
Improve handle semantics with HandlePool / HandleList Summary: Ref T7689, which discusses some of the motivation here. Briefly, these methods are awkward: - Controller->loadHandles() - Controller->loadViewerHandles() - Controller->renderHandlesForPHIDs() This moves us toward better semantics, less awkwardness, and a more reasonable attack on T7688 which won't double-fetch a bunch of data. Test Plan: - Added unit tests. - Converted one controller to the new stuff. - Viewed countdown lists, saw handles render. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7689 Differential Revision: https://secure.phabricator.com/D12202
2015-03-30 03:22:27 +02:00
'PhabricatorHandleList' => array(
'Phobject',
'Iterator',
'ArrayAccess',
'Countable',
),
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorHandleObjectSelectorDataView' => 'Phobject',
Improve handle semantics with HandlePool / HandleList Summary: Ref T7689, which discusses some of the motivation here. Briefly, these methods are awkward: - Controller->loadHandles() - Controller->loadViewerHandles() - Controller->renderHandlesForPHIDs() This moves us toward better semantics, less awkwardness, and a more reasonable attack on T7688 which won't double-fetch a bunch of data. Test Plan: - Added unit tests. - Converted one controller to the new stuff. - Viewed countdown lists, saw handles render. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7689 Differential Revision: https://secure.phabricator.com/D12202
2015-03-30 03:22:27 +02:00
'PhabricatorHandlePool' => 'Phobject',
'PhabricatorHandlePoolTestCase' => 'PhabricatorTestCase',
Proide application-based handle loads; load Slowvote handles from the application Summary: Ref T2715. This is pretty straightforward, I think. Notes: - Long term, I want to replace `PhabricatorObjectHandleData` with `PhabricatorObjectQuery` and `PhabricatorHandleQuery`. The former's name is a relic of old Facebook stuff and unusual now that everything else uses normal queries. - I simplified the amount of work applications need to do in order to populate handles. The should just need to set names and URIs in most cases. Test Plan: Used `phid.lookup` and `phid.query` to load slowvote handles. Browsed around to load other handles. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6508
2013-07-21 16:03:10 +02:00
'PhabricatorHandleQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Remarkup rule for rendering PHIDs as handles Summary: adds the `{{PHID....}}` rule. Should mostly be useful in UI code that refers to Objects. It doesn't add any mention links/transactions. Test Plan: Comment with this, see email (plain + html) and comment box. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15488
2016-03-17 21:24:03 +01:00
'PhabricatorHandleRemarkupRule' => 'PhutilRemarkupRule',
Make "Create Subtask" work properly in EditEngine Summary: Ref T9908. This fixes "Create Subtask" so it works with the new stuff. Mostly straightforward. Test Plan: Created some subtasks. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9908 Differential Revision: https://secure.phabricator.com/D14706
2015-12-08 16:54:01 +01:00
'PhabricatorHandlesEditField' => 'PhabricatorPHIDListEditField',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorHarbormasterApplication' => 'PhabricatorApplication',
Implemented support for build logs Summary: Depends on D7519. This implements support for build logs in Harbormaster. This includes support for appending to a log from the "Run Remote Command" build step. It also adds the ability to cancel builds. Currently the build view page doesn't update the logs live; I'm sure this can be achieved with Javelin, but I don't have enough experience with Javelin to actually make it poll from updates to content in the background. {F79151} {F79153} {F79150} {F79152} Test Plan: Tested this by setting up SSH on a Windows machine and using a Remote Command configured with: ``` C:\Windows\system32\cmd.exe /C cd C:\Build && mkdir Build_${timestamp} && cd Build_${timestamp} && git clone --recursive https://github.com/hach-que/Tychaia.git && cd Tychaia && Protobuild.exe && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Tychaia.Windows.sln ``` and observed the output of the build stream from the Windows machine into Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7521
2013-11-09 03:09:03 +01:00
'PhabricatorHarbormasterConfigOptions' => 'PhabricatorApplicationConfigOptions',
Enforce that global locks have keys shorter than 64 characters Summary: Fixes T7484. There's a bunch of spooky mystery here but the current behavior can probably cause problems in at least some situations. Also moves a couple callsigns to monograms (see T4245). Test Plan: - Faked a short lock length to hit the exception. - Updated normally. - Grepped for other use sites, none seemed suspicious or likely to overflow the lock length. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7484 Differential Revision: https://secure.phabricator.com/D12263
2015-04-02 22:42:22 +02:00
'PhabricatorHash' => 'Phobject',
Add PhabricatorHash::digestForIndex() Summary: Does this seem reasonable? It's a bit more compact than digest() (6 bits / byte instead of 4 bits / byte) and 72 bits of entropy @ 12 bytes instead of 128 bits of entropy @ 32 bytes. I feel like it's important to preserve the printability, though, and this seemed like a fairly good balance of concerns. Test Plan: unit tests Reviewers: vrana Reviewed By: vrana CC: aran, yemao932 Differential Revision: https://secure.phabricator.com/D4253
2012-12-21 14:43:33 +01:00
'PhabricatorHashTestCase' => 'PhabricatorTestCase',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorHelpApplication' => 'PhabricatorApplication',
Provide basic structure for keyboard shortcuts Summary: Implements a simple infrastructure for keyboard shortcuts, see T184, and a "help" shortcut. There's a lot of room for refinement here but I think it basically works. Each shortcut can also provide a "tooltip" handler which allows it to show help when the alt/option key is held down. Test Plan: Pressed "?" and got help. Pressed "?" in various contexts where it should not activate (modifier keys, text input focused) and didn't get help. Reviewers: aran, tuomaspelkonen, jungejason CC: moskov Differential Revision: 362
2011-05-28 20:36:00 +02:00
'PhabricatorHelpController' => 'PhabricatorController',
Allow applications to have multiple "help" menu items Summary: Ref T7199. Convert the single help menu item into a dropdown and allow applications to list multiple items there. When an application has mail command objects, link them in the menu. Test Plan: {F355925} {F355926} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12244
2015-04-01 17:13:12 +02:00
'PhabricatorHelpDocumentationController' => 'PhabricatorHelpController',
Whitelist allowed editor protocols Summary: This is the other half of D8548. Specifically, the attack here was to set your own editor link to `javascript\n:...` and then you could XSS yourself. This isn't a hugely damaging attack, but we can be more certain by adding a whitelist here. We already whitelist linkable protocols in remarkup (`uri.allowed-protocols`) in general. Test Plan: Tried to set and use valid/invalid editor URIs. {F130883} {F130884} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8551
2014-03-17 21:00:37 +01:00
'PhabricatorHelpEditorProtocolController' => 'PhabricatorHelpController',
Provide basic structure for keyboard shortcuts Summary: Implements a simple infrastructure for keyboard shortcuts, see T184, and a "help" shortcut. There's a lot of room for refinement here but I think it basically works. Each shortcut can also provide a "tooltip" handler which allows it to show help when the alt/option key is held down. Test Plan: Pressed "?" and got help. Pressed "?" in various contexts where it should not activate (modifier keys, text input focused) and didn't get help. Reviewers: aran, tuomaspelkonen, jungejason CC: moskov Differential Revision: 362
2011-05-28 20:36:00 +02:00
'PhabricatorHelpKeyboardShortcutController' => 'PhabricatorHelpController',
Begin modularizing main menu items Summary: Ref T10077. Ref T8918. The way the main menu is built is not very modular and fairly hacky. It assumes menus are provided by applications, but this isn't exactly true. Notably, the "Quick Create" menu is not per-application. The current method of building this menu is very inefficient (see T10077). Particularly, we have to build it //twice// because we need to build it once to render the item and then again to render the dropdown options. Start cleaning this up. This diff doesn't actually have any behavioral changes, since I can't swap the menu over until we get rid of all the other items and I haven't extended this to Notifications/Conpherence yet so it doesn't actually fix T8918. Test Plan: Viewed menus while logged in, logged out, in different applications, in desktop/mobile. Nothing appeared different. Reviewers: chad Reviewed By: chad Maniphest Tasks: T8918, T10077 Differential Revision: https://secure.phabricator.com/D14922
2016-01-01 13:26:36 +01:00
'PhabricatorHelpMainMenuBarExtension' => 'PhabricatorMainMenuBarExtension',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorHeraldApplication' => 'PhabricatorApplication',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorHeraldContentSource' => 'PhabricatorContentSource',
Modularize Aphront exception handling Summary: Ref T1806. Ref T7173. Depends on D14047. Currently, all exception handling is in this big messy clump in `AphrontDefaultApplicationConfiguration`. Split it out into modular classes. This will let a future change add new classes in the Phacility cluster which intercept particular exceptions we care about and replaces the default, generic responses with more useful, tailored responses. Test Plan: {F777391} - Hit a Conduit error (made a method throw). - Hit an Ajax error (made comment preview throw). - Hit a high security error (tried to edit TOTP). - Hit a rate limiting error (added a bunch of email addresses). - Hit a policy error (tried to look at something with no permission). - Hit an arbitrary exception (made a randomc ontroller throw). Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14049
2015-09-03 19:04:42 +02:00
'PhabricatorHighSecurityRequestExceptionHandler' => 'PhabricatorRequestExceptionHandler',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorHomeApplication' => 'PhabricatorApplication',
Make "Home" a formal application Summary: Ref T3979. Currently, the home page lives in an old application called "directory" and is informally defined. Make it a real application called "Home", with a formal definition. It isn't launchable and can't be uninstalled. Test Plan: Loaded home, saw exact same stuff. Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T3979 Differential Revision: https://secure.phabricator.com/D8074
2014-01-26 21:26:13 +01:00
'PhabricatorHomeController' => 'PhabricatorController',
'PhabricatorHomeMainController' => 'PhabricatorHomeController',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorHomePreferencesSettingsPanel' => 'PhabricatorSettingsPanel',
Add very basic "quick create" menu Summary: Ref T3623. This is like a pre-v0, in that it doesn't have a dropdown yet. Clicking the button takes you to a page which can serve as a right click / mobile / edit target in the long run, but is obviously not great for desktop use. I'll add the dropdown in the next iteration. Test Plan: {F105631} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T3623 Differential Revision: https://secure.phabricator.com/D8088
2014-01-29 05:18:01 +01:00
'PhabricatorHomeQuickCreateController' => 'PhabricatorHomeController',
Modernize Hovercard implementation Summary: Ref T8980. Move away from events to EngineExtensions. This also simplifies hovercards a bit: - Removes tasks from revision cards. - Removes blockers/blocked from task cards. - Removes "Send Message" from user cards. These mostly felt cluttery to me. Open to arguments to retain them. I think we can make better use of the space, though (e.g., flags, projects + board columns). Test Plan: - Viewed people, task, revision, commit and project hovercards. {F1043256} {F1043257} Reviewers: chad Reviewed By: chad Maniphest Tasks: T8980 Differential Revision: https://secure.phabricator.com/D14878
2015-12-24 20:20:18 +01:00
'PhabricatorHovercardEngineExtension' => 'Phobject',
'PhabricatorHovercardEngineExtensionModule' => 'PhabricatorConfigModule',
Add a `bin/hunks` script to manage migrations of hunk data Summary: Ref T4045. Ref T5179. While we'll eventually need to force a migration, we can let installs (particularly large installs) do an online migration for now. This moves hunks to the new storage format one at a time. (Note that nothing writes to the new store yet, so this is the only way to populate it.) WARNING: Installs, don't run this yet! It won't compress the data. Wait until it can also do compression. Test Plan: Added a `break;` after migrating one row and moved a few rows over. Spot checked them in the database and viewed the affected diffs. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4045, T5179 Differential Revision: https://secure.phabricator.com/D9291
2014-05-25 18:54:12 +02:00
'PhabricatorHunksManagementMigrateWorkflow' => 'PhabricatorHunksManagementWorkflow',
'PhabricatorHunksManagementWorkflow' => 'PhabricatorManagementWorkflow',
Clean up "ids" and "phids" handling in SearchEngines Summary: Ref T9964. I added several hacks to get these working. Clean them up and pull this into a proper extension. The behavior in the web UI is: - they work in all applications; but - they only show up in the UI if a value is specified. So if you visit `/view/?ids=1,2` you get the field, but normally it's not present. We could refine this later. I'm going to add documentation about how to prefill these forms regardless, which should make this discoverable by reading the documentation. There's one teensey weensey hack: in the API, I push these fields to the top of the table. That one feels OK, since it's purely a convenience/display adjustment. Test Plan: Queried by IDs, reviewed docs. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14769
2015-12-13 19:11:40 +01:00
'PhabricatorIDsSearchEngineExtension' => 'PhabricatorSearchEngineExtension',
'PhabricatorIDsSearchField' => 'PhabricatorSearchField',
Rename protocol adapter classes Summary: Ref T5655. Rename protocol adapter classes to remove `Base` from the class name. Test Plan: Unit tests still pass. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D12563
2015-05-18 00:20:11 +02:00
'PhabricatorIRCProtocolAdapter' => 'PhabricatorProtocolAdapter',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhabricatorIconRemarkupRule' => 'PhutilRemarkupRule',
Provide a "PHUIFormIconSetControl" Summary: Ref T9992. This is a step on the path to getting EditEngine working in Badges, Projects and Calendar. This doesn't add a new `EditField` for icons yet, just standardizes the old stuff. New stuff is more general and I saved 150 lines of code. I put the endpoint in Files because the similar "choose a profile picture" endpoint will definitely go there, and this endpoint might eventually feature, like, "draw your own icon~~" or something. Test Plan: - Created events, projects and badges with custom icons. - Edited events, projects and badges, changing their icons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9992 Differential Revision: https://secure.phabricator.com/D14799
2015-12-16 16:53:13 +01:00
'PhabricatorIconSet' => 'Phobject',
Convert projects to EditEngine Summary: Ref T10010. This is pretty straightforward with a couple of very minor new behaviors, like the icon selector edit field. Test Plan: - Created projects. - Edited projects. - Saw "Create Project" in quick create menu. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14896
2015-12-27 15:45:53 +01:00
'PhabricatorIconSetEditField' => 'PhabricatorEditField',
Provide a "PHUIFormIconSetControl" Summary: Ref T9992. This is a step on the path to getting EditEngine working in Badges, Projects and Calendar. This doesn't add a new `EditField` for icons yet, just standardizes the old stuff. New stuff is more general and I saved 150 lines of code. I put the endpoint in Files because the similar "choose a profile picture" endpoint will definitely go there, and this endpoint might eventually feature, like, "draw your own icon~~" or something. Test Plan: - Created events, projects and badges with custom icons. - Edited events, projects and badges, changing their icons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9992 Differential Revision: https://secure.phabricator.com/D14799
2015-12-16 16:53:13 +01:00
'PhabricatorIconSetIcon' => 'Phobject',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhabricatorImageMacroRemarkupRule' => 'PhutilRemarkupRule',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorImageTransformer' => 'Phobject',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorImagemagickSetupCheck' => 'PhabricatorSetupCheck',
Begin improving modularity of IndexEngine, add locks Summary: Ref T9890. Ref T9979. Several adjacent goals: - The `SearchEngine` vs `ApplicationSearchEngine` thing is really confusing. There are also a bunch of confusing class names and class relationships within the fulltext indexing. I want to rename these classes to be more standard (`IndexEngine`, `IndexEngineExtension`, etc). Rename `SearchIndexer` to `IndexEngine`. A future change will rename `SearchEngine`. - Add the index locks described in T9890. - Structure things a little more normally so future diffs can do the "EngineExtension" thing more cleanly. Test Plan: Indexing: - Renamed a task to have a unique word in the title. - Ran `bin/search index Txxx`. - Searched for unique word. - Found task. Locking: - Added a `sleep(10)` after the `lock()` call. - Ran `bin/search index Txxx` in two windows. - Saw first one lock, sleep 10 seconds, index. - Saw second one give up temporarily after failing to grab the lock. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9890, T9979 Differential Revision: https://secure.phabricator.com/D14834
2015-12-20 17:54:29 +01:00
'PhabricatorIndexEngine' => 'Phobject',
Lift Conpherence indexing up out of the Fulltext index Summary: Ref T9979. There are currently some hacks around Conpherence indexing: it does not really use the fulltext index, but its own specialized index. However, it's kind of hacked up so it can get reindexed by the normal indexing pipeline. Lift it up into IndexEngine, instead of FulltextEngine. Specifically, the new stuff is going to look like this: - IndexEngine: Rebuild all indexes. - ConpherenceIndexExtension: Rebuild thread indexes. - ProjectMemberIndexExtension: Rebuild project membership views. - NgramIndexExtension: Rebuild ngram indexes. - FulltextIndexExtension / FulltextEngine: Rebuild fulltext indexes, a special type of index. - FulltextCommentExtension: Rebuild comment fulltext indexes. - FulltextProjectExtension: Rebuild project fulltext indexes. - etc. Most of this is at least sort-of-in-place as of this diff, although some of the part in the middle is still pretty rough. Test Plan: - Made a unique comment in a Conpherence thread. - Used `bin/search index --force` to rebuild the index. - Searched for the comment. - Found the thread. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14841
2015-12-21 15:07:41 +01:00
'PhabricatorIndexEngineExtension' => 'Phobject',
'PhabricatorIndexEngineExtensionModule' => 'PhabricatorConfigModule',
Add test to check all symbols can be loaded Summary: make sure all symboles can be loaded to avoid issues like missing methods in descendants of abstract base class. Test Plan: ran it and verified it passes; remove a method in a descendant class and verified that the test failed. Reviewers: epriestley, nh Reviewed By: nh CC: aran, nh, jungejason Differential Revision: 1023
2011-10-20 03:26:21 +02:00
'PhabricatorInfrastructureTestCase' => 'PhabricatorTestCase',
Add inline comments to Diffusion/Audit Summary: - Add inline comments to Audits, like Differential. - Creates new storage for the comments in the Audits database. - Creates a new PhabricatorAuditInlineComment class, similar to DifferentialInlineComment. - Defines an Interface which Differential and Audit comments conform to. - Makes consumers of DifferentialInlineComments consume objects which implement that interface instead. - Adds save NOTE: Some features are still missing! Wanted to cut this off before it got crazy: - Inline comments aren't shown in the main comment list. - Inline comments aren't shown in the emails. - Inline comments aren't previewed. I'll followup with those but this was getting pretty big. @vrana, does the SQL change look correct? Test Plan: - Created, edited, deleted, replied to, reloaded and saved inline comments in Diffusion, on the left and right side of diffs. - Created, edited, deleted, replied to, reloaded and saved inline comments in Differentila, on the left and right side of primary and diff-versus-diff diffs. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1898
2012-03-14 20:56:01 +01:00
'PhabricatorInlineCommentController' => 'PhabricatorController',
Simplify lightboxing and fix a few things Summary: Minor tweaks to lightboxes. - With "position: fixed;", we don't need to do any of the scroll/resize stuff. Just remove it. - Make the lightbox go over the menu bar -- was it intentional that it wasn't? - Make 'jx-mask' use "position: fixed;" too. - Add a loading indicator. - In Differential/Maniphest/etc, a preview may bring in an image but won't bring in the CSS we need. The "real" fix is to ship CSS/JS with ajax, but that's really hard -- fake it by pulling in the right CSS any time we render a remarkup area. I'm going to do a couple of other tweaks here but need to update JX.Mask. Test Plan: Verified behavior is reasonable in Safari, Firefox, Chrome with multiple images / scroll / previews / resize. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1896 Differential Revision: https://secure.phabricator.com/D3795
2012-10-24 02:34:43 +02:00
'PhabricatorInlineCommentInterface' => 'PhabricatorMarkupInterface',
Make inline comment preview work in Diffusion Summary: created a PhabricatorInlineCommentPreviewController so controllers in Diffusion and Differential respectively just have to handle the URI mapping and data loading like good little controllers. Test Plan: left inline comments on commits, deleted inline commits, submitted inline comments -- all worked well did the same on some diffs Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1176 Differential Revision: https://secure.phabricator.com/D3034
2012-07-23 20:01:28 +02:00
'PhabricatorInlineCommentPreviewController' => 'PhabricatorController',
Separate the inline comment summary element into a separate view Summary: - Affects the "Inline Comments" summary table which appears in comments that have attached inlines in the discussion threads in Differential. - Prepares for inclusion in Diffusion. - No application changes (minor CSS), just factors code better. - Simplify/separate CSS. Test Plan: Looked at on-diff and off-diff comment summaries in Differential, display looked correct. Reviewers: davidreuss, nh, btrahan Reviewed By: davidreuss CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1928
2012-03-20 03:45:16 +01:00
'PhabricatorInlineSummaryView' => 'AphrontView',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorInstructionsEditField' => 'PhabricatorEditField',
Write a very basic string extractor Summary: Ref T1139. This has some issues and glitches, but is a reasonable initial attempt that gets some of the big pieces in. We have about 5,200 strings in Phabricator. Test Plan: {F108261} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D8138
2014-02-05 20:02:41 +01:00
'PhabricatorInternationalizationManagementExtractWorkflow' => 'PhabricatorInternationalizationManagementWorkflow',
'PhabricatorInternationalizationManagementWorkflow' => 'PhabricatorManagementWorkflow',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorInvalidConfigSetupCheck' => 'PhabricatorSetupCheck',
Make password hashing modular Summary: Ref T4443. Make hashing algorithms pluggable and extensible so we can deal with the attendant complexities more easily. This moves "Iterated MD5" to a modular implementation, and adds a tiny bit of hack-glue so we don't need to migrate the DB in this patch. I'll migrate in the next patch, then add bcrypt. Test Plan: - Verified that the same stuff gets stored in the DB (i.e., no functional changes): - Logged into an old password account. - Changed password. - Registered a new account. - Changed password. - Switched back to master. - Logged in / out, changed password. - Switched back, logged in. - Ran unit tests (they aren't super extensive, but cover some of the basics). Reviewers: btrahan Reviewed By: btrahan CC: aran, kofalt Maniphest Tasks: T4443 Differential Revision: https://secure.phabricator.com/D8268
2014-02-18 18:31:30 +01:00
'PhabricatorIteratedMD5PasswordHasher' => 'PhabricatorPasswordHasher',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorIteratedMD5PasswordHasherTestCase' => 'PhabricatorTestCase',
Support pushing data into Git LFS Summary: Ref T7789. Ref T10604. This implements the `upload` action, which streams file data into Files. This makes Git LFS actually work, at least roughly. Test Plan: - Tracked files in an LFS repository. - Pushed LFS data (`git lfs track '*.png'; git add something.png; git commit -m ...; git push`). - Pulled LFS data (`git checkout master^; rm -rf .git/lfs; git checkout master; open something.png`). - Verified LFS refs show up in the gitlfsref table. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7789, T10604 Differential Revision: https://secure.phabricator.com/D15492
2016-03-18 14:22:37 +01:00
'PhabricatorIteratorFileUploadSource' => 'PhabricatorFileUploadSource',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorJIRAAuthProvider' => 'PhabricatorOAuth1AuthProvider',
Bring Javelin into Phabricator via git submodule, not copy-and-paste Summary: Javelin is currently embedded in Phabricator via copy-and-paste of prebuilt packages. This is not so great. Pull it in as a submodule instead and make all the Phabriator resources declare proper dependency trees. Add Javelin linting. Test Plan: I tried to run through pretty much all the JS functionality on the site. This is still a high-risk change, but I did a pretty thorough test Differential: inline comments, revealing diffs, list tokenizers, comment preview, editing/deleting comments, add review action. Maniphest: list tokenizer, comment actions Herald: rule editing, tokenizers, add/remove rows Reviewed By: tomo Reviewers: aran, tomo, mroch, jungejason, tuomaspelkonen CC: aran, tomo, epriestley Differential Revision: 223
2011-05-04 00:11:55 +02:00
'PhabricatorJavelinLinter' => 'ArcanistLinter',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorJiraIssueHasObjectEdgeType' => 'PhabricatorEdgeType',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorJumpNavHandler' => 'Phobject',
Implement a more compact, general database-backed key-value cache Summary: See discussion in D4204. Facebook currently has a 314MB remarkup cache with a 55MB index, which is slow to access. Under the theory that this is an index size/quality problem (the current index is on a potentially-384-byte field, with many keys sharing prefixes), provide a more general index with fancy new features: - It implements PhutilKeyValueCache, so it can be a component in cache stacks and supports TTL. - It has a 12-byte hash-based key. - It automatically compresses large blocks of data (most of what we store is highly-compressible HTML). Test Plan: - Basics: - Loaded /paste/, saw caches generate and save. - Reloaded /paste/, saw the page hit cache. - GC: - Ran GC daemon, saw nothing. - Set maximum lifetime to 1 second, ran GC daemon, saw it collect the entire cache. - Deflate: - Selected row formats from the database, saw a mixture of 'raw' and 'deflate' storage. - Used profiler to verify that 'deflate' is fast (12 calls @ 220us on my paste list). - Ran unit tests Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D4259
2012-12-21 23:17:56 +01:00
'PhabricatorKeyValueDatabaseCache' => 'PhutilKeyValueCache',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorLDAPAuthProvider' => 'PhabricatorAuthProvider',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorLegalpadApplication' => 'PhabricatorApplication',
Legalpad V0.2 - add mail integration Summary: Supports !unsubscribe and commenting on replies. Subscribers get mailed something reasonable. Fixes T3480. Sneaks in /LX/ support. In the near future I want to have that /LX/ be a clean "signature" page sans all the edit actions and other fluff... Will resolve this as part of T3481. Test Plan: used the metamta console to add comments and unsubscribe. added a phlog() inside mail code to verify mail bodies looked okay. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3480 Differential Revision: https://secure.phabricator.com/D6369
2013-07-04 01:37:05 +02:00
'PhabricatorLegalpadConfigOptions' => 'PhabricatorApplicationConfigOptions',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorLegalpadDocumentPHIDType' => 'PhabricatorPHIDType',
Rename `PhabricatorPolicyRule` subclasses for consistency Summary: Ref T5655. Fixes T6849. This is another take on D11131, which was missing the DB migration and was reverted in rP7c4de0f6be77ddaea593e1f41ae27211ec179a55. Test Plan: Ran `./bin/storage upgrade` and verified that the classes were renamed in the `phabricator_policy.policy` table. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6849, T5655 Differential Revision: https://secure.phabricator.com/D11166
2015-01-03 13:48:19 +01:00
'PhabricatorLegalpadSignaturePolicyRule' => 'PhabricatorPolicyRule',
Use `PhutilLibraryTestCase` Summary: Depends on D11231. Test Plan: `arc unit` Reviewers: btrahan, #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11233
2015-01-06 21:38:08 +01:00
'PhabricatorLibraryTestCase' => 'PhutilLibraryTestCase',
Begin modularizing profile panel/link construction Summary: Ref T10054. This has no product impact, but prepares us for customizable side nav on "profiles" (today, projects; probably users some day; and maybe other stuff down the road). Test Plan: Clicked all links on a profile, everything was exactly the same as before. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15007
2016-01-12 19:27:39 +01:00
'PhabricatorLinkProfilePanel' => 'PhabricatorProfilePanel',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorLipsumArtist' => 'Phobject',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorLipsumContentSource' => 'PhabricatorContentSource',
First Diff of Test Data Generator Summary: Progress to fix T2903 Test Plan: Ran './bin/lipsum help' and 'generate' workflows. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5672
2013-04-12 23:07:15 +02:00
'PhabricatorLipsumGenerateWorkflow' => 'PhabricatorLipsumManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorLipsumManagementWorkflow' => 'PhabricatorManagementWorkflow',
Add a basic random image generator Summary: Adds an abstract base class for random image generation. Implements a concrete subclass for generating Mondrian-like images. Test Plan: {F40759} {F40760} {F40761} {F40762} {F40763} Reviewers: DeedyDas, AnhNhan Reviewed By: AnhNhan CC: chad, aran Differential Revision: https://secure.phabricator.com/D5705
2013-04-16 17:19:45 +02:00
'PhabricatorLipsumMondrianArtist' => 'PhabricatorLipsumArtist',
More phabricator organizational stuff.
2011-01-23 02:48:55 +01:00
'PhabricatorLiskDAO' => 'LiskDAO',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorLiskFulltextEngineExtension' => 'PhabricatorFulltextEngineExtension',
Implement a rough initial version of ApplicationSearch-driven Conduit read endpoints Summary: Ref T9964. See that task for some context and discussion. Ref T7715, which has the bigger picture here. Basically, I want Conduit read endpoints to be full-power, ApplicationSearch-driven endpoints, so that applications can: - Write one EditEngine and get web + conduit writes for free. - Write one SearchEngine and get web + conduit reads for free. I previously made some steps toward this, but this puts more of the structure in place. Test Plan: Viewed API console endpoint and read 20 pages of docs: {F1021961} Made various calls: with query keys, constraints, pagination, and limits. Viewed new {nav Config > Modules} page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7715, T9964 Differential Revision: https://secure.phabricator.com/D14743
2015-12-11 17:45:56 +01:00
'PhabricatorLiskSearchEngineExtension' => 'PhabricatorSearchEngineExtension',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorLiskSerializer' => 'Phobject',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorListFilterUIExample' => 'PhabricatorUIExample',
Allow Phabricator storage engines to be extended and configured Summary: See T344. Currently, there's a hard-coded 12MB filesize limit and some awkward interactions with MySQL's max_allowed_packet. Make this system generally more robust: - Move the upload limit to configuration. - Add setup steps which reconcile max_allowed_packet vs MySQL file storage limits. - Add a layer of indirection between uploading files and storage engines. - Allow the definition of new storage engines. - Define a local disk storage engine. - Add a "storage engine selector" class which manages choosing which storage engines to put files in. - Document storage engines. - Document file storage classes. Test Plan: Setup mode: - Disabled MySQL storage engine, misconfigured it, configured it correctly. - Disabled file storage engine, set it to something invalid, set it to something valid. - Verified max_allowed_packet is read correctly. Application mode: - Configured local file storage. - Uploaded large and small files. - Verified larger files were written to local storage. - Verified smaller files were written to MySQL blob storage. Documentation: - Read documentation. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, epriestley, jungejason Differential Revision: 695
2011-07-20 07:48:38 +02:00
'PhabricatorLocalDiskFileStorageEngine' => 'PhabricatorFileStorageEngine',
Improve time localization code Summary: - We throw on a missing date right now, in the DateTime constructor. This can happen in reasonable cases and this is display code, so handle it more gracefully (see T520). - This stuff is a little slow and we sometimes render many hundreds of dates per page. I've been seeing it in profiles on and off. Memoize timezones to improve performance. - Some minor code duplication that would have become less-minor with the constructor change, consolidate the logic. - Add some unit tests and a little documentation. Test Plan: - Ran unit tests. - Profiled 1,000 calls to phabricator_datetime(), cost dropped from ~49ms to ~19ms with addition of memoization. This is still slower than I'd like but I don't think there's an easy way to squeeze it down further. Reviewers: ajtrichards, jungejason, nh, tuomaspelkonen, aran Reviewed By: ajtrichards CC: aran, ajtrichards, epriestley Differential Revision: 966
2011-09-27 18:03:55 +02:00
'PhabricatorLocalTimeTestCase' => 'PhabricatorTestCase',
Send mail to targets in the user's translation Summary: Ref T6367. Test Plan: - Added and executed unit tests. - Sent mail to A (en_US) and B (en_A*). - Got one mail in English and one mail in ENGLISH. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6367 Differential Revision: https://secure.phabricator.com/D13142
2015-06-03 19:49:27 +02:00
'PhabricatorLocaleScopeGuard' => 'Phobject',
'PhabricatorLocaleScopeGuardTestCase' => 'PhabricatorTestCase',
Implement clock/trigger infrastructure for scheduling actions Summary: Ref T6881. Hopefully, this is the hard part. This adds a new daemon (the "trigger" daemon) which processes triggers, schedules them, and then executes them at the scheduled time. The design is a little complicated, but has these goals: - High resistance to race conditions: only the application writes to the trigger table; only the daemon writes to the event table. We won't lose events if someone saves a meeting at the same time as we're sending a reminder out for it. - Execution guarantees: scheduled events are guaranteed to execute exactly once. - Support for arbitrarily large queues: the daemon will make progress even if there are millions of triggers in queue. The cost to update the queue is proportional to the number of changes in it; the cost to process the queue is proportional to the number of events to execute. - Relatively good observability: you can monitor the state of the trigger queue reasonably well from the web UI. - Modular Infrastructure: this is a very low-level construct that Calendar, Phortune, etc., should be able to build on top of. It doesn't have this stuff yet: - Not very robust to bad actions: a misbehaving trigger can stop the queue fairly easily. This is OK for now since we aren't planning to make it part of any other applications for a while. We do still get execute-exaclty-once, but it might not happen for a long time (until someone goes and fixes the queue), when we could theoretically continue executing other events. - Doesn't start automatically: normal users don't need to run this thing yet so I'm not starting it by default. - Not super well tested: I've vetted the basics but haven't run real workloads through this yet. - No sophisticated tooling: I added some basic stuff but it's missing some pieces we'll have to build sooner or later, e.g. `bin/trigger cancel` or whatever. - Intentionally not realtime: This design puts execution guarantees far above realtime concerns, and will not give you precise event execution at 1-second resolution. I think this is the correct goal to pursue architecturally, and certainly correct for subscriptions and meeting reminders. Events which execute after they have become irrelevant can simply decline to do anything (like a meeting reminder which executes after the meeting is over). In general, the expectation for applications is: - When creating an object (like a calendar event) that needs to trigger a scheduled action, write a trigger (and save the PHID if you plan to update it later). - The daemon will process the event and schedule the action efficiently, in a race-free way. - If you want to move the action, update the trigger and the daemon will take care of it. - Your action will eventually dump a task into the task queue, and the task daemons will actually perform it. Test Plan: Using a test script like this: ``` <?php require_once 'scripts/__init_script__.php'; $trigger = id(new PhabricatorWorkerTrigger()) ->setAction( new PhabricatorLogTriggerAction( array( 'message' => 'test', ))) ->setClock( new PhabricatorMetronomicTriggerClock( array( 'period' => 33, ))) ->save(); var_dump($trigger); ``` ...I queued triggers and ran the daemon: - Verified triggers fire; - verified triggers reschedule; - verified trigger events show up in the web UI; - tried different periods; - added some triggers while the daemon was running; - examined `phd debug` output for anything suspicious. It seems to work in trivial use case, at least. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11419
2015-01-16 21:13:31 +01:00
'PhabricatorLogTriggerAction' => 'PhabricatorTriggerAction',
CSRF / Logout
2011-01-31 03:52:29 +01:00
'PhabricatorLogoutController' => 'PhabricatorAuthController',
Rename `PhabricatorPolicyRule` subclasses for consistency Summary: Ref T5655. Fixes T6849. This is another take on D11131, which was missing the DB migration and was reverted in rP7c4de0f6be77ddaea593e1f41ae27211ec179a55. Test Plan: Ran `./bin/storage upgrade` and verified that the classes were renamed in the `phabricator_policy.policy` table. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6849, T5655 Differential Revision: https://secure.phabricator.com/D11166
2015-01-03 13:48:19 +01:00
'PhabricatorLunarPhasePolicyRule' => 'PhabricatorPolicyRule',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorMacroApplication' => 'PhabricatorApplication',
Allow macros to have associated audio and audio behaviors Summary: Ref T3887. Implements storage and editors, but not the actual audio part. Test Plan: Edited audio, audio behaviors of macros. Transactions and email looked good. Hit error cases. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3887 Differential Revision: https://secure.phabricator.com/D7159
2013-09-28 01:01:37 +02:00
'PhabricatorMacroAudioController' => 'PhabricatorMacroController',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorMacroCommentController' => 'PhabricatorMacroController',
MetaMTA: Owners, Pholio, Macro Summary: Port MetaMTA options for Owners, Pholio and Macro. At some point I'd like to get rid of all these options (provide one "reply domain", and not allow overrides of reply handlers -- use events instead) but that's a battle we can fight later. Test Plan: Looked at options, looked at setup issues, edited something. Reviewers: codeblock, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4469
2013-01-16 19:52:30 +01:00
'PhabricatorMacroConfigOptions' => 'PhabricatorApplicationConfigOptions',
Move "Macros" to a first-class application Summary: This is mostly to unblock D3547. - Move "Macros" to a first-class application called "Macros". - After D3547, this application will also house "Memes" (macros with text on them). - This will also make them easier to find; the top navigational query I field is "where are image macros?" nowadays, since it's not intuitive they're part of files. - This makes some of the UI mobile-aware but doesn't set the `device` flag yet, since there are still some missing pieces. - I'll separate storage out and continue modernizing the UI as we unblock and integrate D3547. Test Plan: Created, edited and deleted macros. Viewed files. Reviewers: btrahan, vrana, teisenbe Reviewed By: vrana CC: aran Maniphest Tasks: T175 Differential Revision: https://secure.phabricator.com/D3572
2012-10-01 23:04:03 +02:00
'PhabricatorMacroController' => 'PhabricatorController',
Modernize "macro" typeahead datasource Summary: Ref T4420. Make this modern. Test Plan: - Used typeahead in remarkup comment area to select macro "derpdog". Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9875
2014-07-11 01:18:15 +02:00
'PhabricatorMacroDatasource' => 'PhabricatorTypeaheadDatasource',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorMacroDisableController' => 'PhabricatorMacroController',
Move "Macros" to a first-class application Summary: This is mostly to unblock D3547. - Move "Macros" to a first-class application called "Macros". - After D3547, this application will also house "Memes" (macros with text on them). - This will also make them easier to find; the top navigational query I field is "where are image macros?" nowadays, since it's not intuitive they're part of files. - This makes some of the UI mobile-aware but doesn't set the `device` flag yet, since there are still some missing pieces. - I'll separate storage out and continue modernizing the UI as we unblock and integrate D3547. Test Plan: Created, edited and deleted macros. Viewed files. Reviewers: btrahan, vrana, teisenbe Reviewed By: vrana CC: aran Maniphest Tasks: T175 Differential Revision: https://secure.phabricator.com/D3572
2012-10-01 23:04:03 +02:00
'PhabricatorMacroEditController' => 'PhabricatorMacroController',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorMacroEditor' => 'PhabricatorApplicationTransactionEditor',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'PhabricatorMacroListController' => 'PhabricatorMacroController',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorMacroMacroPHIDType' => 'PhabricatorPHIDType',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorMacroMailReceiver' => 'PhabricatorObjectMailReceiver',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'PhabricatorMacroManageCapability' => 'PhabricatorPolicyCapability',
Made Meme Generator Summary: Fixed T2353 Test Plan: Checked whether same text generated the same URL Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2353 Differential Revision: https://secure.phabricator.com/D4551
2013-01-20 03:43:35 +01:00
'PhabricatorMacroMemeController' => 'PhabricatorMacroController',
Create a basic meme dialog Summary: Simple dialog for creating memes. We can add more features (typeahead, selection thumbs, preview) later. Test Plan: {F29815} Reviewers: DeedyDas, chad Reviewed By: chad CC: aran Maniphest Tasks: T2353 Differential Revision: https://secure.phabricator.com/D4557
2013-01-22 03:46:04 +01:00
'PhabricatorMacroMemeDialogController' => 'PhabricatorMacroController',
Adding some filters and queries to Macro application Summary: Fixes T2778 Introduces `PhabricatorMacroQuery`, which should consolidate all queries regarding macros Adds `PolicyInterface` to `PhabricatorImageMacro`, as else the query would fail (we should consider adding it to the ApplicationTransaction instead, if that was ever planned) Adds `Active Macros` filter, making it the default Adds `My Macros` filter. You may ask why it overwrites `$authors`. Well, I did not want the page jump to the conclusion that it is a search result. It //is// one more or less, but the filter would jump to `seach` instead of `my`. If you want `My Macros` removed, tell me. It is useful only to heavy-macro-uploaders-and-users though. Five or six people in `http://secure.phabricator.(org|com)`, and an estimated dozen and a half at bigger installs. Test Plan: created multiple macros from multiple authors, disabled them at will. browsed around, verified that Macros only appeared in the right filters and that nothing else broke. Reviewers: epriestley, chad, btrahan CC: aran, Korvin Maniphest Tasks: T2778 Differential Revision: https://secure.phabricator.com/D5409
2013-03-22 17:46:21 +01:00
'PhabricatorMacroQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Subclass most ReplyHandlers from TransactionReplyHandler Summary: Ref T7199. Half of these aren't even reachable, but make some progress toward reducing the amount of nonsense and garbage in mail handling. Test Plan: Tested all reachable handlers with `bin/mail receive-test`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12237
2015-04-01 17:39:50 +02:00
'PhabricatorMacroReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Implement generalized application search in Macros Summary: Ref T2625. Works out the last kinks of generalization and gives Macros the more powerful new query engine. Overall, this feels pretty good to me. Test Plan: Executed, saved and edited a bunch of Macro queries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6078
2013-05-30 23:09:37 +02:00
'PhabricatorMacroSearchEngine' => 'PhabricatorApplicationSearchEngine',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorMacroTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorMacroTransactionComment' => 'PhabricatorApplicationTransactionComment',
'PhabricatorMacroTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'PhabricatorMacroViewController' => 'PhabricatorMacroController',
Add basic support for Herald outbound rules Summary: Ref T5791. This is still very basic (no global actions, no support for matching headers/bodies/recipients/etc) but gets the core in. Test Plan: {F715209} {F715211} Reviewers: chad Reviewed By: chad Maniphest Tasks: T5791 Differential Revision: https://secure.phabricator.com/D13897
2015-08-15 19:54:33 +02:00
'PhabricatorMailEmailHeraldField' => 'HeraldField',
'PhabricatorMailEmailHeraldFieldGroup' => 'HeraldFieldGroup',
'PhabricatorMailEmailSubjectHeraldField' => 'PhabricatorMailEmailHeraldField',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorMailImplementationAdapter' => 'Phobject',
Very basic daemon infrastructure, plus MetaMTA daemon. Summary: Amazon SES seems to be working well, except that it takes more than a second to send mail in-process. Kick it out of process. (Between this and the ImplementationAdapter layer, MetaMTA almost makes sense. :/) Test Plan: Ran the daemon and got a flood of unsent test email. Reviewers: CC:
2011-02-10 02:39:55 +01:00
'PhabricatorMailImplementationAmazonSESAdapter' => 'PhabricatorMailImplementationPHPMailerLiteAdapter',
Mailgun receive support Summary: As you've suggested, I took the SendGrid code and massaged it until it played nice with Mailgun. btw - unless I'm missing something, it appears that the SendGrid receiver lets you spoof emails (it performs no validation on the data received). Test Plan: Opened a task with Mailgun. Felt great. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4326 Differential Revision: https://secure.phabricator.com/D7989
2014-01-21 19:36:33 +01:00
'PhabricatorMailImplementationMailgunAdapter' => 'PhabricatorMailImplementationAdapter',
Support SMTP as the mailer. Summary: Support SMTP as the mailer and user could turn on SMTP authentication if needed. Import PHPMailer as PHPMailerLite doesn't support SMTP. Make class PhabricatorMailImplementationPHPMailerAdapter final. Test Plan: N/A Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2139 Differential Revision: https://secure.phabricator.com/D4063
2012-12-09 11:36:40 +01:00
'PhabricatorMailImplementationPHPMailerAdapter' => 'PhabricatorMailImplementationAdapter',
PHPMailerLite
2011-01-26 18:33:31 +01:00
'PhabricatorMailImplementationPHPMailerLiteAdapter' => 'PhabricatorMailImplementationAdapter',
Add support for SendGrid as an outbound mail adapter Summary: SendGrid is a popular mail delivery platform, similar to Amazon SES. Provide support for delivering email via their REST API. Test Plan: Created a SendGrid account, configured my local install to use it, sent some mail, received mail. Reviewers: tuomaspelkonen, jungejason, aran CC: ccheever Differential Revision: 347
2011-05-26 19:00:26 +02:00
'PhabricatorMailImplementationSendGridAdapter' => 'PhabricatorMailImplementationAdapter',
Fix a threading issue with Amazon SES Summary: Amazon SES does not allow us to set a Message-ID header, which means that threads are incorrect in Mail.app (and presumably other applications which respect In-Reply-To and References) because the initial email does not have anything which attaches it to the rest of the thread. To fix this, never rely on Message-ID if the mailer doesn't support Message-ID. (In the Amazon SES case, Amazon generates its own Message-ID which we can't know ahead of time). I additionally used all the Lisk isolation from the other tests to make this testable and wrote tests for it. I also moved the idea of a thread ID lower in the stack and out of DifferentialMail, which should not be responsible for implementation details. NOTE: If you push this, it will cause a one-time break of threading for everyone using Outlook since I've changed the seed for generating Thread-Index. I feel like this is okay to avoid introducing more complexity here. Test Plan: Created and then updated a revision, messages delivered over Amazon SES threaded correctly in Mail.app. Verified headers. Unit tests. Reviewed By: rm Reviewers: aran, tuomaspelkonen, jungejason, rm Commenters: aran CC: aran, rm, epriestley Differential Revision: 195
2011-04-30 20:47:00 +02:00
'PhabricatorMailImplementationTestAdapter' => 'PhabricatorMailImplementationAdapter',
Make all bin/* scripts locate their workflows dynamically Summary: Ref T2015. Not directly related to Drydock, but I bumped into this. All these scripts currently enumerate their workflows explicitly. Instead, use `PhutilSymbolLoader` to automatically discover workflows. This reduces code duplication and errors (see all the bad `extends` this diff fixes) and lets third parties add new workflows (not clearly valuable?). Test Plan: Ran `bin/x help` for each modified script. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7840
2013-12-27 22:15:48 +01:00
'PhabricatorMailManagementListInboundWorkflow' => 'PhabricatorMailManagementWorkflow',
'PhabricatorMailManagementListOutboundWorkflow' => 'PhabricatorMailManagementWorkflow',
'PhabricatorMailManagementReceiveTestWorkflow' => 'PhabricatorMailManagementWorkflow',
'PhabricatorMailManagementResendWorkflow' => 'PhabricatorMailManagementWorkflow',
'PhabricatorMailManagementSendTestWorkflow' => 'PhabricatorMailManagementWorkflow',
'PhabricatorMailManagementShowInboundWorkflow' => 'PhabricatorMailManagementWorkflow',
'PhabricatorMailManagementShowOutboundWorkflow' => 'PhabricatorMailManagementWorkflow',
Add a rough `bin/mail volume` command for showing mail volume Summary: Ref T7013. This might help us understand the problem better. Test Plan: ``` $ ./bin/mail volume +==============+============+ | User | Unfiltered | +==============+============+ | admin | 136 | | dog | 31 | | epriestley | 24 | | ducksey | 18 | | saurus | 8 | | example-list | 7 | | squeakybirdo | 3 | | nnn | 3 | | facebooker | 2 | +==============+============+ Mail sent in the last 30 days. "Unfiltered" is raw volume before preferences were applied. ``` Reviewers: chad Reviewed By: chad Maniphest Tasks: T7013 Differential Revision: https://secure.phabricator.com/D13813
2015-08-06 20:32:17 +02:00
'PhabricatorMailManagementVolumeWorkflow' => 'PhabricatorMailManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorMailManagementWorkflow' => 'PhabricatorManagementWorkflow',
Add basic support for Herald outbound rules Summary: Ref T5791. This is still very basic (no global actions, no support for matching headers/bodies/recipients/etc) but gets the core in. Test Plan: {F715209} {F715211} Reviewers: chad Reviewed By: chad Maniphest Tasks: T5791 Differential Revision: https://secure.phabricator.com/D13897
2015-08-15 19:54:33 +02:00
'PhabricatorMailOutboundMailHeraldAdapter' => 'HeraldAdapter',
'PhabricatorMailOutboundRoutingHeraldAction' => 'HeraldAction',
'PhabricatorMailOutboundRoutingSelfEmailHeraldAction' => 'PhabricatorMailOutboundRoutingHeraldAction',
'PhabricatorMailOutboundRoutingSelfNotificationHeraldAction' => 'PhabricatorMailOutboundRoutingHeraldAction',
Consolidate outbound mail status in a new class Summary: Ref T5791. This collects outbound mail status in one place and makes the list view a little spiffier. Test Plan: Looked at list and detail views. Grepped for changed classes/constants. Reviewers: chad Reviewed By: chad Maniphest Tasks: T5791 Differential Revision: https://secure.phabricator.com/D13884
2015-08-14 13:31:42 +02:00
'PhabricatorMailOutboundStatus' => 'Phobject',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorMailReceiver' => 'Phobject',
Add unit tests to cover PhabricatorMailReceiver::matchAddresses() Summary: Ref T3183. We should accept addresses like `"New Bug" <bugs@example.com>` to match `bugs@example.com`. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3183 Differential Revision: https://secure.phabricator.com/D5923
2013-05-15 00:04:17 +02:00
'PhabricatorMailReceiverTestCase' => 'PhabricatorTestCase',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorMailReplyHandler' => 'Phobject',
Add basic support for Herald outbound rules Summary: Ref T5791. This is still very basic (no global actions, no support for matching headers/bodies/recipients/etc) but gets the core in. Test Plan: {F715209} {F715211} Reviewers: chad Reviewed By: chad Maniphest Tasks: T5791 Differential Revision: https://secure.phabricator.com/D13897
2015-08-15 19:54:33 +02:00
'PhabricatorMailRoutingRule' => 'Phobject',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorMailSetupCheck' => 'PhabricatorSetupCheck',
Build separate mail for each recipient, honoring recipient access levels Summary: Ref T6367. Removes `multiplexMail()`! We can't pass a single body into a function which splits it anymore: we need to split recipients first, then build bodies for each recipient list. This lets us build separate bodies for each recipient's individual translation/access levels. The new logic does this: - First, split recipients into groups called "targets". - Each target corresponds to one actual mail we're going to build. - Each target has a viewer (whose translation / access levels will be used to generate the mail). - Each target has a to/cc list (the users who we'll ultimately send the mail to). - For each target, build a custom mail body based on the viewer's access levels and settings (language prefs not actually implemented). - Then, deliver the mail. Test Plan: - Read new config help. Then did a bunch of testing, primarily with `bin/mail list-outbound` and `bin/mail show-outbound` (to review generated mail), `bin/phd debug taskmaster` (to run daemons freely) and `bin/worker execute --id <id>` (to repeatedly test a specific piece of code after identifying an issue). With `one-mail-per-recipient` on (default): - Sent mail to multiple users. - Verified mail showed up in `mail list-outbound`. - Examined mail with `mail show-outbound`. - Added a project that a subscriber could not see. - Verified it was not present in `X-Phabricator-Projects`. - Verified it was rendered as "Restricted Project" for the non-permissioned viewer. - Added a subscriber, then changed the object policy so they could not see it and sent mail. - Verified I received mail but the other user did not. - Enabled public replies and verified mail generated with public addresses. - Disabld public replies and verified mail generated with private addresses. With `one-mail-per-recipient` off: - Verified that one mail is sent to all recipients. - Verified users who can not see the object are still filtered. - Verified that partially-visible projects are completely visible in the mail (this violates policies, as documented, as the best available compromise). - Enabled public replies and verified the mail generated with "Reply To". Reviewers: btrahan Reviewed By: btrahan Subscribers: carlsverre, epriestley Maniphest Tasks: T6367 Differential Revision: https://secure.phabricator.com/D13131
2015-06-02 23:29:30 +02:00
'PhabricatorMailTarget' => 'Phobject',
Mailgun receive support Summary: As you've suggested, I took the SendGrid code and massaged it until it played nice with Mailgun. btw - unless I'm missing something, it appears that the SendGrid receiver lets you spoof emails (it performs no validation on the data received). Test Plan: Opened a task with Mailgun. Felt great. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4326 Differential Revision: https://secure.phabricator.com/D7989
2014-01-21 19:36:33 +01:00
'PhabricatorMailgunConfigOptions' => 'PhabricatorApplicationConfigOptions',
Begin modularizing main menu items Summary: Ref T10077. Ref T8918. The way the main menu is built is not very modular and fairly hacky. It assumes menus are provided by applications, but this isn't exactly true. Notably, the "Quick Create" menu is not per-application. The current method of building this menu is very inefficient (see T10077). Particularly, we have to build it //twice// because we need to build it once to render the item and then again to render the dropdown options. Start cleaning this up. This diff doesn't actually have any behavioral changes, since I can't swap the menu over until we get rid of all the other items and I haven't extended this to Notifications/Conpherence yet so it doesn't actually fix T8918. Test Plan: Viewed menus while logged in, logged out, in different applications, in desktop/mobile. Nothing appeared different. Reviewers: chad Reviewed By: chad Maniphest Tasks: T8918, T10077 Differential Revision: https://secure.phabricator.com/D14922
2016-01-01 13:26:36 +01:00
'PhabricatorMainMenuBarExtension' => 'Phobject',
Switch to new menubar Summary: - Looks better (can probably still use some tweaks), especially search. - Moves logout from weird footer location to main menu. - Reactive: on tablets and phones, the menu adjusts to remain useful. - Fixed position on desktops for future side nav changes. - Adds an icon header thing that's currently hard-coded but will be application-driven soon. Test Plan: Used menu on desktop, tablet, phone, logged in / logged out, toggled darkconsole. Will add some screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3105
2012-07-31 01:09:14 +02:00
'PhabricatorMainMenuSearchView' => 'AphrontView',
'PhabricatorMainMenuView' => 'AphrontView',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorManagementWorkflow' => 'PhutilArgumentWorkflow',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorManiphestApplication' => 'PhabricatorApplication',
Port Maniphest options. Test Plan: Viewed the new options. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4401
2013-01-11 19:24:35 +01:00
'PhabricatorManiphestConfigOptions' => 'PhabricatorApplicationConfigOptions',
Fixed Task Generation Summary: Ref T2903 Test Plan: Successfully generated tasks with authors and owners. Reviewers: epriestley, AnhNhan Reviewed By: epriestley CC: aran, Korvin, AnhNhan, chad Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5704
2013-04-25 03:17:30 +02:00
'PhabricatorManiphestTaskTestDataGenerator' => 'PhabricatorTestDataGenerator',
Add a generic multistep Markup cache Summary: The immediate issue this addresses is T1366, adding a rendering cache to Phriction. For wiki pages with code blocks especially, rerendering them each time is expensive. The broader issue is that out markup caches aren't very good right now. They have three major problems: **Problem 1: the data is stored in the wrong place.** We currently store remarkup caches on objects. This means we're always loading it and passing it around even when we don't need it, can't genericize cache management code (e.g., have one simple script to drop/GC caches), need to update authoritative rows to clear caches, and can't genericize rendering code since each object is different. To solve this, I created a dedicated cache database that I plan to move all markup caches to use. **Problem 2: time-variant rules break when cached.** Some rules like `**bold**` are time-invariant and always produce the same output, but some rules like `{Tnnn}` and `@username` are variant and may render differently (because a task was closed or a user is on vacation). Currently, we cache the raw output, so these time-variant rules get locked at whatever values they had when they were first rendered. This is the main reason Phriction doesn't have a cache right now -- I wanted `{Tnnn}` rules to reflect open/closed tasks. To solve this, I split markup into a "preprocessing" phase (which does all the parsing and evaluates all time-invariant rules) and a "postprocessing" phase (which evaluates time-variant rules only). The preprocessing phase is most of the expense (and, notably, includes syntax highlighting) so this is nearly as good as caching the final output. I did most of the work here in D737 / D738, but we never moved to use it in Phabricator -- we currently just do the two operations serially in all cases. This diff splits them apart and caches the output of preprocessing only, so we benefit from caching but also get accurate time-variant rendering. **Problem 3: cache access isn't batched/pipelined optimally.** When we're rendering a list of markup blocks, we should be able to batch datafetching better than we do. D738 helped with this (fetching is batched within a single hunk of markup) and this improves batching on cache access. We could still do better here, but this is at least a step forward. Also fixes a bug with generating a link in the Phriction history interface ($uri gets clobbered). I'm using PHP serialization instead of JSON serialization because Remarkup does some stuff with non-ascii characters that might not survive JSON. Test Plan: - Created a Phriction document and verified that previews don't go to cache (no rows appear in the cache table). - Verified that published documents come out of cache. - Verified that caches generate/regenerate correctly, time-variant rules render properly and old documents hit the right caches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1366 Differential Revision: https://secure.phabricator.com/D2945
2012-07-10 00:20:56 +02:00
'PhabricatorMarkupCache' => 'PhabricatorCacheDAO',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorMarkupEngine' => 'Phobject',
'PhabricatorMarkupOneOff' => array(
'Phobject',
'PhabricatorMarkupInterface',
),
Partially generalize Remarkup previews and add support to Differential Summary: Ref T3671. A lot of applications have pretty ad-hoc preview code. Clean it up a bit and add Summary preview to Differential. After ApplicationTransactions we might want to try to serialize the whole form and show a preview of all the transactions, but this seems not very useful in most cases (I'd guess that Remarkup previews are 99% of the value) and tricky to get right (e.g., adding images which don't exist yet to Pholio mocks). I think I can add this in a few other places, too. Test Plan: Edited Maniphest Tasks and Differential Revisions, mashed some buttons. Verified previews rendered correctly. Grepped for removed CSS classes (no hits). {F52907} Reviewers: btrahan, Firehed Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T3671 Differential Revision: https://secure.phabricator.com/D6673
2013-08-05 19:46:39 +02:00
'PhabricatorMarkupPreviewController' => 'PhabricatorController',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhabricatorMemeRemarkupRule' => 'PhutilRemarkupRule',
'PhabricatorMentionRemarkupRule' => 'PhutilRemarkupRule',
Move Git discovery into DiscoveryEngine Summary: Ref T4327. Consolidates and simplifies infrastructure: - Moves Git discovery into DiscoveryEngine. - Collapses a bunch of the Git and Mercurial code related to stream discovery. - Removes all cach code from PullLocal daemon (it's no longer called). - Adds basic unit tests for Git and Mercurial discovery. Various cleanup: - Makes GitStream and MercurialStream extend a common base. - Improves performance of MercurialStream in some cases, by requiring fewer commits be output and parsed. - Makes mirroring exceptions easier to debug. - Fixes discovery of Mercurial repositories with multiple branch heads. - Adds some missing `pht()`. Test Plan: I tested this fairly throughly because I think this phase is complete: - Made new repositories in multiple VCSes and did full imports. - Particularly, I reimported Arcanist to make sure that TODO was resolved. I think it was related to the toposort stuff. - Pushed commits to multiple VCSes. - Pushed commits to a non-close branch, then pushed a merge commit. Observed commits import initially as non-close, then get flagged for close. - Started full daemons and resolved various minor issues that showed up in the daemon log until everything ran cleanly. - Basically spent about 30 minutes banging on this in every way I could think of to try to break it. I found and fixed some minor stuff, but it seems solid. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7987
2014-01-17 00:31:52 +01:00
'PhabricatorMercurialGraphStream' => 'PhabricatorRepositoryGraphStream',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorMetaMTAActor' => 'Phobject',
Show why recipients were excluded from mail Summary: Ref T3306. This interface has a hard time balancing security/policy issues and I'm not sure what the best way forward is. Some possibilities: # We just let you see everything from the web UI. - This makes debugging easier. - Anyone who can see this stuff can trivially take over any user's account with five seconds of work and no technical expertise (reset their password from the web UI, then go read the email and click the link). # We let you see everything, but only for messages you were a recipient of or author of. - This makes it much more difficult to debug issues with mailing lists. - But maybe we could just say mailing list recipients are "public", or define some other ruleset. - Generally this gets privacy and ease of use right. # We could move the whole thing to the CLI. - Makes the UI/UX way worse. # We could strike an awkward balance between concerns, as we do now. - We expose //who// sent and received messages, but not the content of the messages. This doesn't feel great. I'm inclined to probably go with (2) and figure something out for mailing lists? Anyway, irrespective of that this should generally make things more clear, and improves the code a lot if nothing else. Test Plan: {F49546} - Looked at a bunch of mail. - Sent mail from different apps. - Checked that recipients seem correct. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3306 Differential Revision: https://secure.phabricator.com/D6413
2013-07-11 00:17:38 +02:00
'PhabricatorMetaMTAActorQuery' => 'PhabricatorQuery',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorMetaMTAApplication' => 'PhabricatorApplication',
MetaMTA - add (basic) application emails and deploy to Maniphest Summary: Ref T5952, T3404. This lays the basic plumbing for how this will work, all the way to deploying on Maniphest. Aside from what is mentioned on T5952, I think page(s) on editing application emails could use a little more helpful text about what's going on, similar to how the config page that's getting deprecated works. Test Plan: ran migration and noted my create email address migrated successfully. used bin/mail to make a task. added another email and used bin/mail to make a task. deleted an email. edited an email. invoked various error states and they all looked good. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T3404, T5952 Differential Revision: https://secure.phabricator.com/D11418
2015-01-20 01:07:26 +01:00
'PhabricatorMetaMTAApplicationEmail' => array(
'PhabricatorMetaMTADAO',
'PhabricatorPolicyInterface',
Use ApplicationTransactions in ApplicationEmail Summary: Ref T8498. I want to add Spaces to these, and the logic for getting Spaces right is a bit tricky, so swap these to ApplicationTransactions. One new piece of tech: made it easier for Editors to raise DuplicateKeyException as a normal ValidationException, so callers don't have to handle this case specially. One behavioral change: we no longer require these addresses to be at the `auth.email-domains` domains -- I think this wasn't quite right in the general case. It's OK to require users to have `@mycompany.com` addresses but add `@phabricator.mycompany-infrastructure.com` addresses here if you want. Test Plan: - Tried to create a duplicate email. - Tried to create an empty email. - Tried to create an invalid email. - Created a new email. - Deleted an email. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8498 Differential Revision: https://secure.phabricator.com/D13246
2015-06-11 19:15:49 +02:00
'PhabricatorApplicationTransactionInterface',
'PhabricatorDestructibleInterface',
Support Spaces in ApplicationEmail Summary: Ref T8498. Allow ApplicationEmail addresses to be put into spaces: - You can only see and send to addresses in Spaces you have access to. - Objects are created into the same space their address is associated with. Test Plan: - Used `bin/mail receive-test` to send mail to various `xyz-bugs@...` addresses. - Saw objects created in the proper space. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8498 Differential Revision: https://secure.phabricator.com/D13247
2015-06-11 19:23:56 +02:00
'PhabricatorSpacesInterface',
MetaMTA - add (basic) application emails and deploy to Maniphest Summary: Ref T5952, T3404. This lays the basic plumbing for how this will work, all the way to deploying on Maniphest. Aside from what is mentioned on T5952, I think page(s) on editing application emails could use a little more helpful text about what's going on, similar to how the config page that's getting deprecated works. Test Plan: ran migration and noted my create email address migrated successfully. used bin/mail to make a task. added another email and used bin/mail to make a task. deleted an email. edited an email. invoked various error states and they all looked good. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T3404, T5952 Differential Revision: https://secure.phabricator.com/D11418
2015-01-20 01:07:26 +01:00
),
Application Emails - add datasource so we can have a typeahead Summary: Ref T5039. This will be necessary for Herald integration so users can make rules like "if app email is one of x, y, or z add projects foo, bar, and metallica." I think its best to do an actual typeahead here -- users select full email addresses -- rather than support prefix, suffix, etc stuff on the email address. I think the latter approach would yield lots of confusion, as well as prevent us from (more) easily providing diagnostic tools about what happened when and why. Test Plan: hacked a maniphest tokenizer to use this new datasource and it worked Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5039 Differential Revision: https://secure.phabricator.com/D11546
2015-01-28 23:35:42 +01:00
'PhabricatorMetaMTAApplicationEmailDatasource' => 'PhabricatorTypeaheadDatasource',
Use ApplicationTransactions in ApplicationEmail Summary: Ref T8498. I want to add Spaces to these, and the logic for getting Spaces right is a bit tricky, so swap these to ApplicationTransactions. One new piece of tech: made it easier for Editors to raise DuplicateKeyException as a normal ValidationException, so callers don't have to handle this case specially. One behavioral change: we no longer require these addresses to be at the `auth.email-domains` domains -- I think this wasn't quite right in the general case. It's OK to require users to have `@mycompany.com` addresses but add `@phabricator.mycompany-infrastructure.com` addresses here if you want. Test Plan: - Tried to create a duplicate email. - Tried to create an empty email. - Tried to create an invalid email. - Created a new email. - Deleted an email. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8498 Differential Revision: https://secure.phabricator.com/D13246
2015-06-11 19:15:49 +02:00
'PhabricatorMetaMTAApplicationEmailEditor' => 'PhabricatorApplicationTransactionEditor',
Modularize Application Email Herald field Summary: Ref T8726. There's no interface we can check for this, so the adapter needs to opt in. Also fix a spelling mistake. Test Plan: Created rules with "Application Email" fields. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13499
2015-07-06 22:16:26 +02:00
'PhabricatorMetaMTAApplicationEmailHeraldField' => 'HeraldField',
MetaMTA - add (basic) application emails and deploy to Maniphest Summary: Ref T5952, T3404. This lays the basic plumbing for how this will work, all the way to deploying on Maniphest. Aside from what is mentioned on T5952, I think page(s) on editing application emails could use a little more helpful text about what's going on, similar to how the config page that's getting deprecated works. Test Plan: ran migration and noted my create email address migrated successfully. used bin/mail to make a task. added another email and used bin/mail to make a task. deleted an email. edited an email. invoked various error states and they all looked good. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T3404, T5952 Differential Revision: https://secure.phabricator.com/D11418
2015-01-20 01:07:26 +01:00
'PhabricatorMetaMTAApplicationEmailPHIDType' => 'PhabricatorPHIDType',
Modularize application configuration panels Summary: Ref T7149. This is a few steps away, but: - Generally, I'd like to reduce the amount of "Config" configuration we have. - One good way to do this is to move it into UIs in Application configuration. We did this with email recently. - I think this was a great change and I'd like to keep moving in this direction. - T7149 touches configuration related to file storage engines. Although I'm not planning to fully move configuration into applications yet, it would be easier to debug and test if I could drop a read-only panel there to show engines. - So, modularize the config stuff so I can add a new panel without hard-coding it. Test Plan: - Added, edited, and deleted application emails. - Viewed non-email application detail pages. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12051
2015-03-12 21:28:37 +01:00
'PhabricatorMetaMTAApplicationEmailPanel' => 'PhabricatorApplicationConfigurationPanel',
MetaMTA - add (basic) application emails and deploy to Maniphest Summary: Ref T5952, T3404. This lays the basic plumbing for how this will work, all the way to deploying on Maniphest. Aside from what is mentioned on T5952, I think page(s) on editing application emails could use a little more helpful text about what's going on, similar to how the config page that's getting deprecated works. Test Plan: ran migration and noted my create email address migrated successfully. used bin/mail to make a task. added another email and used bin/mail to make a task. deleted an email. edited an email. invoked various error states and they all looked good. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T3404, T5952 Differential Revision: https://secure.phabricator.com/D11418
2015-01-20 01:07:26 +01:00
'PhabricatorMetaMTAApplicationEmailQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Use ApplicationTransactions in ApplicationEmail Summary: Ref T8498. I want to add Spaces to these, and the logic for getting Spaces right is a bit tricky, so swap these to ApplicationTransactions. One new piece of tech: made it easier for Editors to raise DuplicateKeyException as a normal ValidationException, so callers don't have to handle this case specially. One behavioral change: we no longer require these addresses to be at the `auth.email-domains` domains -- I think this wasn't quite right in the general case. It's OK to require users to have `@mycompany.com` addresses but add `@phabricator.mycompany-infrastructure.com` addresses here if you want. Test Plan: - Tried to create a duplicate email. - Tried to create an empty email. - Tried to create an invalid email. - Created a new email. - Deleted an email. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8498 Differential Revision: https://secure.phabricator.com/D13246
2015-06-11 19:15:49 +02:00
'PhabricatorMetaMTAApplicationEmailTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorMetaMTAApplicationEmailTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorMetaMTAAttachment' => 'Phobject',
Implement all remaining config options Summary: Resolves T2255. Test Plan: Looked at mail options. Saw no remaining "Setup Issues". Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4477
2013-01-17 00:06:39 +01:00
'PhabricatorMetaMTAConfigOptions' => 'PhabricatorApplicationConfigOptions',
MetaMTA
2011-01-26 02:40:21 +01:00
'PhabricatorMetaMTAController' => 'PhabricatorController',
'PhabricatorMetaMTADAO' => 'PhabricatorLiskDAO',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorMetaMTAEmailBodyParser' => 'Phobject',
Fix reply email parsing for linebreaks in "On <date>, <user> wrote:" quote identifier Summary: Move the parser to a separate class so it can be easily unit tested, add some tests. Properly parse emails with linebreaks in the quote line. Test Plan: Ran unit tests, used mail receiver to reply to an object. Reviewed By: cadamo Reviewers: aran, jungejason, tuomaspelkonen, cadamo CC: aran, cadamo, epriestley Differential Revision: 392
2011-06-01 17:33:14 +02:00
'PhabricatorMetaMTAEmailBodyParserTestCase' => 'PhabricatorTestCase',
Modularize "Send an Email" Herald actions Summary: Ref T8726. No surprises. Test Plan: Created rules using both action variants, applied upgrade, saw rules still work correctly. {F658842} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13701
2015-07-24 17:19:47 +02:00
'PhabricatorMetaMTAEmailHeraldAction' => 'HeraldAction',
'PhabricatorMetaMTAEmailOthersHeraldAction' => 'PhabricatorMetaMTAEmailHeraldAction',
'PhabricatorMetaMTAEmailSelfHeraldAction' => 'PhabricatorMetaMTAEmailHeraldAction',
When we fail to process mail, tell the user about it Summary: Ref T4371. Ref T4699. Fixes T3994. Currently, we're very conservative about sending errors back to users. A concern I had about this was that mistakes could lead to email loops, massive amounts of email spam, etc. Because of this, I was pretty hesitant about replying to email with more email when I wrote this stuff. However, this was a long time ago. We now have Message-ID deduplication, "X-Phabricator-Sent-This-Mail", generally better mail infrastructure, and rate limiting. Together, these mechanisms should reasonably prevent anything crazy (primarily, infinite email loops) from happening. Thus: - When we hit any processing error after receiving a mail, try to send the author a reply with details about what went wrong. These are limited to 6 per hour per address. - Rewrite most of the errors to be more detailed and informative. - Rewrite most of the errors in a user-facing voice ("You sent this mail..." instead of "This mail was sent.."). - Remove the redundant, less sophisticated code which does something similar in Differential. Test Plan: - Using `scripts/mail/mail_receiver.php`, artificially received a pile of mail. - Hit a bunch of different errors. - Saw reasonable error mail get sent to me. - Saw other reasonable error mail get rate limited. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3994, T4371, T4699 Differential Revision: https://secure.phabricator.com/D8692
2014-04-04 03:43:18 +02:00
'PhabricatorMetaMTAErrorMailAction' => 'PhabricatorSystemAction',
MetaMTA - lay some ground work for having an application Summary: Ref T5791. This does a few bits there. Namely: - Adds PHID column to PhabricatorMetaMTAMail - Implements a PhabricatorMetaMTAMailPHIDType - Script to backpopulate them. - Makes PhabricatorMetaMTAMail implement PolicyInterface. - View policy is NOONE and the author and recipients have automatic view capabilities - No edit capability. - Adds a PhabricatorMetaMTAMailQuery for PhabricatorMetaMTAMail. Test Plan: ran `./bin/storage upgrade` successfully. commented on a maniphest task and verifed the metamta mail object in the database was created successfully with a shiny new phid Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5791 Differential Revision: https://secure.phabricator.com/D13394
2015-06-22 22:46:26 +02:00
'PhabricatorMetaMTAMail' => array(
'PhabricatorMetaMTADAO',
'PhabricatorPolicyInterface',
),
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorMetaMTAMailBody' => 'Phobject',
Centralize rendering of application mail bodies Summary: This is a minor quality-of-life improvement to prevent D2968 from being as nasty as it is. Test Plan: Ran unit tests; generated Differential, Maniphest and Diffusion emails and verified the bodies looked sensible. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran Maniphest Tasks: T931 Differential Revision: https://secure.phabricator.com/D2986
2012-07-17 04:01:43 +02:00
'PhabricatorMetaMTAMailBodyTestCase' => 'PhabricatorTestCase',
MetaMTA - more progress towards a mail application Summary: Ref T5791. This diff does a few things... - Adds code to write recipients to edges on save - Makes Query performance for policy filtering okay-ish - Adds a Search Engine for PhabricatorMetaMTAMail - Adds "working" List Controller - Inbox and Outbox both work - Adds stub View Controller Test Plan: ran `./bin/storage upgrade` and saw my inbox and outbox start getting data. played with application and saw new entries in inbox and outbox Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5791 Differential Revision: https://secure.phabricator.com/D13397
2015-06-23 20:37:14 +02:00
'PhabricatorMetaMTAMailHasRecipientEdgeType' => 'PhabricatorEdgeType',
'PhabricatorMetaMTAMailListController' => 'PhabricatorMetaMTAController',
MetaMTA - lay some ground work for having an application Summary: Ref T5791. This does a few bits there. Namely: - Adds PHID column to PhabricatorMetaMTAMail - Implements a PhabricatorMetaMTAMailPHIDType - Script to backpopulate them. - Makes PhabricatorMetaMTAMail implement PolicyInterface. - View policy is NOONE and the author and recipients have automatic view capabilities - No edit capability. - Adds a PhabricatorMetaMTAMailQuery for PhabricatorMetaMTAMail. Test Plan: ran `./bin/storage upgrade` successfully. commented on a maniphest task and verifed the metamta mail object in the database was created successfully with a shiny new phid Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5791 Differential Revision: https://secure.phabricator.com/D13394
2015-06-22 22:46:26 +02:00
'PhabricatorMetaMTAMailPHIDType' => 'PhabricatorPHIDType',
'PhabricatorMetaMTAMailQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
MetaMTA - more progress towards a mail application Summary: Ref T5791. This diff does a few things... - Adds code to write recipients to edges on save - Makes Query performance for policy filtering okay-ish - Adds a Search Engine for PhabricatorMetaMTAMail - Adds "working" List Controller - Inbox and Outbox both work - Adds stub View Controller Test Plan: ran `./bin/storage upgrade` and saw my inbox and outbox start getting data. played with application and saw new entries in inbox and outbox Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5791 Differential Revision: https://secure.phabricator.com/D13397
2015-06-23 20:37:14 +02:00
'PhabricatorMetaMTAMailSearchEngine' => 'PhabricatorApplicationSearchEngine',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorMetaMTAMailSection' => 'Phobject',
Fix a threading issue with Amazon SES Summary: Amazon SES does not allow us to set a Message-ID header, which means that threads are incorrect in Mail.app (and presumably other applications which respect In-Reply-To and References) because the initial email does not have anything which attaches it to the rest of the thread. To fix this, never rely on Message-ID if the mailer doesn't support Message-ID. (In the Amazon SES case, Amazon generates its own Message-ID which we can't know ahead of time). I additionally used all the Lisk isolation from the other tests to make this testable and wrote tests for it. I also moved the idea of a thread ID lower in the stack and out of DifferentialMail, which should not be responsible for implementation details. NOTE: If you push this, it will cause a one-time break of threading for everyone using Outlook since I've changed the seed for generating Thread-Index. I feel like this is okay to avoid introducing more complexity here. Test Plan: Created and then updated a revision, messages delivered over Amazon SES threaded correctly in Mail.app. Verified headers. Unit tests. Reviewed By: rm Reviewers: aran, tuomaspelkonen, jungejason, rm Commenters: aran CC: aran, rm, epriestley Differential Revision: 195
2011-04-30 20:47:00 +02:00
'PhabricatorMetaMTAMailTestCase' => 'PhabricatorTestCase',
MetaMTA - more progress towards a mail application Summary: Ref T5791. This diff does a few things... - Adds code to write recipients to edges on save - Makes Query performance for policy filtering okay-ish - Adds a Search Engine for PhabricatorMetaMTAMail - Adds "working" List Controller - Inbox and Outbox both work - Adds stub View Controller Test Plan: ran `./bin/storage upgrade` and saw my inbox and outbox start getting data. played with application and saw new entries in inbox and outbox Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5791 Differential Revision: https://secure.phabricator.com/D13397
2015-06-23 20:37:14 +02:00
'PhabricatorMetaMTAMailViewController' => 'PhabricatorMetaMTAController',
Modernize "mailable" typeahead datasources Summary: Ref T4420. Modernize the mailing list datasource, then build a composite "mailable" datasource. Test Plan: - Edited "subscribers" field in Differential revision edit. - Edited "subscribers" field in Differential search. - Edited "add subscribers" field in differential revision view. - Edited "add ccs" field in Diffusion commit view. - Edited "add emails to CC" in a Herald rule. - Edited "add ccs" in maniphest bulk editor. - Edited "add ccs" in maniphest task detail view. - Edited "CC" on maniphest edit view. - Edited "subscribers" on maniphest task earch view. - Edited "CC" on pholio mock edit. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9886
2014-07-18 00:44:29 +02:00
'PhabricatorMetaMTAMailableDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Add a "mailable" function datasource Summary: Ref T4100. Add a function datasource for filtering mailable objects (e.g., subscribers). Test Plan: Searched for objects with "Current Viewer", "Members: Dog Project", etc., as a subscriber in global search. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12524
2015-04-23 12:34:33 +02:00
'PhabricatorMetaMTAMailableFunctionDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Mailgun receive support Summary: As you've suggested, I took the SendGrid code and massaged it until it played nice with Mailgun. btw - unless I'm missing something, it appears that the SendGrid receiver lets you spoof emails (it performs no validation on the data received). Test Plan: Opened a task with Mailgun. Felt great. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4326 Differential Revision: https://secure.phabricator.com/D7989
2014-01-21 19:36:33 +01:00
'PhabricatorMetaMTAMailgunReceiveController' => 'PhabricatorMetaMTAController',
Expand aggregate email recipients prior to multiplexing Summary: Ref T4361. Before we figure out which To/CC are addressable, try to expand To/CC. Specifically, the supported expansion right now is project PHIDs expanding to all their members. Because of the way multiplexing works, we have to do this in two places: explicitly in `multiplexMail()`, and when sending mail that wasn't multiplexed. This is messy; eventually we can get rid of it (after ApplicationTransactions are everywhere). This has some rough edges, but should basically give us what we need to make stuff like projects mailable. Particularly, it deals with most issues in D7436: - I got around the resolution/multiplexing issue by resolving aggregate mailables separately from mailable actors. - We get to keep the Project PHID as a To/CC/Reviewer/Whatever until the last second. - Users won't get two emails for being a CC and also a member of a CC'd project. - We can degrade to the list stuff this way if we want, by having the project aggregate yield a single list PHID. Test Plan: Added a comment to a revision with a project reviewer, got mail to all the project's members. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4361 Differential Revision: https://secure.phabricator.com/D8117
2014-02-01 23:35:55 +01:00
'PhabricatorMetaMTAMemberQuery' => 'PhabricatorQuery',
Allow MetaMTA adapters to indicate that a mail is permanently undeliverable Summary: Currently, adapters can only fail mail temporarily. Allow them to indicate a permanent failure by throwing a special exception. Test Plan: Added and ran unit tests. Reviewers: wez, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6847
2013-08-30 17:21:50 +02:00
'PhabricatorMetaMTAPermanentFailureException' => 'Exception',
Support email replies in Phabricator Summary: Provides support for per-user x per-object unique reply-to email addresses, plus SMTP integration. This does not actually make Phabricator use these in outbound email. Test Plan: Used test console to validate in-Phabricator routing and handling. Piped emails into the "mail_handler.php" script to validate mail parsing. Configured sendmail and sent mail to Phabricator. Technically I haven't conducted all parts of this test on the same machine since I lost the will to configure more SMTP servers after configuring phabricator.com Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, epriestley, jungejason Differential Revision: 226
2011-05-05 08:09:42 +02:00
'PhabricatorMetaMTAReceivedMail' => 'PhabricatorMetaMTADAO',
Begin improving the soundness of received mail Summary: We/I broke a couple of things here recently (see D5911) and are doing some work here in general (see D5912, etc.). Generally, this code is pretty oldschool and not especially well architected for modern application-oriented Phabricator. It hardcodes a lot of stuff which should be applications' responsibilites. Take the first steps toward making it more solid to reduce the risk here. In particular: - Factor out the "self mail" and "duplicate mail" checks and add unit tests. - Make Message-ID hash handling automatic. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5915
2013-05-14 01:32:19 +02:00
'PhabricatorMetaMTAReceivedMailProcessingException' => 'Exception',
'PhabricatorMetaMTAReceivedMailTestCase' => 'PhabricatorTestCase',
Generate expected schemata for MetaMTA, Nuance, MetaData, OAuthServer Summary: Ref T1191. Handful of minor things here (T6150, T6149, T6148, T6147, T6146) but nothing very noteworthy. Test Plan: Viewed web UI, saw fewer errors. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10527
2014-09-24 22:50:00 +02:00
'PhabricatorMetaMTASchemaSpec' => 'PhabricatorConfigSchemaSpec',
Enable SendGrid Parse API as an inbound email handler Summary: Sendmail is seriously difficult to configure; SendGrid is extremely easy. It's also pretty expensive ($80/mo) but there are a bunch of startups that already have plans so it's effectively free for them. Test Plan: Configured SendGrid and sent reply email through it. Reviewed By: aran Reviewers: tuomaspelkonen, jungejason, aran CC: aran, epriestley Differential Revision: 376
2011-05-30 20:07:05 +02:00
'PhabricatorMetaMTASendGridReceiveController' => 'PhabricatorMetaMTAController',
Move functionality of PhabricatorMetaMTADaemon to a worker task Summary: This will allow sending mail to be done by task workers. See T750. Task ID: # Blame Rev: Test Plan: - started taskmaster daemon in test env - used "send new test message" feature in MetMTA (with send now unchecked) - confirmed receipt of 1 email - repeated 2 & 3 with send now checked Revert Plan: Tags: Reviewers: epriestley, jungejason Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T388, T750 Differential Revision: https://secure.phabricator.com/D1723
2012-02-28 02:11:25 +01:00
'PhabricatorMetaMTAWorker' => 'PhabricatorWorker',
Implement clock/trigger infrastructure for scheduling actions Summary: Ref T6881. Hopefully, this is the hard part. This adds a new daemon (the "trigger" daemon) which processes triggers, schedules them, and then executes them at the scheduled time. The design is a little complicated, but has these goals: - High resistance to race conditions: only the application writes to the trigger table; only the daemon writes to the event table. We won't lose events if someone saves a meeting at the same time as we're sending a reminder out for it. - Execution guarantees: scheduled events are guaranteed to execute exactly once. - Support for arbitrarily large queues: the daemon will make progress even if there are millions of triggers in queue. The cost to update the queue is proportional to the number of changes in it; the cost to process the queue is proportional to the number of events to execute. - Relatively good observability: you can monitor the state of the trigger queue reasonably well from the web UI. - Modular Infrastructure: this is a very low-level construct that Calendar, Phortune, etc., should be able to build on top of. It doesn't have this stuff yet: - Not very robust to bad actions: a misbehaving trigger can stop the queue fairly easily. This is OK for now since we aren't planning to make it part of any other applications for a while. We do still get execute-exaclty-once, but it might not happen for a long time (until someone goes and fixes the queue), when we could theoretically continue executing other events. - Doesn't start automatically: normal users don't need to run this thing yet so I'm not starting it by default. - Not super well tested: I've vetted the basics but haven't run real workloads through this yet. - No sophisticated tooling: I added some basic stuff but it's missing some pieces we'll have to build sooner or later, e.g. `bin/trigger cancel` or whatever. - Intentionally not realtime: This design puts execution guarantees far above realtime concerns, and will not give you precise event execution at 1-second resolution. I think this is the correct goal to pursue architecturally, and certainly correct for subscriptions and meeting reminders. Events which execute after they have become irrelevant can simply decline to do anything (like a meeting reminder which executes after the meeting is over). In general, the expectation for applications is: - When creating an object (like a calendar event) that needs to trigger a scheduled action, write a trigger (and save the PHID if you plan to update it later). - The daemon will process the event and schedule the action efficiently, in a race-free way. - If you want to move the action, update the trigger and the daemon will take care of it. - Your action will eventually dump a task into the task queue, and the task daemons will actually perform it. Test Plan: Using a test script like this: ``` <?php require_once 'scripts/__init_script__.php'; $trigger = id(new PhabricatorWorkerTrigger()) ->setAction( new PhabricatorLogTriggerAction( array( 'message' => 'test', ))) ->setClock( new PhabricatorMetronomicTriggerClock( array( 'period' => 33, ))) ->save(); var_dump($trigger); ``` ...I queued triggers and ran the daemon: - Verified triggers fire; - verified triggers reschedule; - verified trigger events show up in the web UI; - tried different periods; - added some triggers while the daemon was running; - examined `phd debug` output for anything suspicious. It seems to work in trivial use case, at least. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11419
2015-01-16 21:13:31 +01:00
'PhabricatorMetronomicTriggerClock' => 'PhabricatorTriggerClock',
Add a motivational profile menu panel Summary: Motivate your employees with inspirational quotes. A new quote every day! Test Plan: So inspirational. Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15026
2016-01-15 00:29:21 +01:00
'PhabricatorMotivatorProfilePanel' => 'PhabricatorProfilePanel',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorMultiColumnUIExample' => 'PhabricatorUIExample',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorMultiFactorSettingsPanel' => 'PhabricatorSettingsPanel',
Skeleton for "Multimeter", a performance sampling application Summary: Ref T6930. This application collects and displays performance samples -- roughly, things Phabricator spent some kind of resource on. It will collect samples on different types of resources and events: - Wall time (queries, service calls, pages) - Bytes In / Bytes Out (requests) - Implicit requests to CSS/JS (static resources) I've started with the simplest case (static resources), since this can be used in an immediate, straghtforward way to improve packaging (look at which individual files have the most requests recently). There's no aggregation yet and a lot of the data isn't collected properly. Future diffs will add more dimension data (controllers, users), more event and resource types (queries, service calls, wall time), and more display options (aggregation, sorting). Test Plan: {F389344} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6930 Differential Revision: https://secure.phabricator.com/D12623
2015-05-01 22:19:43 +02:00
'PhabricatorMultimeterApplication' => 'PhabricatorApplication',
Allow installs to require email verification Summary: Allow installs to require users to verify email addresses before they can use Phabricator. If a user logs in without a verified email address, they're given instructions to verify their address. This isn't too useful on its own since we don't actually have arbitrary email registration, but the next step is to allow installs to restrict email to only some domains (e.g., @mycompany.com). Test Plan: - Verification - Set verification requirement to `true`. - Tried to use Phabricator with an unverified account, was told to verify. - Tried to use Conduit, was given a verification error. - Verified account, used Phabricator. - Unverified account, reset password, verified implicit verification, used Phabricator. - People Admin Interface - Viewed as admin. Clicked "Administrate User". - Viewed as non-admin - Sanity Checks - Used Conduit normally from web/CLI with a verified account. - Logged in/out. - Sent password reset email. - Created a new user. - Logged in with an unverified user but with the configuration set to off. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran, csilvers Maniphest Tasks: T1184 Differential Revision: https://secure.phabricator.com/D2520
2012-05-21 21:47:38 +02:00
'PhabricatorMustVerifyEmailController' => 'PhabricatorAuthController',
Port MySQL settings to PHP Summary: - Ports MySQL settings to PHP. - Removes "mysql.retries" -- this existed only because Magic Numbers Are Bad, but there is no concievable reason it should ever be set to anything other than 3. - Introduced "Hidden" config, which isn't visible from the web (for SaaS, we'll just mark anything with secret keys as "hidden"). - Introduced "Masked" config, which will be masked in darkconsole once that gets updated. - "Hidden" implies "Masked" and "Locked". - Moved "storage.default-namespace" here -- it probably makes more sense than core; this was my bad in T2255. - Put cancel button back for hidden/locked config. - Introduce 'class' config type. Test Plan: Viewed MySQL options. None are editable. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4326
2013-01-03 15:01:14 +01:00
'PhabricatorMySQLConfigOptions' => 'PhabricatorApplicationConfigOptions',
Allow Phabricator storage engines to be extended and configured Summary: See T344. Currently, there's a hard-coded 12MB filesize limit and some awkward interactions with MySQL's max_allowed_packet. Make this system generally more robust: - Move the upload limit to configuration. - Add setup steps which reconcile max_allowed_packet vs MySQL file storage limits. - Add a layer of indirection between uploading files and storage engines. - Allow the definition of new storage engines. - Define a local disk storage engine. - Add a "storage engine selector" class which manages choosing which storage engines to put files in. - Document storage engines. - Document file storage classes. Test Plan: Setup mode: - Disabled MySQL storage engine, misconfigured it, configured it correctly. - Disabled file storage engine, set it to something invalid, set it to something valid. - Verified max_allowed_packet is read correctly. Application mode: - Configured local file storage. - Uploaded large and small files. - Verified larger files were written to local storage. - Verified smaller files were written to MySQL blob storage. Documentation: - Read documentation. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, epriestley, jungejason Differential Revision: 695
2011-07-20 07:48:38 +02:00
'PhabricatorMySQLFileStorageEngine' => 'PhabricatorFileStorageEngine',
Rename "SearchEngine" to "FulltextStorageEngine" Summary: Ref T9979. I picked this name long before the advent of modern "Engine" architecture and it ended up being pretty confusing. Rename "SearchEngine" (currently: mysql or elasticsearch, used to store and query fulltext indexes) to "FulltextStorageEngine" to make it more clear what it does and disambituate it from ApplicationSearch, which also has a bunch of stuff called "SearchEngine", "SearchEngineExtension", etc. Test Plan: Grepped for `phabricatorsearchengine`. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14843
2015-12-21 19:25:28 +01:00
'PhabricatorMySQLFulltextStorageEngine' => 'PhabricatorFulltextStorageEngine',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorMySQLSetupCheck' => 'PhabricatorSetupCheck',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorNamedQuery' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorSearchDAO',
'PhabricatorPolicyInterface',
Introduce PhabricatorNamedQueryQuery Summary: Adds a first-class Query object for querying NamedQueries. xzibit would be proud. Test Plan: Updated query edit interface to use this query, verified it works correctly. Reviewers: btrahan, blc Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6051
2013-05-27 22:40:43 +02:00
),
'PhabricatorNamedQueryQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add a remarkup element for a navigation sequence Summary: Fixes T4769. This is silly and just scratches an itch, but do a better job with navigation sequences. Test Plan: {F195082} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T4769 Differential Revision: https://secure.phabricator.com/D10353
2014-08-26 21:14:28 +02:00
'PhabricatorNavigationRemarkupRule' => 'PhutilRemarkupRule',
Implement clock/trigger infrastructure for scheduling actions Summary: Ref T6881. Hopefully, this is the hard part. This adds a new daemon (the "trigger" daemon) which processes triggers, schedules them, and then executes them at the scheduled time. The design is a little complicated, but has these goals: - High resistance to race conditions: only the application writes to the trigger table; only the daemon writes to the event table. We won't lose events if someone saves a meeting at the same time as we're sending a reminder out for it. - Execution guarantees: scheduled events are guaranteed to execute exactly once. - Support for arbitrarily large queues: the daemon will make progress even if there are millions of triggers in queue. The cost to update the queue is proportional to the number of changes in it; the cost to process the queue is proportional to the number of events to execute. - Relatively good observability: you can monitor the state of the trigger queue reasonably well from the web UI. - Modular Infrastructure: this is a very low-level construct that Calendar, Phortune, etc., should be able to build on top of. It doesn't have this stuff yet: - Not very robust to bad actions: a misbehaving trigger can stop the queue fairly easily. This is OK for now since we aren't planning to make it part of any other applications for a while. We do still get execute-exaclty-once, but it might not happen for a long time (until someone goes and fixes the queue), when we could theoretically continue executing other events. - Doesn't start automatically: normal users don't need to run this thing yet so I'm not starting it by default. - Not super well tested: I've vetted the basics but haven't run real workloads through this yet. - No sophisticated tooling: I added some basic stuff but it's missing some pieces we'll have to build sooner or later, e.g. `bin/trigger cancel` or whatever. - Intentionally not realtime: This design puts execution guarantees far above realtime concerns, and will not give you precise event execution at 1-second resolution. I think this is the correct goal to pursue architecturally, and certainly correct for subscriptions and meeting reminders. Events which execute after they have become irrelevant can simply decline to do anything (like a meeting reminder which executes after the meeting is over). In general, the expectation for applications is: - When creating an object (like a calendar event) that needs to trigger a scheduled action, write a trigger (and save the PHID if you plan to update it later). - The daemon will process the event and schedule the action efficiently, in a race-free way. - If you want to move the action, update the trigger and the daemon will take care of it. - Your action will eventually dump a task into the task queue, and the task daemons will actually perform it. Test Plan: Using a test script like this: ``` <?php require_once 'scripts/__init_script__.php'; $trigger = id(new PhabricatorWorkerTrigger()) ->setAction( new PhabricatorLogTriggerAction( array( 'message' => 'test', ))) ->setClock( new PhabricatorMetronomicTriggerClock( array( 'period' => 33, ))) ->save(); var_dump($trigger); ``` ...I queued triggers and ran the daemon: - Verified triggers fire; - verified triggers reschedule; - verified trigger events show up in the web UI; - tried different periods; - added some triggers while the daemon was running; - examined `phd debug` output for anything suspicious. It seems to work in trivial use case, at least. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11419
2015-01-16 21:13:31 +01:00
'PhabricatorNeverTriggerClock' => 'PhabricatorTriggerClock',
Implement basic ngram search for Owners Package names Summary: Ref T9979. This uses ngrams (specifically, trigrams) to build a reasonably efficient index for substring matching. Specifically, for a package like "Example", with ID 123, we store rows like this: ``` < ex, 123> <exa, 123> <xam, 123> <amp, 123> <mpl, 123> <ple, 123> <le , 123> ``` When the user searches for `exam`, we join this table for packages with tokens `exa` and `xam`. MySQL can do this a lot more efficiently than it can process a `LIKE "%exam%"` query against a huge table. When the user searches for a one-letter or two-letter string, we only search the beginnings of words. This is probably what they want, the only thing we can do quickly, and a reasonable/expected behavior for typeaheads. Test Plan: - Ran storage upgrades and search indexer. - Searched for stuff with "name contains". - Used typehaead and got sensible results. - Searched for `aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz` and saw only 16 joins. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14846
2015-12-21 21:22:07 +01:00
'PhabricatorNgramsIndexEngineExtension' => 'PhabricatorIndexEngineExtension',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorNotificationBuilder' => 'Phobject',
Add a "Mark All Read" button for notifications Summary: Adds a button to mark everything as read. Test Plan: Clicked button. Reviewers: btrahan, jungejason, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T974 Differential Revision: https://secure.phabricator.com/D2812
2012-06-20 22:51:19 +02:00
'PhabricatorNotificationClearController' => 'PhabricatorNotificationController',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorNotificationClient' => 'Phobject',
Move notification configuration into PHP Summary: Bring notification settings to PHP. Test Plan: Viewed notification settings in /config/. Reviewers: codeblock, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4337
2013-01-03 18:29:19 +01:00
'PhabricatorNotificationConfigOptions' => 'PhabricatorApplicationConfigOptions',
Adds base notification application Summary: First diff in a series of diffs to add notifications to Phabricator. This is the notification application ONLY. This commit does not include the changes to other applications that makes them add notifications. As such, no notifications will be generated beyond the initial database import. Test Plan: This is part of the notifications architecture which has been running on http://theoryphabricator.com for the past several months. Reviewers: epriestley, btrahan, ddfisher Reviewed By: epriestley CC: allenjohnashton, keebuhm, aran, Korvin, jungejason, nh Maniphest Tasks: T974 Differential Revision: https://secure.phabricator.com/D2571
2012-06-08 15:31:30 +02:00
'PhabricatorNotificationController' => 'PhabricatorController',
Fully modularize DestructionEngine Summary: Ref T9979. Convert all DestructionEngine behaviors to extensions. Test Plan: {F1033244} Destroyed an object, verifying: - Herald transcripts were destroyed; - edges were destroyed; - flags were destroyed; - tokens were destroyed; - transactions were destroyed; - worker tasks were cancelled. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14832
2015-12-20 17:11:59 +01:00
'PhabricatorNotificationDestructionEngineExtension' => 'PhabricatorDestructionEngineExtension',
Make Notifications Realtime Summary: Adds the node.js Aphlict server, the flash Aphlict client, and some supporting javascript. Built on top of - and requires - D2703 (which is still in progress). Will likely work with no modification on top of the final version, though. The node server is currently run with sudo node support/aphlict/server/aphlict_server.js Test Plan: tested locally Reviewers: epriestley Reviewed By: epriestley CC: allenjohnashton, keebuhm, aran, Korvin Differential Revision: https://secure.phabricator.com/D2704
2012-06-12 02:49:32 +02:00
'PhabricatorNotificationIndividualController' => 'PhabricatorNotificationController',
Add a list of all notifications Summary: Add a "View All Notifications" link and page. Test Plan: Viewed all notifications Reviewers: jungejason, vrana Reviewed By: jungejason CC: aran Maniphest Tasks: T974 Differential Revision: https://secure.phabricator.com/D2780
2012-06-18 23:07:38 +02:00
'PhabricatorNotificationListController' => 'PhabricatorNotificationController',
Adds the UI dropdown panel Summary: Add a dropdown to display notificaitons. Right now there is nothing real time about it, but we do update the panel when the user clicks. This panel is only displayed if the install has notifications enabled and you have them enabled in your preferences (not using them by default). Test Plan: Turn off notifications for user1, left them on for user2. Did things from user1 and from user2 on task both were cc'd on. user2 recieved all notifications, user1 recieved nothing. Made new user, made sure everything was switched off by default. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: keebuhm, ddfisher, aran, Korvin Differential Revision: https://secure.phabricator.com/D2703
2012-06-11 18:37:06 +02:00
'PhabricatorNotificationPanelController' => 'PhabricatorNotificationController',
Simplify lightboxing and fix a few things Summary: Minor tweaks to lightboxes. - With "position: fixed;", we don't need to do any of the scroll/resize stuff. Just remove it. - Make the lightbox go over the menu bar -- was it intentional that it wasn't? - Make 'jx-mask' use "position: fixed;" too. - Add a loading indicator. - In Differential/Maniphest/etc, a preview may bring in an image but won't bring in the CSS we need. The "real" fix is to ship CSS/JS with ajax, but that's really hard -- fake it by pulling in the right CSS any time we render a remarkup area. I'm going to do a couple of other tweaks here but need to update JX.Mask. Test Plan: Verified behavior is reasonable in Safari, Firefox, Chrome with multiple images / scroll / previews / resize. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1896 Differential Revision: https://secure.phabricator.com/D3795
2012-10-24 02:34:43 +02:00
'PhabricatorNotificationQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Move notifications to ApplicationSearch Summary: Ref T5891. This just modernizes infrastructure. Test Plan: Viewed "All" and "Unread" notifications. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T5891 Differential Revision: https://secure.phabricator.com/D10281
2014-08-16 20:14:32 +02:00
'PhabricatorNotificationSearchEngine' => 'PhabricatorApplicationSearchEngine',
Complete modernization of Aphlict configuration Summary: Fixes T10697. This finishes bringing the rest of the config up to cluster power levels. Phabricator is now given an arbitrarily long list of notification servers. Each Aphlict server is given an arbitrarily long list of ports to run services on. Users are free to make them meet in the middle by proxying whatever they want to whatever else they want. This should also accommodate clustering fairly easily in the future. Also rewrote the status UI and changed a million other things. :boar: Test Plan: {F1217864} {F1217865} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10697 Differential Revision: https://secure.phabricator.com/D15703
2016-04-13 21:07:48 +02:00
'PhabricatorNotificationServerRef' => 'Phobject',
'PhabricatorNotificationServersConfigOptionType' => 'PhabricatorConfigJSONOptionType',
Show Aphlict connection status in notification menu Summary: Fixes T5373. Ref T5281. Several changes: - The `marshallExceptions` thing is useful if JS throws an exception when invoked from Flash, so set it. The resulting exceptions are a little odd (not escaped correctly, e.g.) but way better than nothing. - Put connection status in the notification menu. - When the connection fails, try to provide contextual help where we can. Test Plan: {F169493} Reviewers: chad, joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5281, T5373 Differential Revision: https://secure.phabricator.com/D9700
2014-06-24 01:26:16 +02:00
'PhabricatorNotificationStatusView' => 'AphrontTagView',
Add a "Send Test Notification" button to make testing the server easier Summary: Ref T4324. Currently, it's a bit of a pain to send yourself notifications, and often involves multiple browsers. Instead, add a button to send them. Test Plan: {F114495} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4324 Differential Revision: https://secure.phabricator.com/D8255
2014-02-18 01:00:33 +01:00
'PhabricatorNotificationTestController' => 'PhabricatorNotificationController',
Desktop Notification support Summary: Fixes T4139. Adds a "Desktop Notifications" panel to settings. For now, we start with "Send Desktop Notifications Too" functionality. We can try to be fancy later and only send desktop notifications if the web app doesn't have focus, etc. Test Plan: Made some comments as a test user on a task and got purdy desktop notifications using Chrome. Then did it again with Firefox. Played around with permissions form with Chrome and got helpful information about what was up. Played around with Firefox and got similar results, except canceling the dialogue didn't invoke my handler code somehow. Oh Firefox! Reviewers: epriestley Reviewed By: epriestley Subscribers: rbalik, tycho.tatitscheff, joshuaspence, epriestley, Korvin Maniphest Tasks: T4139 Differential Revision: https://secure.phabricator.com/D13219
2015-06-22 22:11:37 +02:00
'PhabricatorNotificationTestFeedStory' => 'PhabricatorFeedStory',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorNotificationUIExample' => 'PhabricatorUIExample',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorNotificationsApplication' => 'PhabricatorApplication',
'PhabricatorNuanceApplication' => 'PhabricatorApplication',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorOAuth1AuthProvider' => 'PhabricatorOAuthAuthProvider',
Convert OAuth1 handshake tokens to new modular temporary tokens Summary: Ref T10603. Swap these over and give them nice UI strings. Test Plan: - Refreshed a Twitter OAuth link. - Unlinked and re-linked a Twitter account. - Viewed the new type in {nav Config > Temporary Tokens}. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10603 Differential Revision: https://secure.phabricator.com/D15480
2016-03-16 14:36:04 +01:00
'PhabricatorOAuth1SecretTemporaryTokenType' => 'PhabricatorAuthTemporaryTokenType',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorOAuth2AuthProvider' => 'PhabricatorOAuthAuthProvider',
'PhabricatorOAuthAuthProvider' => 'PhabricatorAuthProvider',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorOAuthClientAuthorization' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorOAuthServerDAO',
'PhabricatorPolicyInterface',
Modernize OAuthServer PHIDs and Queries Summary: - Modernize PHID types. - Implement `PhabricatorPolicyInterface`. - Make queries policy aware. Test Plan: Browsed client and authorization lists. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Differential Revision: https://secure.phabricator.com/D8560
2014-03-18 21:27:55 +01:00
),
'PhabricatorOAuthClientAuthorizationQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Don't explicitly name abstract base classes Summary: Ref T5655. It is superfluous to include "base" in the name of an abstract base class. Furthermore, it is not done consistently within the code base. Test Plan: Ran `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9989
2014-07-21 16:05:17 +02:00
'PhabricatorOAuthClientController' => 'PhabricatorOAuthServerController',
Allow OAuth applications to be disabled instead of destroyed Summary: Ref T7303. This interaction is very oldschool; modernize it to enable/disable instead of "nuke from orbit". Test Plan: - Enabled applications. - Disabled applications. - Viewed applications in list view. - Generated new tokens. - Tried to use a token from a disabled application (got rebuffed). - Tried to use a token from an enabled application (worked fine). Reviewers: chad Reviewed By: chad Maniphest Tasks: T7303 Differential Revision: https://secure.phabricator.com/D15620
2016-04-05 18:40:22 +02:00
'PhabricatorOAuthClientDisableController' => 'PhabricatorOAuthClientController',
Don't explicitly name abstract base classes Summary: Ref T5655. It is superfluous to include "base" in the name of an abstract base class. Furthermore, it is not done consistently within the code base. Test Plan: Ran `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9989
2014-07-21 16:05:17 +02:00
'PhabricatorOAuthClientEditController' => 'PhabricatorOAuthClientController',
'PhabricatorOAuthClientListController' => 'PhabricatorOAuthClientController',
OAuthServer - hide client secret behind a "View Secret" action Summary: ...also adds policies on who can view and who can edit an action. Fixes T6949. Test Plan: viewed a secret through the new UI and it worked Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6949 Differential Revision: https://secure.phabricator.com/D11401
2015-01-15 02:27:45 +01:00
'PhabricatorOAuthClientSecretController' => 'PhabricatorOAuthClientController',
Modernize some OAuth Server code Summary: Ref T7303. This inches toward properly-behaved cluster logout. - Use IDs instead of PHIDs in URIs. - Slightly more modern code. - Fix some crumb stuff. Test Plan: Created, edited, viewed, deleted, showed secret for, authorized, test-auth'd an application. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7303 Differential Revision: https://secure.phabricator.com/D15592
2016-04-03 16:25:33 +02:00
'PhabricatorOAuthClientTestController' => 'PhabricatorOAuthClientController',
Don't explicitly name abstract base classes Summary: Ref T5655. It is superfluous to include "base" in the name of an abstract base class. Furthermore, it is not done consistently within the code base. Test Plan: Ran `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9989
2014-07-21 16:05:17 +02:00
'PhabricatorOAuthClientViewController' => 'PhabricatorOAuthClientController',
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server Summary: adds a Phabricator OAuth server, which has three big commands: - auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri - token - given a valid authorization code, this command returns an authorization token - whoami - Conduit.whoami, all nice and purdy relative to the oauth server. Also has a "test" handler, which I used to create some test data. T850 will delete this as it adds the ability to create this data in the Phabricator product. This diff also adds the corresponding client in Phabricator for the Phabricator OAuth Server. (Note that clients are known as "providers" in the Phabricator codebase but client makes more sense relative to the server nomenclature) Also, related to make this work well - clean up the diagnostics page by variabilizing the provider-specific information and extending the provider classes as appropriate. - augment Conduit.whoami for more full-featured OAuth support, at least where the Phabricator client is concerned What's missing here... See T844, T848, T849, T850, and T852. Test Plan: - created a dummy client via the test handler. setup development.conf to have have proper variables for this dummy client. went through authorization and de-authorization flows - viewed the diagnostics page for all known oauth providers and saw provider-specific debugging information Reviewers: epriestley CC: aran, epriestley Maniphest Tasks: T44, T797 Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
'PhabricatorOAuthResponse' => 'AphrontResponse',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorOAuthServer' => 'Phobject',
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server Summary: adds a Phabricator OAuth server, which has three big commands: - auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri - token - given a valid authorization code, this command returns an authorization token - whoami - Conduit.whoami, all nice and purdy relative to the oauth server. Also has a "test" handler, which I used to create some test data. T850 will delete this as it adds the ability to create this data in the Phabricator product. This diff also adds the corresponding client in Phabricator for the Phabricator OAuth Server. (Note that clients are known as "providers" in the Phabricator codebase but client makes more sense relative to the server nomenclature) Also, related to make this work well - clean up the diagnostics page by variabilizing the provider-specific information and extending the provider classes as appropriate. - augment Conduit.whoami for more full-featured OAuth support, at least where the Phabricator client is concerned What's missing here... See T844, T848, T849, T850, and T852. Test Plan: - created a dummy client via the test handler. setup development.conf to have have proper variables for this dummy client. went through authorization and de-authorization flows - viewed the diagnostics page for all known oauth providers and saw provider-specific debugging information Reviewers: epriestley CC: aran, epriestley Maniphest Tasks: T44, T797 Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
'PhabricatorOAuthServerAccessToken' => 'PhabricatorOAuthServerDAO',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorOAuthServerApplication' => 'PhabricatorApplication',
Modernize OAuthserver and provide more context on "no permission" exception Summary: Ref T7173. Depends on D14049. Now that Phacility can install custom exception handlers, this puts enough information on the exception so that we can figure out what to do with it. - Generally modernize some of this code. - Add some more information to PolicyExceptions so the new RequestExceptionHandler can handle them properly. Test Plan: Failed authorizations, then succeeded authorizations. See next diff. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7173 Differential Revision: https://secure.phabricator.com/D14050
2015-09-03 19:05:23 +02:00
'PhabricatorOAuthServerAuthController' => 'PhabricatorOAuthServerController',
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server Summary: adds a Phabricator OAuth server, which has three big commands: - auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri - token - given a valid authorization code, this command returns an authorization token - whoami - Conduit.whoami, all nice and purdy relative to the oauth server. Also has a "test" handler, which I used to create some test data. T850 will delete this as it adds the ability to create this data in the Phabricator product. This diff also adds the corresponding client in Phabricator for the Phabricator OAuth Server. (Note that clients are known as "providers" in the Phabricator codebase but client makes more sense relative to the server nomenclature) Also, related to make this work well - clean up the diagnostics page by variabilizing the provider-specific information and extending the provider classes as appropriate. - augment Conduit.whoami for more full-featured OAuth support, at least where the Phabricator client is concerned What's missing here... See T844, T848, T849, T850, and T852. Test Plan: - created a dummy client via the test handler. setup development.conf to have have proper variables for this dummy client. went through authorization and de-authorization flows - viewed the diagnostics page for all known oauth providers and saw provider-specific debugging information Reviewers: epriestley CC: aran, epriestley Maniphest Tasks: T44, T797 Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
'PhabricatorOAuthServerAuthorizationCode' => 'PhabricatorOAuthServerDAO',
Make OAuth client authorizations a Settings panel Summary: This modernizes and simplifies OAuth client authorizations a bit, moving them to a settings panel similar to the "Sessions" panel. Test Plan: - Viewed authorizations. - Revoked an authorization. - Created a test authorization. {F131196} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8561
2014-03-18 21:28:19 +01:00
'PhabricatorOAuthServerAuthorizationsSettingsPanel' => 'PhabricatorSettingsPanel',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorOAuthServerClient' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorOAuthServerDAO',
'PhabricatorPolicyInterface',
Convert OAuthServer to Transactions + EditEngine Summary: Ref T7303. This application is currently stone-age tech (no transactions, hard "delete" action). Bring it up to modern specs. Test Plan: - Created and edited an OAuth application. - Viewed transaction record. - Tried to create something with no name, invalid redirect URI, etc. Was gently rebuffed with detailed explanatory errors. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7303 Differential Revision: https://secure.phabricator.com/D15609
2016-04-04 18:27:42 +02:00
'PhabricatorApplicationTransactionInterface',
remarkup.css: Consistently zero top/bottom margins for first/last block-level children Summary: For block-level elements that have a margin-top or margin-bottom set (generally to 12px), also reset the appropriate margin to 0 when they're a first-child or last-child of their parents. The change doesn't affect nested lists, their selector is more specific. Test Plan: Look at some comments or wiki documents that end with different block elements, verify that the margins are pretty. Reviewers: epriestley, #blessed_reviewers, chad Reviewed By: #blessed_reviewers, chad Subscribers: Korvin, epriestley Projects: #remarkup Maniphest Tasks: T6968 Differential Revision: https://secure.phabricator.com/D11382
2015-01-14 21:14:22 +01:00
'PhabricatorDestructibleInterface',
Modernize OAuthServer PHIDs and Queries Summary: - Modernize PHID types. - Implement `PhabricatorPolicyInterface`. - Make queries policy aware. Test Plan: Browsed client and authorization lists. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Differential Revision: https://secure.phabricator.com/D8560
2014-03-18 21:27:55 +01:00
),
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorOAuthServerClientAuthorizationPHIDType' => 'PhabricatorPHIDType',
'PhabricatorOAuthServerClientPHIDType' => 'PhabricatorPHIDType',
Modernize OAuthServer PHIDs and Queries Summary: - Modernize PHID types. - Implement `PhabricatorPolicyInterface`. - Make queries policy aware. Test Plan: Browsed client and authorization lists. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Differential Revision: https://secure.phabricator.com/D8560
2014-03-18 21:27:55 +01:00
'PhabricatorOAuthServerClientQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Use ApplicationSearch in OAuthServer Summary: Update the infrastructure and UI of the client list. Test Plan: {F131570} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8563
2014-03-18 21:31:04 +01:00
'PhabricatorOAuthServerClientSearchEngine' => 'PhabricatorApplicationSearchEngine',
OAuth Server -- add controllers to RUD client authorizations and CRUD clients Summary: beyond the title, this diff tweaks the test console to have a bit more functionality. also makes a small change to CSS for AphrontFormControlMarkup, which IMO fixes a display issue on https://secure.phabricator.com/settings/page/profile/ where the Profile URI is all up in the air and whatnot I think this is missing pagination. I am getting tired of the size though and will add later. See T905. Test Plan: viewed, updated and deleted client authorizations. viewed, created, updated and deleted clients Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T849, T850, T848 Differential Revision: https://secure.phabricator.com/D1683
2012-02-22 19:21:39 +01:00
'PhabricatorOAuthServerController' => 'PhabricatorController',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'PhabricatorOAuthServerCreateClientsCapability' => 'PhabricatorPolicyCapability',
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server Summary: adds a Phabricator OAuth server, which has three big commands: - auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri - token - given a valid authorization code, this command returns an authorization token - whoami - Conduit.whoami, all nice and purdy relative to the oauth server. Also has a "test" handler, which I used to create some test data. T850 will delete this as it adds the ability to create this data in the Phabricator product. This diff also adds the corresponding client in Phabricator for the Phabricator OAuth Server. (Note that clients are known as "providers" in the Phabricator codebase but client makes more sense relative to the server nomenclature) Also, related to make this work well - clean up the diagnostics page by variabilizing the provider-specific information and extending the provider classes as appropriate. - augment Conduit.whoami for more full-featured OAuth support, at least where the Phabricator client is concerned What's missing here... See T844, T848, T849, T850, and T852. Test Plan: - created a dummy client via the test handler. setup development.conf to have have proper variables for this dummy client. went through authorization and de-authorization flows - viewed the diagnostics page for all known oauth providers and saw provider-specific debugging information Reviewers: epriestley CC: aran, epriestley Maniphest Tasks: T44, T797 Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
'PhabricatorOAuthServerDAO' => 'PhabricatorLiskDAO',
Convert OAuthServer to Transactions + EditEngine Summary: Ref T7303. This application is currently stone-age tech (no transactions, hard "delete" action). Bring it up to modern specs. Test Plan: - Created and edited an OAuth application. - Viewed transaction record. - Tried to create something with no name, invalid redirect URI, etc. Was gently rebuffed with detailed explanatory errors. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7303 Differential Revision: https://secure.phabricator.com/D15609
2016-04-04 18:27:42 +02:00
'PhabricatorOAuthServerEditEngine' => 'PhabricatorEditEngine',
'PhabricatorOAuthServerEditor' => 'PhabricatorApplicationTransactionEditor',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorOAuthServerScope' => 'Phobject',
OAuthServer polish and random sauce Summary: This diff makes the OAuthServer more compliant with the spec by - making it return well-formatted error codes with error types from the spec. - making it respect the "state" variable, which is a transparent variable the client passes and the server passes back - making it be super, duper compliant with respect to redirect uris -- if specified in authorization step, check if its valid relative to the client registered URI and if so save it -- if specified in authorization step, check if its been specified in the access step and error if it doesn't match or doesn't exist -- note we don't make any use of it in the access step which seems strange but hey, that's what the spec says! This diff makes the OAuthServer suck less by - making the "cancel" button do something in the user authorization flow - making the client list view and client edit view be a bit more usable around client secrets - fixing a few bugs I managed to introduce along the way Test Plan: - create a test phabricator client, updated my conf, and then linked and unlinked phabricator to itself - wrote some tests for PhabricatorOAuthServer -- they pass! -- these validate the various validate URI checks - tried a few important authorization calls -- http://phabricator.dev/oauthserver/auth/?client_id=X&state=test&redirect_uri=http://www.evil.com --- verified error'd from mismatching redirect uri's --- verified state parameter in response --- verified did not redirect to client redirect uri -- http://phabricator.dev/oauthserver/auth/?client_id=X w/ existing authorization --- got redirected to proper client url with error that response_type not specified -- http://phabricator.dev/oauthserver/auth/?client_id=X&response_type=code w/ existing authorization --- got redirected to proper client url with pertinent code! - tried a few important access calls -- verified appropriate errors if missing any required parameters -- verified good access code with appropriate other variables resulted in an access token - verified that if redirect_uri set correctly in authorization required for access and errors if differs at all / only succeeds if exactly the same Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley, ajtrichards Maniphest Tasks: T889, T906, T897 Differential Revision: https://secure.phabricator.com/D1727
2012-03-01 23:46:18 +01:00
'PhabricatorOAuthServerTestCase' => 'PhabricatorTestCase',
Modernize OAuthserver and provide more context on "no permission" exception Summary: Ref T7173. Depends on D14049. Now that Phacility can install custom exception handlers, this puts enough information on the exception so that we can figure out what to do with it. - Generally modernize some of this code. - Add some more information to PolicyExceptions so the new RequestExceptionHandler can handle them properly. Test Plan: Failed authorizations, then succeeded authorizations. See next diff. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7173 Differential Revision: https://secure.phabricator.com/D14050
2015-09-03 19:05:23 +02:00
'PhabricatorOAuthServerTokenController' => 'PhabricatorOAuthServerController',
Convert OAuthServer to Transactions + EditEngine Summary: Ref T7303. This application is currently stone-age tech (no transactions, hard "delete" action). Bring it up to modern specs. Test Plan: - Created and edited an OAuth application. - Viewed transaction record. - Tried to create something with no name, invalid redirect URI, etc. Was gently rebuffed with detailed explanatory errors. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7303 Differential Revision: https://secure.phabricator.com/D15609
2016-04-04 18:27:42 +02:00
'PhabricatorOAuthServerTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorOAuthServerTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorObjectHandle' => array(
'Phobject',
'PhabricatorPolicyInterface',
),
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorObjectHasAsanaSubtaskEdgeType' => 'PhabricatorEdgeType',
'PhabricatorObjectHasAsanaTaskEdgeType' => 'PhabricatorEdgeType',
'PhabricatorObjectHasContributorEdgeType' => 'PhabricatorEdgeType',
'PhabricatorObjectHasFileEdgeType' => 'PhabricatorEdgeType',
'PhabricatorObjectHasJiraIssueEdgeType' => 'PhabricatorEdgeType',
'PhabricatorObjectHasSubscriberEdgeType' => 'PhabricatorEdgeType',
'PhabricatorObjectHasUnsubscriberEdgeType' => 'PhabricatorEdgeType',
'PhabricatorObjectHasWatcherEdgeType' => 'PhabricatorEdgeType',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorObjectListQuery' => 'Phobject',
Extract textual object list parsing from Differential Summary: Ref T2222. Currently, Differential has a fairly hairy piece of logic to parse object lists, like `Reviewers: alincoln, htaft`. Extract, generalize, and cover this. - Some of the logic can be simplified with modern ObjectQuery stuff. - Make `@username` the formal monogram for users. - Make `list@domain.com` the formal monogram for mailing lists. - Add test coverage. Test Plan: - Ran unit tests. - Called `differential.parsecommitmessage` with a bunch of real-world inputs and got sensible results. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8445
2014-03-08 02:44:44 +01:00
'PhabricatorObjectListQueryTestCase' => 'PhabricatorTestCase',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorObjectMailReceiver' => 'PhabricatorMailReceiver',
Move sender validation into MailReceiver classes Summary: Ref T1205. Finally able to delete a big chunk of this nastiness. Make MailReceivers responsible for validating senders. For object creation receivers (bugs, conpherences) this just means that users must not be disabled. For other receivers the senders must be able to see the objects, have the right hashes, etc., according to policy. Test Plan: Added a bunch of test cases (everything except policy). Verified behavior via the Receive test console. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5943
2013-05-17 12:49:29 +02:00
'PhabricatorObjectMailReceiverTestCase' => 'PhabricatorTestCase',
Rename classes for consistency Summary: These classes are named differently from other `PhabricatorEdgeType` subclasses. Rename them for consistency. Test Plan: I would expect the linter to complain if I missed anything. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11112
2015-01-01 05:40:26 +01:00
'PhabricatorObjectMentionedByObjectEdgeType' => 'PhabricatorEdgeType',
'PhabricatorObjectMentionsObjectEdgeType' => 'PhabricatorEdgeType',
Provide basic infrastructure for moving PHIDs, Handles and Object Names to applications Summary: See discussion in T2715. Currently, PHIDs are all hard coded in the PHID application. In the long run, we need to move them out into actual applications. A specific immediate issue is Releeph, which uses a very very old and very broken mechanism to inject PHIDs in a way that only sort of works. Moving forward, every PHID type will be provided by a `PhabricatorPHIDType` subclass, which will manage loading it, etc. This also moves toward cleaning up the "load objects by name" (where "name" means something like `D12`) code, which is an //enormous// mess and spread across at least 4-5 callsites. Test Plan: Used `phid.lookup` and `phid.query` to load Slowvotes. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6502
2013-07-21 15:34:21 +02:00
'PhabricatorObjectQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhabricatorObjectRemarkupRule' => 'PhutilRemarkupRule',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorObjectSelectorDialog' => 'Phobject',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorObjectUsesCredentialsEdgeType' => 'PhabricatorEdgeType',
More Drydock Stuff Summary: - Still really really rough. - Adds a full synchronous mode for debugging. - Adds some logging. - It can now allocate EC2 machines and put webroots on them in a hacky, terrible way. - Adds a base query class. Test Plan: oh hey look a test page? http://ec2-50-18-65-151.us-west-1.compute.amazonaws.com:2011/ Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D2026
2012-03-27 05:54:26 +02:00
'PhabricatorOffsetPagedQuery' => 'PhabricatorQuery',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorOldWorldContentSource' => 'PhabricatorContentSource',
Implement "trigger clocks" for scheduling events Summary: Ref T6881. This will probably make more sense in a couple of diffs, but this is a class that implements scheduling/recurrence rules. Two rules are provided: - Trigger an event at a specific time (e.g., a meeting reminder notification). - Trigger an event on the Nth day of every month (e.g., a subscription bill). At some point, we'll presumably add a rule for T2896 (maybe using the "RRULE" spec) so you can do stuff like "the second to last thursday of every month", etc., but we don't need that for now. (The "Nth day of every month, or move it back if no such day exists" rule doesn't seem to be expressible with the "RRULE" format, so implementing that wouldn't give us a superset of this. I think this rule is correct and desirable for this purpose, though.) Test Plan: Added and executed unit tests. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11403
2015-01-16 00:57:45 +01:00
'PhabricatorOneTimeTriggerClock' => 'PhabricatorTriggerClock',
Restructure cache checks to improve modularity Summary: Ref T5501. This code was headed down a bad road; dump an indirection layer between rendering and data gatehring. In particular, this will make it much easier to lift these issues into setup warnings eventually. Test Plan: Viewed cache status page. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5501 Differential Revision: https://secure.phabricator.com/D12315
2015-04-07 23:38:03 +02:00
'PhabricatorOpcodeCacheSpec' => 'PhabricatorCacheSpec',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorOwnerPathQuery' => 'Phobject',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorOwnersApplication' => 'PhabricatorApplication',
Add PhabricatorOwnersArchiveController Summary: Ability to Archive and Activate Packages from the view page. Ref T9414 Test Plan: New Package, Edit Package, Archive Package, Activate Package Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9414 Differential Revision: https://secure.phabricator.com/D14728
2015-12-09 22:41:31 +01:00
'PhabricatorOwnersArchiveController' => 'PhabricatorOwnersController',
MetaMTA: Owners, Pholio, Macro Summary: Port MetaMTA options for Owners, Pholio and Macro. At some point I'd like to get rid of all these options (provide one "reply domain", and not allow overrides of reply handlers -- use events instead) but that's a battle we can fight later. Test Plan: Looked at options, looked at setup issues, edited something. Reviewers: codeblock, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4469
2013-01-16 19:52:30 +01:00
'PhabricatorOwnersConfigOptions' => 'PhabricatorApplicationConfigOptions',
Add CustomField support to Owners Summary: Fixes T9351. This is straightforward since this application is now relatively modern and doesn't have any bizarre craziness. Test Plan: {F787981} {F787982} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9351 Differential Revision: https://secure.phabricator.com/D14093
2015-09-10 22:32:31 +02:00
'PhabricatorOwnersConfiguredCustomField' => array(
'PhabricatorOwnersCustomField',
'PhabricatorStandardCustomFieldInterface',
),
owners
2011-04-03 23:48:36 +02:00
'PhabricatorOwnersController' => 'PhabricatorController',
Add CustomField support to Owners Summary: Fixes T9351. This is straightforward since this application is now relatively modern and doesn't have any bizarre craziness. Test Plan: {F787981} {F787982} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9351 Differential Revision: https://secure.phabricator.com/D14093
2015-09-10 22:32:31 +02:00
'PhabricatorOwnersCustomField' => 'PhabricatorCustomField',
'PhabricatorOwnersCustomFieldNumericIndex' => 'PhabricatorCustomFieldNumericIndexStorage',
'PhabricatorOwnersCustomFieldStorage' => 'PhabricatorCustomFieldStorage',
'PhabricatorOwnersCustomFieldStringIndex' => 'PhabricatorCustomFieldStringIndexStorage',
owners
2011-04-03 23:48:36 +02:00
'PhabricatorOwnersDAO' => 'PhabricatorLiskDAO',
Give Owners real view and edit policies Summary: Fixes T10360. In modern code, most of the meat is automatic. Test Plan: - Edited view policy and edit policy from web UI. - Viewed package, saw policy badge in header. - Tried to edit a package as a user without permission, got appropriate disabled states and errors. - Changed policies via Conduit. - Tried to view a package as a user without permission. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10360 Differential Revision: https://secure.phabricator.com/D15275
2016-02-15 20:37:13 +01:00
'PhabricatorOwnersDefaultEditCapability' => 'PhabricatorPolicyCapability',
'PhabricatorOwnersDefaultViewCapability' => 'PhabricatorPolicyCapability',
owners
2011-04-03 23:48:36 +02:00
'PhabricatorOwnersDetailController' => 'PhabricatorOwnersController',
Some owners write workflows.
2011-04-04 07:03:27 +02:00
'PhabricatorOwnersEditController' => 'PhabricatorOwnersController',
owners
2011-04-03 23:48:36 +02:00
'PhabricatorOwnersListController' => 'PhabricatorOwnersController',
'PhabricatorOwnersOwner' => 'PhabricatorOwnersDAO',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorOwnersPackage' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorOwnersDAO',
'PhabricatorPolicyInterface',
Use ApplicationTransactions for all non-path edits to Owners packages Summary: Ref T8320. Test Plan: {F437431} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8320 Differential Revision: https://secure.phabricator.com/D13028
2015-05-27 19:30:08 +02:00
'PhabricatorApplicationTransactionInterface',
Add CustomField support to Owners Summary: Fixes T9351. This is straightforward since this application is now relatively modern and doesn't have any bizarre craziness. Test Plan: {F787981} {F787982} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9351 Differential Revision: https://secure.phabricator.com/D14093
2015-09-10 22:32:31 +02:00
'PhabricatorCustomFieldInterface',
Implement DestructibleInterface for Owners Packages Summary: Fixes T9945. This is straightforward. The two sub-object types are very lightweight so I just deleted them directly instead of loading + delete()'ing (or implementing DestructibleInterface on them, which would require they have PHIDs). Also improve a US English localization. Test Plan: - Used `bin/remove destroy PHID-... --trace` to destroy a package. - Verified it was gone. - Inspected the SQL in the log for general reasonableness. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9945 Differential Revision: https://secure.phabricator.com/D14729
2015-12-10 14:14:54 +01:00
'PhabricatorDestructibleInterface',
Add "owners.search" Conduit API endpoint, with CustomField support Summary: Ref T9964. Adds a new-style "owners.search" endpoint, and an extension for customfields. Puts enough indirection in place to give us nice, consistent "custom.key" user-facing keys instead of "std:custom:owners:na0shf9a8dfdsafl" junk. Test Plan: - Searched Owners via API. - Searched by ID. - Ordered by custom fields. - Reviewed API docs. - Used normal search with ordering. - Viewed custom field values in search results. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14758
2015-12-13 01:25:51 +01:00
'PhabricatorConduitResultInterface',
Implement basic ngram search for Owners Package names Summary: Ref T9979. This uses ngrams (specifically, trigrams) to build a reasonably efficient index for substring matching. Specifically, for a package like "Example", with ID 123, we store rows like this: ``` < ex, 123> <exa, 123> <xam, 123> <amp, 123> <mpl, 123> <ple, 123> <le , 123> ``` When the user searches for `exam`, we join this table for packages with tokens `exa` and `xam`. MySQL can do this a lot more efficiently than it can process a `LIKE "%exam%"` query against a huge table. When the user searches for a one-letter or two-letter string, we only search the beginnings of words. This is probably what they want, the only thing we can do quickly, and a reasonable/expected behavior for typeaheads. Test Plan: - Ran storage upgrades and search indexer. - Searched for stuff with "name contains". - Used typehaead and got sensible results. - Searched for `aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz` and saw only 16 joins. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14846
2015-12-21 21:22:07 +01:00
'PhabricatorFulltextInterface',
'PhabricatorNgramsInterface',
Add PhabricatorOwnersPackageQuery Summary: This is a step toward unearthing Project queries enough that I can make them policy-aware. Right now, some ProjectQuery callsites do not have reasonable access to the viewer. In particular, Owners packages need to issue Project queries because we allow projects to own packages and resolve project members inside of some package queries. Currently, we have a very unmodern approach to querying packages, with a large number of one-off static load methods: PhabricatorOwnersPackage::loadAffectedPackages() PhabricatorOwnersPackage::loadOwningPackages() PhabricatorOwnersPackage::loadPackagesForPaths() PhabricatorOwnersOwner::loadAllForPackages() PhabricatorOwnersOwner::loadAffiliatedUserPHIDs() PhabricatorOwnersOwner::loadAffiliatedPackages() ConduitAPI_owners_query_Method::queryAll() ConduitAPI_owners_query_Method::queryByOwner() ConduitAPI_owners_query_Method::queryByAffiliatedUser() ConduitAPI_owners_query_Method::queryByPath() We should replace `PhabricatorOwnersOwner` with an Edge and move all of these calls to a Query class. I'm going to try to do as little of this work as I can for now since I'm much more interested in getting a functional policy implementation into other applications, but ProjectQuery needs to be policy-aware before I can do that and I need to dig some at least some of the callsites out enough that I can get a viewer in there without making the code worse than it is. This adds a PhabricatorOwnersPackageQuery class and removes one callsite of one of those static methods. I also intend to dissolve the two separate concepts of an "owner" (direct owner) and an "affiliated user" (indirect owner via project membership) since I think we're always fine with "affiliated users" owners. Test Plan: Loaded home page / audit tool, which use the modified path. Ran queries manually via script. Made sure results included directly owned packages and packages owned through project membership. Reviewers: vrana, btrahan, meitros Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3193
2012-08-08 21:25:11 +02:00
),
Modernize "owners" datasource Summary: Ref T4420. Update owners. Test Plan: - Used typeahead from Herald. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9880
2014-07-11 01:21:21 +02:00
'PhabricatorOwnersPackageDatasource' => 'PhabricatorTypeaheadDatasource',
Move Owners to EditEngine Summary: Ref T9132. Paste is in fairly good shape so Owners is up next. Reasoning: - One install wants API access for it. - It's a simple application for getting CustomFields working with EditEngine. This only does the EditEngine part, so CustomFields are no longer editable until I make that work. That will be up next, and I'll hold this until that's ready. Test Plan: - Created and edited packages via web UI. - Created and edited package editing forms via web UI. - Created and edited packages via Conduit. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14598
2015-11-29 18:33:36 +01:00
'PhabricatorOwnersPackageEditEngine' => 'PhabricatorEditEngine',
Implement basic ngram search for Owners Package names Summary: Ref T9979. This uses ngrams (specifically, trigrams) to build a reasonably efficient index for substring matching. Specifically, for a package like "Example", with ID 123, we store rows like this: ``` < ex, 123> <exa, 123> <xam, 123> <amp, 123> <mpl, 123> <ple, 123> <le , 123> ``` When the user searches for `exam`, we join this table for packages with tokens `exa` and `xam`. MySQL can do this a lot more efficiently than it can process a `LIKE "%exam%"` query against a huge table. When the user searches for a one-letter or two-letter string, we only search the beginnings of words. This is probably what they want, the only thing we can do quickly, and a reasonable/expected behavior for typeaheads. Test Plan: - Ran storage upgrades and search indexer. - Searched for stuff with "name contains". - Used typehaead and got sensible results. - Searched for `aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz` and saw only 16 joins. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14846
2015-12-21 21:22:07 +01:00
'PhabricatorOwnersPackageFulltextEngine' => 'PhabricatorFulltextEngine',
Modernize Audit search engine Summary: Fixes T9279. Modernizes the SearchEngine and Query classes. User-facing changes: - Added order by commit date, default to order by commit date with newest commits first. - Added explicit "Needs Audit by". - Added new `packages(...)` typeahead function. - Picked up automatic subscribers, projects, and order fields. This changes behavior a little bit: we previously attempted to exclude, e.g., commits which a package you own needs to audit, but which you have resigned from. This is difficult in general and I think it needs a more comprehensive solution. This shouldn't impact users much, anyway. Test Plan: {F767628} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9279 Differential Revision: https://secure.phabricator.com/D14013
2015-08-31 19:17:54 +02:00
'PhabricatorOwnersPackageFunctionDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Implement basic ngram search for Owners Package names Summary: Ref T9979. This uses ngrams (specifically, trigrams) to build a reasonably efficient index for substring matching. Specifically, for a package like "Example", with ID 123, we store rows like this: ``` < ex, 123> <exa, 123> <xam, 123> <amp, 123> <mpl, 123> <ple, 123> <le , 123> ``` When the user searches for `exam`, we join this table for packages with tokens `exa` and `xam`. MySQL can do this a lot more efficiently than it can process a `LIKE "%exam%"` query against a huge table. When the user searches for a one-letter or two-letter string, we only search the beginnings of words. This is probably what they want, the only thing we can do quickly, and a reasonable/expected behavior for typeaheads. Test Plan: - Ran storage upgrades and search indexer. - Searched for stuff with "name contains". - Used typehaead and got sensible results. - Searched for `aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz` and saw only 16 joins. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14846
2015-12-21 21:22:07 +01:00
'PhabricatorOwnersPackageNameNgrams' => 'PhabricatorSearchNgrams',
Modernize Audit search engine Summary: Fixes T9279. Modernizes the SearchEngine and Query classes. User-facing changes: - Added order by commit date, default to order by commit date with newest commits first. - Added explicit "Needs Audit by". - Added new `packages(...)` typeahead function. - Picked up automatic subscribers, projects, and order fields. This changes behavior a little bit: we previously attempted to exclude, e.g., commits which a package you own needs to audit, but which you have resigned from. This is difficult in general and I think it needs a more comprehensive solution. This shouldn't impact users much, anyway. Test Plan: {F767628} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9279 Differential Revision: https://secure.phabricator.com/D14013
2015-08-31 19:17:54 +02:00
'PhabricatorOwnersPackageOwnerDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorOwnersPackagePHIDType' => 'PhabricatorPHIDType',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorOwnersPackageQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Use ApplicationSearch in Owners Summary: Ref T8320. Modernize search and major interfaces. This slightly regresses some list view and search features; I'll probably restore some later (once the Query has proper `needX(...)` methods) and drop the rest. Test Plan: Browsed, edited, deleted, and created packages. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8320 Differential Revision: https://secure.phabricator.com/D13024
2015-05-27 19:29:01 +02:00
'PhabricatorOwnersPackageSearchEngine' => 'PhabricatorApplicationSearchEngine',
Allow excluding paths from package Summary: Resolves T2149. Test Plan: $ bin/storage upgrade # /owners/ - saw + # /owners/package/1/ - saw + # /owners/edit/1/ - added exclude paths, saw correct e-mail # /rPabc123 - included paths are still highlighted and excluded not # /owners/view/search/?path=/included/ - found # /owners/view/search/?path=/excluded/ - not found # owners.query - path: /included/ # owners.query - path: /excluded/ # new unit test PhabricatorOwnersPackage::loadAffectedPackages( $repository, array('/excluded/b.php')); PhabricatorOwnersPackage::loadAffectedPackages( $repository, array('/included/a.php')); Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2149 Differential Revision: https://secure.phabricator.com/D4102
2012-12-07 02:23:56 +01:00
'PhabricatorOwnersPackageTestCase' => 'PhabricatorTestCase',
Use ApplicationTransactions for all non-path edits to Owners packages Summary: Ref T8320. Test Plan: {F437431} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8320 Differential Revision: https://secure.phabricator.com/D13028
2015-05-27 19:30:08 +02:00
'PhabricatorOwnersPackageTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorOwnersPackageTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
'PhabricatorOwnersPackageTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
owners
2011-04-03 23:48:36 +02:00
'PhabricatorOwnersPath' => 'PhabricatorOwnersDAO',
Separate editing of package data and paths in Owners Summary: Ref T8320. There's currently one enormous form; split it into a general information form (name, description, owners) and a paths form. I think this is a little more manageable from both a UX point of view and from an "I have to convert this to use ApplicationTransactions" point of view. Test Plan: - Edited paths. - Edited non-path information. - Created new packages. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8320 Differential Revision: https://secure.phabricator.com/D13026
2015-05-27 19:29:50 +02:00
'PhabricatorOwnersPathsController' => 'PhabricatorOwnersController',
Give "owners.search" a "paths" attachment and a default "owners" value Summary: Ref T9964. - Add a "paths" attachment for fetching paths. - Always load owners. We will need this to do policy checks in the future, anyway, and this data is not large, is very useful, and is reasonable to load unconditionally. Test Plan: - Queried packages via API. - Edited packages (paths, owners). - Created a package. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14775
2015-12-14 15:11:03 +01:00
'PhabricatorOwnersPathsSearchEngineAttachment' => 'PhabricatorSearchEngineAttachment',
Fix file PHID extraction in Owners and Differential Summary: Ref T9787. To fix this, I want to change how file PHIDs are extracted slightly: specifically, I'm going to extract them later in the editing process. Before doing this, clean up a couple of bad implementations: - Owners extracts its description as a file PHID. This is an error. - Extract the description as a remarkup block instead. - Add an edge table so stuff like file attachment works properly. - Differential has a no-op extract method. This is presumably just a copy/paste issue from long ago. Test Plan: - Edited a revision in Differential. - Dropped a file into the description of an Owners package. - Before change: this did not attach the file. - After change: the file now attaches properly and shows up as "Attached" in the file details. Reviewers: chad, joshuaspence Reviewed By: joshuaspence Subscribers: joshuaspence Maniphest Tasks: T9787 Differential Revision: https://secure.phabricator.com/D14493
2015-11-16 18:53:01 +01:00
'PhabricatorOwnersSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Move some PhabricatorSearchField subclasses Summary: Move some `PhabricatorSearchField` subclasses to be adjacent to the application to which they belong. This seems generally better to me than lumping them all together in the `src/applications/search/field/` directory. I was also wondering if it makes sense to rename these subclasses as `PhabricatorXSearchField` rather than `PhabricatorSearchXField` (as per T5655), but wasn't really sure if these objects are meant to be search-fields, or just fields belonging to the #search application. Test Plan: N/A. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13374
2015-07-06 14:52:04 +02:00
'PhabricatorOwnersSearchField' => 'PhabricatorSearchTokenizerField',
PHD Options. Test Plan: Looked at the options render properly. Reviewers: epriestley, btrahan, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4367
2013-01-09 15:05:34 +01:00
'PhabricatorPHDConfigOptions' => 'PhabricatorApplicationConfigOptions',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorPHID' => 'Phobject',
'PhabricatorPHIDConstants' => 'Phobject',
Improve code structure of PHID fields in EditEngine Summary: Ref T9132. I had some hacks in place for dealing with Edge/Subscribers stuff. Clean that up so it's structured a little better. Test Plan: - Edited subscribers and projects. - Verified things still show up in Conduit. - Made concurrent edits (added a project in one window, removed it in another window, got a clean result with a correct merge of the two edits). Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14601
2015-11-29 22:24:47 +01:00
'PhabricatorPHIDListEditField' => 'PhabricatorEditField',
Make "Assign / Claim" stacked action work properly in Maniphest Summary: Ref T9132. This is kind of a mess because the tokenizer rewrite left rendering tokenizers in Javascript a little rough. This causes bugs like icons not showing up on tokens in the "Policy" dialog, which there's a task for somewhere I think. I think I've fixed it enough that the beahavior is now correct (i.e., icons show up properly), but some of the code is a bit iffy. I'll eventually clean this up properly, but it's fairly well contained for now. Test Plan: - Reassigned a task. - Put a task up for grabs. - No reassign on closed tasks. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14669
2015-12-04 18:30:53 +01:00
'PhabricatorPHIDListEditType' => 'PhabricatorEditType',
Provide formal Users/Projects/Mailable fields for EditEngine Summary: Ref T9132. This allows you to prefill EditEngine forms with stuff like `?subscribers=epriestley`, and we'll figure out what you mean. Test Plan: - Did `/?subscribers=...` with various values (good, bad, mis-capitalized). - Did `/?projects=...` with various values (good, bad, mis-capitalized). - Reviewed documentation. - Reviewed {nav Config > HTTP Parameter Types}. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14404
2015-11-04 19:20:38 +01:00
'PhabricatorPHIDResolver' => 'Phobject',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorPHIDType' => 'Phobject',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorPHIDTypeTestCase' => 'PhutilTestCase',
Clean up "ids" and "phids" handling in SearchEngines Summary: Ref T9964. I added several hacks to get these working. Clean them up and pull this into a proper extension. The behavior in the web UI is: - they work in all applications; but - they only show up in the UI if a value is specified. So if you visit `/view/?ids=1,2` you get the field, but normally it's not present. We could refine this later. I'm going to add documentation about how to prefill these forms regardless, which should make this discoverable by reading the documentation. There's one teensey weensey hack: in the API, I push these fields to the top of the table. That one feels OK, since it's purely a convenience/display adjustment. Test Plan: Queried by IDs, reviewed docs. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14769
2015-12-13 19:11:40 +01:00
'PhabricatorPHIDsSearchField' => 'PhabricatorSearchField',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPHPASTApplication' => 'PhabricatorApplication',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorPHPConfigSetupCheck' => 'PhabricatorSetupCheck',
Bring PHPMailer config into the new config UI Summary: Port PHPMailer options. Also: - Don't show values on config lists if they're masked (this is mostly for passwords, to prevent them from being idly/accidentally disclosed). - Don't show "default" icon -- just show an icon if the value has been customized. This makes it easier to pick out custom values. Test Plan: Looked at / edited mailer values. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4441
2013-01-15 21:03:44 +01:00
'PhabricatorPHPMailerConfigOptions' => 'PhabricatorApplicationConfigOptions',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorPagedFormUIExample' => 'PhabricatorUIExample',
'PhabricatorPagerUIExample' => 'PhabricatorUIExample',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPassphraseApplication' => 'PhabricatorApplication',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorPasswordAuthProvider' => 'PhabricatorAuthProvider',
Make password hashing modular Summary: Ref T4443. Make hashing algorithms pluggable and extensible so we can deal with the attendant complexities more easily. This moves "Iterated MD5" to a modular implementation, and adds a tiny bit of hack-glue so we don't need to migrate the DB in this patch. I'll migrate in the next patch, then add bcrypt. Test Plan: - Verified that the same stuff gets stored in the DB (i.e., no functional changes): - Logged into an old password account. - Changed password. - Registered a new account. - Changed password. - Switched back to master. - Logged in / out, changed password. - Switched back, logged in. - Ran unit tests (they aren't super extensive, but cover some of the basics). Reviewers: btrahan Reviewed By: btrahan CC: aran, kofalt Maniphest Tasks: T4443 Differential Revision: https://secure.phabricator.com/D8268
2014-02-18 18:31:30 +01:00
'PhabricatorPasswordHasher' => 'Phobject',
'PhabricatorPasswordHasherTestCase' => 'PhabricatorTestCase',
'PhabricatorPasswordHasherUnavailableException' => 'Exception',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorPasswordSettingsPanel' => 'PhabricatorSettingsPanel',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorPaste' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPasteDAO',
'PhabricatorSubscribableInterface',
'PhabricatorTokenReceiverInterface',
'PhabricatorFlaggableInterface',
Transactions - add infrastructure for "mentions" Summary: Fixes T4036. Now if you say something on diff X like "This reminds me of Tx and Dy and commitHashFoo and Px." each of those objects gets a little visible transaction that the mention occurred. No feed, email, or notifications. Test Plan: made a comment like above and verified transactions. also submitted a diff that "Fixes Tx" and Tx did not get the transaction as expected. Reviewers: epriestley Reviewed By: epriestley Subscribers: joshuaspence, epriestley, Korvin Maniphest Tasks: T4036 Differential Revision: https://secure.phabricator.com/D10451
2014-09-09 23:21:13 +02:00
'PhabricatorMentionableInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
'PhabricatorProjectInterface',
Allow pastes to be destroyed Summary: Fixes T6186. Test Plan: - Used `bin/remove destroy Pxxx` to destroy a paste. - Verified file, transactions, etc., were destroyed. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6186 Differential Revision: https://secure.phabricator.com/D10563
2014-09-25 22:42:38 +02:00
'PhabricatorDestructibleInterface',
'PhabricatorApplicationTransactionInterface',
Add spacePHID infrastructure and implement in Paste Summary: Ref T8424. I'm using Paste as a testbed application because Spaces make some degree of sense for it but it's also flat/simple. This doesn't do anything interesting or useful and mostly just making the next (more interesting) diff smaller. Test Plan: - Ran `bin/storage upgrade -f`. - Browsed pastes. - Created a paste. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8424 Differential Revision: https://secure.phabricator.com/D13154
2015-06-05 02:45:24 +02:00
'PhabricatorSpacesInterface',
Implement a rough initial version of ApplicationSearch-driven Conduit read endpoints Summary: Ref T9964. See that task for some context and discussion. Ref T7715, which has the bigger picture here. Basically, I want Conduit read endpoints to be full-power, ApplicationSearch-driven endpoints, so that applications can: - Write one EditEngine and get web + conduit writes for free. - Write one SearchEngine and get web + conduit reads for free. I previously made some steps toward this, but this puts more of the structure in place. Test Plan: Viewed API console endpoint and read 20 pages of docs: {F1021961} Made various calls: with query keys, constraints, pagination, and limits. Viewed new {nav Config > Modules} page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7715, T9964 Differential Revision: https://secure.phabricator.com/D14743
2015-12-11 17:45:56 +01:00
'PhabricatorConduitResultInterface',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
),
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPasteApplication' => 'PhabricatorApplication',
Add PasteArchiveController Summary: Makes this more consistent. Also clean up spacing. Ref T9414 Test Plan: Archive/Activate Paste, Edit Paste Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9414 Differential Revision: https://secure.phabricator.com/D14724
2015-12-09 20:50:19 +01:00
'PhabricatorPasteArchiveController' => 'PhabricatorPasteController',
Add some create mail handlers for paste and files Summary: Fixes T1144. Though actually I think T1144 wanted some handy way to email from the command-line / arc, this is cooler. :D Test Plan: set conf properly and then ./bin/mail receive-test --as btrahan --to pasties@phabricator.dev | README --> it worked...! couldn't test files as easily but verified exception thrown when I tried to test. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1144 Differential Revision: https://secure.phabricator.com/D6622
2013-07-30 22:26:55 +02:00
'PhabricatorPasteConfigOptions' => 'PhabricatorApplicationConfigOptions',
Add a "content" attachment for Pastes for Conduit API Summary: Ref T9964. Builds on D14772. Allows callers to get the raw content of pastes as an attachment. Test Plan: - Read docs. - Executed attachment query. - Saw raw paste content. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14774
2015-12-14 15:01:04 +01:00
'PhabricatorPasteContentSearchEngineAttachment' => 'PhabricatorSearchEngineAttachment',
Pastebin Summary: This is Paste. It needs some work, but epriestley recommended that I just commit something that works, and expand on that later. Specifically, it lacks the ability to view a raw paste right now, and to turn off line numbers, making it hard to copy/paste from for now. It works for showing other people code, however. Test Plan: Pasted stuff, and was able to view it, and see it in the list on /paste/. Put a file extension in the title, and saw that syntax highlighting worked as expected. Reviewers: epriestley CC: Differential Revision: 424
2011-06-10 08:53:53 +02:00
'PhabricatorPasteController' => 'PhabricatorController',
'PhabricatorPasteDAO' => 'PhabricatorLiskDAO',
Split paste create/edit and list views Summary: We have this hybrid "create / last few pastes" landing screen right now but I ~never use the list at the bottom and it makes the controller kind of complicated. I want to let you edit pastes too, and this generally simplifies things. Also makes the textarea monospaced and cleans up the fork logic a bit. Test Plan: Created, forked pastes. Viewed paste lists. Viewed pastes. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1690 Differential Revision: https://secure.phabricator.com/D3375
2012-08-24 22:19:14 +02:00
'PhabricatorPasteEditController' => 'PhabricatorPasteController',
Allow ApplicationEditor forms to be reconfigured Summary: Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs. Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like: - "New Bug Report" - "New Feature Request" These would be views of the "Create Task" form, but with various adjustments: - A form might have additional instructions ("how to file a good bug report"). - A form might have prefilled values for some fields (like particular projects, subscribers, or policies). - A form might have some fields locked (so they can not be edited) or hidden. - A form might have a different field order. - A form might have a limited visibility policy, so only some users can access it. This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way". This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future. Test Plan: ApplicationEditor forms now let you manage available forms and edit the current form: {F959025} There's a new (bare bones) list of all available engines: {F959030} And if you jump into an engine, you can see all the forms for it: {F959038} The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14453
2015-11-04 21:52:52 +01:00
'PhabricatorPasteEditEngine' => 'PhabricatorEditEngine',
Paste - add transactions Summary: Ref T3650. This adds a create transaction, transactions for metadata (title, langauge, view policy), and comments. Editor is used on all create /edit paths. Test Plan: made some pastes via web and email - yay. edited pastes - yay. verified txns showed up on pastes and in feed correctly. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3516, T3650 Differential Revision: https://secure.phabricator.com/D6645
2013-08-02 21:56:58 +02:00
'PhabricatorPasteEditor' => 'PhabricatorApplicationTransactionEditor',
Improve lispum generation of pastes Summary: Fixes T8482, or something. I can't actually repro that but I think it should be fixed either here or earlier Test Plan: ``` $ ./bin/lipsum generate paste GENERATORS Selected generators: Pastes. WARNING This command generates synthetic test data, including user accounts. It is intended for use in development environments so you can test features more easily. There is no easy way to delete this data or undo the effects of this command. If you run it in a production environment, it will pollute your data with large amounts of meaningless garbage that you can not get rid of. Are you sure you want to generate piles of garbage? [y/N] y LIPSUM Generating synthetic test objects forever. Use ^C to stop when satisfied. Generated "Paste": P223 forgotten_memory_disks_backup.java Generated "Paste": P224 backup_disk_tables_and_administrate_backup_memory_account.java Generated "Paste": P225 sync_backup_disk_and_undo_memory.php Generated "Paste": P226 administrate_memory_shard_helper.php Generated "Paste": P227 cancel_disk_users Generated "Paste": P228 backups_pro.txt Generated "Paste": P229 undo_host.txt Generated "Paste": P230 accelerate_database_accounts.java Generated "Paste": P231 entomb_accounts.java Generated "Paste": P232 legendary_legendary_shards_helper.java Generated "Paste": P233 compact_backup_and_user_and_purge_memory Generated "Paste": P234 account_script_script_backup_helper_helper.java Generated "Paste": P235 purge_disk.php Generated "Paste": P236 forgotten_elder_account.txt Generated "Paste": P237 ancient_ancient_disks.txt Generated "Paste": P238 disk_user.php ``` Reviewers: chad Reviewed By: chad Maniphest Tasks: T8482 Differential Revision: https://secure.phabricator.com/D14883
2015-12-25 15:20:25 +01:00
'PhabricatorPasteFilenameContextFreeGrammar' => 'PhutilContextFreeGrammar',
Move Maniphest list rendering to SearchEngine Summary: Ref T4986. Moves Maniphest over. Nothing tricky here, just a complex block of rendering. Test Plan: Viewed Maniphest list. Created Maniphest panel. Used batch editor, drag-and-drop. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9139
2014-05-16 04:17:38 +02:00
'PhabricatorPasteListController' => 'PhabricatorPasteController',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorPastePastePHIDType' => 'PhabricatorPHIDType',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorPasteQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Provide a stable URI for getting raw paste content Summary: Fixes T9312. This is a bit fluff, but does simplify the view controller slightly and seems reasonable/useful in general. Test Plan: Clicked "View Raw File" on a paste, got redirected to the raw file via a stable URI. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9312 Differential Revision: https://secure.phabricator.com/D14167
2015-09-25 19:45:01 +02:00
'PhabricatorPasteRawController' => 'PhabricatorPasteController',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhabricatorPasteRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Generate expected scheamta for Passphrase, Paste, Phlux, Phame Summary: Ref T1191. Nothing notable in these. Test Plan: Viewed web UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10528
2014-09-24 22:50:57 +02:00
'PhabricatorPasteSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Move paste search to generic search. Summary: Begin implementing generic application search and refactoring paste search. Test Plan: See if the paste search still works. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5621
2013-04-14 15:53:20 +02:00
'PhabricatorPasteSearchEngine' => 'PhabricatorApplicationSearchEngine',
Truncate long source lines in Paste search result list snippets Summary: An attempt to resolve T9600. - `PhabricatorPasteQuery` builds truncated snippet when requested using `needSnippet()`. - `PhabricatorPasteSearchEngine` uses Paste snippet istead of content. - `PhabricatorSourceCodeView` accepts truncated source and type instead of line limit. Test Plan: Generated some content for Paste application and also added huge JSON oneliner. Checked Paste application pages in browser. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T9600 Differential Revision: https://secure.phabricator.com/D14313
2015-10-20 21:07:04 +02:00
'PhabricatorPasteSnippet' => 'Phobject',
Completed Paste Generation Summary: Ref T2903 Test Plan: Pastes being generated with all types of parents, view policies, code, etc. Reviewers: epriestley, AnhNhan Reviewed By: epriestley CC: AnhNhan, aran, Korvin Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5707
2013-04-29 21:10:53 +02:00
'PhabricatorPasteTestDataGenerator' => 'PhabricatorTestDataGenerator',
Paste - add transactions Summary: Ref T3650. This adds a create transaction, transactions for metadata (title, langauge, view policy), and comments. Editor is used on all create /edit paths. Test Plan: made some pastes via web and email - yay. edited pastes - yay. verified txns showed up on pastes and in feed correctly. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3516, T3650 Differential Revision: https://secure.phabricator.com/D6645
2013-08-02 21:56:58 +02:00
'PhabricatorPasteTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorPasteTransactionComment' => 'PhabricatorApplicationTransactionComment',
'PhabricatorPasteTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Pastebin Summary: This is Paste. It needs some work, but epriestley recommended that I just commit something that works, and expand on that later. Specifically, it lacks the ability to view a raw paste right now, and to turn off line numbers, making it hard to copy/paste from for now. It works for showing other people code, however. Test Plan: Pasted stuff, and was able to view it, and see it in the list on /paste/. Put a file extension in the title, and saw that syntax highlighting worked as expected. Reviewers: epriestley CC: Differential Revision: 424
2011-06-10 08:53:53 +02:00
'PhabricatorPasteViewController' => 'PhabricatorPasteController',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorPathSetupCheck' => 'PhabricatorSetupCheck',
Add an anyone() typeahead function for matching any document owner Summary: Fixes T5733. Test Plan: Ran search and Maniphest queries. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5733 Differential Revision: https://secure.phabricator.com/D12535
2015-04-24 00:44:27 +02:00
'PhabricatorPeopleAnyOwnerDatasource' => 'PhabricatorTypeaheadDatasource',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPeopleApplication' => 'PhabricatorApplication',
Implement most of the administrative UI for approval queues Summary: Nothing fancy here, just: - UI to show users needing approval. - "Approve" and "Disable" actions. - Send "Approved" email on approve. - "Approve" edit + log operations. - "Wait for Approval" state for users who need approval. There's still no natural way for users to end up not-approved -- you have to write directly to the database. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7573
2013-11-13 20:24:18 +01:00
'PhabricatorPeopleApproveController' => 'PhabricatorPeopleController',
Convert user profiles to Profile Panels Summary: Ref T10054. Primary goal is to be able to remove IconNav from the codebase. I've made these non-editable so users can't customize them yet. We //might// want administrators to customize these globally instead? In any case, we avoid a bunch of product questions by just locking these down for now. Test Plan: {F1061348} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15020
2016-01-14 15:47:06 +01:00
'PhabricatorPeopleCalendarController' => 'PhabricatorPeopleProfileController',
Basic user/account tool.
2011-01-24 03:09:16 +01:00
'PhabricatorPeopleController' => 'PhabricatorController',
Make user creation process simpler Summary: Fixes T4065. This divides user creation into separate "Standard User" and "Script/Bot" workflows which show only relevant fields and provide guidance. This fixes the verification mess associated with script/bot users by verifying their email addresses automatically. Test Plan: - Created a standard user. - Created a script/bot. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8674
2014-04-02 21:06:27 +02:00
'PhabricatorPeopleCreateController' => 'PhabricatorPeopleController',
Modernize "users" typeahead datasource Summary: Ref T4420. Modernize users. Test Plan: - Edited "Commit Authors" on Audit search. - Edited "Created By" on calendar search. - Edited "invited" on calendar search. - Edited "To" on "New conpherence message". - Edited user on "Add user to conpherence thread". - Edited "Authors" on countdown search. - Edited "Author" on differential search. - Edited "Responsible users" on differential search. - Edited "Owner" on Diffusion lint search. - Edited "include users" on Feed search. - Edited "Authors" on file search. - Edited "Authors" on Herald rule search. - Edited a couple of user-selecting Herald fields on rules. - Edited "user" on legalpad signature exemption. - Edited "creator" on legalpad search. - Edited "contributors" on legalpad search. - Edited "signers" on legalpad signature search. - Edited "Authors" on macro search. - Edited "Reassign/claim" on task detail. - Edited "assigned to" on task edit. - Edited "assigned to", "users projects", "authors" on task search. - Edited "creators" on oauthserver. - Edited "authors" on paste search. - Edited "actors" and "users" on activity log search. - Edited "authors" on pholio search. - Edited "users" on phrequent search. - Edited "authors", "answered by" on Ponder search. - Edited "add members" on project membership editor. - Edited "members" on project search. - Edited "pushers" on releeph product edit. - Edited "requestors" on releeph request search. - Edited "pushers" on diffusion push log. - Edited "authors", "owners", "subscribers" on global search. - Edited "authors" on slowvote search. - Edited users in custom policy. - Grepped for "common/authors", no hits. - Grepped for "common/users", no (relevant) hits. - Grepped for "common/accounts", no (relevant) hits. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9885
2014-07-18 00:44:18 +02:00
'PhabricatorPeopleDatasource' => 'PhabricatorTypeaheadDatasource',
Move "Delete User" action to user profiles Summary: Ref T4065. The existence of two separate edit workflows for users is broadly confusing to administrators. I want to unify user administration and improve administration of system agent accounts. Particularly, I plan to: - Give administrators limited access to profile editing of system agents (e.g., change profile picture). - Give administrators limited access to Settings for system agents. - Broadly, move all the weird old special editing into standard editing. Test Plan: - Hit all the errors (delete self, no username, wrong username). - Deleted a user. - Visited page as a non-admin, got 403'd. - Viewed old edit UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8662
2014-04-02 21:05:07 +02:00
'PhabricatorPeopleDeleteController' => 'PhabricatorPeopleController',
Convert user profiles to Profile Panels Summary: Ref T10054. Primary goal is to be able to remove IconNav from the codebase. I've made these non-editable so users can't customize them yet. We //might// want administrators to customize these globally instead? In any case, we avoid a bunch of product questions by just locking these down for now. Test Plan: {F1061348} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15020
2016-01-14 15:47:06 +01:00
'PhabricatorPeopleDetailsProfilePanel' => 'PhabricatorProfilePanel',
Implement most of the administrative UI for approval queues Summary: Nothing fancy here, just: - UI to show users needing approval. - "Approve" and "Disable" actions. - Send "Approved" email on approve. - "Approve" edit + log operations. - "Wait for Approval" state for users who need approval. There's still no natural way for users to end up not-approved -- you have to write directly to the database. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7573
2013-11-13 20:24:18 +01:00
'PhabricatorPeopleDisableController' => 'PhabricatorPeopleController',
Put Disable/Admin flags on profiles Summary: Ref T4065. Moves the "disable / enable" and "make / unmake administrator" actions to profiles. Test Plan: Disabled and enabled users, and made and unmade administrators. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8666
2014-04-02 21:05:49 +02:00
'PhabricatorPeopleEmpowerController' => 'PhabricatorPeopleController',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorPeopleExternalPHIDType' => 'PhabricatorPHIDType',
Allow users to have profile icons Summary: Ref T10054. This primarily improves aesthetics and consistency for member/wathcher lists in projects. Test Plan: {F1068873} {F1068874} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15103
2016-01-24 14:43:57 +01:00
'PhabricatorPeopleIconSet' => 'PhabricatorIconSet',
Add administrative invite interfaces Summary: Ref T7152. This implements the administrative UI for the upstream email invite workflow. Pieces of this will be reused in Instances to implement the instance invite workflow, although some of it is probably going to be a bit copy/pastey. This doesn't actually create or send invites yet, and they still can't be carried through registration. Test Plan: {F290970} {F290971} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152 Differential Revision: https://secure.phabricator.com/D11733
2015-02-11 15:05:53 +01:00
'PhabricatorPeopleInviteController' => 'PhabricatorPeopleController',
'PhabricatorPeopleInviteListController' => 'PhabricatorPeopleInviteController',
'PhabricatorPeopleInviteSendController' => 'PhabricatorPeopleInviteController',
Added ldap import controller
2012-07-04 04:10:38 +02:00
'PhabricatorPeopleLdapController' => 'PhabricatorPeopleController',
Move Maniphest list rendering to SearchEngine Summary: Ref T4986. Moves Maniphest over. Nothing tricky here, just a complex block of rendering. Test Plan: Viewed Maniphest list. Created Maniphest panel. Used batch editor, drag-and-drop. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9139
2014-05-16 04:17:38 +02:00
'PhabricatorPeopleListController' => 'PhabricatorPeopleController',
Modernize user activity logs (ApplicationSearch, policies) Summary: Ref T4398. Ref T4842. I want to let users review their own account activity, partly as a general security measure and partly to make some of the multi-factor stuff easier to build and debug. To support this, implement modern policies and application search. I also removed the "old" and "new" columns from this output, since they had limited utility and revealed email addresses to administrators for some actions. We don't let administrators access email addresses from other UIs, and the value of doing so here seems very small. Test Plan: Used interface to issue a bunch of queries against user logs, got reasonable/expected results. Reviewers: btrahan Reviewed By: btrahan Subscribers: keir, epriestley Maniphest Tasks: T4842, T4398 Differential Revision: https://secure.phabricator.com/D8856
2014-04-28 02:31:35 +02:00
'PhabricatorPeopleLogQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhabricatorPeopleLogSearchEngine' => 'PhabricatorApplicationSearchEngine',
Move Maniphest list rendering to SearchEngine Summary: Ref T4986. Moves Maniphest over. Nothing tricky here, just a complex block of rendering. Test Plan: Viewed Maniphest list. Created Maniphest panel. Used batch editor, drag-and-drop. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9139
2014-05-16 04:17:38 +02:00
'PhabricatorPeopleLogsController' => 'PhabricatorPeopleController',
Begin modularizing main menu items Summary: Ref T10077. Ref T8918. The way the main menu is built is not very modular and fairly hacky. It assumes menus are provided by applications, but this isn't exactly true. Notably, the "Quick Create" menu is not per-application. The current method of building this menu is very inefficient (see T10077). Particularly, we have to build it //twice// because we need to build it once to render the item and then again to render the dropdown options. Start cleaning this up. This diff doesn't actually have any behavioral changes, since I can't swap the menu over until we get rid of all the other items and I haven't extended this to Notifications/Conpherence yet so it doesn't actually fix T8918. Test Plan: Viewed menus while logged in, logged out, in different applications, in desktop/mobile. Nothing appeared different. Reviewers: chad Reviewed By: chad Maniphest Tasks: T8918, T10077 Differential Revision: https://secure.phabricator.com/D14922
2016-01-01 13:26:36 +01:00
'PhabricatorPeopleMainMenuBarExtension' => 'PhabricatorMainMenuBarExtension',
Move user editing/management actions to a separate "Manage" item, like projects Summary: This improves consistency (by making this UI more similar to the projects UI) and gives us more flexibility the next time we update user profiles. Test Plan: {F1068889} Took all the actions (probably?) to check that all the redirects were updated. Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15104
2016-01-24 16:07:17 +01:00
'PhabricatorPeopleManageProfilePanel' => 'PhabricatorProfilePanel',
Make user creation process simpler Summary: Fixes T4065. This divides user creation into separate "Standard User" and "Script/Bot" workflows which show only relevant fields and provide guidance. This fixes the verification mess associated with script/bot users by verifying their email addresses automatically. Test Plan: - Created a standard user. - Created a script/bot. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8674
2014-04-02 21:06:27 +02:00
'PhabricatorPeopleNewController' => 'PhabricatorPeopleController',
Refine global search UI for tokenizer functions Summary: Ref T4100. - Removes the "with unowned" checkbox in favor of the "no owners" function. - Support functions in "Authors" and "Owners". Test Plan: - Ran various global search and Maniphest queries. {F379931} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12523
2015-04-23 12:07:24 +02:00
'PhabricatorPeopleNoOwnerDatasource' => 'PhabricatorTypeaheadDatasource',
'PhabricatorPeopleOwnerDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Basic user/account tool.
2011-01-24 03:09:16 +01:00
'PhabricatorPeopleProfileController' => 'PhabricatorPeopleController',
Convert user profiles to Profile Panels Summary: Ref T10054. Primary goal is to be able to remove IconNav from the codebase. I've made these non-editable so users can't customize them yet. We //might// want administrators to customize these globally instead? In any case, we avoid a bunch of product questions by just locking these down for now. Test Plan: {F1061348} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15020
2016-01-14 15:47:06 +01:00
'PhabricatorPeopleProfileEditController' => 'PhabricatorPeopleProfileController',
Move user editing/management actions to a separate "Manage" item, like projects Summary: This improves consistency (by making this UI more similar to the projects UI) and gives us more flexibility the next time we update user profiles. Test Plan: {F1068889} Took all the actions (probably?) to check that all the redirects were updated. Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15104
2016-01-24 16:07:17 +01:00
'PhabricatorPeopleProfileManageController' => 'PhabricatorPeopleProfileController',
Convert user profiles to Profile Panels Summary: Ref T10054. Primary goal is to be able to remove IconNav from the codebase. I've made these non-editable so users can't customize them yet. We //might// want administrators to customize these globally instead? In any case, we avoid a bunch of product questions by just locking these down for now. Test Plan: {F1061348} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15020
2016-01-14 15:47:06 +01:00
'PhabricatorPeopleProfilePanelEngine' => 'PhabricatorProfilePanelEngine',
'PhabricatorPeopleProfilePictureController' => 'PhabricatorPeopleProfileController',
'PhabricatorPeopleProfileViewController' => 'PhabricatorPeopleProfileController',
Use ObjectItemListView in Diviner Summary: Ref T988. Nuke the old directory CSS. Test Plan: {F44796} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6093
2013-05-31 19:51:53 +02:00
'PhabricatorPeopleQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Move "Change Username" from weird edit panel to standard object action Summary: Ref T4065. Make this work in a more standard way which administrators have a reasonable shot at finding and using. See D8662 for discussion. Test Plan: Changed a user's username. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8663
2014-04-02 21:05:19 +02:00
'PhabricatorPeopleRenameController' => 'PhabricatorPeopleController',
Implement ApplicationSearch in People Summary: Ref T2625. Fixes T2812. Implement ApplicationSearch in People. {F44788} Test Plan: Made People queries. Used Conduit. Used `@mentions`. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2625, T2812 Differential Revision: https://secure.phabricator.com/D6092
2013-05-31 19:51:20 +02:00
'PhabricatorPeopleSearchEngine' => 'PhabricatorApplicationSearchEngine',
Successfully Generated People Summary: Ref T2903 Test Plan: Added new person whose profile was visible afterwards. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan, btrahan Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5682
2013-04-15 04:09:20 +02:00
'PhabricatorPeopleTestDataGenerator' => 'PhabricatorTestDataGenerator',
Implement PhabricatorApplicationTransactionInterface on PhabricatorUser Summary: Right now, "Publish" workers for user profile edits (title / blub) can get gummed up in the daemons. Implement the interfaces and provide a Query so they can go through. Test Plan: - Made a profile "Title" edit. - Used `bin/worker execute --id <id>` to see task fail. - Applied patch. - Saw task work. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D13213
2015-06-08 22:35:57 +02:00
'PhabricatorPeopleTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Rename TypehaeadUserParameterizedDatasource to PeopleUserFunctionDatasource Summary: Ref T4100. This improves application scoping (Typeahead -> People) and uses a more consitent and concise name (Parameterized -> Function). Test Plan: - `grep` - Used affected datasource. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12532
2015-04-23 17:06:46 +02:00
'PhabricatorPeopleUserFunctionDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorPeopleUserPHIDType' => 'PhabricatorPHIDType',
Move "Send Welcome Email" to profiles and nuke old weird edit UI Summary: Ref T4065. Moves the last of the weird alternate edit UI to profiles. The old "Edit" controller is now for creation only, and the funky pencil icon is gone. Test Plan: Created accounts; sent welcome email. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8670
2014-04-02 21:06:17 +02:00
'PhabricatorPeopleWelcomeController' => 'PhabricatorPeopleController',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorPersonaAuthProvider' => 'PhabricatorAuthProvider',
Auth - restore Phabricator OAuth as a provider Summary: So meta it hurts. Fixes T887. Test Plan: created a second instance of phabricator locally. made an account on oauth server phabricator. set up my normal dev phabricator to use this new oauth phabricator. noted the form worked. created an account via the oauth method and it worked. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T887 Differential Revision: https://secure.phabricator.com/D11287
2015-01-09 01:28:04 +01:00
'PhabricatorPhabricatorAuthProvider' => 'PhabricatorOAuth2AuthProvider',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPhameApplication' => 'PhabricatorApplication',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorPhameBlogPHIDType' => 'PhabricatorPHIDType',
'PhabricatorPhamePostPHIDType' => 'PhabricatorPHIDType',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPhluxApplication' => 'PhabricatorApplication',
'PhabricatorPholioApplication' => 'PhabricatorApplication',
MetaMTA: Owners, Pholio, Macro Summary: Port MetaMTA options for Owners, Pholio and Macro. At some point I'd like to get rid of all these options (provide one "reply domain", and not allow overrides of reply handlers -- use events instead) but that's a battle we can fight later. Test Plan: Looked at options, looked at setup issues, edited something. Reviewers: codeblock, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4469
2013-01-16 19:52:30 +01:00
'PhabricatorPholioConfigOptions' => 'PhabricatorApplicationConfigOptions',
Parse VCS revert langauge in commit messages Summary: Ref T1751. When commit messages include language like "reverts X", parse it. This change doesn't do anything with the commits yet. I attempted to cover all "natural" VCS messages and all reasonable human variations of these messages. Test Plan: Added unit tests. Added `var_dump()` and used `scripts/repository/reparse.php --message X` to reparse some commit messages, with expected results. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1751 Differential Revision: https://secure.phabricator.com/D5840
2013-05-06 21:33:37 +02:00
'PhabricatorPholioMockTestDataGenerator' => 'PhabricatorTestDataGenerator',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPhortuneApplication' => 'PhabricatorApplication',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorPhortuneContentSource' => 'PhabricatorContentSource',
Add some of a billing daemon skeleton Summary: Ref T6881. This adds the worker, and a script to make it easier to test. It doesn't actually invoice anything. I'm intentionally allowing the script to double-bill since it makes testing way easier (by letting you bill the same period over and over again), and provides a tool for recovery if billing screws up. (This diff isn't very interesting, just trying to avoid a 5K-line diff at the end.) Test Plan: Used `bin/phortune invoice ...` to get the worker to print out some date ranges which it would theoretically invoice. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11577
2015-01-30 20:29:05 +01:00
'PhabricatorPhortuneManagementInvoiceWorkflow' => 'PhabricatorPhortuneManagementWorkflow',
'PhabricatorPhortuneManagementWorkflow' => 'PhabricatorManagementWorkflow',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPhragmentApplication' => 'PhabricatorApplication',
'PhabricatorPhrequentApplication' => 'PhabricatorApplication',
Implemented Phrequent time tracking functionality. Summary: This differential implements Phrequent's time tracking functionality for users and hooks it up to Maniphest. It also includes a basic "Time Tracked" list for the Phrequent application, where users can review what they've spent time working on. Test Plan: Apply the patch and track some things in Maniphest. They should appear in the "Time Tracked" view of Phrequent. There is also a `phrequent.show-prompt` option which toggles whether to display a prompt when tracking time. I'm unsure of whether the prompt is useful or is more likely to cause people to click "Track Time", go off and do the task and then come back to the prompt still waiting for them to confirm. A potential solution to the "accidentally clicking the button and recording 2 seconds of time" might be to show a prompt on stop if the total time is under 10 seconds, asking whether the user wants to keep or discard the tracked time. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2857 Differential Revision: https://secure.phabricator.com/D5479
2013-03-30 17:32:29 +01:00
'PhabricatorPhrequentConfigOptions' => 'PhabricatorApplicationConfigOptions',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPhrictionApplication' => 'PhabricatorApplication',
Phriction setting. Summary: One setting. Test Plan: - Looked at the setting in the web interface. - Waved to it - Introduced myself - Had a nice conversation - Made a new friend - Turns out `phriction.enabled` is a nice guy. Reviewers: epriestley, chad Reviewed By: chad CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4436
2013-01-15 15:31:53 +01:00
'PhabricatorPhrictionConfigOptions' => 'PhabricatorApplicationConfigOptions',
DRAFT - throw together Phurl skeleton. Summary: DRAFT - throw together Phurl skeleton. Test Plan: The idea is that `some/long/url` will become `install/Udet4d` and can be viewed and edited at `install/Udet4d/view` and `install/Udet4d/edit`, respectively? Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: joshuaspence, chad, epriestley, Korvin Maniphest Tasks: T6049 Differential Revision: https://secure.phabricator.com/D13681
2015-07-24 20:06:27 +02:00
'PhabricatorPhurlApplication' => 'PhabricatorApplication',
Allow a domain other than the install domain to serve as a short Phurl domain Summary: Ref T8995, config option for Phurl short domain to share shortened URL's Test Plan: - Configure Phurl short domain to something like "zz.us" - Navigate to `zz.us`; get 404 - Navigate to `zz.us/u/3` or `zz.us/u/alias` where `U3` is an existing Phurl; redirect to correct destination Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Maniphest Tasks: T8995 Differential Revision: https://secure.phabricator.com/D14447
2015-11-09 19:09:19 +01:00
'PhabricatorPhurlConfigOptions' => 'PhabricatorApplicationConfigOptions',
DRAFT - throw together Phurl skeleton. Summary: DRAFT - throw together Phurl skeleton. Test Plan: The idea is that `some/long/url` will become `install/Udet4d` and can be viewed and edited at `install/Udet4d/view` and `install/Udet4d/edit`, respectively? Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: joshuaspence, chad, epriestley, Korvin Maniphest Tasks: T6049 Differential Revision: https://secure.phabricator.com/D13681
2015-07-24 20:06:27 +02:00
'PhabricatorPhurlController' => 'PhabricatorController',
'PhabricatorPhurlDAO' => 'PhabricatorLiskDAO',
Add Phurl Remarkup Summary: Ref T9722, Add Phurl Remarkup as `((id))` or `((alias))` Test Plan: Add a comment to any object as `((id))` or `((alias))`. Make sure comment renders as a link. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T9722 Differential Revision: https://secure.phabricator.com/D14427
2015-11-06 22:47:52 +01:00
'PhabricatorPhurlLinkRemarkupRule' => 'PhutilRemarkupRule',
'PhabricatorPhurlRemarkupRule' => 'PhabricatorObjectRemarkupRule',
DRAFT - throw together Phurl skeleton. Summary: DRAFT - throw together Phurl skeleton. Test Plan: The idea is that `some/long/url` will become `install/Udet4d` and can be viewed and edited at `install/Udet4d/view` and `install/Udet4d/edit`, respectively? Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: joshuaspence, chad, epriestley, Korvin Maniphest Tasks: T6049 Differential Revision: https://secure.phabricator.com/D13681
2015-07-24 20:06:27 +02:00
'PhabricatorPhurlSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Allow a domain other than the install domain to serve as a short Phurl domain Summary: Ref T8995, config option for Phurl short domain to share shortened URL's Test Plan: - Configure Phurl short domain to something like "zz.us" - Navigate to `zz.us`; get 404 - Navigate to `zz.us/u/3` or `zz.us/u/alias` where `U3` is an existing Phurl; redirect to correct destination Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Maniphest Tasks: T8995 Differential Revision: https://secure.phabricator.com/D14447
2015-11-09 19:09:19 +01:00
'PhabricatorPhurlShortURLController' => 'PhabricatorPhurlController',
'PhabricatorPhurlShortURLDefaultController' => 'PhabricatorPhurlController',
DRAFT - throw together Phurl skeleton. Summary: DRAFT - throw together Phurl skeleton. Test Plan: The idea is that `some/long/url` will become `install/Udet4d` and can be viewed and edited at `install/Udet4d/view` and `install/Udet4d/edit`, respectively? Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: joshuaspence, chad, epriestley, Korvin Maniphest Tasks: T6049 Differential Revision: https://secure.phabricator.com/D13681
2015-07-24 20:06:27 +02:00
'PhabricatorPhurlURL' => array(
'PhabricatorPhurlDAO',
'PhabricatorPolicyInterface',
'PhabricatorProjectInterface',
'PhabricatorApplicationTransactionInterface',
'PhabricatorSubscribableInterface',
'PhabricatorTokenReceiverInterface',
'PhabricatorDestructibleInterface',
'PhabricatorMentionableInterface',
'PhabricatorFlaggableInterface',
'PhabricatorSpacesInterface',
),
Ref T8989, Phurl "Visit URL" link should route through a separate controller. Summary: Ref T8989, Phurl "Visit URL" should now route to an access controller that decides if the URL is valid whether to open it, or redirect back to Phurl object. New route is `local.install.com/u/1` to open link. Test Plan: - open Phurl object with invalid URL, "Visit URL" link should redirect back to object - open Phurl object with valid URL, "Visit URL" link should open the link - open `local.install.com/u/1` for `U1` with valid URL should open the link - open `local.install.com/u/1` for `U1` with invalid URL should redirect to `local.install.com/U1` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: joshuaspence, Korvin Maniphest Tasks: T8989 Differential Revision: https://secure.phabricator.com/D14381
2015-11-02 21:08:47 +01:00
'PhabricatorPhurlURLAccessController' => 'PhabricatorPhurlController',
Remarkup links to link to short url instead of long and fix commenting on Phurl's Summary: Ref T6049, remarkup links to use short URLs and make commenting on Phurl's actually work Test Plan: - Create Phurl `U123` - Comment on that Phurl `((123))` Comment should link to `/u/123` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T6049 Differential Revision: https://secure.phabricator.com/D14477
2015-11-13 23:36:58 +01:00
'PhabricatorPhurlURLCommentController' => 'PhabricatorPhurlController',
Ref T6049, Add Phurl URL create capability Summary: Ref T6049, Add Phurl URL create capability Test Plan: - Change {nav Home > Applications > Phurl > Configure} to allow no one to create Phurl URLs - Attempt {nav Phurl > Shorten URL}. Should not be able to create a Phurl. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin Maniphest Tasks: T6049 Differential Revision: https://secure.phabricator.com/D14510
2015-11-18 21:24:09 +01:00
'PhabricatorPhurlURLCreateCapability' => 'PhabricatorPolicyCapability',
DRAFT - throw together Phurl skeleton. Summary: DRAFT - throw together Phurl skeleton. Test Plan: The idea is that `some/long/url` will become `install/Udet4d` and can be viewed and edited at `install/Udet4d/view` and `install/Udet4d/edit`, respectively? Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: joshuaspence, chad, epriestley, Korvin Maniphest Tasks: T6049 Differential Revision: https://secure.phabricator.com/D13681
2015-07-24 20:06:27 +02:00
'PhabricatorPhurlURLEditController' => 'PhabricatorPhurlController',
'PhabricatorPhurlURLEditor' => 'PhabricatorApplicationTransactionEditor',
'PhabricatorPhurlURLListController' => 'PhabricatorPhurlController',
Fix two issues with Phurl / Badges mail generation Summary: - Phurl is missing a ReplyHandler / MailReceiver (all of this code should get cleaned up eventually, but I don't plan to get to it for a while). - Badges has a bad call. This should clean up some bad daemon tasks. Test Plan: Saw fewer daemon errors after these changes. Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D14852
2015-12-22 17:05:56 +01:00
'PhabricatorPhurlURLMailReceiver' => 'PhabricatorObjectMailReceiver',
DRAFT - throw together Phurl skeleton. Summary: DRAFT - throw together Phurl skeleton. Test Plan: The idea is that `some/long/url` will become `install/Udet4d` and can be viewed and edited at `install/Udet4d/view` and `install/Udet4d/edit`, respectively? Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: joshuaspence, chad, epriestley, Korvin Maniphest Tasks: T6049 Differential Revision: https://secure.phabricator.com/D13681
2015-07-24 20:06:27 +02:00
'PhabricatorPhurlURLPHIDType' => 'PhabricatorPHIDType',
'PhabricatorPhurlURLQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Fix two issues with Phurl / Badges mail generation Summary: - Phurl is missing a ReplyHandler / MailReceiver (all of this code should get cleaned up eventually, but I don't plan to get to it for a while). - Badges has a bad call. This should clean up some bad daemon tasks. Test Plan: Saw fewer daemon errors after these changes. Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D14852
2015-12-22 17:05:56 +01:00
'PhabricatorPhurlURLReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
DRAFT - throw together Phurl skeleton. Summary: DRAFT - throw together Phurl skeleton. Test Plan: The idea is that `some/long/url` will become `install/Udet4d` and can be viewed and edited at `install/Udet4d/view` and `install/Udet4d/edit`, respectively? Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: joshuaspence, chad, epriestley, Korvin Maniphest Tasks: T6049 Differential Revision: https://secure.phabricator.com/D13681
2015-07-24 20:06:27 +02:00
'PhabricatorPhurlURLSearchEngine' => 'PhabricatorApplicationSearchEngine',
'PhabricatorPhurlURLTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorPhurlURLTransactionComment' => 'PhabricatorApplicationTransactionComment',
'PhabricatorPhurlURLTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'PhabricatorPhurlURLViewController' => 'PhabricatorPhurlController',
Add a pirate translation Summary: Basic Pirate, mostly Maniphest Test Plan: Play lots with Maniphest Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14830
2015-12-20 16:03:07 +01:00
'PhabricatorPirateEnglishTranslation' => 'PhutilTranslation',
Modularize Aphront "sites" Summary: Fixes T5702. The path here is long and windy: - I want to move `blog.phacility.com` to the new `secure` host. - That host has `security.require-https` set, which I want to keep set (before, this was handled in a sort of hacky way at the nginx/preamble level, but I've cleaned up everything else now). - Currently, that setting forces blogs to HTTPS too, which won't work. - To let blogs be individually configurable, we need to either modularize site config or make things hackier. - Modularize rather than increasing hackiness. - Also add a little "modules" panel in Config. See T6859. This feels like a reasonable middle ground between putting this stuff in Applications and burying it in `bin/somewhere`. Test Plan: - Visited normal site. - Visited phame on-domain site. - Visited phame off-domain site. - Viewed static resources. {F561897} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D13474
2015-06-29 23:04:48 +02:00
'PhabricatorPlatformSite' => 'PhabricatorSite',
Support enabling a formal points field in Maniphest Summary: Ref T4427. - New config option for labels, enabling, etc., but no UI/niceness yet. - When enabled, add a field. - Allow nonnegative values, including fractional values. - EditEngine is nice and Conduit / actions basically just work with a tiny bit of extra support code. Test Plan: - Edited points via "Edit". - Edited points via Conduit. - Edited points via stacked actions. - Tried to set "zebra" points. - Tried to set -1 points. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4427 Differential Revision: https://secure.phabricator.com/D15220
2016-02-09 00:24:52 +01:00
'PhabricatorPointsEditField' => 'PhabricatorEditField',
Add basic per-object privacy policies Summary: Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change. Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request. The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens. We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can. Test Plan: Unit tests, played around in the UI with various policy settings. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
'PhabricatorPolicies' => 'PhabricatorPolicyConstants',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorPolicy' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyDAO',
'PhabricatorPolicyInterface',
remarkup.css: Consistently zero top/bottom margins for first/last block-level children Summary: For block-level elements that have a margin-top or margin-bottom set (generally to 12px), also reset the appropriate margin to 0 when they're a first-child or last-child of their parents. The change doesn't affect nested lists, their selector is more specific. Test Plan: Look at some comments or wiki documents that end with different block elements, verify that the margins are pretty. Reviewers: epriestley, #blessed_reviewers, chad Reviewed By: #blessed_reviewers, chad Subscribers: Korvin, epriestley Projects: #remarkup Maniphest Tasks: T6968 Differential Revision: https://secure.phabricator.com/D11382
2015-01-14 21:14:22 +01:00
'PhabricatorDestructibleInterface',
Prepare the policy rule edit endpoint for integration Summary: Ref T603. Allow the endpoint to take an existing policy PHID to populate the editor and return a useful datastructure. Test Plan: In the next revision, actually hooked this up. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7299
2013-10-14 21:07:31 +02:00
),
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPolicyApplication' => 'PhabricatorApplication',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorPolicyAwareQuery' => 'PhabricatorOffsetPagedQuery',
'PhabricatorPolicyAwareTestQuery' => 'PhabricatorPolicyAwareQuery',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'PhabricatorPolicyCanEditCapability' => 'PhabricatorPolicyCapability',
'PhabricatorPolicyCanJoinCapability' => 'PhabricatorPolicyCapability',
'PhabricatorPolicyCanViewCapability' => 'PhabricatorPolicyCapability',
Allow applications to define new policy capabilities Summary: Ref T603. I want to let applications define new capabilities (like "can manage global rules" in Herald) and get full support for them, including reasonable error strings in the UI. Currently, this is difficult for a couple of reasons. Partly this is just a code organization issue, which is easy to fix. The bigger thing is that we have a bunch of strings which depend on both the policy and capability, like: "You must be an administrator to view this object." "Administrator" is the policy, and "view" is the capability. That means every new capability has to add a string for each policy, and every new policy (should we introduce any) needs to add a string for each capability. And we can't do any piecemeal "You must be a {$role} to {$action} this object" becuase it's impossible to translate. Instead, make all the strings depend on //only// the policy, //only// the capability, or //only// the object type. This makes the dialogs read a little more strangely, but I think it's still pretty easy to understand, and it makes adding new stuff way way easier. Also provide more context, and more useful exception messages. Test Plan: - See screenshots. - Also triggered a policy exception and verified it was dramatically more useful than it used to be. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7260
2013-10-07 22:28:58 +02:00
'PhabricatorPolicyCapability' => 'Phobject',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorPolicyCapabilityTestCase' => 'PhabricatorTestCase',
Add Policy options. Test Plan: Looked at the setting and available options from the dropdown. Reviewers: epriestley, chad Reviewed By: chad CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4354
2013-01-07 21:47:26 +01:00
'PhabricatorPolicyConfigOptions' => 'PhabricatorApplicationConfigOptions',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorPolicyConstants' => 'Phobject',
Explain policy exception rules to users Summary: Ref T603. Adds clarifying text which expands on policies and explains exceptions and rules. The goal is to provide an easy way for users to learn about special policy rules, like "task owners can always see a task". This presentation might be a little aggressive. That's probably OK as we introduce policies, but something a little more tempered might be better down the road. Test Plan: See screenshot. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7150
2013-09-27 17:43:41 +02:00
'PhabricatorPolicyController' => 'PhabricatorController',
Add storage for custom policies Summary: Ref T603. Allows custom policies to be saved. No integration with policy controls yet. Test Plan: mysql> select * from policy where id = 3\G *************************** 1. row *************************** id: 3 phid: PHID-PLCY-e4v2fnbyuibi4supl5tn rules: [{"action":"allow","rule":"PhabricatorPolicyRuleAdministrators","value":null},{"action":"allow","rule":"PhabricatorPolicyRuleProjects","value":["PHID-PROJ-cwovm5gn2ilubjehcdgd"]},{"action":"allow","rule":"PhabricatorPolicyRuleLunarPhase","value":"new"}] defaultAction: deny dateCreated: 1381437466 dateModified: 1381437466 1 row in set (0.00 sec) Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7282
2013-10-11 01:09:51 +02:00
'PhabricatorPolicyDAO' => 'PhabricatorLiskDAO',
Make Maniphest list page react to viewer capabilities Summary: Ref T603. Basically: - Hide "Reports". - Hide "batch edit" and "export to excel". - Hide reprioritization controls. - I left the edit controls, they show a "login to continue" dialog when hit. - Allow tokenizer results to fill for public users. - Fix a bug where membership in projects was computed incorrectly in certain cases. - Add a unit test covering the project membership bug. Test Plan: Viewed /maniphest/ when logged out, and while logged in. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7126
2013-09-25 22:45:04 +02:00
'PhabricatorPolicyDataTestCase' => 'PhabricatorTestCase',
Custom Policy Editor Summary: Ref T603. This isn't remotely usable yet, but I wanted to get any feedback before I build it out anymore. I think this is a reasonable interface for defining custom policies? It's basically similar to Herald, although it's a bit simpler. I imagine users will rarely interact with this, but this will service the high end of policy complexity (and allow the definition of things like "is member of LDAP group" or whatever). Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, asherkin Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7217
2013-10-09 23:05:10 +02:00
'PhabricatorPolicyEditController' => 'PhabricatorPolicyController',
Modularize application extensions to EditEngine Summary: Ref T9132. Currently, EditEngine had some branchy-`instanceof` code like this: ``` if ($object instanceof Whatever) { do_magic(); } if ($object instanceof SomethingElse) { do_other_magic(); } ``` ...where `Whatever` and `SomethingElse` are first-party applications like ProjectsInterface and SubscribersInterface. This kind of code is generally bad because third-parties can't add new stuff, and it suggest something is kind of hacky in its architecture. Ideally, we would eventually get rid of almost all of this. T9789 is a similar discussion of this for the next layer down (`TransactionEditor`) and plans to get rid of branchy-instanceofs there too. Since I'm about to add more stuff here (for Custom Fields), split it out first so I'm not digging us any deeper than I already dug us. Broadly, this allows third-party extensions to add fields to every EditEngine UI if they want, like we do for Policies, Subscribers, Projects and Comments today (and CustomFields soon). Test Plan: {F1007575} - Observed that all fields still appear on the form and seem to work correctly. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14599
2015-11-29 19:05:41 +01:00
'PhabricatorPolicyEditEngineExtension' => 'PhabricatorEditEngineExtension',
Implement a basic version of ApplicationEditor in Paste Summary: Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste. This mostly looks and works like ApplicationSearch, and is heavily modeled on it. Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else. This has no functional changes, except: - I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it. - Subscribers are now editable. - Form field order is a little goofy (this will be fixed in a future diff). - Subscribers and projects are now race-resistant. The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits. Test Plan: - Created pastes. - Created pastes via API. - Edited pastes. - Edited every field. - Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4768, T9132 Differential Revision: https://secure.phabricator.com/D14390
2015-11-03 03:58:32 +01:00
'PhabricatorPolicyEditField' => 'PhabricatorEditField',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'PhabricatorPolicyException' => 'Exception',
Explain policy exception rules to users Summary: Ref T603. Adds clarifying text which expands on policies and explains exceptions and rules. The goal is to provide an easy way for users to learn about special policy rules, like "task owners can always see a task". This presentation might be a little aggressive. That's probably OK as we introduce policies, but something a little more tempered might be better down the road. Test Plan: See screenshot. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7150
2013-09-27 17:43:41 +02:00
'PhabricatorPolicyExplainController' => 'PhabricatorPolicyController',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorPolicyFilter' => 'Phobject',
Work around a bug in PHP 5.3-ish with abstract methods in interfaces Summary: @chad is hitting an issue described in P961, which I think is this bug in PHP: https://bugs.php.net/bug.php?id=43200 Work around it by defining a "PHIDInterface" and having both "Flaggable" and "Policy" extend it, so that there is only one `getPHID()` declaration. Test Plan: shrug~ Reviewers: chad, btrahan Reviewed By: chad CC: chad, aran Differential Revision: https://secure.phabricator.com/D7408
2013-10-26 00:58:17 +02:00
'PhabricatorPolicyInterface' => 'PhabricatorPHIDInterface',
Add a very simple `bin/policy` script for CLI policy administration Summary: Ref T603. I want to provide at least a basic CLI tool for fixing policy problems, since there are various ways users can lock themselves out of objects right now. Although I imagine we'll solve most of them in the application eventually, having a workaround in the meantime will probably make support a lot easier. This implements `bin/policy show <object>`, which shows an object's policy settings. In a future diff, I'll implement something like `bin/policy set --capability view --policy users <object>`, although maybe just `bin/policy unlock <object>` (which sets view and edit to "all users") would be better for now. Whichever way we go, it will be some blanket answer to people showing up in IRC having locked themselves out of objects which unblocks them while we work on preventing the issue in the first place. Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7171
2013-09-29 18:06:41 +02:00
'PhabricatorPolicyManagementShowWorkflow' => 'PhabricatorPolicyManagementWorkflow',
Add `bin/policy unlock` Summary: Ref T603. We might need a fine-grained CLI tool later on, but here's a bat we can bludgeon things with. Test Plan: - Ran `bin/policy unlock D12` (adjusted policies). - Ran `bin/policy unlock rPca85c457ebcb` (got "not mutable" stuff). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7189
2013-10-02 01:01:15 +02:00
'PhabricatorPolicyManagementUnlockWorkflow' => 'PhabricatorPolicyManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorPolicyManagementWorkflow' => 'PhabricatorManagementWorkflow',
Add storage for custom policies Summary: Ref T603. Allows custom policies to be saved. No integration with policy controls yet. Test Plan: mysql> select * from policy where id = 3\G *************************** 1. row *************************** id: 3 phid: PHID-PLCY-e4v2fnbyuibi4supl5tn rules: [{"action":"allow","rule":"PhabricatorPolicyRuleAdministrators","value":null},{"action":"allow","rule":"PhabricatorPolicyRuleProjects","value":["PHID-PROJ-cwovm5gn2ilubjehcdgd"]},{"action":"allow","rule":"PhabricatorPolicyRuleLunarPhase","value":"new"}] defaultAction: deny dateCreated: 1381437466 dateModified: 1381437466 1 row in set (0.00 sec) Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7282
2013-10-11 01:09:51 +02:00
'PhabricatorPolicyPHIDTypePolicy' => 'PhabricatorPHIDType',
Prepare the policy rule edit endpoint for integration Summary: Ref T603. Allow the endpoint to take an existing policy PHID to populate the editor and return a useful datastructure. Test Plan: In the next revision, actually hooked this up. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7299
2013-10-14 21:07:31 +02:00
'PhabricatorPolicyQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Modularize Aphront exception handling Summary: Ref T1806. Ref T7173. Depends on D14047. Currently, all exception handling is in this big messy clump in `AphrontDefaultApplicationConfiguration`. Split it out into modular classes. This will let a future change add new classes in the Phacility cluster which intercept particular exceptions we care about and replaces the default, generic responses with more useful, tailored responses. Test Plan: {F777391} - Hit a Conduit error (made a method throw). - Hit an Ajax error (made comment preview throw). - Hit a high security error (tried to edit TOTP). - Hit a rate limiting error (added a bunch of email addresses). - Hit a policy error (tried to look at something with no permission). - Hit an arbitrary exception (made a randomc ontroller throw). Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14049
2015-09-03 19:04:42 +02:00
'PhabricatorPolicyRequestExceptionHandler' => 'PhabricatorRequestExceptionHandler',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorPolicyRule' => 'Phobject',
Implement a rough initial version of ApplicationSearch-driven Conduit read endpoints Summary: Ref T9964. See that task for some context and discussion. Ref T7715, which has the bigger picture here. Basically, I want Conduit read endpoints to be full-power, ApplicationSearch-driven endpoints, so that applications can: - Write one EditEngine and get web + conduit writes for free. - Write one SearchEngine and get web + conduit reads for free. I previously made some steps toward this, but this puts more of the structure in place. Test Plan: Viewed API console endpoint and read 20 pages of docs: {F1021961} Made various calls: with query keys, constraints, pagination, and limits. Viewed new {nav Config > Modules} page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7715, T9964 Differential Revision: https://secure.phabricator.com/D14743
2015-12-11 17:45:56 +01:00
'PhabricatorPolicySearchEngineExtension' => 'PhabricatorSearchEngineExtension',
Add basic per-object privacy policies Summary: Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change. Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request. The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens. We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can. Test Plan: Unit tests, played around in the UI with various policy settings. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
'PhabricatorPolicyTestCase' => 'PhabricatorTestCase',
Add support for "Extended Policies" Summary: Ref T7703. See that task and inline for a bunch of discussion. Briefly, when we run implicit policy rules ("to see a revision, you must also be able to see its repository") at query time, they don't apply to other viewers we might check later. We do this very rarely, but when we do we're often doing it for a bunch of different viewers (for example, in Herald) so I don't want to just reload the object a million times. Test Plan: - Added and executed unit tests. - Wrote a "flag everything" Herald rule, as in the original report in T7703, and no longer got "Unknown Object" flags on revisions. - Rigged up a lot of cases in the web UI and couldn't find any inconsistencies, although this case is normally very hard to hit. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7703 Differential Revision: https://secure.phabricator.com/D13104
2015-05-11 23:23:35 +02:00
'PhabricatorPolicyTestObject' => array(
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'Phobject',
Add support for "Extended Policies" Summary: Ref T7703. See that task and inline for a bunch of discussion. Briefly, when we run implicit policy rules ("to see a revision, you must also be able to see its repository") at query time, they don't apply to other viewers we might check later. We do this very rarely, but when we do we're often doing it for a bunch of different viewers (for example, in Herald) so I don't want to just reload the object a million times. Test Plan: - Added and executed unit tests. - Wrote a "flag everything" Herald rule, as in the original report in T7703, and no longer got "Unknown Object" flags on revisions. - Rigged up a lot of cases in the web UI and couldn't find any inconsistencies, although this case is normally very hard to hit. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7703 Differential Revision: https://secure.phabricator.com/D13104
2015-05-11 23:23:35 +02:00
'PhabricatorPolicyInterface',
'PhabricatorExtendedPolicyInterface',
),
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorPolicyType' => 'PhabricatorPolicyConstants',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorPonderApplication' => 'PhabricatorApplication',
Begin modularizing profile panel/link construction Summary: Ref T10054. This has no product impact, but prepares us for customizable side nav on "profiles" (today, projects; probably users some day; and maybe other stuff down the road). Test Plan: Clicked all links on a profile, everything was exactly the same as before. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15007
2016-01-12 19:27:39 +01:00
'PhabricatorProfilePanel' => 'Phobject',
'PhabricatorProfilePanelConfiguration' => array(
'PhabricatorSearchDAO',
'PhabricatorPolicyInterface',
'PhabricatorExtendedPolicyInterface',
Make "profile menu" configuration mostly work Summary: Ref T10054. This does a big chunk of the legwork to let users reconfigure profile menus (currently, just project menus). This includes: - Editing builtin items (e.g., you can rename the default items). - Creating new items (for now, only links are available). This does not yet include: - Hiding items. - Reordering items. - Lots of fancy types of items (dashboards, etc). - Any UI changes. - Documentation (does feature: TODO link for documentation). Test Plan: {F1060695} {F1060696} {F1060697} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15010
2016-01-13 00:06:43 +01:00
'PhabricatorApplicationTransactionInterface',
Begin modularizing profile panel/link construction Summary: Ref T10054. This has no product impact, but prepares us for customizable side nav on "profiles" (today, projects; probably users some day; and maybe other stuff down the road). Test Plan: Clicked all links on a profile, everything was exactly the same as before. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15007
2016-01-12 19:27:39 +01:00
),
'PhabricatorProfilePanelConfigurationQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhabricatorProfilePanelConfigurationTransaction' => 'PhabricatorApplicationTransaction',
Add a missing transaction query class for panel transactions Summary: Ref T10054. The daemons look for this but currently can't find it. Test Plan: Ran daemons, clean exit on profile menu edits instead of permanent failure. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15053
2016-01-19 16:28:10 +01:00
'PhabricatorProfilePanelConfigurationTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Make "profile menu" configuration mostly work Summary: Ref T10054. This does a big chunk of the legwork to let users reconfigure profile menus (currently, just project menus). This includes: - Editing builtin items (e.g., you can rename the default items). - Creating new items (for now, only links are available). This does not yet include: - Hiding items. - Reordering items. - Lots of fancy types of items (dashboards, etc). - Any UI changes. - Documentation (does feature: TODO link for documentation). Test Plan: {F1060695} {F1060696} {F1060697} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15010
2016-01-13 00:06:43 +01:00
'PhabricatorProfilePanelEditEngine' => 'PhabricatorEditEngine',
'PhabricatorProfilePanelEditor' => 'PhabricatorApplicationTransactionEditor',
Begin modularizing profile panel/link construction Summary: Ref T10054. This has no product impact, but prepares us for customizable side nav on "profiles" (today, projects; probably users some day; and maybe other stuff down the road). Test Plan: Clicked all links on a profile, everything was exactly the same as before. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15007
2016-01-12 19:27:39 +01:00
'PhabricatorProfilePanelEngine' => 'Phobject',
Make "profile menu" configuration mostly work Summary: Ref T10054. This does a big chunk of the legwork to let users reconfigure profile menus (currently, just project menus). This includes: - Editing builtin items (e.g., you can rename the default items). - Creating new items (for now, only links are available). This does not yet include: - Hiding items. - Reordering items. - Lots of fancy types of items (dashboards, etc). - Any UI changes. - Documentation (does feature: TODO link for documentation). Test Plan: {F1060695} {F1060696} {F1060697} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15010
2016-01-13 00:06:43 +01:00
'PhabricatorProfilePanelIconSet' => 'PhabricatorIconSet',
Begin modularizing profile panel/link construction Summary: Ref T10054. This has no product impact, but prepares us for customizable side nav on "profiles" (today, projects; probably users some day; and maybe other stuff down the road). Test Plan: Clicked all links on a profile, everything was exactly the same as before. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15007
2016-01-12 19:27:39 +01:00
'PhabricatorProfilePanelPHIDType' => 'PhabricatorPHIDType',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorProject' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorProjectDAO',
Transactions - deploy buildTransactionTimeline against Config, Pholio, and Projects Summary: Ref T4712. These are a bit time consuming to test so might as well send off a batch now and again. Test Plan: foreach impacted controller, made sure the timeline rendered as it did before. for project column and config, noted the "should terminate" UI was also rendered unlike before. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10923
2014-12-03 21:28:53 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorFlaggableInterface',
'PhabricatorPolicyInterface',
Implement query and policy rules for subprojects Summary: Ref T10010. This implements technical groundwork for subprojects. Specifically, it implements policy rules like Phriction: - to see a project, you must be able to see all of its parents (and the project itself). - you can edit a project if you can edit any of its parents (or the project itself). To facilitiate this, we load all project ancestors when querying projects so we can do the view/edit checks. This does NOT yet implement: - proper membership rules for these projects (up next); - any kind of UI to let users create subprojects. Test Plan: - Added unit tests. - Executed unit tests. - Browsed Projects (no change in behavior is expected). Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14861
2015-12-23 12:42:51 +01:00
'PhabricatorExtendedPolicyInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorCustomFieldInterface',
'PhabricatorDestructibleInterface',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorFulltextInterface',
Implement a basic project.search third-generation API method Summary: Ref T10010. This still needs support for attachments (to get members) and more constraints (like slugs), but mostly works. Test Plan: Ran query, saw basically sensible results. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14889
2015-12-27 11:44:07 +01:00
'PhabricatorConduitResultInterface',
Roughly implement milestone columns on workboards Summary: Ref T10010. These aren't perfect but I think (?) they aren't horribly broken. - When a project is a parent project, destroy (as far as the user can tell) any custom columns. - When a project has milestones, automatically generate columns on the project's workboard (if it has a workboard). - When you move tasks between milestones, add the proper milestone tag. - When you move tasks out of milestones back into the backlog, add the proper parent project tag. - (Plenty of UI / design stuff to adjust.) Test Plan: - Dragged stuff between milestone columns. - Used a normal workboard. - Wasn't able to find any egregiously bad cases that did anything terrible. {F1088224} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D15171
2016-02-02 18:53:18 +01:00
'PhabricatorColumnProxyInterface',
update library map (from D3200)
2012-08-10 00:42:44 +02:00
),
Modularize "add projects" and "remove projects" Herald actions Summary: Ref T8726. Convert these to be modular. Test Plan: - Created rules using these actions. - Upgraded them. - Verified they still work. {F659266} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13705
2015-07-24 19:56:52 +02:00
'PhabricatorProjectAddHeraldAction' => 'PhabricatorProjectHeraldAction',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorProjectApplication' => 'PhabricatorApplication',
Move "Archive Project" to a standard, separate action Summary: Ref T4379. Projects currently include their "delete/disable" function as part of edit, which is atypical. Instead, provide it as a first-class action. This is primarily for consistency between applications. (The action list on projects is getting pretty huge, but we can deal with that separately; I have some ideas.) Test Plan: Archived/unarchived a project. Edited a project. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4379 Differential Revision: https://secure.phabricator.com/D8177
2014-02-10 23:30:47 +01:00
'PhabricatorProjectArchiveController' => 'PhabricatorProjectController',
Allow workboard background colors to be configured Summary: Adds a UI for selecting background colors. You can choose "Use Parent", which is the default, and allows you to set a color that all descendants inherit. You can also choose "None", if a parent has a WHACKY BACKGROUND that you refuse to put up with. Test Plan: {F1114588} {F1114589} Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15279
2016-02-16 15:52:32 +01:00
'PhabricatorProjectBoardBackgroundController' => 'PhabricatorProjectBoardController',
Add a secret board view to Projects Summary: Ref T1344. This is //very// rough. Some UI issues: - Empty states for the board and columns are junky. - Column widths are crazy. I think we need to set them to fixed-width, since we may have an arbitrarily large number of columns? - I don't think we have the header UI elements in M10 yet and that mock is pretty old, so I sort of very roughly approximated it. - What should we do when you click a task title? Popping the whole task in a dialog is possible but needs a bunch of work to actually work. Might need to build "sheets" or something. - Icons are slightly clipped for some reason. - All the backend stuff is totally faked. Generally, my plan is just to use these to implement all of T390. Specifically: - "Kanban" projects will have "Backlog" on the left. You'll drag them toward the right as you make progress. - "Milestone" projects will have "No Milestone" on the left, then "Milestone 9", "Milestone 8", etc. - "Sprint" projects will have "Backlog" on the left, then "Sprint 31", "Sprint 30", etc. So all of these things end up being pretty much exactly the same, with some minor text changes and new columns showing up on the left vs the right or whatever. Test Plan: See screenshot. Reviewers: chad, btrahan Reviewed By: btrahan CC: chad, aran, sascha-egerer Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7374
2013-10-22 06:11:36 +02:00
'PhabricatorProjectBoardController' => 'PhabricatorProjectController',
Allow workboards to be disabled, hiding "(Backlog)" column annotations Summary: Fixes T7410. - Adds a "Disable Workboard" action to the "Manage Backlog" menu. - We'll probably move this somewhere else if/when that column gets too messy. - Disabling a board hides it, prevents it from being recreated by non-editors, and hides the "Project (Backlog)" annotations. - Resotring a board puts it back in pristine condition. Test Plan: - Disabled a board. - Verified "(Backlog)" annotations vanished. - Enabled a board. Reviewers: chad Reviewed By: chad Subscribers: mbishopim3 Maniphest Tasks: T7410 Differential Revision: https://secure.phabricator.com/D15215
2016-02-08 20:24:32 +01:00
'PhabricatorProjectBoardDisableController' => 'PhabricatorProjectBoardController',
Workboards - add new "initialization" flow Summary: Currently, we just create a default "backlog" column if / when you visit a workboard for the first time. Post this patch, instead you see a blocking dialog that lets you either create the default backlog column or import columns from another project. In the case of the latter, the user gets another dialog which lets them select any project of which they are a member that also has columns in it. Note that only not hidden columns get imported. Fixes T4431. Test Plan: - made a new workboard and got my new dialog. made a default backlog and it worked! - made a new workboard again and tried the import flow - it also worked. - verified projects with no columns do not show up in import dialog - verified project with / without columns still all show up in maniphest project typeahead Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4431 Differential Revision: https://secure.phabricator.com/D10153
2014-08-05 22:40:41 +02:00
'PhabricatorProjectBoardImportController' => 'PhabricatorProjectBoardController',
Move uncommon workboard management options to "Manage Board" view Summary: This gives us room for less-common workboard management options like "Disable Board" without overloading the menus on the main board. Particularly, we can add background color options here without anything getting weird. I've left "Add Column" on the main UI since I think it's common enough to leave there. We could probably move "Hide Column" to this UI in the future, though. Test Plan: {F1114475} Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15278
2016-02-16 15:24:15 +01:00
'PhabricatorProjectBoardManageController' => 'PhabricatorProjectBoardController',
Allow board columns to be reordered Summary: Fixes T4567. This isn't going to win design awards and we have some leaky CSS, but it works fine. Test Plan: {F176743} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T4567 Differential Revision: https://secure.phabricator.com/D9905
2014-07-12 04:27:07 +02:00
'PhabricatorProjectBoardReorderController' => 'PhabricatorProjectBoardController',
Workboards - add column detail page Summary: followup to D8544. This ends up creating an editor + transactions to get the job done. Test Plan: made a column - saw a nice created transaction. edited the name - saw a nice name edit. deleted the column - saw a deleted transaction, updated "deleted" ui, and hte action change to activate. "Activated" the column and saw a transaction and updated UI. Tried to delete a column with tasks in it and got an error. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D8620
2014-03-26 22:40:47 +01:00
'PhabricatorProjectBoardViewController' => 'PhabricatorProjectBoardController',
Add ProjectCardView, use on Hovercards Summary: Builds a new ProjectCardView, starts basic Project Hovercard redesign (needs milestone, subproject support). Ref T10055 Test Plan: View all the colors. {F1092622} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T10055 Differential Revision: https://secure.phabricator.com/D15186
2016-02-05 05:11:36 +01:00
'PhabricatorProjectCardView' => 'AphrontTagView',
Allow project colors to be relabeled Summary: Fixes T5819. Adds configuration for setting color labels on projects and changing the default. Options are locked to what we make available. Test Plan: {F1066823} Reviewers: chad Reviewed By: chad Maniphest Tasks: T5819 Differential Revision: https://secure.phabricator.com/D15088
2016-01-22 13:33:23 +01:00
'PhabricatorProjectColorsConfigOptionType' => 'PhabricatorConfigJSONOptionType',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorProjectColumn' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorProjectDAO',
Transactions - deploy buildTransactionTimeline against Config, Pholio, and Projects Summary: Ref T4712. These are a bit time consuming to test so might as well send off a batch now and again. Test Plan: foreach impacted controller, made sure the timeline rendered as it did before. for project column and config, noted the "should terminate" UI was also rendered unlike before. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10923
2014-12-03 21:28:53 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
'PhabricatorDestructibleInterface',
Use an extended policy to bind column and board policies together Summary: Ref T10349. Columns have the same policies as the projects they belong to. However, the current implementation just returns the policy directly. This usually works, but if the project has a policy like "Members of (This) Project", the policy filter tries to check if the viewer is a member of //the column itself//. That doesn't work, since columns don't have members. This leads to a situation where columns on "Editable By: Project Members" projects can not be edited. Instead, return a permissive base policy and then use an extended policy to bind the column policy to the project policy. Test Plan: - Edited a column on an "Editable By: Members of Project" board. - Added and ran a unit test covering this case. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10349 Differential Revision: https://secure.phabricator.com/D15268
2016-02-13 19:02:42 +01:00
'PhabricatorExtendedPolicyInterface',
Add a secret board view to Projects Summary: Ref T1344. This is //very// rough. Some UI issues: - Empty states for the board and columns are junky. - Column widths are crazy. I think we need to set them to fixed-width, since we may have an arbitrarily large number of columns? - I don't think we have the header UI elements in M10 yet and that mock is pretty old, so I sort of very roughly approximated it. - What should we do when you click a task title? Popping the whole task in a dialog is possible but needs a bunch of work to actually work. Might need to build "sheets" or something. - Icons are slightly clipped for some reason. - All the backend stuff is totally faked. Generally, my plan is just to use these to implement all of T390. Specifically: - "Kanban" projects will have "Backlog" on the left. You'll drag them toward the right as you make progress. - "Milestone" projects will have "No Milestone" on the left, then "Milestone 9", "Milestone 8", etc. - "Sprint" projects will have "Backlog" on the left, then "Sprint 31", "Sprint 30", etc. So all of these things end up being pretty much exactly the same, with some minor text changes and new columns showing up on the left vs the right or whatever. Test Plan: See screenshot. Reviewers: chad, btrahan Reviewed By: btrahan CC: chad, aran, sascha-egerer Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7374
2013-10-22 06:11:36 +02:00
),
Workboards - add column detail page Summary: followup to D8544. This ends up creating an editor + transactions to get the job done. Test Plan: made a column - saw a nice created transaction. edited the name - saw a nice name edit. deleted the column - saw a deleted transaction, updated "deleted" ui, and hte action change to activate. "Activated" the column and saw a transaction and updated UI. Tried to delete a column with tasks in it and got an error. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D8620
2014-03-26 22:40:47 +01:00
'PhabricatorProjectColumnDetailController' => 'PhabricatorProjectBoardController',
Allow columns to have a point limit Summary: Fixes T5885. This implements optional soft point limits for workboard columns, per traditional Kanban. - Allow columns to have a point limit set. - When a column has a point limit, show it in the header. - If a column has too many points in it, show the column and point count in red. @chad, this could probably use some design tweaks. In particular: - I changed the color of "hidden" columns to avoid confusion with "overfull" columns. We might be able to find a better color. - UI hints for overfull columns might need adjustment. (After T4427, we'll let you sum some custom field instead of total number of tasks, which is why this is called "points" rather than "number of tasks".) Test Plan: {F190914} Note that: - "Pre-planning" has a limit, so it shows "4/12". - "Planning" has a limit and is overfull, so it shows "5 / 4". - Other columns do not have limits. - "Post-planning" is a hidden column. This might be too muted now. Transactions: {F190915} Error messages / edit screen: {F190916} Reviewers: btrahan, chad Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T5885 Differential Revision: https://secure.phabricator.com/D10276
2014-08-15 20:16:08 +02:00
'PhabricatorProjectColumnEditController' => 'PhabricatorProjectBoardController',
Move column hide/show to the column context menu on workboards Summary: Fixes T5993. Now that we have a context menu we can make some edit operations easier to access. Test Plan: Toggled column visibility. Verified board state (columns shown/hidden, ordering) was retained. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5993 Differential Revision: https://secure.phabricator.com/D10417
2014-09-04 21:47:32 +02:00
'PhabricatorProjectColumnHideController' => 'PhabricatorProjectBoardController',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorProjectColumnPHIDType' => 'PhabricatorPHIDType',
Move board relationships to dedicated storage Summary: Fixes T5476. Using edges to store which objects are on which board columns ends up being pretty awkward. In particular, it makes T4807 very difficult to implement. Introduce a dedicated `BoardColumnPosition` storage. This doesn't affect ordering rules (T4807) yet: boards are still arranged by priority. We just read which tasks are on which columns out of a new table. Test Plan: - Migrated data, then viewed some boards. Saw exactly the same data. - Dragged tasks from column to column. - Created a task directly into a column. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5476 Differential Revision: https://secure.phabricator.com/D10160
2014-08-07 00:09:09 +02:00
'PhabricatorProjectColumnPosition' => array(
'PhabricatorProjectDAO',
'PhabricatorPolicyInterface',
),
'PhabricatorProjectColumnPositionQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add a secret board view to Projects Summary: Ref T1344. This is //very// rough. Some UI issues: - Empty states for the board and columns are junky. - Column widths are crazy. I think we need to set them to fixed-width, since we may have an arbitrarily large number of columns? - I don't think we have the header UI elements in M10 yet and that mock is pretty old, so I sort of very roughly approximated it. - What should we do when you click a task title? Popping the whole task in a dialog is possible but needs a bunch of work to actually work. Might need to build "sheets" or something. - Icons are slightly clipped for some reason. - All the backend stuff is totally faked. Generally, my plan is just to use these to implement all of T390. Specifically: - "Kanban" projects will have "Backlog" on the left. You'll drag them toward the right as you make progress. - "Milestone" projects will have "No Milestone" on the left, then "Milestone 9", "Milestone 8", etc. - "Sprint" projects will have "Backlog" on the left, then "Sprint 31", "Sprint 30", etc. So all of these things end up being pretty much exactly the same, with some minor text changes and new columns showing up on the left vs the right or whatever. Test Plan: See screenshot. Reviewers: chad, btrahan Reviewed By: btrahan CC: chad, aran, sascha-egerer Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7374
2013-10-22 06:11:36 +02:00
'PhabricatorProjectColumnQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Workboards - add column detail page Summary: followup to D8544. This ends up creating an editor + transactions to get the job done. Test Plan: made a column - saw a nice created transaction. edited the name - saw a nice name edit. deleted the column - saw a deleted transaction, updated "deleted" ui, and hte action change to activate. "Activated" the column and saw a transaction and updated UI. Tried to delete a column with tasks in it and got an error. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D8620
2014-03-26 22:40:47 +01:00
'PhabricatorProjectColumnTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorProjectColumnTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
'PhabricatorProjectColumnTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Implement custom fields in Projects Summary: Ref T4379. Ref T3794. Fixes T4010. This brings CustomFields to projects. My primary goal is to get rid of the special casing around project profiles and profile editing, so all edits are ApplicationTransactions. Particularly, I want to make the "blurb/description" field a custom field which goes through builtin infrastructure. A distant secondary goal is that this is a feature which users like/want because users like/want features. Test Plan: Added a custom field and examined it in the edit, view, and search interfaces. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3794, T4010, T4379 Differential Revision: https://secure.phabricator.com/D8180
2014-02-10 23:31:34 +01:00
'PhabricatorProjectConfigOptions' => 'PhabricatorApplicationConfigOptions',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorProjectConfiguredCustomField' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorProjectStandardCustomField',
'PhabricatorStandardCustomFieldInterface',
Implement custom fields in Projects Summary: Ref T4379. Ref T3794. Fixes T4010. This brings CustomFields to projects. My primary goal is to get rid of the special casing around project profiles and profile editing, so all edits are ApplicationTransactions. Particularly, I want to make the "blurb/description" field a custom field which goes through builtin infrastructure. A distant secondary goal is that this is a feature which users like/want because users like/want features. Test Plan: Added a custom field and examined it in the edit, view, and search interfaces. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3794, T4010, T4379 Differential Revision: https://secure.phabricator.com/D8180
2014-02-10 23:31:34 +01:00
),
Rough cut of projects. Summary: Test Plan: Reviewers: CC:
2011-02-21 03:41:23 +01:00
'PhabricatorProjectController' => 'PhabricatorController',
Simplify ProjectQuery handling of viewer membership Summary: Ref T10010. Currently, we do an unusual JOIN to make testing for viewer membership in projects a little cheaper. This won't work as-is once we have subprojects, so standardize, simplify, and cover it with more tests for now. (I may be able to get a similar optimization later, but want a correct implementation first.) Test Plan: This change should create no behavioral differences. - Added tests. - Ran tests. - Viewed projects. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14859
2015-12-23 12:42:42 +01:00
'PhabricatorProjectCoreTestCase' => 'PhabricatorTestCase',
Support drag-and-drop to set cover images on workboard cards Summary: This was slightly more complex than I believed, but not too terrible. Test Plan: {F1096126} - Also used some normal file uploaders to make sure I didn't break that. Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15202
2016-02-06 23:05:15 +01:00
'PhabricatorProjectCoverController' => 'PhabricatorProjectController',
Implement custom fields in Projects Summary: Ref T4379. Ref T3794. Fixes T4010. This brings CustomFields to projects. My primary goal is to get rid of the special casing around project profiles and profile editing, so all edits are ApplicationTransactions. Particularly, I want to make the "blurb/description" field a custom field which goes through builtin infrastructure. A distant secondary goal is that this is a feature which users like/want because users like/want features. Test Plan: Added a custom field and examined it in the edit, view, and search interfaces. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3794, T4010, T4379 Differential Revision: https://secure.phabricator.com/D8180
2014-02-10 23:31:34 +01:00
'PhabricatorProjectCustomField' => 'PhabricatorCustomField',
Add a secret board view to Projects Summary: Ref T1344. This is //very// rough. Some UI issues: - Empty states for the board and columns are junky. - Column widths are crazy. I think we need to set them to fixed-width, since we may have an arbitrarily large number of columns? - I don't think we have the header UI elements in M10 yet and that mock is pretty old, so I sort of very roughly approximated it. - What should we do when you click a task title? Popping the whole task in a dialog is possible but needs a bunch of work to actually work. Might need to build "sheets" or something. - Icons are slightly clipped for some reason. - All the backend stuff is totally faked. Generally, my plan is just to use these to implement all of T390. Specifically: - "Kanban" projects will have "Backlog" on the left. You'll drag them toward the right as you make progress. - "Milestone" projects will have "No Milestone" on the left, then "Milestone 9", "Milestone 8", etc. - "Sprint" projects will have "Backlog" on the left, then "Sprint 31", "Sprint 30", etc. So all of these things end up being pretty much exactly the same, with some minor text changes and new columns showing up on the left vs the right or whatever. Test Plan: See screenshot. Reviewers: chad, btrahan Reviewed By: btrahan CC: chad, aran, sascha-egerer Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7374
2013-10-22 06:11:36 +02:00
'PhabricatorProjectCustomFieldNumericIndex' => 'PhabricatorCustomFieldNumericIndexStorage',
'PhabricatorProjectCustomFieldStorage' => 'PhabricatorCustomFieldStorage',
'PhabricatorProjectCustomFieldStringIndex' => 'PhabricatorCustomFieldStringIndexStorage',
Rough cut of projects. Summary: Test Plan: Reviewers: CC:
2011-02-21 03:41:23 +01:00
'PhabricatorProjectDAO' => 'PhabricatorLiskDAO',
Modernize "projects" typeahead datasource Summary: Ref T4420. Update "projects" source. Test Plan: - Edited projects on a Differential revision. - Edited projects on a commit. - Edited projects on a repository. - Edited projects in feed search. - Edited projects in a Herald rule field. - Edited projects in a Herald rule action. - Edited projects in Maniphest batch editor. - Edited projects on Maniphest task. - Edited projects in "Associate Projects..." action in Maniphest. - Edited projects on Maniphest search in "all projects", "any project" and "not projects" fields. - Edited projects on a Paste. - Edited projects on a Pholio mock. - Edited projects on a custom policy rule. - Edited projects on a Ponder question. - Edited projects on a Diffusion search query. - Edited projects on a global search query. - Edited projects on a slowvote. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9884
2014-07-11 02:28:29 +02:00
'PhabricatorProjectDatasource' => 'PhabricatorTypeaheadDatasource',
Allow workboard sorting and filtering to be saved as defaults Summary: Fixes T6641. This allows users who have permission to edit a project to use "Save as Default" to save the current order and filter as defaults for the project. These are per-board defaults, and apply to all users. The rationale is that I think the best default ordering/filtering depends mostly on the board, not the viewer. This seems to align with most requests in the task, although rationale is a bit light. But, for example, it seems reasonable you might want to change the default filter to "All Tasks" on a sprint board, so you can see what's in the "Done" column. This also fixes some minor issues I ran into: - Herald could hit an issue while checking permissions if the project was a subproject and a non-member had a triggering rule. - "Advanced filter..." did not prefill with the current filter. Test Plan: - Set default order and filter on a workboard. - Reloaded board, saw settings stick. - Tried to edit a board as an unprivileged user (disabled menu items, error). - Reviewed transaction log. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6641 Differential Revision: https://secure.phabricator.com/D15260
2016-02-12 15:19:26 +01:00
'PhabricatorProjectDefaultController' => 'PhabricatorProjectBoardController',
Migrate project blurb/description to standard custom field storage Summary: Ref T4379. Major goal here is to remove `ProjectProfile` so all edits use ApplicationTransactions. This also makes things more flexible, allowing users to disable this field if they don't like it. Test Plan: Ran migration, verified data survived, edited/created projects, reordered fields. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4379 Differential Revision: https://secure.phabricator.com/D8182
2014-02-10 23:31:57 +01:00
'PhabricatorProjectDescriptionField' => 'PhabricatorProjectStandardCustomField',
Begin modularizing profile panel/link construction Summary: Ref T10054. This has no product impact, but prepares us for customizable side nav on "profiles" (today, projects; probably users some day; and maybe other stuff down the road). Test Plan: Clicked all links on a profile, everything was exactly the same as before. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15007
2016-01-12 19:27:39 +01:00
'PhabricatorProjectDetailsProfilePanel' => 'PhabricatorProfilePanel',
Convert projects to EditEngine Summary: Ref T10010. This is pretty straightforward with a couple of very minor new behaviors, like the icon selector edit field. Test Plan: - Created projects. - Edited projects. - Saw "Create Project" in quick create menu. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14896
2015-12-27 15:45:53 +01:00
'PhabricatorProjectEditController' => 'PhabricatorProjectController',
'PhabricatorProjectEditEngine' => 'PhabricatorEditEngine',
Merge some of the project editing options into an edit UI Summary: Ref T4426. This moves "Edit Details", "Edit Picture", and "Archive" to a separate "Edit" interface. "History" becomes part of this UI. Test Plan: {F114417} {F114418} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T4426 Differential Revision: https://secure.phabricator.com/D8248
2014-02-17 05:17:52 +01:00
'PhabricatorProjectEditPictureController' => 'PhabricatorProjectController',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorProjectFulltextEngine' => 'PhabricatorFulltextEngine',
Modularize "add projects" and "remove projects" Herald actions Summary: Ref T8726. Convert these to be modular. Test Plan: - Created rules using these actions. - Upgraded them. - Verified they still work. {F659266} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13705
2015-07-24 19:56:52 +02:00
'PhabricatorProjectHeraldAction' => 'HeraldAction',
Add Herald support for projects Summary: Ref T10054. Ref T6113. I'm going to remove subscribers from projects to fix the confusion between "watch" and "subscribe". Users who have unusual use cases where they legitimately want to know when a project's description is updated or members change can use Herald to follow it. This is also useful in general and improves consistency, although I don't have too many use cases for it. Test Plan: Wrote a Herald rule, edited a project, saw the rule fire and send me email about the change. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6113, T10054 Differential Revision: https://secure.phabricator.com/D15061
2016-01-20 02:18:17 +01:00
'PhabricatorProjectHeraldAdapter' => 'HeraldAdapter',
'PhabricatorProjectHeraldFieldGroup' => 'HeraldFieldGroup',
New People Hovercards Summary: Mimics the Project Hovercards, more custom UI. Test Plan: Hover over person with and without badges, hover over project. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15253
2016-02-11 23:55:44 +01:00
'PhabricatorProjectHovercardEngineExtension' => 'PhabricatorHovercardEngineExtension',
Provide a "PHUIFormIconSetControl" Summary: Ref T9992. This is a step on the path to getting EditEngine working in Badges, Projects and Calendar. This doesn't add a new `EditField` for icons yet, just standardizes the old stuff. New stuff is more general and I saved 150 lines of code. I put the endpoint in Files because the similar "choose a profile picture" endpoint will definitely go there, and this endpoint might eventually feature, like, "draw your own icon~~" or something. Test Plan: - Created events, projects and badges with custom icons. - Edited events, projects and badges, changing their icons. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9992 Differential Revision: https://secure.phabricator.com/D14799
2015-12-16 16:53:13 +01:00
'PhabricatorProjectIconSet' => 'PhabricatorIconSet',
Allow project colors to be relabeled Summary: Fixes T5819. Adds configuration for setting color labels on projects and changing the default. Options are locked to what we make available. Test Plan: {F1066823} Reviewers: chad Reviewed By: chad Maniphest Tasks: T5819 Differential Revision: https://secure.phabricator.com/D15088
2016-01-22 13:33:23 +01:00
'PhabricatorProjectIconsConfigOptionType' => 'PhabricatorConfigJSONOptionType',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'PhabricatorProjectListController' => 'PhabricatorProjectController',
Add very basic UI for creating milestones and subprojects Summary: Ref T10010. This has a lot of UI/UX problems but I think it: - technically allows subproject creation; - technically allows milestone creation; - doesn't let users unwittingly destroy their installs (probably). Test Plan: - Created milestones. - Created subprojects. - Created and edited normal projects. - Observed some reasonable interactions (e.g., you can't create milestones for a milestone or edit a superproject's members). - Observed plenty of silly/confusing interactions that need additional work. {F1046657} {F1046658} {F1046655} {F1046656} {F1046654} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14904
2015-12-27 14:16:36 +01:00
'PhabricatorProjectListView' => 'AphrontView',
Move "Lock Project" to a separate action Summary: Ref T10010. Three motivations: - Primarily: this makes conversion to EditEngine easier since I don't have to convert this weird control. - This probably needs to have "Lock", "Unlock" and "Use Parent Project Setting" values after subprojects? But maybe just locking any parent locks all the children? Anyway, doesn't make sense to put it on the main edit form if it's weird like this, I think, since we'll want some kind of explanatory text. - I probably want to move this to the "Members" tab anyway, and this won't be available on milestone projects at all. Test Plan: Locked, unlocked, edited projects. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14895
2015-12-27 15:56:15 +01:00
'PhabricatorProjectLockController' => 'PhabricatorProjectController',
Make queries for Project "X" mean "X, or any subproject of X" Summary: Ref T10010. I think this is the desired/expected default behavior (e.g., searching for "Maniphest" should find tasks in any subproject or sprint of that project). I'll probably add an "exact(...)" function later to mean "only the Maniphest superproject, exactly, not any of its children". Test Plan: - Added and executed unit tests. - Ran various queries from the web UI. - Got sensible-seeming results. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14910
2015-12-29 14:06:47 +01:00
'PhabricatorProjectLogicalAncestorDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Make "user's projects" a logical datasource and add viewerprojects() Summary: Ref T4100. Ref T5595. This converts `projects(user)` into a logical datasource. Also adds a viewerprojects() logical datasource. Test Plan: {F375546} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4100, T5595 Differential Revision: https://secure.phabricator.com/D12462
2015-04-18 20:04:50 +02:00
'PhabricatorProjectLogicalDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Implement a project logic datasource Summary: Ref T4100. Ref T5595. This allows you to execute all "Projects", "Any Project", "Not in projects" and "include no projects" operations in one field. It doesn't actually implement such a field yet. Test Plan: {F375516} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5595, T4100 Differential Revision: https://secure.phabricator.com/D12460
2015-04-18 18:58:33 +02:00
'PhabricatorProjectLogicalOrNotDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Make "user's projects" a logical datasource and add viewerprojects() Summary: Ref T4100. Ref T5595. This converts `projects(user)` into a logical datasource. Also adds a viewerprojects() logical datasource. Test Plan: {F375546} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4100, T5595 Differential Revision: https://secure.phabricator.com/D12462
2015-04-18 20:04:50 +02:00
'PhabricatorProjectLogicalUserDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
'PhabricatorProjectLogicalViewerDatasource' => 'PhabricatorTypeaheadDatasource',
First cut of new Project Home Summary: First pass at a new Project Home page. This is starting to sprawl, so punting this up now before it gets too large. - Project homes now have "large header" - Custom Fields / Descriptions are in the main column - Feed is simpler visually - new "Background" option for PHUIObjectBoxView - move header buttons globally to "Grey" instead of "Simple" - New color and hover states for "Grey" - Transitions on Buttons haha - Edit Icon on Nav is now under "Manage" panel - New "Manage" Panel TODO: - More testing of bad cases of Custom Fields - Members Page in flux, needs design - Um still not sure how to make Custom Field not show UI Test Plan: Lots of random Project page visits. Save project, watch project, edit project, etc. {F1068191} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15097
2016-01-24 01:02:29 +01:00
'PhabricatorProjectManageController' => 'PhabricatorProjectController',
'PhabricatorProjectManageProfilePanel' => 'PhabricatorProfilePanel',
Materialize parent project memberships Summary: Ref T10010. Subprojects have the following general membership rule: if you are a member of a subproject ("Engineering > Backend"), you are also a member of the parent project. It would be unreasonably difficult to implement this rule directly in SQL when querying `withMemberPHIDs()`, because we'd have to do an arbitrarily large number of arbitrarily deep joins, or fetch and then requery a lot of data. Instead, introduce "materailized members", which are just a copy of all the effective members of a project. When a subproject has a membership change, we go recompute the effective membership of all the parent projects. Then we can just JOIN to satisfy `withMemberPHIDs()`. Having this process avialable will also be useful in the future, when a project's membership might be defined by some external source. Also make milestones mostly work like we'd expect them to with respect to membership and visibility. Test Plan: - Added and executed unit tests. - Changed project members, verified materialized members populated correctly in the database. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14863
2015-12-23 12:12:20 +01:00
'PhabricatorProjectMaterializedMemberEdgeType' => 'PhabricatorEdgeType',
Move member/watch actions to "Members/Watchers" page Summary: Ref T10054. This tries to make the members page a bit more consistent and provide hints to users about subproject/milestone membership rules. In particular: - You now join, leave, watch, unwatch, add and remove members, and lock and unlock membership from the members screen. - We now explain the membership rule for the project on this screen. There are currently four rules: - Normal Project: Join/leave normally. - Parent Project: Uses subprojects to determine members. - Milestone: Uses parent project to determine members. - Locked: Membership is locked. - (Future) Imported from LDAP/other external sources: Membership is determined by something else. Test Plan: {F1064878} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15059
2016-01-20 01:27:36 +01:00
'PhabricatorProjectMemberListView' => 'PhabricatorProjectUserListView',
Migrate Project edges to subclass `PhabricatorEdgeType` Summary: Modernize Project edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Add a member to a project, saw new rows in the `phabricator_project.edge` and `phabricator_user.edge` tables. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11111
2015-01-02 00:10:58 +01:00
'PhabricatorProjectMemberOfProjectEdgeType' => 'PhabricatorEdgeType',
Move member/watch actions to "Members/Watchers" page Summary: Ref T10054. This tries to make the members page a bit more consistent and provide hints to users about subproject/milestone membership rules. In particular: - You now join, leave, watch, unwatch, add and remove members, and lock and unlock membership from the members screen. - We now explain the membership rule for the project on this screen. There are currently four rules: - Normal Project: Join/leave normally. - Parent Project: Uses subprojects to determine members. - Milestone: Uses parent project to determine members. - Locked: Membership is locked. - (Future) Imported from LDAP/other external sources: Membership is determined by something else. Test Plan: {F1064878} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15059
2016-01-20 01:27:36 +01:00
'PhabricatorProjectMembersAddController' => 'PhabricatorProjectController',
Simplify members() datasource function Summary: Ref T4100. Implement members() in terms of the real projects datasource. Test Plan: Used members() functions in Differential, browsed members() functions. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12459
2015-04-18 18:26:04 +02:00
'PhabricatorProjectMembersDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Implement a "Project Members" object policy rule Summary: Fixes T9019. Pretty much ripped from D14467. I added the "policy hint" stuff so that you can create a project with this policy immediately. I really dislike how the "hint" code works, but we //almost// never need to use it and the badness feels fairly well-contained. Also pick up a quick feedback fix from D14863. Test Plan: - Added test coverage, got it to pass. - Created a project with "Visible To: Project Members". Reviewers: joshuaspence, chad Reviewed By: chad Maniphest Tasks: T9019 Differential Revision: https://secure.phabricator.com/D14869
2015-12-24 01:34:01 +01:00
'PhabricatorProjectMembersPolicyRule' => 'PhabricatorPolicyRule',
Begin modularizing profile panel/link construction Summary: Ref T10054. This has no product impact, but prepares us for customizable side nav on "profiles" (today, projects; probably users some day; and maybe other stuff down the road). Test Plan: Clicked all links on a profile, everything was exactly the same as before. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15007
2016-01-12 19:27:39 +01:00
'PhabricatorProjectMembersProfilePanel' => 'PhabricatorProfilePanel',
Use standard UI kit on project member page Summary: Fixes T4400. Removes very, very old "PhabricatorObjectListView", which was only used here. Test Plan: {F132249} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley, chad Maniphest Tasks: T4400 Differential Revision: https://secure.phabricator.com/D8574
2014-03-20 03:30:27 +01:00
'PhabricatorProjectMembersRemoveController' => 'PhabricatorProjectController',
Move member/watch actions to "Members/Watchers" page Summary: Ref T10054. This tries to make the members page a bit more consistent and provide hints to users about subproject/milestone membership rules. In particular: - You now join, leave, watch, unwatch, add and remove members, and lock and unlock membership from the members screen. - We now explain the membership rule for the project on this screen. There are currently four rules: - Normal Project: Join/leave normally. - Parent Project: Uses subprojects to determine members. - Milestone: Uses parent project to determine members. - Locked: Membership is locked. - (Future) Imported from LDAP/other external sources: Membership is determined by something else. Test Plan: {F1064878} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15059
2016-01-20 01:27:36 +01:00
'PhabricatorProjectMembersViewController' => 'PhabricatorProjectController',
Send appropriate requests to the server when dragging cards on project boards Summary: Ref T1344. Makes requests to the server, which are received and ignored. Performs appropriate locking/unlocking/enabling/disabling on the client. Test Plan: Dragged stuff around, saw it enable/disable/send correctly. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7943
2014-01-13 21:24:36 +01:00
'PhabricatorProjectMoveController' => 'PhabricatorProjectController',
Improve lipsum generation of projects Summary: Fixes T9156. - Fix hashtag generation. - Fix various badnesses. - Improve project name generator. Test Plan: ``` $ ./bin/lipsum generate projects GENERATORS Selected generators: Projects. WARNING This command generates synthetic test data, including user accounts. It is intended for use in development environments so you can test features more easily. There is no easy way to delete this data or undo the effects of this command. If you run it in a production environment, it will pollute your data with large amounts of meaningless garbage that you can not get rid of. Are you sure you want to generate piles of garbage? [y/N] y LIPSUM Generating synthetic test objects forever. Use ^C to stop when satisfied. Generated "Project": Self-Flying Data Center Swag Performance Generated "Project": Optimize Cars Generated "Project": Triaging Culture Optimization Generated "Project": Automating Experience Generated "Project": Accelerating NUX Performance Generated "Project": Optimizing Culture Optimization Generated "Project": Optimize Hardware ``` {F1042949} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9156 Differential Revision: https://secure.phabricator.com/D14874
2015-12-24 14:29:57 +01:00
'PhabricatorProjectNameContextFreeGrammar' => 'PhutilContextFreeGrammar',
Implement a project logic datasource Summary: Ref T4100. Ref T5595. This allows you to execute all "Projects", "Any Project", "Not in projects" and "include no projects" operations in one field. It doesn't actually implement such a field yet. Test Plan: {F375516} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5595, T4100 Differential Revision: https://secure.phabricator.com/D12460
2015-04-18 18:58:33 +02:00
'PhabricatorProjectNoProjectsDatasource' => 'PhabricatorTypeaheadDatasource',
Modernize Project/Object edges Summary: Ref T5245. Updates the project/object edge to use a modern class definition. Moves further toward real edges. Test Plan: Added projects to some objects, viewed transactions in transaction record. Reviewers: chad, btrahan, joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5245 Differential Revision: https://secure.phabricator.com/D9849
2014-07-18 00:42:19 +02:00
'PhabricatorProjectObjectHasProjectEdgeType' => 'PhabricatorEdgeType',
Modernize "user or project" typeahead datasources Summary: Ref T4420. These are used for some stuff like "reviewer". Test Plan: - Edited "reviewers" in differential edit. - Edited "reviewers" in differential search. - Edited "reviewers" in Differential "add reviewers..." action on detail page. - Edited a "reviewers" field in a herald rule. - Edited "owner" in owners search. - Edited "primary owner", "owners" on owners edit. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9887
2014-07-18 00:45:07 +02:00
'PhabricatorProjectOrUserDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Modernize Audit search engine Summary: Fixes T9279. Modernizes the SearchEngine and Query classes. User-facing changes: - Added order by commit date, default to order by commit date with newest commits first. - Added explicit "Needs Audit by". - Added new `packages(...)` typeahead function. - Picked up automatic subscribers, projects, and order fields. This changes behavior a little bit: we previously attempted to exclude, e.g., commits which a package you own needs to audit, but which you have resigned from. This is difficult in general and I think it needs a more comprehensive solution. This shouldn't impact users much, anyway. Test Plan: {F767628} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9279 Differential Revision: https://secure.phabricator.com/D14013
2015-08-31 19:17:54 +02:00
'PhabricatorProjectOrUserFunctionDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Provide formal Users/Projects/Mailable fields for EditEngine Summary: Ref T9132. This allows you to prefill EditEngine forms with stuff like `?subscribers=epriestley`, and we'll figure out what you mean. Test Plan: - Did `/?subscribers=...` with various values (good, bad, mis-capitalized). - Did `/?projects=...` with various values (good, bad, mis-capitalized). - Reviewed documentation. - Reviewed {nav Config > HTTP Parameter Types}. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14404
2015-11-04 19:20:38 +01:00
'PhabricatorProjectPHIDResolver' => 'PhabricatorPHIDResolver',
Make "profile menu" configuration mostly work Summary: Ref T10054. This does a big chunk of the legwork to let users reconfigure profile menus (currently, just project menus). This includes: - Editing builtin items (e.g., you can rename the default items). - Creating new items (for now, only links are available). This does not yet include: - Hiding items. - Reordering items. - Lots of fancy types of items (dashboards, etc). - Any UI changes. - Documentation (does feature: TODO link for documentation). Test Plan: {F1060695} {F1060696} {F1060697} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15010
2016-01-13 00:06:43 +01:00
'PhabricatorProjectPanelController' => 'PhabricatorProjectController',
Add a basic progress bar for milestones Summary: Ref T4427. This kind of works. Test Plan: {F1100578} Reviewers: chad Reviewed By: chad Maniphest Tasks: T4427 Differential Revision: https://secure.phabricator.com/D15221
2016-02-09 02:31:21 +01:00
'PhabricatorProjectPointsProfilePanel' => 'PhabricatorProfilePanel',
Rough cut of projects. Summary: Test Plan: Reviewers: CC:
2011-02-21 03:41:23 +01:00
'PhabricatorProjectProfileController' => 'PhabricatorProjectController',
Prepare Profile Panels for adoption in other applications Summary: Ref T10054. Take specialization off the objects and put it on Engine subclasses instead. One reason for this is that certain objects (like users) might have multiple different sets of panels in the future (e.g., their user profile and their home page). Test Plan: - No user-visible changes. - PanelEngine no longer has any hardcoded "project" stuff. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15018
2016-01-14 14:59:25 +01:00
'PhabricatorProjectProfilePanelEngine' => 'PhabricatorProfilePanelEngine',
Migrate Project edges to subclass `PhabricatorEdgeType` Summary: Modernize Project edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Add a member to a project, saw new rows in the `phabricator_project.edge` and `phabricator_user.edge` tables. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11111
2015-01-02 00:10:58 +01:00
'PhabricatorProjectProjectHasMemberEdgeType' => 'PhabricatorEdgeType',
Modernize Project/Object edges Summary: Ref T5245. Updates the project/object edge to use a modern class definition. Moves further toward real edges. Test Plan: Added projects to some objects, viewed transactions in transaction record. Reviewers: chad, btrahan, joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5245 Differential Revision: https://secure.phabricator.com/D9849
2014-07-18 00:42:19 +02:00
'PhabricatorProjectProjectHasObjectEdgeType' => 'PhabricatorEdgeType',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorProjectProjectPHIDType' => 'PhabricatorPHIDType',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorProjectQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Modularize "add projects" and "remove projects" Herald actions Summary: Ref T8726. Convert these to be modular. Test Plan: - Created rules using these actions. - Upgraded them. - Verified they still work. {F659266} Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13705
2015-07-24 19:56:52 +02:00
'PhabricatorProjectRemoveHeraldAction' => 'PhabricatorProjectHeraldAction',
Generate expected Project schemata Summary: Ref T1191. Notes: - Drops the project affiliation table. This is a very old membership table which was migrated to edges. - Drops the subproject table. This is a very old table for a removed feature. Test Plan: - Grepped for dropped tables. - Saw ~100 fewer setup issues. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10581
2014-10-01 16:37:01 +02:00
'PhabricatorProjectSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Use ApplicationSearch in projects Summary: Ref T2715. I stripped a bunch of stuff from the list since it was buggy, slow, or both. Some day, we'll rebuild it. Test Plan: {F51128} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6525
2013-07-22 17:34:35 +02:00
'PhabricatorProjectSearchEngine' => 'PhabricatorApplicationSearchEngine',
Move some PhabricatorSearchField subclasses Summary: Move some `PhabricatorSearchField` subclasses to be adjacent to the application to which they belong. This seems generally better to me than lumping them all together in the `src/applications/search/field/` directory. I was also wondering if it makes sense to rename these subclasses as `PhabricatorXSearchField` rather than `PhabricatorSearchXField` (as per T5655), but wasn't really sure if these objects are meant to be search-fields, or just fields belonging to the #search application. Test Plan: N/A. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13374
2015-07-06 14:52:04 +02:00
'PhabricatorProjectSearchField' => 'PhabricatorSearchTokenizerField',
Replace subscribe/unsubscribe for projects with explicit mail setting Summary: Ref T10054. Ref T6113. Users can currently subscribe to projects, which causes them to receive: # mail about project membership changes, description changes, etc; and # mail to the project, e.g. when the project is added as a subscriber on a task, or a reviewer on a revision. Almost no one cares about (1), and after D15061 you can use Herald to get this stuff if you really want it. (It will get progressively more annoying in the future with external membership sources causing automated project membership updates.) A lot of users are confused about (2) and how it relates to membership, watching, etc, and most users who want (2) don't want (1). Instead, add an explicit option for this and explain what it does. This is fairly verbose but I've hidden it on the member/watch screen, which is now the "explain how projects work" screen, I guess. Test Plan: {F1064929} {F1064930} {F1064931} - Disabled/enabled mail for a project. - Sent mail to a project with mail disabled, verified I didn't get a copy. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6113, T10054 Differential Revision: https://secure.phabricator.com/D15065
2016-01-20 03:56:15 +01:00
'PhabricatorProjectSilenceController' => 'PhabricatorProjectController',
'PhabricatorProjectSilencedEdgeType' => 'PhabricatorEdgeType',
Projects - add "Additional Hashtags" to projects Summary: Fixes T4021. Chooses to keep a "primary" slug based off the name - including all that lovely logic - and allow the user to specify "additional" slugs. Expose these as "hashtags" to the user. Sets us up for a fun diff where we can delete all the Project => Phriction automagicalness. In terms of this diff, see the TODOs i added. Test Plan: added a primary slug as an additional slug - got an error. added a slug in use on another project - got an error. added multiple good slugs and they worked. removed slugs and it worked. made some remark using multiple new slugs and they all linked to the correct project ran epriestley's case - Create project "A". - Give it additional slug "B". - Try to create project "B". and i got a nice error about hashtag collision Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4021 Differential Revision: https://secure.phabricator.com/D9250
2014-05-22 20:19:03 +02:00
'PhabricatorProjectSlug' => 'PhabricatorProjectDAO',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorProjectStandardCustomField' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorProjectCustomField',
'PhabricatorStandardCustomFieldInterface',
Migrate project blurb/description to standard custom field storage Summary: Ref T4379. Major goal here is to remove `ProjectProfile` so all edits use ApplicationTransactions. This also makes things more flexible, allowing users to disable this field if they don't like it. Test Plan: Ran migration, verified data survived, edited/created projects, reordered fields. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4379 Differential Revision: https://secure.phabricator.com/D8182
2014-02-10 23:31:57 +01:00
),
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorProjectStatus' => 'Phobject',
Put subprojects and milestones back into the Project UI Summary: Ref T10010. Restores subprojects and milestones to the UI with a more modern style and more warnings. Test Plan: {F1085207} {F1085208} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D15152
2016-02-01 16:04:19 +01:00
'PhabricatorProjectSubprojectWarningController' => 'PhabricatorProjectController',
Add empty subproject/milestone controllers Summary: Ref T10010. These do nothing yet. Test Plan: Clicked 'em. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14894
2015-12-27 13:47:08 +01:00
'PhabricatorProjectSubprojectsController' => 'PhabricatorProjectController',
Put subprojects and milestones back into the Project UI Summary: Ref T10010. Restores subprojects and milestones to the UI with a more modern style and more warnings. Test Plan: {F1085207} {F1085208} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D15152
2016-02-01 16:04:19 +01:00
'PhabricatorProjectSubprojectsProfilePanel' => 'PhabricatorProfilePanel',
Finished Project Generation Summary: Progress on T2903 Test Plan: Projects are generating. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5794
2013-04-29 21:17:55 +02:00
'PhabricatorProjectTestDataGenerator' => 'PhabricatorTestDataGenerator',
Move Project transaction storage to modern tables Summary: Ref T4010. Projects have a weird proto-version of ApplicationTransactions which is very similar but not quite the same. Move the storage to a modern format, but keep all the other code for now. Test Plan: Migrated project transactions; edited projects. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4010 Differential Revision: https://secure.phabricator.com/D7370
2013-10-22 22:49:28 +02:00
'PhabricatorProjectTransaction' => 'PhabricatorApplicationTransaction',
Implement "Edit Members" and "Join/Leave" with real ApplicationTransactions Summary: Ref T4379. Projects has been partially converted to ApplicationTransactions, but the rough state of the world is that all the //storage// is modern, but most of the stuff on top isn't yet. Particularly, there's a `PhabricatorProjectEditor` which is //not// a subclass of `PhabricatorApplicationTransactionEditor`, but which fakes its way through writing reasonable data into modern storage. This introduces a real transaction editor, `PhabricatorProjectTransactionEditor`, with the eventual goal of moving all of the old functionality into it and deleting the old class. This diff only moves the membership transaction into new code (it doesn't even move all of it -- when we create a project, we add the author as a member, and that can't move quite yet since there are other transactions at the same time). Test Plan: - Created a new project. - Edited members. - Joined / left project. - This already has a pile of unit test coverage. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4379 Differential Revision: https://secure.phabricator.com/D8167
2014-02-10 23:30:00 +01:00
'PhabricatorProjectTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
Add project history and title strings Summary: Ref T4010. Adds a history page and restores the transaction title strings, which previously sort-of existed in the defunct feed story class. Test Plan: See screenshots. Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T4010 Differential Revision: https://secure.phabricator.com/D7371
2013-10-22 22:49:37 +02:00
'PhabricatorProjectTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Implement PhabricatorProjectInterface for marking that objects can be tagged with projects Summary: Ref T2628. This makes Transactions understand objects that can have project relationships, extract project mentions, and handle watching. Test Plan: See next diff. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2628 Differential Revision: https://secure.phabricator.com/D9340
2014-06-04 02:19:40 +02:00
'PhabricatorProjectUIEventListener' => 'PhabricatorEventListener',
Add a Join / Leave button to Projects Summary: Make it easy to join or leave (well, slightly less easy) a project. Publish join/leave to feed. Fix a couple of membership editor bugs. Test Plan: Joined, left a project. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T681 Differential Revision: https://secure.phabricator.com/D1485
2012-01-25 20:51:20 +01:00
'PhabricatorProjectUpdateController' => 'PhabricatorProjectController',
Modernize Audit search engine Summary: Fixes T9279. Modernizes the SearchEngine and Query classes. User-facing changes: - Added order by commit date, default to order by commit date with newest commits first. - Added explicit "Needs Audit by". - Added new `packages(...)` typeahead function. - Picked up automatic subscribers, projects, and order fields. This changes behavior a little bit: we previously attempted to exclude, e.g., commits which a package you own needs to audit, but which you have resigned from. This is difficult in general and I think it needs a more comprehensive solution. This shouldn't impact users much, anyway. Test Plan: {F767628} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9279 Differential Revision: https://secure.phabricator.com/D14013
2015-08-31 19:17:54 +02:00
'PhabricatorProjectUserFunctionDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Move member/watch actions to "Members/Watchers" page Summary: Ref T10054. This tries to make the members page a bit more consistent and provide hints to users about subproject/milestone membership rules. In particular: - You now join, leave, watch, unwatch, add and remove members, and lock and unlock membership from the members screen. - We now explain the membership rule for the project on this screen. There are currently four rules: - Normal Project: Join/leave normally. - Parent Project: Uses subprojects to determine members. - Milestone: Uses parent project to determine members. - Locked: Membership is locked. - (Future) Imported from LDAP/other external sources: Membership is determined by something else. Test Plan: {F1064878} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15059
2016-01-20 01:27:36 +01:00
'PhabricatorProjectUserListView' => 'AphrontView',
Revamp Projects with new navigation Summary: A refresh of Projects including a new navigations UI. - New Navigation UI. - Auto switch default page if Workboard has been initialized - Move Feed to it's own page - Increase 'tasks' on Project Home to 50 over 10 - Fix various display bugs on Workboards - Remove 'crumbs' from Project portal (unneeded). Test Plan: - clicked a link for a project with no workboard and saw the profile - clicked a link for a project with a workboard and saw the workboard - navigated around the various edit pages, inspecting links and making sure things linked back to the new profile uri {F266460} {F266461} {F266462} {F266463} {F266464} Reviewers: epriestley, btrahan Reviewed By: epriestley, btrahan Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11272
2015-01-12 19:04:01 +01:00
'PhabricatorProjectViewController' => 'PhabricatorProjectController',
Allow projects to be "watched", sort of a super-subscribe Summary: Ref T4967. Adds a "Watch" relationship to projects, which is stronger than member/subscribed. Specifically, when a task is tagged with a project, we'll include all project watchers in the email/notifications. Normally we don't include projects unless they're explicitly CC'd, or have some other active role in the object (like being a reviewer or auditor). This allows you to closely follow a project without needing to write a Herald rule for every project you care about. Test Plan: - Watched/unwatched a project. - Tested the watch/subscribe/member relationships: - Watching implies subscribe. - Joining implies subscribe. - Leaving implies unsubscribe + unwatch. - You can't unsubscribe until you unwatch (slightly better would be unsubscribe implies unwatch, but this is a bit tricky). - Watched a project, then recevied email about a tagged task without otherwise being involved. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4967 Differential Revision: https://secure.phabricator.com/D9185
2014-05-19 21:40:57 +02:00
'PhabricatorProjectWatchController' => 'PhabricatorProjectController',
Move member/watch actions to "Members/Watchers" page Summary: Ref T10054. This tries to make the members page a bit more consistent and provide hints to users about subproject/milestone membership rules. In particular: - You now join, leave, watch, unwatch, add and remove members, and lock and unlock membership from the members screen. - We now explain the membership rule for the project on this screen. There are currently four rules: - Normal Project: Join/leave normally. - Parent Project: Uses subprojects to determine members. - Milestone: Uses parent project to determine members. - Locked: Membership is locked. - (Future) Imported from LDAP/other external sources: Membership is determined by something else. Test Plan: {F1064878} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15059
2016-01-20 01:27:36 +01:00
'PhabricatorProjectWatcherListView' => 'PhabricatorProjectUserListView',
Allow workboard background colors to be configured Summary: Adds a UI for selecting background colors. You can choose "Use Parent", which is the default, and allows you to set a color that all descendants inherit. You can also choose "None", if a parent has a WHACKY BACKGROUND that you refuse to put up with. Test Plan: {F1114588} {F1114589} Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15279
2016-02-16 15:52:32 +01:00
'PhabricatorProjectWorkboardBackgroundColor' => 'Phobject',
Begin modularizing profile panel/link construction Summary: Ref T10054. This has no product impact, but prepares us for customizable side nav on "profiles" (today, projects; probably users some day; and maybe other stuff down the road). Test Plan: Clicked all links on a profile, everything was exactly the same as before. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15007
2016-01-12 19:27:39 +01:00
'PhabricatorProjectWorkboardProfilePanel' => 'PhabricatorProfilePanel',
Introduce "Curtain" views, panels, and extensions Summary: This opens up the new action column to have specialized rendering and behavior. Briefly: - Converted applications (right now, only Paste) render a `CurtainView` to build the column content. - This view uses new extensions to build panels (projects, subscribers, tokens). - The panel extension code and rendering can be changed without breaking old stuff. Minor changes: - Token awards now load their tokens, for consistency/simplicity. - Removed the rest of the "fork of" / "forked from" UI in Paste -- I essentially removed these features a while ago, and no one has complained. Test Plan: UI is a bit rough, but works, and it's going to get changed now anyway: {F1160550} {F1160551} Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15414
2016-03-05 23:45:56 +01:00
'PhabricatorProjectsCurtainExtension' => 'PHUICurtainExtension',
Modularize application extensions to EditEngine Summary: Ref T9132. Currently, EditEngine had some branchy-`instanceof` code like this: ``` if ($object instanceof Whatever) { do_magic(); } if ($object instanceof SomethingElse) { do_other_magic(); } ``` ...where `Whatever` and `SomethingElse` are first-party applications like ProjectsInterface and SubscribersInterface. This kind of code is generally bad because third-parties can't add new stuff, and it suggest something is kind of hacky in its architecture. Ideally, we would eventually get rid of almost all of this. T9789 is a similar discussion of this for the next layer down (`TransactionEditor`) and plans to get rid of branchy-instanceofs there too. Since I'm about to add more stuff here (for Custom Fields), split it out first so I'm not digging us any deeper than I already dug us. Broadly, this allows third-party extensions to add fields to every EditEngine UI if they want, like we do for Policies, Subscribers, Projects and Comments today (and CustomFields soon). Test Plan: {F1007575} - Observed that all fields still appear on the form and seem to work correctly. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14599
2015-11-29 19:05:41 +01:00
'PhabricatorProjectsEditEngineExtension' => 'PhabricatorEditEngineExtension',
Provide formal Users/Projects/Mailable fields for EditEngine Summary: Ref T9132. This allows you to prefill EditEngine forms with stuff like `?subscribers=epriestley`, and we'll figure out what you mean. Test Plan: - Did `/?subscribers=...` with various values (good, bad, mis-capitalized). - Did `/?projects=...` with various values (good, bad, mis-capitalized). - Reviewed documentation. - Reviewed {nav Config > HTTP Parameter Types}. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14404
2015-11-04 19:20:38 +01:00
'PhabricatorProjectsEditField' => 'PhabricatorTokenizerEditField',
Modularize fulltext indexing of Projects, Subscriptions and Custom Fields Summary: Ref T9979. This is going to become `FulltextEngine`, but pave the way for that by pulling extensions out of it. Test Plan: {F1036624} - Used `bin/search index Txxx`, saw projects, subscribers and custom fields rebuild in the index. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14835
2015-12-21 15:31:31 +01:00
'PhabricatorProjectsFulltextEngineExtension' => 'PhabricatorFulltextEngineExtension',
Add more information (colors, members, watchers) to project.search Summary: Fixes T6501. This adds more API information to the newish `project.search` API method. Test Plan: Called `project.search`, used attachments. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6501 Differential Revision: https://secure.phabricator.com/D15105
2016-01-24 16:19:54 +01:00
'PhabricatorProjectsMembersSearchEngineAttachment' => 'PhabricatorSearchEngineAttachment',
Materialize parent project memberships Summary: Ref T10010. Subprojects have the following general membership rule: if you are a member of a subproject ("Engineering > Backend"), you are also a member of the parent project. It would be unreasonably difficult to implement this rule directly in SQL when querying `withMemberPHIDs()`, because we'd have to do an arbitrarily large number of arbitrarily deep joins, or fetch and then requery a lot of data. Instead, introduce "materailized members", which are just a copy of all the effective members of a project. When a subproject has a membership change, we go recompute the effective membership of all the parent projects. Then we can just JOIN to satisfy `withMemberPHIDs()`. Having this process avialable will also be useful in the future, when a project's membership might be defined by some external source. Also make milestones mostly work like we'd expect them to with respect to membership and visibility. Test Plan: - Added and executed unit tests. - Changed project members, verified materialized members populated correctly in the database. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14863
2015-12-23 12:12:20 +01:00
'PhabricatorProjectsMembershipIndexEngineExtension' => 'PhabricatorIndexEngineExtension',
Rename `PhabricatorPolicyRule` subclasses for consistency Summary: Ref T5655. Fixes T6849. This is another take on D11131, which was missing the DB migration and was reverted in rP7c4de0f6be77ddaea593e1f41ae27211ec179a55. Test Plan: Ran `./bin/storage upgrade` and verified that the classes were renamed in the `phabricator_policy.policy` table. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6849, T5655 Differential Revision: https://secure.phabricator.com/D11166
2015-01-03 13:48:19 +01:00
'PhabricatorProjectsPolicyRule' => 'PhabricatorPolicyRule',
Add a "projects" Search attachment for Conduit APIs Summary: Ref T9964. Builds on D14772. Allows callers to request project PHIDs for objects. Test Plan: {F1025468} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14773
2015-12-14 14:41:26 +01:00
'PhabricatorProjectsSearchEngineAttachment' => 'PhabricatorSearchEngineAttachment',
Modularize SearchEngine extensions Summary: Ref T9964. ApplicationSearch currently has a bunch of hard-coded `if ($object instanceof thing)` stuff. Pull that out so it can live in extensions. Test Plan: - Searched by spaces, subscribers, projects. {F1023921} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14764
2015-12-13 13:12:34 +01:00
'PhabricatorProjectsSearchEngineExtension' => 'PhabricatorSearchEngineExtension',
Add more information (colors, members, watchers) to project.search Summary: Fixes T6501. This adds more API information to the newish `project.search` API method. Test Plan: Called `project.search`, used attachments. Reviewers: chad Reviewed By: chad Maniphest Tasks: T6501 Differential Revision: https://secure.phabricator.com/D15105
2016-01-24 16:19:54 +01:00
'PhabricatorProjectsWatchersSearchEngineAttachment' => 'PhabricatorSearchEngineAttachment',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorProtocolAdapter' => 'Phobject',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorPygmentSetupCheck' => 'PhabricatorSetupCheck',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorQuery' => 'Phobject',
Add "Edge Logic" support to PolicyAwareQuery Summary: Ref T4100. Ref T5595. This allows PolicyAwareQuery to write all the logic for AND, OR, NOT, and NULL (i.e., "not in any projects") queries against any edge type. It accepts an edge type and a list of constraints (which are basically just operator-value pairs, like `<NOT, PHID-X-Y>`, meaning the results must not have an edge connecting them to `PHID-X-Y`). This doesn't actually do anything yet; see future diffs. Test Plan: `arc unit --everything` Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4100, T5595 Differential Revision: https://secure.phabricator.com/D12455
2015-04-18 16:53:43 +02:00
'PhabricatorQueryConstraint' => 'Phobject',
Begin formalizing query orders Summary: Ref T7803. Queries currently have a single `getPagingColumn()`, which is oversimplified and insufficient to describe many ordering operations. Frequently, orders must span multiple columns. Move toward an "order vector", which is a list of orderable values like "name, id". These map directly to columns, and are sufficient to actually describe orders. The more modern Query classes (Maniphest, Repository) essentially do this manually anyway. Test Plan: - Added and executed unit tests. - Browsed around, verified the correct ORDER BY clauses were generated. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7803 Differential Revision: https://secure.phabricator.com/D12352
2015-04-11 21:10:35 +02:00
'PhabricatorQueryOrderItem' => 'Phobject',
'PhabricatorQueryOrderTestCase' => 'PhabricatorTestCase',
'PhabricatorQueryOrderVector' => array(
'Phobject',
'Iterator',
),
Modularize Aphront exception handling Summary: Ref T1806. Ref T7173. Depends on D14047. Currently, all exception handling is in this big messy clump in `AphrontDefaultApplicationConfiguration`. Split it out into modular classes. This will let a future change add new classes in the Phacility cluster which intercept particular exceptions we care about and replaces the default, generic responses with more useful, tailored responses. Test Plan: {F777391} - Hit a Conduit error (made a method throw). - Hit an Ajax error (made comment preview throw). - Hit a high security error (tried to edit TOTP). - Hit a rate limiting error (added a bunch of email addresses). - Hit a policy error (tried to look at something with no permission). - Hit an arbitrary exception (made a randomc ontroller throw). Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14049
2015-09-03 19:04:42 +02:00
'PhabricatorRateLimitRequestExceptionHandler' => 'PhabricatorRequestExceptionHandler',
Move Recaptcha config to PHP Summary: Bring these over. Also sort the group list. Test Plan: Viewed config. Reviewers: btrahan, codeblock, chad Reviewed By: chad CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4338
2013-01-03 18:17:38 +01:00
'PhabricatorRecaptchaConfigOptions' => 'PhabricatorApplicationConfigOptions',
Badges v0.1 Summary: Basic plumbing for Badges application. - You can make Badges. - You can look at a list of them. - They can be edited. - They can be assigned to people. - You can revoke them from people. - You can subscribe to them. Test Plan: Make Badges with various options. Give them to people. Take them away from people. Reviewers: lpriestley, epriestley Reviewed By: epriestley Subscribers: tycho.tatitscheff, johnny-bit, epriestley, Korvin Maniphest Tasks: T6526 Differential Revision: https://secure.phabricator.com/D13626
2015-07-22 22:37:20 +02:00
'PhabricatorRecipientHasBadgeEdgeType' => 'PhabricatorEdgeType',
Automatically redirect 404's that wouldn't be 404s if they had a trailing slash to their trailing-slash counterparts.
2011-04-04 19:29:46 +02:00
'PhabricatorRedirectController' => 'PhabricatorController',
Fix conservative CSRF token cycling limit Summary: We currently cycle CSRF tokens every hour and check for the last two valid ones. This means that a form could go stale in as little as an hour, and is certainly stale after two. When a stale form is submitted, you basically get a terrible heisen-state where some of your data might persist if you're lucky but more likely it all just vanishes. The .js file below outlines some more details. This is a pretty terrible UX and we don't need to be as conservative about CSRF validation as we're being. Remedy this problem by: - Accepting the last 6 CSRF tokens instead of the last 1 (i.e., pages are valid for at least 6 hours, and for as long as 7). - Using JS to refresh the CSRF token every 55 minutes (i.e., pages connected to the internet are valid indefinitely). - Showing the user an explicit message about what went wrong when CSRF validation fails so the experience is less bewildering. They should now only be able to submit with a bad CSRF token if: - They load a page, disconnect from the internet for 7 hours, reconnect, and submit the form within 55 minutes; or - They are actually the victim of a CSRF attack. We could eventually fix the first one by tracking reconnects, which might be "free" once the notification server gets built. It will probably never be an issue in practice. Test Plan: - Reduced CSRF cycle frequency to 2 seconds, submitted a form after 15 seconds, got the CSRF exception. - Reduced csrf-refresh cycle frequency to 3 seconds, submitted a form after 15 seconds, got a clean form post. - Added debugging code the the csrf refresh to make sure it was doing sensible things (pulling different tokens, finding all the inputs). Reviewed By: aran Reviewers: tuomaspelkonen, jungejason, aran CC: aran, epriestley Differential Revision: 660
2011-07-13 23:05:18 +02:00
'PhabricatorRefreshCSRFController' => 'PhabricatorAuthController',
New Registration Workflow Summary: Currently, registration and authentication are pretty messy. Two concrete problems: - The `PhabricatorLDAPRegistrationController` and `PhabricatorOAuthDefaultRegistrationController` controllers are giant copy/pastes of one another. This is really bad. - We can't practically implement OpenID because we can't reissue the authentication request. Additionally, the OAuth registration controller can be replaced wholesale by config, which is a huge API surface area and a giant mess. Broadly, the problem right now is that registration does too much: we hand it some set of indirect credentials (like OAuth tokens) and expect it to take those the entire way to a registered user. Instead, break registration into smaller steps: - User authenticates with remote service. - Phabricator pulls information (remote account ID, username, email, real name, profile picture, etc) from the remote service and saves it as `PhabricatorUserCredentials`. - Phabricator hands the `PhabricatorUserCredentials` to the registration form, which is agnostic about where they originate from: it can process LDAP credentials, OAuth credentials, plain old email credentials, HTTP basic auth credentials, etc. This doesn't do anything yet -- there is no way to create credentials objects (and no storage patch), but I wanted to get any initial feedback, especially about the event call for T2394. In particular, I think the implementation would look something like this: $profile = $event->getValue('profile') $username = $profile->getDefaultUsername(); $is_employee = is_this_a_facebook_employee($username); if (!$is_employee) { throw new Exception("You are not employed at Facebook."); } $fbid = get_fbid_for_facebook_username($username); $profile->setDefaultEmail($fbid); $profile->setCanEditUsername(false); $profile->setCanEditEmail(false); $profile->setCanEditRealName(false); $profile->setShouldVerifyEmail(true); Seem reasonable? Test Plan: N/A yet, probably fatals. Reviewers: vrana, btrahan, codeblock, chad Reviewed By: btrahan CC: aran, asherkin, nh, wez Maniphest Tasks: T1536, T2394 Differential Revision: https://secure.phabricator.com/D4647
2013-06-16 19:13:49 +02:00
'PhabricatorRegistrationProfile' => 'Phobject',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorReleephApplication' => 'PhabricatorApplication',
'PhabricatorReleephApplicationConfigOptions' => 'PhabricatorApplicationConfigOptions',
Make a PhabricatorRemarkupControl to de-duplicate code usage around adding a Remarkup reference to a TextAreaControl. Summary: ...also makes Maniphest Task Edit Controller use this when its not appropriate to upsell email. Test Plan: played around with each tool and verified the Remarkup reference was present Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1756 Differential Revision: https://secure.phabricator.com/D3468
2012-09-19 21:27:28 +02:00
'PhabricatorRemarkupControl' => 'AphrontFormTextAreaControl',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhabricatorRemarkupCowsayBlockInterpreter' => 'PhutilRemarkupBlockInterpreter',
'PhabricatorRemarkupCustomBlockRule' => 'PhutilRemarkupBlockRule',
Make remarkup rules runtime-pluggable in a reasonable way Summary: Gets rid of some old Differential-specific nonsense and replaces it with general runtime-pluggable Remarkup rules. Facebook: This removes two options which may be in use. Have any classes being added via config here just subclass the new abstract bases instead. This should take 5 seconds to fix. You can adjust order by overriding `getPriority()` on the rules, if necessary. Test Plan: See comments. Reviewers: btrahan Reviewed By: btrahan CC: FacebookPOC, andrewjcg, aran Differential Revision: https://secure.phabricator.com/D7393
2013-10-25 02:26:07 +02:00
'PhabricatorRemarkupCustomInlineRule' => 'PhutilRemarkupRule',
Allow form configurations to retitle and reorder forms and add preambles Summary: Ref T9132. This just makes edited forms do //something//, albeit not anything very useful yet. You can now edit a form and: - Retitle it; - add a preamble (instructions on top of the form); and - reorder the form's fields. Test Plan: {F974632} {F974633} {F974634} {F974635} {F974636} Reviewers: chad Reviewed By: chad Subscribers: hach-que Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14503
2015-11-17 18:33:06 +01:00
'PhabricatorRemarkupEditField' => 'PhabricatorEditField',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhabricatorRemarkupFigletBlockInterpreter' => 'PhutilRemarkupBlockInterpreter',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorRemarkupUIExample' => 'PhabricatorUIExample',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorRepositoriesSetupCheck' => 'PhabricatorSetupCheck',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorRepository' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorRepositoryDAO',
Transactions - deploy buildTransactionTimeline to remaining applications Summary: Ref T4712. Specifically... - Differential - needed getApplicationTransactionViewObject() implemented - Audit - needed getApplicationTransactionViewObject() implemented - Repository - one object needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) - Ponder - BONUS BUG FIX - leaving a comment on an answer had a bad redirect URI - both PonderQuestion and PonderAnswer needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on both "history" controllers - left a "TODO" on buildAnswers on the question view controller, which is non-standard and should be re-written eventually - Phortune - BONUS BUG FIX - fix new user "createNewAccount" code to not fatal - PhortuneAccount, PhortuneMerchant, and PhortuneCart needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on Account view, merchant view, and cart view controller - Fund - Legalpad - Nuance - NuanceSource needed PhabricatorApplicationTransactionInterface implemented - Releeph (this product is kind of a mess...) - HACKQUEST - had to manually create an arcanist project to even be able to make a "product" and get started...! - BONUS BUG FIX - make sure to "setName" on product edit - ReleephProject (should be ReleepProduct...?), ReleephBranch, and ReleepRequest needed PhabricatorApplicationTransactionInterface implemented - Harbormaster - HarbormasterBuildable, HarbormasterBuild, HarbormasterBuildPlan, and HarbormasterBuildStep all needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) all over the place Test Plan: foreach application, viewed the timeline(s) and made sure they still rendered Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10925
2014-12-04 00:35:47 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
'PhabricatorFlaggableInterface',
'PhabricatorMarkupInterface',
'PhabricatorDestructibleInterface',
'PhabricatorProjectInterface',
Support Spaces in Diffusion Summary: Ref T8493. Diffusion is probably the strongest upstream use case we have for Spaces right now, so I want to get us on it to kick the tires a bit. Small amount of hackiness around the multi-page form thing but it shouldn't create any problems. Test Plan: - Created a new repo. - Edited a repo. - Tried invalid edits, saw value preserved. - Viewed edit full detail screen, saw space info. - Viewed repo detail view, saw space. - Viewed repo list view, saw space. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8493 Differential Revision: https://secure.phabricator.com/D13414
2015-06-24 19:56:46 +02:00
'PhabricatorSpacesInterface',
Trivially implement RepositoryEditEngine and API methods Summary: Ref T10748. Ref T10337. This technically implements this stuff, but it does not do anything useful yet. This skips all the hard stuff. Test Plan: - Technically used `diffusion.repository.search` to get repository information. - Technically used `diffusion.repository.edit` to change a repository name. - Used `editpro/` to edit a repository name. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10337, T10748 Differential Revision: https://secure.phabricator.com/D15736
2016-04-17 01:45:19 +02:00
'PhabricatorConduitResultInterface',
Make Repositories partially policy-aware Summary: Small step toward repository hosting. No user-visible changes. Test Plan: Looked at repositories in Diffusion. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D4227
2012-12-19 20:07:06 +01:00
),
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorRepositoryAuditRequest' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorRepositoryDAO',
'PhabricatorPolicyInterface',
Audit - move over to application search Summary: ...also kills off "PhabricatorAuditCommitQuery" and "PhabricatorAuditQuery", by moving the work to "DiffusionCommitQuery". Generally cleans up some code around the joint on this too. Also provides policies for audit requests, which is basically the policy for the underlying commit. Fixes T4715. (For the TODO I added about files, I just grabbed T4713.) Test Plan: Audit: verified the three default views all showed the correct things, including highligthing. did some custom queries and got the correct results. Diffusion: verified "blame view" still worked. verified paths were highlighted for packages i owned. Home: verified audit boxes showed up with proper commits w/ audits bin/audit: played around with it via --dry-run and got the right audits back Reviewers: epriestley Reviewed By: epriestley Subscribers: chad, epriestley, Korvin Maniphest Tasks: T4715 Differential Revision: https://secure.phabricator.com/D8805
2014-04-27 18:43:05 +02:00
),
Allow saving lint errors to database Summary: This saves lint errors to the path change of current commit. It requires pushed revision. It doesn't save difference from previous commit mentioned in T2038#comment-4 - I don't plan doing it after all, everything would be much more complicated and the amount of data saved with this approach isn't that bad. Test Plan: Applied patch, ran script, verified DB. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2038 Differential Revision: https://secure.phabricator.com/D3899
2012-11-06 08:09:36 +01:00
'PhabricatorRepositoryBranch' => 'PhabricatorRepositoryDAO',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorRepositoryCommit' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorRepositoryDAO',
'PhabricatorPolicyInterface',
'PhabricatorFlaggableInterface',
Add workboard link to emails about workboard changes Summary: Fixes T4652, adding workboard link to emails Test Plan: Move a task in a workboard from one column to another. Email notification should contain "WORKBOARD" section with link to that workboard Reviewers: chad, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T4652 Differential Revision: https://secure.phabricator.com/D10889
2014-11-21 02:25:02 +01:00
'PhabricatorProjectInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorTokenReceiverInterface',
Move Audit to proper Subscriptions Summary: Ref T4896. Currently, subscriptions to commits are stored as auditors with a special "CC" type. Instead, use normal subscriptions storage, reads and writes. Test Plan: - Ran migration and verified data still looked good. - Viewed commits in UI and saw "subscribers". - Saw "Automatically Subscribed", clicked Subscribe/Unsubscribe on a non-authored commit, saw subscriptions update. - Pushed a commit through Herald rules and saw them trigger subscriptions and auditors. - Used "Add CCs". - Added CCs with mentions. Reviewers: btrahan, joshuaspence Reviewed By: btrahan, joshuaspence Subscribers: epriestley Maniphest Tasks: T4896 Differential Revision: https://secure.phabricator.com/D10103
2014-08-02 09:06:13 +02:00
'PhabricatorSubscribableInterface',
Transactions - add infrastructure for "mentions" Summary: Fixes T4036. Now if you say something on diff X like "This reminds me of Tx and Dy and commitHashFoo and Px." each of those objects gets a little visible transaction that the mention occurred. No feed, email, or notifications. Test Plan: made a comment like above and verified transactions. also submitted a diff that "Fixes Tx" and Tx did not get the transaction as expected. Reviewers: epriestley Reviewed By: epriestley Subscribers: joshuaspence, epriestley, Korvin Maniphest Tasks: T4036 Differential Revision: https://secure.phabricator.com/D10451
2014-09-09 23:21:13 +02:00
'PhabricatorMentionableInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'HarbormasterBuildableInterface',
Add a "Build with CircleCI" build step Summary: Ref T9456. Some rough edges and we can't complete the build yet since I haven't written a webhook, but this mostly seems to be working. Test Plan: - Ran this build on some stuff. - Ran a normal HTTP step build to make sure I didn't break that. {F880301} {F880302} {F880303} Reviewers: chad Reviewed By: chad Subscribers: JustinTulloss, joshma Maniphest Tasks: T9456 Differential Revision: https://secure.phabricator.com/D14286
2015-10-15 05:01:22 +02:00
'HarbormasterCircleCIBuildableInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorCustomFieldInterface',
Use standard infrastructure to attach commits to other objects Summary: Ref T4896. Now that we have a transaction editor, we can delete a giant block of hacks. I believe this also resolves the commit/task attachment issues @joshuaspence and @mbishopim3 mentioned. Test Plan: Attached and detached commits and tasks. Reviewers: btrahan, joshuaspence, mbishopim3 Reviewed By: mbishopim3 Subscribers: mbishopim3, epriestley, joshuaspence Maniphest Tasks: T4896 Differential Revision: https://secure.phabricator.com/D10138
2014-08-04 21:03:58 +02:00
'PhabricatorApplicationTransactionInterface',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorFulltextInterface',
Prepare Diffusion for hovercards Summary: Move Diffusion to be hovercard-ready, and expand our ability to resolve commit references. - Link unqualified hashes of 7 characters or more which match a commit. - Link qualified hashes of 5 characters or more which match a commit. - Support `{...}` syntax. Test Plan: {F33896} Reviewers: chad, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5121
2013-02-27 17:04:54 +01:00
),
Increase parseriness of some parsery things. Summary: None of these are parsnips. Test Plan: Reviewers: CC:
2011-03-11 18:34:22 +01:00
'PhabricatorRepositoryCommitChangeParserWorker' => 'PhabricatorRepositoryCommitParserWorker',
'PhabricatorRepositoryCommitData' => 'PhabricatorRepositoryDAO',
HeraldCommitAdapter and some related junk.
2011-04-04 08:23:36 +02:00
'PhabricatorRepositoryCommitHeraldWorker' => 'PhabricatorRepositoryCommitParserWorker',
Increase parseriness of some parsery things. Summary: None of these are parsnips. Test Plan: Reviewers: CC:
2011-03-11 18:34:22 +01:00
'PhabricatorRepositoryCommitMessageParserWorker' => 'PhabricatorRepositoryCommitParserWorker',
Add Related Commits for Owners Summary: For each commit, find the affected packages, and provide a way to search by package. Test Plan: create commits that touch and don't touch two packages, and verify that they display correctly in all the UI pages. Reviewers: epriestley, blair, nh, tuomaspelkonen Reviewed By: epriestley CC: benmathews, aran, epriestley, btrahan, jungejason, mpodobnik, prithvi Maniphest Tasks: T83 Differential Revision: 1208
2011-12-14 09:53:25 +01:00
'PhabricatorRepositoryCommitOwnersWorker' => 'PhabricatorRepositoryCommitParserWorker',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorRepositoryCommitPHIDType' => 'PhabricatorPHIDType',
Increase parseriness of some parsery things. Summary: None of these are parsnips. Test Plan: Reviewers: CC:
2011-03-11 18:34:22 +01:00
'PhabricatorRepositoryCommitParserWorker' => 'PhabricatorWorker',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorRepositoryCommitRef' => 'Phobject',
Repository option. Test Plan: Looked at the option. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4468
2013-01-16 18:35:47 +01:00
'PhabricatorRepositoryConfigOptions' => 'PhabricatorApplicationConfigOptions',
Rough cut of Repositories and GitHub post-receive hooks. Summary: Test Plan: Reviewers: CC:
2011-02-13 03:26:15 +01:00
'PhabricatorRepositoryDAO' => 'PhabricatorLiskDAO',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorRepositoryDiscoveryEngine' => 'PhabricatorRepositoryEngine',
Begin transacitonalizing repository edits and provide a more sensible edit interface Summary: Ref T2231, T603. Plan of attack here is pretty much: - Built out a new (currently not linked in the UI) edit interface in Diffusion which is transaction-based and has a sensible layout. - Build out a new create interface based on PagedForm which dumps into the new edit interface. - Throw the old stuff away. - Everyone lives happily ever after. Test Plan: {F44163} {F44164} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D6029
2013-05-24 21:37:42 +02:00
'PhabricatorRepositoryEditor' => 'PhabricatorApplicationTransactionEditor',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorRepositoryEngine' => 'Phobject',
Increase parseriness of some parsery things. Summary: None of these are parsnips. Test Plan: Reviewers: CC:
2011-03-11 18:34:22 +01:00
'PhabricatorRepositoryGitCommitChangeParserWorker' => 'PhabricatorRepositoryCommitChangeParserWorker',
'PhabricatorRepositoryGitCommitMessageParserWorker' => 'PhabricatorRepositoryCommitMessageParserWorker',
Implement a Git LFS link table and basic batch API Summary: Ref T7789. This implements: - A new table to store the `<objectHash, filePHID>` relationship between Git LFS files and Phabricator file objects. - A basic response to `batch` commands, which return actions for a list of files. Test Plan: Ran `git lfs push origin master`, got a little further than previously: ``` epriestley@orbital ~/dev/scratch/poemslocal $ git lfs push origin master Git LFS: (2 of 1 files) 174.24 KB / 87.12 KB Git LFS operation "upload/b7e0aeb82a03d627c6aa5fc1bbfd454b6789d9d9affc8607d40168fa18cf6c69" is not supported by this server. Git LFS operation "upload/b7e0aeb82a03d627c6aa5fc1bbfd454b6789d9d9affc8607d40168fa18cf6c69" is not supported by this server. ``` With `GIT_TRACE=1`, this shows the batch part of the API going through. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7789 Differential Revision: https://secure.phabricator.com/D15489
2016-03-17 20:49:18 +01:00
'PhabricatorRepositoryGitLFSRef' => array(
'PhabricatorRepositoryDAO',
'PhabricatorPolicyInterface',
Implement DestructibleInterface on GitLFS refs Summary: Ref T7789. Make sure these get cleaned up when a repository is destroyed. Test Plan: - Created a new repository. - Pushed some LFS data to it. - Used `bin/remove destroy` to nuke it. - Verified the LFS stuff was cleaned up and the underlying files were destroyed (`SELECT * FROM repository_gitlfsref`, etc). Reviewers: chad Reviewed By: chad Maniphest Tasks: T7789 Differential Revision: https://secure.phabricator.com/D15493
2016-03-18 15:16:24 +01:00
'PhabricatorDestructibleInterface',
Implement a Git LFS link table and basic batch API Summary: Ref T7789. This implements: - A new table to store the `<objectHash, filePHID>` relationship between Git LFS files and Phabricator file objects. - A basic response to `batch` commands, which return actions for a list of files. Test Plan: Ran `git lfs push origin master`, got a little further than previously: ``` epriestley@orbital ~/dev/scratch/poemslocal $ git lfs push origin master Git LFS: (2 of 1 files) 174.24 KB / 87.12 KB Git LFS operation "upload/b7e0aeb82a03d627c6aa5fc1bbfd454b6789d9d9affc8607d40168fa18cf6c69" is not supported by this server. Git LFS operation "upload/b7e0aeb82a03d627c6aa5fc1bbfd454b6789d9d9affc8607d40168fa18cf6c69" is not supported by this server. ``` With `GIT_TRACE=1`, this shows the batch part of the API going through. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7789 Differential Revision: https://secure.phabricator.com/D15489
2016-03-17 20:49:18 +01:00
),
'PhabricatorRepositoryGitLFSRefQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorRepositoryGraphCache' => 'Phobject',
Move Git discovery into DiscoveryEngine Summary: Ref T4327. Consolidates and simplifies infrastructure: - Moves Git discovery into DiscoveryEngine. - Collapses a bunch of the Git and Mercurial code related to stream discovery. - Removes all cach code from PullLocal daemon (it's no longer called). - Adds basic unit tests for Git and Mercurial discovery. Various cleanup: - Makes GitStream and MercurialStream extend a common base. - Improves performance of MercurialStream in some cases, by requiring fewer commits be output and parsed. - Makes mirroring exceptions easier to debug. - Fixes discovery of Mercurial repositories with multiple branch heads. - Adds some missing `pht()`. Test Plan: I tested this fairly throughly because I think this phase is complete: - Made new repositories in multiple VCSes and did full imports. - Particularly, I reimported Arcanist to make sure that TODO was resolved. I think it was related to the toposort stuff. - Pushed commits to multiple VCSes. - Pushed commits to a non-close branch, then pushed a merge commit. Observed commits import initially as non-close, then get flagged for close. - Started full daemons and resolved various minor issues that showed up in the daemon log until everything ran cleanly. - Basically spent about 30 minutes banging on this in every way I could think of to try to break it. I found and fixed some minor stuff, but it seems solid. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7987
2014-01-17 00:31:52 +01:00
'PhabricatorRepositoryGraphStream' => 'Phobject',
Implement a chunked, APC-backed graph cache Summary: Ref T2683. This is a refinement and simplification of D5257. In particular: - D5257 only cached the commit chain, not path changes. This meant that we had to go issue an awkward query (which was slow on Facebook's install) periodically while reading the cache. This was reasonable locally but killed performance at FB scale. Instead, we can include path information in the cache. It is very rare that this is large except in Subversion, and we do not need to use this cache in Subversion. In other VCSes, the scale of this data is quite small (a handful of bytes per commit on average). - D5257 required a large, slow offline computation step. This relies on D9044 to populate parent data so we can build the cache online at will, and let it expire with normal LRU/LFU/whatever semantics. We need this parent data for other reasons anyway. - D5257 separated graph chunks per-repository. This change assumes we'll be able to pull stuff from APC most of the time and that the cost of switching chunks is not very large, so we can just build one chunk cache across all repositories. This allows the cache to be simpler. - D5257 needed an offline cache, and used a unique cache structure. Since this one can be built online it can mostly use normal cache code. - This also supports online appends to the cache. - Finally, this has a timeout to guarantee a ceiling on the worst case: the worst case is something like a query for a file that has never existed, in a repository which receives exactly 1 commit every time other repositories receive 4095 commits, on a cold cache. If we hit cases like this we can bail after warming the cache up a bit and fall back to asking the VCS for an answer. This cache isn't perfect, but I believe it will give us substantial gains in the average case. It can often satisfy "average-looking" queries in 4-8ms, and pathological-ish queries in 20ms on my machine; `hg` usually can't even start up in less than 100ms. The major thing that's attractive about this approach is that it does not require anything external or complicated, and will "just work", even producing reasonble improvements for users without APC. In followups, I'll modify queries to use this cache and see if it holds up in more realistic workloads. Test Plan: - Used `bin/repository cache` to examine the behavior of this cache. - Did some profiling/testing from the web UI using `debug.php`. - This //appears// to provide a reasonable fast way to issue this query very quickly in the average case, without the various issues that plagued D5257. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley, jhurwitz Maniphest Tasks: T2683 Differential Revision: https://secure.phabricator.com/D9045
2014-05-10 19:10:13 +02:00
'PhabricatorRepositoryManagementCacheWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Add `bin/repository clusterize` and document setup and migration for clusters Summary: Ref T4292. This provides at least some sort of hint about how to set up cluster repositories. Test Plan: - Read documentation. - Ran `bin/repository clusterize` to add + remove clusters. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4292 Differential Revision: https://secure.phabricator.com/D15798
2016-04-25 16:45:10 +02:00
'PhabricatorRepositoryManagementClusterizeWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Introduce "bin/repository" for repository management Summary: Nothing new or exciting here yet, just moving the random scripts/repositories/ things to bin/repository. Also add `repository list`. (Console stuff comes from D2841.) Test Plan: Ran `repository list`, `repository pull`, `repository discover`, `repository discover --verbose`, `repository help`. Reviewers: jungejason, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2849
2012-06-25 21:35:37 +02:00
'PhabricatorRepositoryManagementDiscoverWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Add an administrative `bin/repository importing` command to list importing commits Summary: Ref T4068. Adds a command to list all commits in an "importing" status. This will allow users to use `reparse.php` to diagnose and repair issues. Test Plan: - Ran `bin/repository importing P`, etc. - Used `reparse.php` to reparse some commit stages and saw status update correctly. - Ran on a repo with no importing commits. - Ran with `... --simple | xargs`, which saves us having to put an `awk` or something in there for users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4068 Differential Revision: https://secure.phabricator.com/D7515
2013-11-06 20:26:41 +01:00
'PhabricatorRepositoryManagementImportingWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Add `repository list-paths` and `repository move-paths` Summary: Ref T7149. These formalize the local path adjustment step for cluster imports, rather than relying on an ad-hoc script. Test Plan: Used `list-paths` and `move-paths` to list and move repositories. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D13621
2015-07-16 23:11:33 +02:00
'PhabricatorRepositoryManagementListPathsWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Introduce "bin/repository" for repository management Summary: Nothing new or exciting here yet, just moving the random scripts/repositories/ things to bin/repository. Also add `repository list`. (Console stuff comes from D2841.) Test Plan: Ran `repository list`, `repository pull`, `repository discover`, `repository discover --verbose`, `repository help`. Reviewers: jungejason, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2849
2012-06-25 21:35:37 +02:00
'PhabricatorRepositoryManagementListWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Provide a standalone query for resolution of commit author/committer into Phabricator users Summary: Ref T4195. To implement the "Author" and "Committer" rules, I need to resolve author/committer strings into Phabricator users. The code to do this is currently buried in the daemons. Extract it into a standalone query. I also added `bin/repository lookup-users <commit>` to test this query, both to improve confidence I'm getting this right and to provide a diagnostic command for users, since there's occasionally some confusion over how author/committer strings resolve into valid users. Test Plan: I tested this using `bin/repository lookup-users` and `reparse.php --message` on Git, Mercurial and SVN commits. Here's the `lookup-users` output: >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rINIS3 Examining commit rINIS3... Raw author string: epriestley Phabricator user: epriestley (Evan Priestley ) Raw committer string: null >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rPOEMS165b6c54f487c8 Examining commit rPOEMS165b6c54f487... Raw author string: epriestley <git@epriestley.com> Phabricator user: epriestley (Evan Priestley ) Raw committer string: epriestley <git@epriestley.com> Phabricator user: epriestley (Evan Priestley ) >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rINIH6d24c1aee7741e Examining commit rINIH6d24c1aee774... Raw author string: epriestley <hg@yghe.net> Phabricator user: epriestley (Evan Priestley ) Raw committer string: null >>> orbital ~/devtools/phabricator $ The `reparse.php` output was similar, and all VCSes resolved authors correctly. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1731, T4195 Differential Revision: https://secure.phabricator.com/D7801
2013-12-19 20:05:17 +01:00
'PhabricatorRepositoryManagementLookupUsersWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Add an administrative `bin/repository mark-imported` command Summary: Ref T4068. In some cases like that one, I anticipate a repository not fully importing when a handful of random commits are broken. In the long run we should just deal with that properly, but in the meantime provide an administrative escape hatch so you can mark the repository as imported and get it running normally. The major reason to do this is that Herald, Feed, Harbormaster, etc., won't activate until a repository is "imported". Test Plan: - Tried to mark an imported repository as imported, got an "already imported" message. - Same for not-imported. - Marked a repository not-imported. - Marked a repository imported. - Marked a repository not-imported, then waited for the daemons to mark it imported again automatically. Reviewers: btrahan Reviewed By: btrahan CC: aran, kbrownlees Maniphest Tasks: T4068 Differential Revision: https://secure.phabricator.com/D7514
2013-11-06 20:26:24 +01:00
'PhabricatorRepositoryManagementMarkImportedWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Separate repository mirroring into an Engine and provide `bin/repository mirror` Summary: Ref T4338. Currently, there's no diagnostic command to execute mirroring (so I can't give users an easy command to run), and it's roughly the last piece of real logic left in the PullLocal daemon. Separate mirroring out, and provide `bin/repository mirror`. Test Plan: - Ran `bin/repository mirror` to mirror a repository. - Ran PullLocalDaemon and verified it also continued mirroring normally. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4338 Differential Revision: https://secure.phabricator.com/D8066
2014-01-25 23:01:58 +01:00
'PhabricatorRepositoryManagementMirrorWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Add `repository list-paths` and `repository move-paths` Summary: Ref T7149. These formalize the local path adjustment step for cluster imports, rather than relying on an ad-hoc script. Test Plan: Used `list-paths` and `move-paths` to list and move repositories. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D13621
2015-07-16 23:11:33 +02:00
'PhabricatorRepositoryManagementMovePathsWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Record parent relationships when discovering commits Summary: Ref T4455. This adds a `repository_parents` table which stores `<childCommitID, parentCommitID>` relationships. For new commits, it is populated when commits are discovered. For older commits, there's a `bin/repository parents` script to rebuild the data. Right now, there's no UI suggestion that you should run the script. I haven't come up with a super clean way to do this, and this table will only improve performance for now, so it's not important that we get everyone to run the script right away. I'm just leaving it for the moment, and we can figure out how to tell admins to run it later. The ultimate goal is to solve T2683, but solving T4455 gets us some stuff anyway (for example, we can serve `diffusion.commitparentsquery` faster out of this cache). Test Plan: - Used `bin/repository discover` to discover new commits in Git, SVN and Mercurial repositories. - Used `bin/repository parents` to rebuild Git and Mercurial repositories (SVN repos just exit with a message). - Verified that the table appears to be sensible. Reviewers: btrahan Reviewed By: btrahan Subscribers: jhurwitz, epriestley Maniphest Tasks: T4455 Differential Revision: https://secure.phabricator.com/D9044
2014-05-10 21:41:18 +02:00
'PhabricatorRepositoryManagementParentsWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Introduce "bin/repository" for repository management Summary: Nothing new or exciting here yet, just moving the random scripts/repositories/ things to bin/repository. Also add `repository list`. (Console stuff comes from D2841.) Test Plan: Ran `repository list`, `repository pull`, `repository discover`, `repository discover --verbose`, `repository help`. Reviewers: jungejason, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2849
2012-06-25 21:35:37 +02:00
'PhabricatorRepositoryManagementPullWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Introduce ref cursors for repository parsing Summary: Ref T4327. I want to make change parsing testable; one thing which is blocking this is that the Git discovery process is still part of `PullLocal` daemon instead of being part of `DiscoveryEngine`. The unit test stuff which I want to use for change parsing relies on `DiscoveryEngine` to discover repositories during unit tests. The major reason git discovery isn't part of `DiscoveryEngine` is that it relies on the messy "autoclose" logic, which we never implemented for Mercurial. Generally, I don't like how autoclose was implemented: it's complicated and gross and too hard to figure out and extend. Instead, I want to do something more similar to what we do for pushes, which is cleaner overall. Basically this means remembering the old branch heads from the last time we parsed a repository, and figuring out what's new by comparing the old and new branch heads. This should give us several advantages: - It should be simpler to understand than the autoclose stuff, which is pretty mind-numbing, at least for me. - It will let us satisfy branch and tag queries cheaply (from the database) instead of having to go to the repository. We could also satisfy some ref-resolve queries from the database. - It should be easier to extend to Mercurial. This implements the basics -- pretty much a table to store the cursors, which we update only for Git for now. Test Plan: - Ran migration. - Ran `bin/repository discover X --trace --verbose` on various repositories with branches and tags, before and after modifying pushes. - Pushed commits to a git repo. - Looked at database tables. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7982
2014-01-16 21:05:30 +01:00
'PhabricatorRepositoryManagementRefsWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Repositories - Move scripts/repository/reparse.php to bin/repository reparse Summary: Fixes T5966. Accomplishes a few things - see title - adds a force-autoclose flag and the plumbing for it - removes references to some HarborMaster thing that used to key off commits and seems long dead, but forgotten :/ Test Plan: ran a few commands. These first three had great success: `./repository reparse --all FIRSTREPO --message --change --herald --owners` `./repository reparse --all FIRSTREPO --message --change --herald --owners --min-date yesterday` `./repository reparse --all FIRSTREPO --message --change --herald --owners --min-date yesterday --force-autoclose` ...and these next two showed me some errors as expected: `./repository reparse --all FIRSTREPO --message --change --herald --owners --min-date garbagedata` `./repository reparse --all GARBAGEREPO --message --change --herald --owners` Also, made a diff in a repository with autoclose disabled and commited the diff. Later, reparse the diff with force-autoclose. Verified the diff closed and that the reason "why" had the proper message text. Reviewers: epriestley Reviewed By: epriestley Subscribers: joshuaspence, epriestley, Korvin Maniphest Tasks: T5966 Differential Revision: https://secure.phabricator.com/D10492
2015-01-06 20:42:15 +01:00
'PhabricatorRepositoryManagementReparseWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Implement `bin/repository thaw` for unfreezing cluster repositories Summary: Ref T10751. Add support tooling for manually prying your way out of trouble if disaster strikes. Refine documentation, try to refer to devices as "devices" more consistently instead of sometimes calling them "nodes". Test Plan: Promoted and demoted repository devices with `bin/repository thaw`. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10751 Differential Revision: https://secure.phabricator.com/D15768
2016-04-20 15:54:53 +02:00
'PhabricatorRepositoryManagementThawWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Separate repository updates from the pull daemon Summary: Ref T4605. Currently, the PullLocal daemon is responsible for two relatively distinct things: - scheduling repository updates; and - actually updating repositories. Move the "actually updating" part into a new `bin/repository update` command, which basically runs the pull, discover, refs and mirror commands. This will let the parent process focus on scheduling in a more understandable way and update multiple repositories at once. It also makes it easier to debug and understand update behavior since the non-scheduling pipeline can be run separately. Test Plan: - Ran `update --trace` on SVN, Mercurial and Git repos. - Ran PullLocal daemon for a while without issues. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4605 Differential Revision: https://secure.phabricator.com/D8780
2014-04-16 22:00:29 +02:00
'PhabricatorRepositoryManagementUpdateWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorRepositoryManagementWorkflow' => 'PhabricatorManagementWorkflow',
Basic support for Mercurial in Diffusion Summary: Change import script plus almost all the view stuff. Still some rough edges but this seems to mostly work. Blame is currently unsupported but I think everything else works properly. Test Plan: Imported the hg repository itself. It doesn't immediately seem completely broken. Here are some screens: https://secure.phabricator.com/file/view/PHID-FILE-1438b71cc7c4a2eb4569/ https://secure.phabricator.com/file/view/PHID-FILE-3cec4f72f39e7de2d041/ https://secure.phabricator.com/file/view/PHID-FILE-2ea4883f160e8e5098f9/ https://secure.phabricator.com/file/view/PHID-FILE-35f751a36ebf65399ade/ All the parsers were able to churn through it without errors. Ran the new "reparse.php" script in various one-commit and repository modes. Browsed/imported some git repos for good measure. NOTE: The hg repository is only 15,000 commits and around 1,000 files. Performance is okay but hg doesn't provide performant, native APIs to get some data efficiently so we have to do some dumb stuff. If some of these interfaces are cripplingly slow or whatever, let me know and we can start bundling some Mercurial extensions with Arcanist. Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran Reviewed By: Makinde CC: aran, Makinde, epriestley Differential Revision: 960
2011-09-26 20:07:38 +02:00
'PhabricatorRepositoryMercurialCommitChangeParserWorker' => 'PhabricatorRepositoryCommitChangeParserWorker',
Add a Mercurial message parser Summary: See D943, this is the second parse stage. This will mark Differential revisions as "Committed" among other things. Almost all the logic here is shared between VCSes so the implementation itself is straightforward. Test Plan: Parsed all messages for the official Mercurial repository. Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran Reviewed By: Makinde CC: aran, Makinde Differential Revision: 944
2011-09-16 18:37:15 +02:00
'PhabricatorRepositoryMercurialCommitMessageParserWorker' => 'PhabricatorRepositoryCommitMessageParserWorker',
Cut mirroring over to new URIs Summary: Ref T10748. This migrates and swaps mirroring to `PhabricatorRepositoryURI`, obsoleting `PhabricatorRepositoryMirror`. This prevents you from editing, adding or disabling mirrors unless you know a secret URI (until the UI cuts over fully), but existing mirroring is not affected. Test Plan: - Added a mirroring URI to an old repository. - Verified it worked with `bin/repository mirror`. - Migrated forward. - Verified it still worked with `bin/repository mirror`. - Wow, mirroring: https://github.com/epriestley/locktopia-mirror Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15841
2016-05-03 22:40:13 +02:00
'PhabricatorRepositoryMirror' => 'PhabricatorRepositoryDAO',
Separate repository mirroring into an Engine and provide `bin/repository mirror` Summary: Ref T4338. Currently, there's no diagnostic command to execute mirroring (so I can't give users an easy command to run), and it's roughly the last piece of real logic left in the PullLocal daemon. Separate mirroring out, and provide `bin/repository mirror`. Test Plan: - Ran `bin/repository mirror` to mirror a repository. - Ran PullLocalDaemon and verified it also continued mirroring normally. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4338 Differential Revision: https://secure.phabricator.com/D8066
2014-01-25 23:01:58 +01:00
'PhabricatorRepositoryMirrorEngine' => 'PhabricatorRepositoryEngine',
Begin making change parsers testable Summary: Ref T4327. There are a bunch of other probably-related tasks too, some linked there. We have some rare/unusual bugs in the change parsers, mostly in Subversion, but it's terrifying to touch them because they're complicated and fragile and have no test coverage. To fix this stuff, I want to make them more testable. In particular, they basically end with this big INSERT right now. Instead, I'm going to make them return objects representing the data to be inserted, then have the common infrastructure do the insert. This gives us two benefits: - Reduced code duplication on the insert; - we can stop before the insert and have unit tests examine the objects. This swaps the Git parser over, but doesn't swap the hg/svn parsers yet. I'll do those separately, the SVN one looks a bit tricky. Test Plan: - Used `scripts/repository/reparse.php` to reparse a Git commit, with `--trace`. Verified it looked the same as before and the SQL that was executed seemed reasonable. - Did the same for `hg` / `svn` commits, to make sure I didn't derp anything. These aren't expected to do anything differently. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7980
2014-01-20 22:12:44 +01:00
'PhabricatorRepositoryParsedChange' => 'Phobject',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorRepositoryPullEngine' => 'PhabricatorRepositoryEngine',
Add a basic pull event log for debugging repository cloning Summary: Ref T10228. This is currently quite limited: - No UI. - No SSH support. My primary goal is to debug the issue in T10228. In the long run we can expand this to be a bit fancier. Test Plan: Made various valid and invalid clones, got sucess responses and not-so-successful responses, viewed the log table for general corresponding messages and broad sanity. Ran GC via `bin/phd debug trigger`, no issues. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10228 Differential Revision: https://secure.phabricator.com/D15127
2016-01-28 14:21:38 +01:00
'PhabricatorRepositoryPullEvent' => array(
'PhabricatorRepositoryDAO',
'PhabricatorPolicyInterface',
),
'PhabricatorRepositoryPullEventPHIDType' => 'PhabricatorPHIDType',
'PhabricatorRepositoryPullEventQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Run one daemon to pull all working copies, not one daemon per working copy Summary: Allow the pull daemon to take a list of repositories. By default, pull all repositories. Make some effort to respect pull frequencies, although we'll necessarily suffer a bit if running with only one process. NOTE: We still launch one discovery daemon per working copy, so this only cuts the daemon count in half. Test Plan: - Ran `phd debug pulllocal`, verified behavior. - Ran `pull.php P MTEST SVNTEST --trace`, verified it pulled the repos and ran the right commands. - Ran `phd repository-launch-master`, verified the right daemons launched, checked daemon console. - Ran `phd repository-launch-readonly`, verified the right daemon launched, checked daemon console. Reviewers: btrahan, csilvers, davidreuss Reviewed By: csilvers CC: aran Differential Revision: https://secure.phabricator.com/D2418
2012-05-08 00:01:10 +02:00
'PhabricatorRepositoryPullLocalDaemon' => 'PhabricatorDaemon',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorRepositoryPushEvent' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorRepositoryDAO',
'PhabricatorPolicyInterface',
Provide a real object ("PhabricatorRepositoryPushEvent") to represent an entire push transaction Summary: Ref T4677. Currently, we record individual actions in a push as PhabricatorRepositoryPushLogs, but tie them together only loosely with a `transactionKey`. Provide a real PushEvent object, and move some of the denormalized fields to it. This primarily just gives us more robust infrastructure for building, e.g., email about pushes, for T4677, since we can act on real PHIDs rather than passing awkward identifiers around. Test Plan: - Performed migration. - Looked at database for consistency. - Browsed/queried push logs. - Pushed a bunch of stuff. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4677 Differential Revision: https://secure.phabricator.com/D8615
2014-03-26 03:43:26 +01:00
),
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorRepositoryPushEventPHIDType' => 'PhabricatorPHIDType',
Provide a real object ("PhabricatorRepositoryPushEvent") to represent an entire push transaction Summary: Ref T4677. Currently, we record individual actions in a push as PhabricatorRepositoryPushLogs, but tie them together only loosely with a `transactionKey`. Provide a real PushEvent object, and move some of the denormalized fields to it. This primarily just gives us more robust infrastructure for building, e.g., email about pushes, for T4677, since we can act on real PHIDs rather than passing awkward identifiers around. Test Plan: - Performed migration. - Looked at database for consistency. - Browsed/queried push logs. - Pushed a bunch of stuff. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4677 Differential Revision: https://secure.phabricator.com/D8615
2014-03-26 03:43:26 +01:00
'PhabricatorRepositoryPushEventQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorRepositoryPushLog' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorRepositoryDAO',
'PhabricatorPolicyInterface',
Add a basic push log for recording repository push events Summary: Ref T4195. This log serves two purposes: - It's a log, so you can see what happened. Particularly, in Git/Hg, there is no other way to tell: - Who //pushed// a change (vs committed / authored)? - When was a change pushed? - What was the old value of some tag/branch before someone destroyed it? - We can hand these objects off to Herald to implement pre-commit rules. This is a very basic implementation, but gets some data written and has a basic UI for it. Test Plan: {F87339} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7705
2013-12-05 20:56:14 +01:00
),
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorRepositoryPushLogPHIDType' => 'PhabricatorPHIDType',
Add a basic push log for recording repository push events Summary: Ref T4195. This log serves two purposes: - It's a log, so you can see what happened. Particularly, in Git/Hg, there is no other way to tell: - Who //pushed// a change (vs committed / authored)? - When was a change pushed? - What was the old value of some tag/branch before someone destroyed it? - We can hand these objects off to Herald to implement pre-commit rules. This is a very basic implementation, but gets some data written and has a basic UI for it. Test Plan: {F87339} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7705
2013-12-05 20:56:14 +01:00
'PhabricatorRepositoryPushLogQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhabricatorRepositoryPushLogSearchEngine' => 'PhabricatorApplicationSearchEngine',
Allow users to receive email about pushes via Herald Summary: Fixes T4677. Implements a "send an email" pre-receive action, which sends push summaries. For use cases where features are often pushed as a large number of commits (e.g., checkpoint commits are retained), using commit emails means users get a ton of email. Instead, this allows you to get an email about a push, which summarizes what changed. Overall, this is basically the same as commit email, but more suitable for some workflows. Test Plan: Wrote some rules, then made a bunch of pushes. Got email like this: {F134929} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4677 Differential Revision: https://secure.phabricator.com/D8618
2014-03-26 18:44:06 +01:00
'PhabricatorRepositoryPushMailWorker' => 'PhabricatorWorker',
'PhabricatorRepositoryPushReplyHandler' => 'PhabricatorMailReplyHandler',
Make Repositories partially policy-aware Summary: Small step toward repository hosting. No user-visible changes. Test Plan: Looked at repositories in Diffusion. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D4227
2012-12-19 20:07:06 +01:00
'PhabricatorRepositoryQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorRepositoryRefCursor' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorRepositoryDAO',
'PhabricatorPolicyInterface',
Introduce ref cursors for repository parsing Summary: Ref T4327. I want to make change parsing testable; one thing which is blocking this is that the Git discovery process is still part of `PullLocal` daemon instead of being part of `DiscoveryEngine`. The unit test stuff which I want to use for change parsing relies on `DiscoveryEngine` to discover repositories during unit tests. The major reason git discovery isn't part of `DiscoveryEngine` is that it relies on the messy "autoclose" logic, which we never implemented for Mercurial. Generally, I don't like how autoclose was implemented: it's complicated and gross and too hard to figure out and extend. Instead, I want to do something more similar to what we do for pushes, which is cleaner overall. Basically this means remembering the old branch heads from the last time we parsed a repository, and figuring out what's new by comparing the old and new branch heads. This should give us several advantages: - It should be simpler to understand than the autoclose stuff, which is pretty mind-numbing, at least for me. - It will let us satisfy branch and tag queries cheaply (from the database) instead of having to go to the repository. We could also satisfy some ref-resolve queries from the database. - It should be easier to extend to Mercurial. This implements the basics -- pretty much a table to store the cursors, which we update only for Git for now. Test Plan: - Ran migration. - Ran `bin/repository discover X --trace --verbose` on various repositories with branches and tags, before and after modifying pushes. - Pushed commits to a git repo. - Looked at database tables. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7982
2014-01-16 21:05:30 +01:00
),
Add proper PHIDs to RefCursors Summary: Ref T9952. See discussion there. This change is primarily aimed at letting me build a typeahead of branches in a repository so that we can land to arbitrary branches a few diffs from now. Test Plan: - Ran migrations. - Verified database populated properly with PHIDs (`SELECT * FROM repository_refcursor;`). - Ran `bin/repository update`. - Viewed a Git repository in Diffusion. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9952 Differential Revision: https://secure.phabricator.com/D14731
2015-12-10 21:59:25 +01:00
'PhabricatorRepositoryRefCursorPHIDType' => 'PhabricatorPHIDType',
Introduce ref cursors for repository parsing Summary: Ref T4327. I want to make change parsing testable; one thing which is blocking this is that the Git discovery process is still part of `PullLocal` daemon instead of being part of `DiscoveryEngine`. The unit test stuff which I want to use for change parsing relies on `DiscoveryEngine` to discover repositories during unit tests. The major reason git discovery isn't part of `DiscoveryEngine` is that it relies on the messy "autoclose" logic, which we never implemented for Mercurial. Generally, I don't like how autoclose was implemented: it's complicated and gross and too hard to figure out and extend. Instead, I want to do something more similar to what we do for pushes, which is cleaner overall. Basically this means remembering the old branch heads from the last time we parsed a repository, and figuring out what's new by comparing the old and new branch heads. This should give us several advantages: - It should be simpler to understand than the autoclose stuff, which is pretty mind-numbing, at least for me. - It will let us satisfy branch and tag queries cheaply (from the database) instead of having to go to the repository. We could also satisfy some ref-resolve queries from the database. - It should be easier to extend to Mercurial. This implements the basics -- pretty much a table to store the cursors, which we update only for Git for now. Test Plan: - Ran migration. - Ran `bin/repository discover X --trace --verbose` on various repositories with branches and tags, before and after modifying pushes. - Pushed commits to a git repo. - Looked at database tables. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7982
2014-01-16 21:05:30 +01:00
'PhabricatorRepositoryRefCursorQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhabricatorRepositoryRefEngine' => 'PhabricatorRepositoryEngine',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorRepositoryRepositoryPHIDType' => 'PhabricatorPHIDType',
Generate expected schemata for Repository Summary: Ref T1191. Add specs for repository tables. Test Plan: Saw ~300 fewer schema warnings. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10575
2014-09-29 00:12:21 +02:00
'PhabricatorRepositorySchemaSpec' => 'PhabricatorConfigSchemaSpec',
Use ApplicationSearch in Diffusion Summary: Ref T2625. Switches Diffusion to ApplicationSearch. Notes: - Rendering is a bit rough, I'll clean that up next. - Ordering is a bit arbitrary, also coming shortly. Test Plan: Used `/diffusion/` to execute various searches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6917
2013-09-11 00:26:08 +02:00
'PhabricatorRepositorySearchEngine' => 'PhabricatorApplicationSearchEngine',
Add "RepositoryStatusMessage" and detailed information about initilization Summary: `RepositoryStatusMessage` is basically a key/value table associated with a repository that I'm using to let the daemons store the most recent event of a given type, so we can easily show it on the status dashboard. I think this will be a lot easier for users to figure out than digging through logfiles. I'm also going to write the "this needs a pull" status here eventually, for reducing the time lapse between pushes and discovery. - Add storage for these messages. - Have the pull engine populate the INIT phase. I'll do the FETCH phase next. - Update the status readout to show all the various states. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7461
2013-10-31 00:04:19 +01:00
'PhabricatorRepositoryStatusMessage' => 'PhabricatorRepositoryDAO',
Diffusion change parser for SVN. Summary: there is a small possibility this works correctly Test Plan: Reviewers: CC:
2011-03-11 23:13:23 +01:00
'PhabricatorRepositorySvnCommitChangeParserWorker' => 'PhabricatorRepositoryCommitChangeParserWorker',
Increase parseriness of some parsery things. Summary: None of these are parsnips. Test Plan: Reviewers: CC:
2011-03-11 18:34:22 +01:00
'PhabricatorRepositorySvnCommitMessageParserWorker' => 'PhabricatorRepositoryCommitMessageParserWorker',
Add storage for repository symbol tracking Summary: See T315 for an extensive description of this feature. Adds the descibed storage table. Test Plan: Used phpsh to read/write symbol objects. Reviewers: jungejason, nh, tuomaspelkonen, aran Reviewed By: tuomaspelkonen CC: aran, epriestley, tuomaspelkonen Differential Revision: 897
2011-09-05 02:31:16 +02:00
'PhabricatorRepositorySymbol' => 'PhabricatorRepositoryDAO',
Relax the same-origin check in the Git commit discovery daemon Summary: Git accepts either "git@x:/path" or "ssh://git@x.com/path" URIs to mean the exact same thing, which is causing some false positives and confusion, particularly because we sometimes mutate URIs. Since this is just a sanity check, we don't really care about the username, domain or credentials -- matching the paths is good enough. We're just trying to make it hard to shoot yourself in the foot by copy-pasting the same local path into two repositories and forgetting to change one, like I did. :P Relax the check to only verify the paths are the same. Test Plan: - Ran unit tests, which should fully cover things. - Ran commit discovery daemon in debug mode on incorrectly and correctly configured repositories. Reviewers: ajtrichards, jungejason, btrahan Reviewed By: jungejason CC: aran, jungejason Maniphest Tasks: T710 Differential Revision: https://secure.phabricator.com/D1279
2011-12-23 17:11:11 +01:00
'PhabricatorRepositoryTestCase' => 'PhabricatorTestCase',
Begin transacitonalizing repository edits and provide a more sensible edit interface Summary: Ref T2231, T603. Plan of attack here is pretty much: - Built out a new (currently not linked in the UI) edit interface in Diffusion which is transaction-based and has a sensible layout. - Build out a new create interface based on PagedForm which dumps into the new edit interface. - Throw the old stuff away. - Everyone lives happily ever after. Test Plan: {F44163} {F44164} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D6029
2013-05-24 21:37:42 +02:00
'PhabricatorRepositoryTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorRepositoryTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorRepositoryType' => 'Phobject',
Rough sketch of new repository URI editing Summary: Ref T10748. Ref T10366. This adds a new EditEngine, EditController, Editor, Query, and Transaction for RepositoryURIs. None of these really do anything helpful yet, and these URIs are still unused in the actual application. Test Plan: {F1249794} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10366, T10748 Differential Revision: https://secure.phabricator.com/D15815
2016-04-28 17:33:44 +02:00
'PhabricatorRepositoryURI' => array(
'PhabricatorRepositoryDAO',
'PhabricatorApplicationTransactionInterface',
'PhabricatorPolicyInterface',
'PhabricatorExtendedPolicyInterface',
Allow callers to query information about repository URIs from diffusion.repository.search Summary: Ref T10748. Adds a "uris" attachment with URI information. Test Plan: Queried URI information via Conduit, saw reasonable looking information. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15822
2016-04-29 23:10:04 +02:00
'PhabricatorConduitResultInterface',
Rough sketch of new repository URI editing Summary: Ref T10748. Ref T10366. This adds a new EditEngine, EditController, Editor, Query, and Transaction for RepositoryURIs. None of these really do anything helpful yet, and these URIs are still unused in the actual application. Test Plan: {F1249794} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10366, T10748 Differential Revision: https://secure.phabricator.com/D15815
2016-04-28 17:33:44 +02:00
),
Move repository URIs to a dedicated index Summary: Ref T4705 (there are also some other adjacent related tasks dealing with URIs). Currently, we issue a "get repositories matching URIs: ..." query by loading every possible repository and then checking their URIs in PHP. Instead, put URIs in a separate table. I plan for each repository to potentially have multiple URIs soon, so this prepares for that. Test Plan: - Ran migrations. - Looked at index table, made sure it appeared sensible. - Ran some queries by `uri` to find repositories, found the repositories I expected. - Updated the remote URI of a repository, saw queries / index update appropriately. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4705 Differential Revision: https://secure.phabricator.com/D15005
2016-01-12 15:45:17 +01:00
'PhabricatorRepositoryURIIndex' => 'PhabricatorRepositoryDAO',
Move repository URI normalization out of PullLocalDaemon Summary: Ref T4327. Moves us one small step forward toward testable change parsers by separating out this unrelated logic from the PullLocal daemon. We will also probably want to run this logic so we can do remote path lookups to limit the role of Arcanist Projects in the future, which is why I made the URI type (here, only "git") a parameter rather than calling this a `GitURINormalizer` or something. Test Plan: - Ran unit tests. - Ran `repository discover` on a correctly-configured remote repository. - Ran `repository discover` on an incorrectly-configured remote, got an error message. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7981
2014-01-16 19:49:03 +01:00
'PhabricatorRepositoryURINormalizer' => 'Phobject',
'PhabricatorRepositoryURINormalizerTestCase' => 'PhabricatorTestCase',
Rough sketch of new repository URI editing Summary: Ref T10748. Ref T10366. This adds a new EditEngine, EditController, Editor, Query, and Transaction for RepositoryURIs. None of these really do anything helpful yet, and these URIs are still unused in the actual application. Test Plan: {F1249794} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10366, T10748 Differential Revision: https://secure.phabricator.com/D15815
2016-04-28 17:33:44 +02:00
'PhabricatorRepositoryURIPHIDType' => 'PhabricatorPHIDType',
'PhabricatorRepositoryURIQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Fix some repository URI handling issues in Git and Mercurial Summary: See <https://github.com/facebook/phabricator/issues/467>. @dctrwatson also ran into an issue where we were trying to `setPass()` a GitURI. - For Git and Mercurial, properly generate credential URIs where relevant. - Don't try to `setPass()` on Git-style URIs. This isn't perfect but should clean things up a bit. Test Plan: Added unit tests. Lots of `grep`. Reviewers: btrahan Reviewed By: btrahan CC: dctrwatson, aran Differential Revision: https://secure.phabricator.com/D7759
2013-12-12 18:45:27 +01:00
'PhabricatorRepositoryURITestCase' => 'PhabricatorTestCase',
Rough sketch of new repository URI editing Summary: Ref T10748. Ref T10366. This adds a new EditEngine, EditController, Editor, Query, and Transaction for RepositoryURIs. None of these really do anything helpful yet, and these URIs are still unused in the actual application. Test Plan: {F1249794} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10366, T10748 Differential Revision: https://secure.phabricator.com/D15815
2016-04-28 17:33:44 +02:00
'PhabricatorRepositoryURITransaction' => 'PhabricatorApplicationTransaction',
Add repository URI view pages and IO/Display edit logic Summary: Ref T10748. - New View page for repository URIs. - Make display and I/O behavior (observe, mirror, read, read/write) editable. - Add a bunch of checks to prevent you from completely screwing up a repository by making it writable from a bunch of differnet sources. Test Plan: {F1249866} {F1249867} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10748 Differential Revision: https://secure.phabricator.com/D15816
2016-04-28 19:40:35 +02:00
'PhabricatorRepositoryURITransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Implementation of VCS passwords against user. Summary: This allows users to set their HTTP access passwords via Diffusion interface. Test Plan: Clicked the "Set HTTP Access Password" link, set a password and saw it appear in the DB. Reviewers: #blessed_reviewers, hach-que, btrahan Reviewed By: hach-que CC: Korvin, epriestley, aran, jamesr Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7462
2013-11-01 16:34:11 +01:00
'PhabricatorRepositoryVCSPassword' => 'PhabricatorRepositoryDAO',
Fix Mercurial command injection vulnerability Summary: See <http://chargen.matasano.com/chargen/2015/3/17/this-new-vulnerability-mercurial-command-injection-cve-2014-9462.html>. Test Plan: Crafted bad remote URL; got error instead of code execution. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D12112
2015-03-20 17:26:32 +01:00
'PhabricatorRepositoryVersion' => 'Phobject',
Move toward multi-master replicated repositories Summary: Ref T4292. This mostly implements the locking/versioning logic for multi-master repositories. It is only active on Git SSH pathways, and doesn't actually do anything useful yet: it just does bookkeeping so far. When we read (e.g., `git fetch`) the logic goes like this: - Get the read lock (unique to device + repository). - Read all the versions of the repository on every other device. - If any node has a newer version: - Fetch the newer version. - Increment our version to be the same as the version we fetched. - Release the read lock. - Actually do the fetch. This makes sure that any time you do a read, you always read the most recently acknowledged write. You may have to wait for an internal fetch to happen (this isn't actually implemented yet) but the operation will always work like you expect it to. When we write (e.g., `git push`) the logic goes like this: - Get the write lock (unique to the repository). - Do all the read steps so we're up to date. - Mark a write pending. - Do the actual write. - Bump our version and mark our write finished. - Release the write lock. This allows you to write to any replica. Again, you might have to wait for a fetch first, but everything will work like you expect. There's one notable failure mode here: if the network connection between the repository node and the database fails during the write, the write lock might be released even though a write is ongoing. The "isWriting" column protects against that, by staying locked if we lose our connection to the database. This will currently "freeze" the repository (prevent any new writes) until an administrator can sort things out, since it'd dangerous to continue doing writes (we may lose data). (Since we won't actually acknowledge the write, I think, we could probably smooth this out a bit and make it self-healing //most// of the time: basically, have the broken node rewind itself by updating from another good node. But that's a little more complex.) Test Plan: - Pushed changes to a cluster-mode repository. - Viewed web interface, saw "writing" flag and version changes. - Pulled changes. - Faked various failures, got sensible states. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4292 Differential Revision: https://secure.phabricator.com/D15688
2016-04-11 20:58:02 +02:00
'PhabricatorRepositoryWorkingCopyVersion' => 'PhabricatorRepositoryDAO',
Modularize Aphront exception handling Summary: Ref T1806. Ref T7173. Depends on D14047. Currently, all exception handling is in this big messy clump in `AphrontDefaultApplicationConfiguration`. Split it out into modular classes. This will let a future change add new classes in the Phacility cluster which intercept particular exceptions we care about and replaces the default, generic responses with more useful, tailored responses. Test Plan: {F777391} - Hit a Conduit error (made a method throw). - Hit an Ajax error (made comment preview throw). - Hit a high security error (tried to edit TOTP). - Hit a rate limiting error (added a bunch of email addresses). - Hit a policy error (tried to look at something with no permission). - Hit an arbitrary exception (made a randomc ontroller throw). Reviewers: chad Reviewed By: chad Maniphest Tasks: T1806, T7173 Differential Revision: https://secure.phabricator.com/D14049
2015-09-03 19:04:42 +02:00
'PhabricatorRequestExceptionHandler' => 'AphrontRequestExceptionHandler',
Also update the resource map This is not my morning. Auditors: chad
2015-12-11 17:23:39 +01:00
'PhabricatorResourceSite' => 'PhabricatorSite',
Add a robots.txt file to disallow /diffusion/ Summary: Fixes T4610. Open to suggestions, etc., if there's anything I'm missing. Also: - Moves these "system" endpoints into a real application. - Makes `isUnlisted()` work a little more consistently. Test Plan: Accessed `/robots.txt`, `/status/` and `/debug/`. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4610 Differential Revision: https://secure.phabricator.com/D8532
2014-03-14 19:53:17 +01:00
'PhabricatorRobotsController' => 'PhabricatorController',
Add an Amazon S3 storage engine for Phabricator Summary: Implements an S3 storage engine option for Phabricator. Test Plan: - Uploaded files to S3. - Looked at them. - Verified they appeared in S3 using the S3 file browser. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason Differential Revision: 752
2011-07-31 22:54:58 +02:00
'PhabricatorS3FileStorageEngine' => 'PhabricatorFileStorageEngine',
Add SMS support Summary: Provides a working SMS implementation with support for Twilio. This version doesn't really retry if we get any gruff at all. Future versions should retry. Test Plan: used bin/sms to send messages and look at them. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: aurelijus, epriestley, Korvin Maniphest Tasks: T920 Differential Revision: https://secure.phabricator.com/D8930
2014-05-09 21:47:21 +02:00
'PhabricatorSMS' => 'PhabricatorSMSDAO',
'PhabricatorSMSConfigOptions' => 'PhabricatorApplicationConfigOptions',
'PhabricatorSMSDAO' => 'PhabricatorLiskDAO',
'PhabricatorSMSDemultiplexWorker' => 'PhabricatorSMSWorker',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorSMSImplementationAdapter' => 'Phobject',
Add SMS support Summary: Provides a working SMS implementation with support for Twilio. This version doesn't really retry if we get any gruff at all. Future versions should retry. Test Plan: used bin/sms to send messages and look at them. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: aurelijus, epriestley, Korvin Maniphest Tasks: T920 Differential Revision: https://secure.phabricator.com/D8930
2014-05-09 21:47:21 +02:00
'PhabricatorSMSImplementationTestBlackholeAdapter' => 'PhabricatorSMSImplementationAdapter',
'PhabricatorSMSImplementationTwilioAdapter' => 'PhabricatorSMSImplementationAdapter',
'PhabricatorSMSManagementListOutboundWorkflow' => 'PhabricatorSMSManagementWorkflow',
'PhabricatorSMSManagementSendTestWorkflow' => 'PhabricatorSMSManagementWorkflow',
'PhabricatorSMSManagementShowOutboundWorkflow' => 'PhabricatorSMSManagementWorkflow',
'PhabricatorSMSManagementWorkflow' => 'PhabricatorManagementWorkflow',
'PhabricatorSMSSendWorker' => 'PhabricatorSMSWorker',
'PhabricatorSMSWorker' => 'PhabricatorWorker',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorSQLPatchList' => 'Phobject',
Add a "Generate Keypair" option on the SSH Keys panel Summary: Ref T4587. Add an option to automatically generate a keypair, associate the public key, and save the private key. Test Plan: Generated some keypairs. Hit error conditions, etc. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4587 Differential Revision: https://secure.phabricator.com/D8513
2014-03-13 02:17:11 +01:00
'PhabricatorSSHKeyGenerator' => 'Phobject',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorSSHKeysSettingsPanel' => 'PhabricatorSettingsPanel',
Add an SSH access log Summary: Ref T4107. Ref T4189. This implements an SSH access log, similar to the HTTP access log. Test Plan: [Thu, 05 Dec 2013 13:45:41 -0800] 77841 orbital ::1 dweller epriestley epriestley git-receive-pack /diffusion/POEMS/ 0 324765 402 232 [Thu, 05 Dec 2013 13:45:48 -0800] 77860 orbital ::1 dweller epriestley epriestley git-receive-pack /diffusion/POEMS/ 0 325634 402 232 Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4107, T4189 Differential Revision: https://secure.phabricator.com/D7719
2013-12-06 02:00:48 +01:00
'PhabricatorSSHLog' => 'Phobject',
Generalize SSH passthru for repository hosting Summary: Ref T2230. In Git, we can determine if a command is read-only or read/write from the command itself, but this isn't the case in Mercurial or SVN. For Mercurial and SVN, we need to proxy the protocol that's coming over the wire, look at each request from the client, and then check if it's a read or a write. To support this, provide a more flexible version of `passthruIO`. The way this will work is: - The SSH IO channel is wrapped in a `ProtocolChannel` which can parse the the incoming stream into message objects. - The `willWriteCallback` will look at those messages and determine if they're reads or writes. - If they're writes, it will check for write permission. - If we're good to go, the message object is converted back into a byte stream and handed to the underlying command. Test Plan: Executed `git clone`, `git clone --depth 3`, `git push` (against no-write repo, got error), `git push` (against valid repo). Reviewers: btrahan Reviewed By: btrahan CC: hach-que, asherkin, aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7551
2013-11-11 21:12:21 +01:00
'PhabricatorSSHPassthruCommand' => 'Phobject',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorSSHWorkflow' => 'PhabricatorManagementWorkflow',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorSavedQuery' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorSearchDAO',
'PhabricatorPolicyInterface',
Introduce PhabricatorSavedQueryQuery Summary: Same as D6051, but for SavedQueries instead of NamedQueries. These are POLICY_PUBLIC because you need to know the hash to access them, and because we want to let users copy/paste query URLs. Ref T2625. Test Plan: Saved a query, reused a saved query. Reviewers: btrahan, blc Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6054
2013-05-27 22:41:20 +02:00
),
'PhabricatorSavedQueryQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add a "schedule task" trigger action Summary: Ref T6881. Add a standard "just queue a task" trigger action; I expect almost all application code to use this. Test Plan: Will test in Instances. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11429
2015-01-20 01:55:23 +01:00
'PhabricatorScheduleTaskTriggerAction' => 'PhabricatorTriggerAction',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorScopedEnv' => 'Phobject',
'PhabricatorSearchAbstractDocument' => 'Phobject',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorSearchApplication' => 'PhabricatorApplication',
Partially use ApplicationSearch in main search Summary: Ref T4365. Primary search currently uses `PhabricatorSearchQuery` for storage, which is pretty much the same as `PhabricatorSavedQuery`, except that it's old and not used anywhere else anymore. Maniphest used to also use this table, but no longer does after Septmeber, 2013. We need to retain the class so the migration can work. This introduces `PhabricatorSearchApplicationSearchEngine` and `PhabricatorSearchDocumentQuery`, but they're both stubs that I just needed for technical reasons and/or to pass lint. The next couple patches will move logic into them and use ApplicationSearch properly. Test Plan: - Searched for stuff. - Searched for stuff with filters. - Searched for fulltext in Maniphest. - Grepped for `PhabricatorSearchQuery`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4365 Differential Revision: https://secure.phabricator.com/D8120
2014-02-03 21:51:08 +01:00
'PhabricatorSearchApplicationSearchEngine' => 'PhabricatorApplicationSearchEngine',
Modernize search engine selection Summary: Remove the `PhabricatorDefaultSearchEngineSelector` class. This is quite similar to D12053. Test Plan: Went to `/view/PhabricatorSearchApplication/` and saw the storage engine configuration. Set `search.elastic.host` and saw the highlighted storage engine change. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D12670
2015-05-19 22:59:58 +02:00
'PhabricatorSearchApplicationStorageEnginePanel' => 'PhabricatorApplicationConfigurationPanel',
Add "final" to all Phabricator "Controller" classes Summary: These are all unambiguously unextensible. Issues I hit: - Maniphest Change/Diff controllers, just consolidated them. - Some search controllers incorrectly extend from "Search" but should extend from "SearchBase". This has no runtime effects. - D1836 introduced a closure, which we don't handle correctly (somewhat on purpose; we target PHP 5.2). See T962. Test Plan: Ran "testEverythingImplemented" unit test to identify classes extending from `final` classes. Resolved issues. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T795 Differential Revision: https://secure.phabricator.com/D1843
2012-03-10 00:46:25 +01:00
'PhabricatorSearchAttachController' => 'PhabricatorSearchBaseController',
Rought cut of search. Summary: Botched this pretty badly in git so we'll see how much I broke. :/ Test Plan: Reviewers: CC:
2011-02-15 00:34:20 +01:00
'PhabricatorSearchBaseController' => 'PhabricatorController',
Move Pholio to SearchFields Summary: Ref T8441. Ref T7715. - Update PholioSearchEngine. - Automatically add project fields. - Update Paste to support project search. - Simplify common Query class construction. Test Plan: - Searched for pastes. - Searched for mocks. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13174
2015-06-07 16:31:28 +02:00
'PhabricatorSearchCheckboxesField' => 'PhabricatorSearchField',
Search options. Test Plan: - Looked at the new options - Saved `search.engine-selector` successfully. Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4410
2013-01-12 00:28:16 +01:00
'PhabricatorSearchConfigOptions' => 'PhabricatorApplicationConfigOptions',
Move even more rendering into SearchEngine Summary: Ref T4986. I think this is the last of the easy ones, there are about 10 not-quite-so-trivial ones left. Test Plan: - Viewed app results. - Created panels. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9025
2014-05-09 21:28:02 +02:00
'PhabricatorSearchController' => 'PhabricatorSearchBaseController',
Move Projects to SearchFields Summary: Ref T8441. Ref T7715. This is mostly about getting SearchFields + CustomFields working. (This includes a couple of SearchFields which aren't used quite yet.) Test Plan: - Used all search controls. - Defined custom fields and searched for them. - Created an old saved search which searches on custom fields on master, switched to this patch, search worked exaclty as written. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13189
2015-06-08 21:20:16 +02:00
'PhabricatorSearchCustomFieldProxyField' => 'PhabricatorSearchField',
Rought cut of search. Summary: Botched this pretty badly in git so we'll see how much I broke. :/ Test Plan: Reviewers: CC:
2011-02-15 00:34:20 +01:00
'PhabricatorSearchDAO' => 'PhabricatorLiskDAO',
Modernize global search typeahead datasource Summary: Ref T4420. Bring the global search up to date. Test Plan: Typed various things into global search. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D9889
2014-07-18 00:48:36 +02:00
'PhabricatorSearchDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Move Projects to SearchFields Summary: Ref T8441. Ref T7715. This is mostly about getting SearchFields + CustomFields working. (This includes a couple of SearchFields which aren't used quite yet.) Test Plan: - Used all search controls. - Defined custom fields and searched for them. - Created an old saved search which searches on custom fields on master, switched to this patch, search worked exaclty as written. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13189
2015-06-08 21:20:16 +02:00
'PhabricatorSearchDatasourceField' => 'PhabricatorSearchTokenizerField',
Refactor Calendar Search, and implement Projects on events Summary: Ref T7950, Refactor Calendar Search, and implement Projects on events Test Plan: Verify that all queries in Calendar search still work, and that events can now have associated Projects that you can search by in Calendar Search. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T7950 Differential Revision: https://secure.phabricator.com/D13393
2015-06-22 22:27:37 +02:00
'PhabricatorSearchDateControlField' => 'PhabricatorSearchField',
Begin modularizing fields in SearchEngines Summary: Ref T8441. Ref T7715. Add a layer of indirection to fields in search engines. This will allow us to: - Simplify SearchEngine code, which has collected a lot of duplication around expressing what is effectively field types. - Automatically add fields like "Spaces" and "Projects" (primary driver for T8441). - Reorder or hide fields (not sure if we really want to do this, but it seems plausible, and this will let us play around with it, at least). - Drive Conduit Query methods via SearchEngines, so the same code specifies both the search UI and the `application.query` endpoint (primary driver in T7715). Test Plan: - Searched for stuff in Paste, everything behaved exaclty like it used to (except that I removed the "no language" checkbox, which seemed like fluff from a bygone era). - Searched for stuff in other applications, saw no changes. - Hit date field errors. - Used query strings to specify values. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13169
2015-06-05 20:21:08 +02:00
'PhabricatorSearchDateField' => 'PhabricatorSearchField',
Allow custom queries to be deleted Summary: Ref T2625. Currently, custom saved queries can be edited but not deleted. Allow them to be deleted. Also: - Clean up an unused property in `PhabricatorPasteViewController`. - Fix an issue with left nav highlighting of builtin queries. - Improve submit behavior for edits. - Add a cancel button on edits. Test Plan: Saved, edited and deleted queries. Reviewers: btrahan, blc Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6059
2013-05-27 22:42:44 +02:00
'PhabricatorSearchDeleteController' => 'PhabricatorSearchBaseController',
Rought cut of search. Summary: Botched this pretty badly in git so we'll see how much I broke. :/ Test Plan: Reviewers: CC:
2011-02-15 00:34:20 +01:00
'PhabricatorSearchDocument' => 'PhabricatorSearchDAO',
'PhabricatorSearchDocumentField' => 'PhabricatorSearchDAO',
Rename `PhabricatorSearchField` to `PhabricatorSearchFieldDocumentType` Summary: Ref T8441. I want to use `PhabricatorSearchField` for a better, more useful object. Test Plan: `grep`, `arc lint` Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8441 Differential Revision: https://secure.phabricator.com/D13168
2015-06-05 20:01:25 +02:00
'PhabricatorSearchDocumentFieldType' => 'Phobject',
Partially use ApplicationSearch in main search Summary: Ref T4365. Primary search currently uses `PhabricatorSearchQuery` for storage, which is pretty much the same as `PhabricatorSavedQuery`, except that it's old and not used anywhere else anymore. Maniphest used to also use this table, but no longer does after Septmeber, 2013. We need to retain the class so the migration can work. This introduces `PhabricatorSearchApplicationSearchEngine` and `PhabricatorSearchDocumentQuery`, but they're both stubs that I just needed for technical reasons and/or to pass lint. The next couple patches will move logic into them and use ApplicationSearch properly. Test Plan: - Searched for stuff. - Searched for stuff with filters. - Searched for fulltext in Maniphest. - Grepped for `PhabricatorSearchQuery`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4365 Differential Revision: https://secure.phabricator.com/D8120
2014-02-03 21:51:08 +01:00
'PhabricatorSearchDocumentQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Rought cut of search. Summary: Botched this pretty badly in git so we'll see how much I broke. :/ Test Plan: Reviewers: CC:
2011-02-15 00:34:20 +01:00
'PhabricatorSearchDocumentRelationship' => 'PhabricatorSearchDAO',
Use a typeahead for "document types" in global search Summary: - Now that we have "browse", this is a much more reasonable control for random sets of things. - The new explicit search scope selector reduces the need to fiddle with this field manually, too. Test Plan: {F379292} {F379293} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D12510
2015-04-23 00:25:34 +02:00
'PhabricatorSearchDocumentTypeDatasource' => 'PhabricatorTypeaheadDatasource',
Make saved queries editable Summary: Ref T2625. Rename the "Name" controller to "Edit" and allow it to edit named queries. Also some UI touchups. Add an edit link to the saved query browse view. Test Plan: Created and edited named queries. Reviewers: btrahan, blc Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6056
2013-05-27 22:42:01 +02:00
'PhabricatorSearchEditController' => 'PhabricatorSearchBaseController',
Implement a rough initial version of ApplicationSearch-driven Conduit read endpoints Summary: Ref T9964. See that task for some context and discussion. Ref T7715, which has the bigger picture here. Basically, I want Conduit read endpoints to be full-power, ApplicationSearch-driven endpoints, so that applications can: - Write one EditEngine and get web + conduit writes for free. - Write one SearchEngine and get web + conduit reads for free. I previously made some steps toward this, but this puts more of the structure in place. Test Plan: Viewed API console endpoint and read 20 pages of docs: {F1021961} Made various calls: with query keys, constraints, pagination, and limits. Viewed new {nav Config > Modules} page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7715, T9964 Differential Revision: https://secure.phabricator.com/D14743
2015-12-11 17:45:56 +01:00
'PhabricatorSearchEngineAPIMethod' => 'ConduitAPIMethod',
Implement an "Attachments" behavior for Conduit Search APIs Summary: Ref T9964. We have various kinds of secondary data on objects (like subscribers, projects, paste content, Owners paths, file attachments, etc) which is somewhat slow, or somewhat large, or both. Some approaches to handling this in the API include: - Always return all of it (very easy, but slow). - Require users to make separate API calls to get each piece of data (very simple, but inefficient and really cumbersome to use). - Implement a hierarchical query language like GraphQL (powerful, but very complex). - Kind of mix-and-match a half-power query language and some extra calls? (fairly simple, not too terrible?) We currently mix-and-match internally, with `->needStuff(true)`. This is not a general-purpose, full-power graph query language like GraphQL, and it occasionally does limit us. For example, there is no way to do this sort of thing: $conpherence_thread_query = id(new ConpherenceThreadQuery()) ->setViewer($viewer) // ... ->setNeedMessages(true) ->setWhenYouLoadTheMessagesTheyNeedProfilePictures(true); However, we almost never actually need to do this and when we do want to do it we usually don't //really// want to do it, so I don't think this is a major limit to the practical power of the system for the kinds of things we really want to do with it. Put another way, we have a lot of 1-level hierarchical queries (get pictures or repositories or projects or files or content for these objects) but few-to-no 2+ level queries (get files for these objects, then get all the projects for those files). So even though 1-level hierarchies are not a beautiful, general-purpose, fully-abstract system, they've worked well so far in practice and I'm comfortable moving forward with them in the API. If we do need N-level queries in the future, there is no technical reason we can't put GraphQL (or something similar) on top of this eventually, and this would represent a solid step toward that. However, I suspect we'll never need them. Upshot: I'm pretty happy with "->needX()" for all practical purposes, so this is just adding a way to say "->needX()" to the API. Specifically, you say: ``` { "attachments": { "subscribers": true, } } ``` ...and get back subscriber data. In the future (or for certain attachments), `true` might become a dictionary of extra parameters, if necessary, and could do so without breaking the API. Test Plan: - Ran queries to get attachments. {F1025449} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14772
2015-12-14 13:58:34 +01:00
'PhabricatorSearchEngineAttachment' => 'Phobject',
Implement a rough initial version of ApplicationSearch-driven Conduit read endpoints Summary: Ref T9964. See that task for some context and discussion. Ref T7715, which has the bigger picture here. Basically, I want Conduit read endpoints to be full-power, ApplicationSearch-driven endpoints, so that applications can: - Write one EditEngine and get web + conduit writes for free. - Write one SearchEngine and get web + conduit reads for free. I previously made some steps toward this, but this puts more of the structure in place. Test Plan: Viewed API console endpoint and read 20 pages of docs: {F1021961} Made various calls: with query keys, constraints, pagination, and limits. Viewed new {nav Config > Modules} page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7715, T9964 Differential Revision: https://secure.phabricator.com/D14743
2015-12-11 17:45:56 +01:00
'PhabricatorSearchEngineExtension' => 'Phobject',
'PhabricatorSearchEngineExtensionModule' => 'PhabricatorConfigModule',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorSearchEngineTestCase' => 'PhabricatorTestCase',
Begin modularizing fields in SearchEngines Summary: Ref T8441. Ref T7715. Add a layer of indirection to fields in search engines. This will allow us to: - Simplify SearchEngine code, which has collected a lot of duplication around expressing what is effectively field types. - Automatically add fields like "Spaces" and "Projects" (primary driver for T8441). - Reorder or hide fields (not sure if we really want to do this, but it seems plausible, and this will let us play around with it, at least). - Drive Conduit Query methods via SearchEngines, so the same code specifies both the search UI and the `application.query` endpoint (primary driver in T7715). Test Plan: - Searched for stuff in Paste, everything behaved exaclty like it used to (except that I removed the "no language" checkbox, which seemed like fluff from a bygone era). - Searched for stuff in other applications, saw no changes. - Hit date field errors. - Used query strings to specify values. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13169
2015-06-05 20:21:08 +02:00
'PhabricatorSearchField' => 'Phobject',
Added basic hovercard controller Summary: Refs T1048; Depends on D5542, D5543, D5544 - It currently just renders multiple hovercards nicely for test purposes. More is on the way. Mode `test`: Human test chamber. Mode `retrieve`: For JS. Added so it would not clash with search key routing. badassery Test Plan: `/search/hovercard/test/?phids[hover-T4]=PHID-TASK-g5pduvwrrwvkq5gkx736&phids[hover-T2]=PHID-TASK-gta6lzaaagziavkktima` Verified the appearance of two tasks with correct rendering and correct ids Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1048 Differential Revision: https://secure.phabricator.com/D5545
2013-04-03 17:31:27 +02:00
'PhabricatorSearchHovercardController' => 'PhabricatorSearchBaseController',
Allow index extensions to skip indexing if the object has not changed Summary: Fixes T9890. This allows IndexExtensions to emit an object version. Before we build indexes, we check if the indexed version is the same as the current version. If it is, we just don't call that extension. T9890 has a case where this is useful: a script went crazy and posted thousands of comments to a single task. Without versioning, that results in the same comments being indexed over and over again. With versioning, most of the queue could just exit without doing any work. Test Plan: - Added a `sleep(1)` to the actual indexing, used `bin/search index --background` to queue up a lot of tasks, ran them with `bin/phd debug task`, saw them complete very quickly with only one actual index operation performed. - Used `bin/search index --trace` and `bin/search index --trace --background` to observe the behavior of queries against the index version store, which looked sensible. - Made comments/transactions, saw versions update. - Used `bin/remove destroy`, verified index versions were purged. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9890 Differential Revision: https://secure.phabricator.com/D14845
2015-12-21 20:04:08 +01:00
'PhabricatorSearchIndexVersion' => 'PhabricatorSearchDAO',
'PhabricatorSearchIndexVersionDestructionEngineExtension' => 'PhabricatorDestructionEngineExtension',
Improve Search architecture Summary: The search indexing API has several problems right now: - Always runs in-process. - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it. - Being able to use the task queue will also make rebuilding indexes faster. - Instead, make the API phid-oriented. - No uniform indexing API. - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird. - Instead, provide a uniform API. - No uniform CLI. - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers. - Instead, let indexers expose documents for indexing. - Not application-oriented. - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world. - Instead, move indexers to applications and load them with SymbolLoader. Test Plan: - `bin/search index` - Indexed one revision, one task. - Indexed `--type TASK`, `--type DREV`, etc., for all types. - Indexed `--all`. - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it. - Creating users is a pain; searched for a user after indexing. - Creating commits is a pain; searched for a commit after indexing. - Mocks aren't currently loadable in the result view, so their indexing is moot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: 20after4, aran Maniphest Tasks: T1991, T2104 Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
'PhabricatorSearchManagementIndexWorkflow' => 'PhabricatorSearchManagementWorkflow',
Properly create Elasticsearch index Summary: When the index does not exist and auto_create_index isn't enabled, running ./bin/index results in a failure. That's T5990 Instead create an index properly. This also allows us to do nice things like do a proper mapping and analysis like for substring matching like outlined by @fabe in T6552. Test Plan: Deleted and created index multiple times to verify proper index creation and usage. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, manybubbles, chasemp, fabe, epriestley Differential Revision: https://secure.phabricator.com/D10955
2014-12-22 22:10:52 +01:00
'PhabricatorSearchManagementInitWorkflow' => 'PhabricatorSearchManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorSearchManagementWorkflow' => 'PhabricatorManagementWorkflow',
Implement basic ngram search for Owners Package names Summary: Ref T9979. This uses ngrams (specifically, trigrams) to build a reasonably efficient index for substring matching. Specifically, for a package like "Example", with ID 123, we store rows like this: ``` < ex, 123> <exa, 123> <xam, 123> <amp, 123> <mpl, 123> <ple, 123> <le , 123> ``` When the user searches for `exam`, we join this table for packages with tokens `exa` and `xam`. MySQL can do this a lot more efficiently than it can process a `LIKE "%exam%"` query against a huge table. When the user searches for a one-letter or two-letter string, we only search the beginnings of words. This is probably what they want, the only thing we can do quickly, and a reasonable/expected behavior for typeaheads. Test Plan: - Ran storage upgrades and search indexer. - Searched for stuff with "name contains". - Used typehaead and got sensible results. - Searched for `aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz` and saw only 16 joins. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14846
2015-12-21 21:22:07 +01:00
'PhabricatorSearchNgrams' => 'PhabricatorSearchDAO',
'PhabricatorSearchNgramsDestructionEngineExtension' => 'PhabricatorDestructionEngineExtension',
Allow named queries to be reordered by dragging Summary: Also you have to drop them. So drag, and then drop. This needs some cleanup and reconciliation/generalization with the Maniphest implementation. In particular, you can't drag things to the very top right now, and they should share more CSS and more behaviors. Test Plan: Look I alphabetized them: {F45286} Reviewers: chad Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6136
2013-06-06 01:22:27 +02:00
'PhabricatorSearchOrderController' => 'PhabricatorSearchBaseController',
Support ordering in SearchField Summary: Ref T8441. Ref T7715. Automatically generate a modern "Order" control in ApplicationSearch for engines which fully support SearchField. Notably, this allows the standard "Order" control to automatically support custom field orders. We do this in Maniphest today, but in an ad-hoc way. Test Plan: Performed order-by queries in Almanac (Services), Pholio, Files, People, Projects, and Paste. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13193
2015-06-08 21:21:48 +02:00
'PhabricatorSearchOrderField' => 'PhabricatorSearchField',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorSearchPreferencesSettingsPanel' => 'PhabricatorSettingsPanel',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorSearchRelationship' => 'Phobject',
Improve search result listing Summary: Make it prettier, paginate, add user pictures, show document types, clean some stuff up a little. Plenty of room for improvement but this should make it a lot more useful. Test Plan: Here's what the new one looks like: https://secure.phabricator.com/file/view/PHID-FILE-edce2b83c2e3a121c2b7/ Reviewed By: jungejason Reviewers: tomo, jungejason, aran, tuomaspelkonen, mroch Commenters: tomo CC: aran, tomo, jungejason, epriestley Differential Revision: 545
2011-06-28 23:35:02 +02:00
'PhabricatorSearchResultView' => 'AphrontView',
Add an edge table to the `search` database Summary: Fixes T10778. This is a result of T10262: when we save a form configuration and adjust the policy, we try to scramble attached file secrets. There aren't going to be any attached files, but there's also no edge table, so we fail. We could skip this code, but we'll likely need an edge table here sooner or later so it's probably simpler in the long run to just add an empty one. Test Plan: - Ran `bin/storage upgrade`, got a clean bill of health. - Saved a form configuration after making a policy edit, no more `edge` exception. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10778 Differential Revision: https://secure.phabricator.com/D15803
2016-04-26 20:19:03 +02:00
'PhabricatorSearchSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Add "final" to all Phabricator "Controller" classes Summary: These are all unambiguously unextensible. Issues I hit: - Maniphest Change/Diff controllers, just consolidated them. - Some search controllers incorrectly extend from "Search" but should extend from "SearchBase". This has no runtime effects. - D1836 introduced a closure, which we don't handle correctly (somewhat on purpose; we target PHP 5.2). See T962. Test Plan: Ran "testEverythingImplemented" unit test to identify classes extending from `final` classes. Resolved issues. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T795 Differential Revision: https://secure.phabricator.com/D1843
2012-03-10 00:46:25 +01:00
'PhabricatorSearchSelectController' => 'PhabricatorSearchBaseController',
Move Projects to SearchFields Summary: Ref T8441. Ref T7715. This is mostly about getting SearchFields + CustomFields working. (This includes a couple of SearchFields which aren't used quite yet.) Test Plan: - Used all search controls. - Defined custom fields and searched for them. - Created an old saved search which searches on custom fields on master, switched to this patch, search worked exaclty as written. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13189
2015-06-08 21:20:16 +02:00
'PhabricatorSearchSelectField' => 'PhabricatorSearchField',
Begin modularizing fields in SearchEngines Summary: Ref T8441. Ref T7715. Add a layer of indirection to fields in search engines. This will allow us to: - Simplify SearchEngine code, which has collected a lot of duplication around expressing what is effectively field types. - Automatically add fields like "Spaces" and "Projects" (primary driver for T8441). - Reorder or hide fields (not sure if we really want to do this, but it seems plausible, and this will let us play around with it, at least). - Drive Conduit Query methods via SearchEngines, so the same code specifies both the search UI and the `application.query` endpoint (primary driver in T7715). Test Plan: - Searched for stuff in Paste, everything behaved exaclty like it used to (except that I removed the "no language" checkbox, which seemed like fluff from a bygone era). - Searched for stuff in other applications, saw no changes. - Hit date field errors. - Used query strings to specify values. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13169
2015-06-05 20:21:08 +02:00
'PhabricatorSearchStringListField' => 'PhabricatorSearchField',
Make Subscribers automatically provide working SearchFields Summary: Ref T8441. Ref T7715. For modern Query classes, automatically make subscriber queries and SearchField integrations work. In particular, we can just drive this query with EdgeLogic and don't need to do anything specific on these Query classes beyond making sure they're implemented in a way that picks up all of the EdgeLogic clauses. Test Plan: - Searched for subscribers in Pholio, Files, Paste, and Projects. - Searched for all other fields in Projects to check that Query changes are OK. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13191
2015-06-08 21:20:53 +02:00
'PhabricatorSearchSubscribersField' => 'PhabricatorSearchTokenizerField',
Move Projects to SearchFields Summary: Ref T8441. Ref T7715. This is mostly about getting SearchFields + CustomFields working. (This includes a couple of SearchFields which aren't used quite yet.) Test Plan: - Used all search controls. - Defined custom fields and searched for them. - Created an old saved search which searches on custom fields on master, switched to this patch, search worked exaclty as written. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13189
2015-06-08 21:20:16 +02:00
'PhabricatorSearchTextField' => 'PhabricatorSearchField',
Convert Files to SearchFields Summary: Ref T8441. Ref T7715. - Update FileSearchEngine. - Nothing too special/fancy. Test Plan: - Searched for various files. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13175
2015-06-07 16:32:09 +02:00
'PhabricatorSearchThreeStateField' => 'PhabricatorSearchField',
Begin modularizing fields in SearchEngines Summary: Ref T8441. Ref T7715. Add a layer of indirection to fields in search engines. This will allow us to: - Simplify SearchEngine code, which has collected a lot of duplication around expressing what is effectively field types. - Automatically add fields like "Spaces" and "Projects" (primary driver for T8441). - Reorder or hide fields (not sure if we really want to do this, but it seems plausible, and this will let us play around with it, at least). - Drive Conduit Query methods via SearchEngines, so the same code specifies both the search UI and the `application.query` endpoint (primary driver in T7715). Test Plan: - Searched for stuff in Paste, everything behaved exaclty like it used to (except that I removed the "no language" checkbox, which seemed like fluff from a bygone era). - Searched for stuff in other applications, saw no changes. - Hit date field errors. - Used query strings to specify values. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7715, T8441 Differential Revision: https://secure.phabricator.com/D13169
2015-06-05 20:21:08 +02:00
'PhabricatorSearchTokenizerField' => 'PhabricatorSearchField',
Perform search indexing in the worker queue and respect `bin/search index --background` Summary: Fixes T3857. Earlier work made this trivial and just left product questions, which I've answered by requiring the daemons to run on reasonable installs. Test Plan: Ran `bin/search index` and `bin/search index --background`. Observed indexes write in the former case and tasks queue in the latter case. Commented with a unique string on a revision and searched for it a moment later, got exactly one result (that revision), verifying that reindexing works correctly. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3857 Differential Revision: https://secure.phabricator.com/D7966
2014-01-14 22:22:56 +01:00
'PhabricatorSearchWorker' => 'PhabricatorWorker',
Add the "Security" config group options. Summary: Added all the "Security" group options listed in T2255. Test Plan: - Looked at all the options. - Tested validation on `security.alternate-file-domain` Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4334
2013-01-03 14:45:23 +01:00
'PhabricatorSecurityConfigOptions' => 'PhabricatorApplicationConfigOptions',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorSecuritySetupCheck' => 'PhabricatorSetupCheck',
Implement a basic version of ApplicationEditor in Paste Summary: Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste. This mostly looks and works like ApplicationSearch, and is heavily modeled on it. Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else. This has no functional changes, except: - I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it. - Subscribers are now editable. - Form field order is a little goofy (this will be fixed in a future diff). - Subscribers and projects are now race-resistant. The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits. Test Plan: - Created pastes. - Created pastes via API. - Edited pastes. - Edited every field. - Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4768, T9132 Differential Revision: https://secure.phabricator.com/D14390
2015-11-03 03:58:32 +01:00
'PhabricatorSelectEditField' => 'PhabricatorEditField',
Bring SendGrid configuration into PHP Summary: Port more settings. Test Plan: Looked at, edited settings. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4442
2013-01-15 21:04:05 +01:00
'PhabricatorSendGridConfigOptions' => 'PhabricatorApplicationConfigOptions',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorSessionsSettingsPanel' => 'PhabricatorSettingsPanel',
Add semi-generic rate limiting infrastructure Summary: This adds a system which basically keeps a record of recent actions, who took them, and how many "points" they were worth, like: epriestley email.add 1 1233989813 epriestley email.add 1 1234298239 epriestley email.add 1 1238293981 We can use this to rate-limit actions by examining how many actions the user has taken in the past hour (i.e., their total score) and comparing that to an allowed limit. One major thing I want to use this for is to limit the amount of error email we'll send to an email address. A big concern I have with sending more error email is that we'll end up in loops. We have some protections against this in headers already, but hard-limiting the system so it won't send more than a few errors to a particular address per hour should provide a reasonable secondary layer of protection. This use case (where the "actor" needs to be an email address) is why the table uses strings + hashes instead of PHIDs. For external users, it might be appropriate to rate limit by cookies or IPs, too. To prove it works, I rate limited adding email addresses. This is a very, very low-risk security thing where a user with an account can enumerate addresses (by checking if they get an error) and sort of spam/annoy people (by adding their address over and over again). Limiting them to 6 actions / hour should satisfy all real users while preventing these behaviors. Test Plan: This dialog is uggos but I'll fix that in a sec: {F137406} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8683
2014-04-03 20:22:38 +02:00
'PhabricatorSettingsAddEmailAction' => 'PhabricatorSystemAction',
Move Settings to a separate directory Summary: We currently have two relatively distinct applications, "People" and "Settings", living in /people/. Move settings to its own directory. This renames a couple of classes but makes no real code changes. Test Plan: Browsed /settings/, changed some settings. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569, T631 Differential Revision: https://secure.phabricator.com/D3256
2012-08-13 21:37:18 +02:00
'PhabricatorSettingsAdjustController' => 'PhabricatorController',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorSettingsApplication' => 'PhabricatorApplication',
Move Settings to a separate directory Summary: We currently have two relatively distinct applications, "People" and "Settings", living in /people/. Move settings to its own directory. This renames a couple of classes but makes no real code changes. Test Plan: Browsed /settings/, changed some settings. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569, T631 Differential Revision: https://secure.phabricator.com/D3256
2012-08-13 21:37:18 +02:00
'PhabricatorSettingsMainController' => 'PhabricatorController',
Begin modularizing main menu items Summary: Ref T10077. Ref T8918. The way the main menu is built is not very modular and fairly hacky. It assumes menus are provided by applications, but this isn't exactly true. Notably, the "Quick Create" menu is not per-application. The current method of building this menu is very inefficient (see T10077). Particularly, we have to build it //twice// because we need to build it once to render the item and then again to render the dropdown options. Start cleaning this up. This diff doesn't actually have any behavioral changes, since I can't swap the menu over until we get rid of all the other items and I haven't extended this to Notifications/Conpherence yet so it doesn't actually fix T8918. Test Plan: Viewed menus while logged in, logged out, in different applications, in desktop/mobile. Nothing appeared different. Reviewers: chad Reviewed By: chad Maniphest Tasks: T8918, T10077 Differential Revision: https://secure.phabricator.com/D14922
2016-01-01 13:26:36 +01:00
'PhabricatorSettingsMainMenuBarExtension' => 'PhabricatorMainMenuBarExtension',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorSettingsPanel' => 'Phobject',
'PhabricatorSetupCheck' => 'Phobject',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhabricatorSetupCheckTestCase' => 'PhabricatorTestCase',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorSetupIssue' => 'Phobject',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorSetupIssueUIExample' => 'PhabricatorUIExample',
Detect and raise setup warnings from within Phabricator Summary: This is basicaly a light version of D4286. The major problem with D4286 is that it's a huge leap and completely replaces the setup process in one step. Instead, I want to do this: - Add the post-setup warnings (yellow bar with "6 unresolved warnings..."). - Copy all setup checks into post-setup warnings (so every check has an old-style check and a new-style check). - Run that for a little bit and make sure it's stable. - Implement fatal post-setup checks (the red screen, vs the yellow bar). - Run that for a little bit. - Nuke setup mode and delete all the old checks. This should give us a bunch of very gradual steps toward the brave new world of simpler setup. Test Plan: - Faked APC setup failures, saw warnings raise. - Verified that this runs after restart (get + set). - Verified that this costs us only one cache hit after first-run (get only). Reviewers: btrahan, codeblock, vrana, chad Reviewed By: codeblock CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4295
2012-12-30 15:37:49 +01:00
'PhabricatorSetupIssueView' => 'AphrontView',
Allow a domain other than the install domain to serve as a short Phurl domain Summary: Ref T8995, config option for Phurl short domain to share shortened URL's Test Plan: - Configure Phurl short domain to something like "zz.us" - Navigate to `zz.us`; get 404 - Navigate to `zz.us/u/3` or `zz.us/u/alias` where `U3` is an existing Phurl; redirect to correct destination Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Maniphest Tasks: T8995 Differential Revision: https://secure.phabricator.com/D14447
2015-11-09 19:09:19 +01:00
'PhabricatorShortSite' => 'PhabricatorSite',
Roughly generate transaction-oriented API methods from EditEngines Summary: Ref T5873. Ref T9132. This is really rough and feels pretty flimsy at the edges (missing validation, generality, modularity, clean error handling, etc) but gets us most of the way toward generating plausible "whatever.edit" Conduit API methods from EditEngines. These methods are full-power methods which can do everything the edit form can, automatically support the same range of operations, and update when new fields are added. Test Plan: - Used new `paste.edit` to create a new Paste. - Used new `paste.edit` to update an existing paste. - Applied a variety of different transactions. - Hit a reasonable set of errors. {F941144} {F941145} {F941146} {F941147} Reviewers: chad Reviewed By: chad Maniphest Tasks: T5873, T9132 Differential Revision: https://secure.phabricator.com/D14393
2015-11-03 17:45:00 +01:00
'PhabricatorSimpleEditType' => 'PhabricatorEditType',
Modularize Aphront "sites" Summary: Fixes T5702. The path here is long and windy: - I want to move `blog.phacility.com` to the new `secure` host. - That host has `security.require-https` set, which I want to keep set (before, this was handled in a sort of hacky way at the nginx/preamble level, but I've cleaned up everything else now). - Currently, that setting forces blogs to HTTPS too, which won't work. - To let blogs be individually configurable, we need to either modularize site config or make things hackier. - Modularize rather than increasing hackiness. - Also add a little "modules" panel in Config. See T6859. This feels like a reasonable middle ground between putting this stuff in Applications and burying it in `bin/somewhere`. Test Plan: - Visited normal site. - Visited phame on-domain site. - Visited phame off-domain site. - Viewed static resources. {F561897} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D13474
2015-06-29 23:04:48 +02:00
'PhabricatorSite' => 'AphrontSite',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorSlowvoteApplication' => 'PhabricatorApplication',
Port the "Slowvote" application Summary: Port slowvote. This has some style/layout roughness but gets us most of the way there. I'll followup to fix some of the markup issues. Test Plan: Created and voted in several different kinds of poll. Reviewed By: codeblock Reviewers: codeblock, tomo, jungejason, aran, tuomaspelkonen Commenters: aran, jungejason CC: aran, codeblock, jungejason, epriestley Differential Revision: 613
2011-07-08 20:13:11 +02:00
'PhabricatorSlowvoteChoice' => 'PhabricatorSlowvoteDAO',
Ability to close poll Summary: Fixes T3566 List of poll actions should include ability to close an open poll or reopen a closed poll. Test Plan: Poll author should be able to close/reopen poll. Non-author should get policy screen when attempting to close/reopen poll. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T3566 Differential Revision: https://secure.phabricator.com/D8846
2014-04-24 21:00:31 +02:00
'PhabricatorSlowvoteCloseController' => 'PhabricatorSlowvoteController',
Restore Slowvote commenting with ApplicationTransactions Summary: Now it works like everything else does. Test Plan: {F50168} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6455
2013-07-15 13:45:43 +02:00
'PhabricatorSlowvoteCommentController' => 'PhabricatorSlowvoteController',
Port the "Slowvote" application Summary: Port slowvote. This has some style/layout roughness but gets us most of the way there. I'll followup to fix some of the markup issues. Test Plan: Created and voted in several different kinds of poll. Reviewed By: codeblock Reviewers: codeblock, tomo, jungejason, aran, tuomaspelkonen Commenters: aran, jungejason CC: aran, codeblock, jungejason, epriestley Differential Revision: 613
2011-07-08 20:13:11 +02:00
'PhabricatorSlowvoteController' => 'PhabricatorController',
'PhabricatorSlowvoteDAO' => 'PhabricatorLiskDAO',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'PhabricatorSlowvoteDefaultViewCapability' => 'PhabricatorPolicyCapability',
Make most slowvote fields edit transactionally Summary: No support for responses yet, since they're more complicated, but put everything else on the transactions plan. This also prepares polls for editability, shortly. Test Plan: {F50205} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6460
2013-07-15 19:50:38 +02:00
'PhabricatorSlowvoteEditController' => 'PhabricatorSlowvoteController',
Restore Slowvote commenting with ApplicationTransactions Summary: Now it works like everything else does. Test Plan: {F50168} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6455
2013-07-15 13:45:43 +02:00
'PhabricatorSlowvoteEditor' => 'PhabricatorApplicationTransactionEditor',
Move Slowvote rendering into SearchEngine Summary: Ref T4986. This adds a bit of structure for handles, since we used to have Controller utilities but no longer do. Hopefully these will start going faster soon... Test Plan: - Checked feed for collateral damage. - Checked slowvote for collateral damage. - Made a slowvote panel. {F151550} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9010
2014-05-08 17:40:59 +02:00
'PhabricatorSlowvoteListController' => 'PhabricatorSlowvoteController',
Add mail/feed to Slowvote Summary: Adds mailkeys, basic structure for publishing to feed, sending mail. Test Plan: New Poll, vote, comment, etc. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13749
2015-08-02 00:41:08 +02:00
'PhabricatorSlowvoteMailReceiver' => 'PhabricatorObjectMailReceiver',
Port the "Slowvote" application Summary: Port slowvote. This has some style/layout roughness but gets us most of the way there. I'll followup to fix some of the markup issues. Test Plan: Created and voted in several different kinds of poll. Reviewed By: codeblock Reviewers: codeblock, tomo, jungejason, aran, tuomaspelkonen Commenters: aran, jungejason CC: aran, codeblock, jungejason, epriestley Differential Revision: 613
2011-07-08 20:13:11 +02:00
'PhabricatorSlowvoteOption' => 'PhabricatorSlowvoteDAO',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorSlowvotePoll' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorSlowvoteDAO',
Transactions - deploy buildTransactionTimeline against a few more applications Summary: Ref T4712. Thus far, it seems that most "non-standard" things can be done pretty easily in the controller. Aside from deploying, this diff had to fix a few bugs / missing implementations of stuff. (Notably, PhabricatorAuthProviderConfig, HeraldRule, PhabricatorSlowvotePoll, and AlmanacNetwork needed to implement PhabricatorApplicationTransactionInterface, PhabricatorAuthAuthProviderPHIDType had to be added, and a rendering bug in transactions of type PhabricatorOAuth2AuthProvider had to be fixed.) Test Plan: Almanac - looked at binding, device, network, and service view controllers and verified timeline displayed properly. Herald - looked at a rule and verified timeline. Slowvote - looked at a vote and verified timeline. Auth - looked at an auth provider (Facebook) and verified proper display of transactions within timeline. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10921
2014-12-02 23:33:59 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
'PhabricatorSubscribableInterface',
'PhabricatorFlaggableInterface',
'PhabricatorTokenReceiverInterface',
'PhabricatorProjectInterface',
Disable notifications while running unit tests Summary: Currently, we'll try to publish notifications while running tests. This is at best unnecessary and at worst problematic (we don't stub out the server). For now, just never publish them. Test Plan: Ran unit tests with notifications enabled but the server down and didn't get a bunch of warnings. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D10171
2014-08-07 00:27:57 +02:00
'PhabricatorDestructibleInterface',
Implements Spaces application in Slowvote Summary: Implements T8733 Test Plan: Verify that spaces policies can be implemented in the creation and editing of polls. Reviewers: lpriestley, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13537
2015-07-14 16:45:38 +02:00
'PhabricatorSpacesInterface',
Add PhabricatorSlowvoteQuery Summary: Ref T603. Ref T2625. Start pushing Slowvote (the greatest app of all time) into the modern era. Test Plan: Looked at vote detail. Used `V1` and `{V1}` embeds. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6444
2013-07-13 19:41:30 +02:00
),
Port the "Slowvote" application Summary: Port slowvote. This has some style/layout roughness but gets us most of the way there. I'll followup to fix some of the markup issues. Test Plan: Created and voted in several different kinds of poll. Reviewed By: codeblock Reviewers: codeblock, tomo, jungejason, aran, tuomaspelkonen Commenters: aran, jungejason CC: aran, codeblock, jungejason, epriestley Differential Revision: 613
2011-07-08 20:13:11 +02:00
'PhabricatorSlowvotePollController' => 'PhabricatorSlowvoteController',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorSlowvotePollPHIDType' => 'PhabricatorPHIDType',
Use ApplicationSearch in Slowvote Summary: Ref T2625. Ref T603. Make the vote list policy-aware, mobile-friendly, and use ApplicationSearch. Test Plan: {F50022} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6445
2013-07-13 19:41:49 +02:00
'PhabricatorSlowvoteQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add mail/feed to Slowvote Summary: Adds mailkeys, basic structure for publishing to feed, sending mail. Test Plan: New Poll, vote, comment, etc. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13749
2015-08-02 00:41:08 +02:00
'PhabricatorSlowvoteReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Generate expected schemata for Workers, XHProf, PHPAAST, Tokens, System, Slowvote Summary: T1191. Nothing very notable here. Test Plan: Saw more blue in web UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D10522
2014-09-19 14:45:24 +02:00
'PhabricatorSlowvoteSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Use ApplicationSearch in Slowvote Summary: Ref T2625. Ref T603. Make the vote list policy-aware, mobile-friendly, and use ApplicationSearch. Test Plan: {F50022} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6445
2013-07-13 19:41:49 +02:00
'PhabricatorSlowvoteSearchEngine' => 'PhabricatorApplicationSearchEngine',
Migrate Slowvote comments to ApplicationTransactions Summary: Move comments from the old table to ApplicationTransactions. Patch dances around which objects it uses since I intend to delete the comment table. NOTE: This temporarily disables comment writes. I'll restore them shortly. Test Plan: {F50166} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6454
2013-07-15 13:20:10 +02:00
'PhabricatorSlowvoteTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorSlowvoteTransactionComment' => 'PhabricatorApplicationTransactionComment',
'PhabricatorSlowvoteTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Embed slowvotes have basic interaction Summary: User can now vote through embed slowvote Test Plan: Voted'n stuff Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad, AnhNhan Maniphest Tasks: T2883 Differential Revision: https://secure.phabricator.com/D5743
2013-05-04 00:48:59 +02:00
'PhabricatorSlowvoteVoteController' => 'PhabricatorSlowvoteController',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorSlug' => 'Phobject',
PhabricatorSlug Summary: This is to be used in Phame so the logic is shared where possible. The change has three main things going on - broke out functionality from PhrictionDocument that isn't Phriction specific. - swept up code base to use new PhabricatorSlug class. - altered the regex ever so slightly per discussion and http://stackoverflow.com/questions/2028022/javascript-how-to-convert-unicode-string-to-ascii I think maybe we should punt on unicode here for quite a bit -- http://www.456bereastreet.com/archive/201006/be_careful_with_non-ascii_characters_in_urls/ -- but we'll be well-positioned to add it with the code here. Test Plan: used phriction to create, edit, view documents. used a tool (codemod) for the codebase sweeping Reviewers: epriestley Reviewed By: epriestley CC: aran Differential Revision: https://secure.phabricator.com/D2195
2012-04-10 23:18:20 +02:00
'PhabricatorSlugTestCase' => 'PhabricatorTestCase',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorSortTableUIExample' => 'PhabricatorUIExample',
Modernize Paste Summary: - Add a PhabricatorApplication. - Make most of the views work well on tablets / phones. The actual "Create" form doesn't, but everything else is good -- need to make device-friendly form layouts before I can do the form. Test Plan: Will attach screenshots. Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3293
2012-08-15 19:45:06 +02:00
'PhabricatorSourceCodeView' => 'AphrontView',
Implement a basic version of ApplicationEditor in Paste Summary: Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste. This mostly looks and works like ApplicationSearch, and is heavily modeled on it. Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else. This has no functional changes, except: - I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it. - Subscribers are now editable. - Form field order is a little goofy (this will be fixed in a future diff). - Subscribers and projects are now race-resistant. The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits. Test Plan: - Created pastes. - Created pastes via API. - Edited pastes. - Edited every field. - Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4768, T9132 Differential Revision: https://secure.phabricator.com/D14390
2015-11-03 03:58:32 +01:00
'PhabricatorSpaceEditField' => 'PhabricatorEditField',
Spaces - re-jigger application name for new Spaces application Summary: got some errors in my sandbox when I updated. this fixes them and I think is the right naming convention. Test Plan: /settings/panel/emailpreferences/ started working again! /spaces/ also loaded unit tests passed without errors Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T8377 Differential Revision: https://secure.phabricator.com/D13103
2015-06-01 23:54:18 +02:00
'PhabricatorSpacesApplication' => 'PhabricatorApplication',
Allow Spaces to be archived Summary: Ref T8377. This adds a standard disable/enable feature to Spaces, with a couple of twists: - You can't create new stuff in an archived space, and you can't move stuff into an archived space. - We don't show results from an archived space by default in ApplicationSearch queries. You can still find these objects if you explicitly search for "Spaces: <the archived space>". So this is a "put it in a box in the attic" sort of operation, but that seems fairly nice/reasonable. Test Plan: - Archived and activated spaces. - Used ApplicationSearch, which omitted archived objects by default but allowed searches for them, specifically, to succeed. - Tried to create objects into an archived space (this is not allowed). - Edited objects in an archived space (this is OK). Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8377 Differential Revision: https://secure.phabricator.com/D13238
2015-06-11 19:13:47 +02:00
'PhabricatorSpacesArchiveController' => 'PhabricatorSpacesController',
Add "Spaces", an application for managing policy namespaces Summary: Ref T3820. This doesn't actually do anything yet, but dumps in all the plumbing. Test Plan: {F156989} {F156990} {F156991} Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, wienczny, jdloft, devurandom, thz, hwinkel, 20after4, sascha-egerer, seporaitis, joshuaspence, chad, epriestley Maniphest Tasks: T3820 Differential Revision: https://secure.phabricator.com/D9204
2015-06-01 20:28:38 +02:00
'PhabricatorSpacesCapabilityCreateSpaces' => 'PhabricatorPolicyCapability',
'PhabricatorSpacesCapabilityDefaultEdit' => 'PhabricatorPolicyCapability',
'PhabricatorSpacesCapabilityDefaultView' => 'PhabricatorPolicyCapability',
'PhabricatorSpacesController' => 'PhabricatorController',
'PhabricatorSpacesDAO' => 'PhabricatorLiskDAO',
'PhabricatorSpacesEditController' => 'PhabricatorSpacesController',
'PhabricatorSpacesInterface' => 'PhabricatorPHIDInterface',
'PhabricatorSpacesListController' => 'PhabricatorSpacesController',
'PhabricatorSpacesNamespace' => array(
'PhabricatorSpacesDAO',
'PhabricatorPolicyInterface',
'PhabricatorApplicationTransactionInterface',
Implement DestructibleInterface on Spaces, add some basic tests Summary: Ref T8377. Mostly just a framework for test coverage. Test Plan: Tests pass. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8377 Differential Revision: https://secure.phabricator.com/D13102
2015-06-01 21:02:20 +02:00
'PhabricatorDestructibleInterface',
Add "Spaces", an application for managing policy namespaces Summary: Ref T3820. This doesn't actually do anything yet, but dumps in all the plumbing. Test Plan: {F156989} {F156990} {F156991} Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, wienczny, jdloft, devurandom, thz, hwinkel, 20after4, sascha-egerer, seporaitis, joshuaspence, chad, epriestley Maniphest Tasks: T3820 Differential Revision: https://secure.phabricator.com/D9204
2015-06-01 20:28:38 +02:00
),
Support PhabricatorSpacesInterface in ApplicationSearch UI Summary: Ref T8441. Does what it says, provided other conditions (like using the new SearchField stuff) are fulfilled. Test Plan: {F473836} {F473837} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8441 Differential Revision: https://secure.phabricator.com/D13171
2015-06-05 20:21:45 +02:00
'PhabricatorSpacesNamespaceDatasource' => 'PhabricatorTypeaheadDatasource',
Add "Spaces", an application for managing policy namespaces Summary: Ref T3820. This doesn't actually do anything yet, but dumps in all the plumbing. Test Plan: {F156989} {F156990} {F156991} Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, wienczny, jdloft, devurandom, thz, hwinkel, 20after4, sascha-egerer, seporaitis, joshuaspence, chad, epriestley Maniphest Tasks: T3820 Differential Revision: https://secure.phabricator.com/D9204
2015-06-01 20:28:38 +02:00
'PhabricatorSpacesNamespaceEditor' => 'PhabricatorApplicationTransactionEditor',
'PhabricatorSpacesNamespacePHIDType' => 'PhabricatorPHIDType',
'PhabricatorSpacesNamespaceQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhabricatorSpacesNamespaceSearchEngine' => 'PhabricatorApplicationSearchEngine',
'PhabricatorSpacesNamespaceTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorSpacesNamespaceTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
When an install has spaces but a user has no access, roadblock them Summary: Ref T8449. If a user doesn't have access to any spaces, most applications just don't work, and they fail in confusing ways. Just lock users out of everything explicitly up front with a clear message instead of letting them stumble into a big broken mess. Test Plan: Locked a user out of all spaces, saw error to that effect. Reviewers: btrahan, eadler Reviewed By: eadler Subscribers: eadler, epriestley Maniphest Tasks: T8449 Differential Revision: https://secure.phabricator.com/D13545
2015-07-03 22:03:33 +02:00
'PhabricatorSpacesNoAccessController' => 'PhabricatorSpacesController',
Add a Spaces remarkup rule Summary: Ref T8449. Test Plan: {F474032} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8449 Differential Revision: https://secure.phabricator.com/D13172
2015-06-05 23:19:40 +02:00
'PhabricatorSpacesRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Add a "Description" field to Spaces Summary: Ref T8377. - Add a description field. - Add edges so files can be attached. Test Plan: {F492410} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8377 Differential Revision: https://secure.phabricator.com/D13235
2015-06-11 00:53:51 +02:00
'PhabricatorSpacesSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Implement a rough initial version of ApplicationSearch-driven Conduit read endpoints Summary: Ref T9964. See that task for some context and discussion. Ref T7715, which has the bigger picture here. Basically, I want Conduit read endpoints to be full-power, ApplicationSearch-driven endpoints, so that applications can: - Write one EditEngine and get web + conduit writes for free. - Write one SearchEngine and get web + conduit reads for free. I previously made some steps toward this, but this puts more of the structure in place. Test Plan: Viewed API console endpoint and read 20 pages of docs: {F1021961} Made various calls: with query keys, constraints, pagination, and limits. Viewed new {nav Config > Modules} page. Reviewers: chad Reviewed By: chad Maniphest Tasks: T7715, T9964 Differential Revision: https://secure.phabricator.com/D14743
2015-12-11 17:45:56 +01:00
'PhabricatorSpacesSearchEngineExtension' => 'PhabricatorSearchEngineExtension',
Move some PhabricatorSearchField subclasses Summary: Move some `PhabricatorSearchField` subclasses to be adjacent to the application to which they belong. This seems generally better to me than lumping them all together in the `src/applications/search/field/` directory. I was also wondering if it makes sense to rename these subclasses as `PhabricatorXSearchField` rather than `PhabricatorSearchXField` (as per T5655), but wasn't really sure if these objects are meant to be search-fields, or just fields belonging to the #search application. Test Plan: N/A. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13374
2015-07-06 14:52:04 +02:00
'PhabricatorSpacesSearchField' => 'PhabricatorSearchTokenizerField',
Implement DestructibleInterface on Spaces, add some basic tests Summary: Ref T8377. Mostly just a framework for test coverage. Test Plan: Tests pass. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8377 Differential Revision: https://secure.phabricator.com/D13102
2015-06-01 21:02:20 +02:00
'PhabricatorSpacesTestCase' => 'PhabricatorTestCase',
Add "Spaces", an application for managing policy namespaces Summary: Ref T3820. This doesn't actually do anything yet, but dumps in all the plumbing. Test Plan: {F156989} {F156990} {F156991} Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, wienczny, jdloft, devurandom, thz, hwinkel, 20after4, sascha-egerer, seporaitis, joshuaspence, chad, epriestley Maniphest Tasks: T3820 Differential Revision: https://secure.phabricator.com/D9204
2015-06-01 20:28:38 +02:00
'PhabricatorSpacesViewController' => 'PhabricatorSpacesController',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
'PhabricatorStandardCustomField' => 'PhabricatorCustomField',
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 16:15:25 +02:00
'PhabricatorStandardCustomFieldBlueprints' => 'PhabricatorStandardCustomFieldTokenizer',
Implement standard field "bool" type Summary: Depends on D7005. Implements the existing "bool" type. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7006
2013-09-17 01:03:51 +02:00
'PhabricatorStandardCustomFieldBool' => 'PhabricatorStandardCustomField',
Implement a "credential" standard custom field Summary: Ref T4590. Ref T1049. This is primarily intended to support HTTP auth in Harbormaster. Test Plan: Added a field, edited it, etc. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4590, T1049 Differential Revision: https://secure.phabricator.com/D8607
2014-03-26 00:13:27 +01:00
'PhabricatorStandardCustomFieldCredential' => 'PhabricatorStandardCustomField',
Provide a generic "Datasource" StandardCustomField Summary: Ref T9253. See discussion in D13843. I want to let Drydock blueprints for Almanac services choose those services from a typeahead, but only list appropriate services in the typeahead. To do this: - Provide a StandardCustomField for an arbitrary datasource. - Adjust the AlmanacServiceDatasource to allow filtering by service class. This implementation is substantially the same as the one in D13843, with some adjustments: - I lifted most of the code in the `Users` standard custom field into a new `Tokenizer` standard custom field. - The `Users` and `Datasource` custom fields now extend the `Tokenizer` custom field and can share most of the code it uses. - I exposed this field fully as a configurable field. I don't think anyone will ever use it, but this generality costs us nearly nothing and improves consistency. - The code in D13843 didn't actually pass the parameters over the wire, since the object that responds to the request is not the same object that renders the field. Use the "parameters" mechanism in datasources to get things passed over the wire. Test Plan: - Created a custom "users" field in Maniphest and made sure it still wokred. - Created a custom "almanc services" field in Maniphest and selected some services for a task. - With additional changes from D13843, selected an appropriate Almanac service in a new Drydock blueprint. Reviewers: hach-que, chad Reviewed By: hach-que, chad Maniphest Tasks: T9253 Differential Revision: https://secure.phabricator.com/D14111
2015-09-21 13:41:52 +02:00
'PhabricatorStandardCustomFieldDatasource' => 'PhabricatorStandardCustomFieldTokenizer',
Add a "date" standard custom field Summary: See previous revisions. As maniphest. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7009
2013-09-17 01:04:31 +02:00
'PhabricatorStandardCustomFieldDate' => 'PhabricatorStandardCustomField',
Add a "Header" standard custom field Summary: Ref T418. This is the last of the Maniphest field types, although I have a few more capabilities/options to port over. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D7018
2013-09-17 23:22:04 +02:00
'PhabricatorStandardCustomFieldHeader' => 'PhabricatorStandardCustomField',
Use classes to define standard field types and implement an "int" type Summary: Currently, `ManiphestAuxiliaryFieldDefaultSpecification` uses about a dozen giant `switch` statements to implement stadard field types (int, string, date, bool, select, user, remarkup, etc). This is: - pretty gross; - not extensible; and - doesn't really let us share that much code. I got about halfway through porting a similar implementation into StandardField but I wasn't thrilled with it. Subclass StandardField instead to implement custom field types. Test Plan: Added an "int" custom field, verified it had integer semantics and indexed into the integer index. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7005
2013-09-17 01:03:24 +02:00
'PhabricatorStandardCustomFieldInt' => 'PhabricatorStandardCustomField',
Add link custom field. Summary: Ref T3868. Adds a link custom field that verifies and links to the text provided. Test Plan: Add a custom field with type "link", then enter a well-formed URL in the provided box in the edit task screen. Verify that the URL displays correctly on the task display page. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T3868 Differential Revision: https://secure.phabricator.com/D12543
2015-04-24 20:49:11 +02:00
'PhabricatorStandardCustomFieldLink' => 'PhabricatorStandardCustomField',
Add "user" and "users" standard custom fields Summary: These end up a little weird with subclassing instead of `switch`, but some day we could alias them to one another or something I guess. If I'm feeling brave, I might get rid of the "user" variant when I migrate Maniphest custom field specs, and turn it into "users, limit = 1" or something like that. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7010
2013-09-17 01:04:46 +02:00
'PhabricatorStandardCustomFieldPHIDs' => 'PhabricatorStandardCustomField',
Implement a "remarkup" standard field type Summary: See D7006, etc. This one's easy since exposing it to ApplicationSearch doesn't make much sense. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7008
2013-09-17 01:04:18 +02:00
'PhabricatorStandardCustomFieldRemarkup' => 'PhabricatorStandardCustomField',
Implement a "select" standard custom field type Summary: See D7006, etc. Brings this from Maniphest. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7007
2013-09-17 01:04:08 +02:00
'PhabricatorStandardCustomFieldSelect' => 'PhabricatorStandardCustomField',
Use classes to define standard field types and implement an "int" type Summary: Currently, `ManiphestAuxiliaryFieldDefaultSpecification` uses about a dozen giant `switch` statements to implement stadard field types (int, string, date, bool, select, user, remarkup, etc). This is: - pretty gross; - not extensible; and - doesn't really let us share that much code. I got about halfway through porting a similar implementation into StandardField but I wasn't thrilled with it. Subclass StandardField instead to implement custom field types. Test Plan: Added an "int" custom field, verified it had integer semantics and indexed into the integer index. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7005
2013-09-17 01:03:24 +02:00
'PhabricatorStandardCustomFieldText' => 'PhabricatorStandardCustomField',
Provide a generic "Datasource" StandardCustomField Summary: Ref T9253. See discussion in D13843. I want to let Drydock blueprints for Almanac services choose those services from a typeahead, but only list appropriate services in the typeahead. To do this: - Provide a StandardCustomField for an arbitrary datasource. - Adjust the AlmanacServiceDatasource to allow filtering by service class. This implementation is substantially the same as the one in D13843, with some adjustments: - I lifted most of the code in the `Users` standard custom field into a new `Tokenizer` standard custom field. - The `Users` and `Datasource` custom fields now extend the `Tokenizer` custom field and can share most of the code it uses. - I exposed this field fully as a configurable field. I don't think anyone will ever use it, but this generality costs us nearly nothing and improves consistency. - The code in D13843 didn't actually pass the parameters over the wire, since the object that responds to the request is not the same object that renders the field. Use the "parameters" mechanism in datasources to get things passed over the wire. Test Plan: - Created a custom "users" field in Maniphest and made sure it still wokred. - Created a custom "almanc services" field in Maniphest and selected some services for a task. - With additional changes from D13843, selected an appropriate Almanac service in a new Drydock blueprint. Reviewers: hach-que, chad Reviewed By: hach-que, chad Maniphest Tasks: T9253 Differential Revision: https://secure.phabricator.com/D14111
2015-09-21 13:41:52 +02:00
'PhabricatorStandardCustomFieldTokenizer' => 'PhabricatorStandardCustomFieldPHIDs',
'PhabricatorStandardCustomFieldUsers' => 'PhabricatorStandardCustomFieldTokenizer',
Make mobile navigation work properly by default in more cases Summary: Fixes T5752. This obsoletes a bunch of old patterns and I'll follow up on those with a big "go do a bunch of mechanical code changes" task. Major goals are: - Don't load named queries multiple times on search pages. - Don't require extra code to get standard navigation right on mobile. - Reduce the amount of boilerplate in ListControllers. - Reduce the amount of boilerplate around navigation/menus in all controllers. Specifically, here's what this does: - The StandardPage is now a smarter/more structured object with `setNavigation()` and `setCrumbs()` methods. More rendering decisions are delayed until the last possible moment. - It uses this to automatically add crumb actions to the application menu. - It uses this to automatically reuse one SearchEngine instead of running queries multiple times. - The new preferred way to build responses is `$this->newPage()` (like `$this->newDialog()`), which has structured methods for adding stuff (`setTitle()`, etc). - SearchEngine exposes a new convenience method so you don't have to do all the controller delegation stuff. - Building menus is generally simpler. Test Plan: - Tested paste list, view, edit, comment, raw controllers for functionality, mobile menu, crumbs, navigation menu. - Edited saved queries. - Tested Differential, Maniphest (no changes). - Verified the paste pages don't run any duplicate NamedQuery queries. Reviewers: chad Reviewed By: chad Maniphest Tasks: T5752 Differential Revision: https://secure.phabricator.com/D14382
2015-11-02 21:06:28 +01:00
'PhabricatorStandardPageView' => array(
'PhabricatorBarePageView',
'AphrontResponseProducerInterface',
),
Support "Select" custom fields in Herald rules Summary: Fixes T5016. Ref T655. Ref T8434. Ref T8726. For "select" custom fields, permit construction of Herald rules. Test Plan: {F602997} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T655, T5016, T8434, T8726 Differential Revision: https://secure.phabricator.com/D13618
2015-07-16 23:12:54 +02:00
'PhabricatorStandardSelectCustomFieldDatasource' => 'PhabricatorTypeaheadDatasource',
Convert DrydockBlueprints to EditEngine Summary: Ref T10457. Fixes T10024. This primarily just modernizes blueprints to use EditEngine. This also fixes T10024, which was an issue with stored properties not being flagged correctly. Also slightly improves typeaheads for blueprints (more information, disabled state). Test Plan: - Created and edited various types of blueprints. - Set and removed limits. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10024, T10457 Differential Revision: https://secure.phabricator.com/D15390
2016-03-03 13:34:47 +01:00
'PhabricatorStaticEditField' => 'PhabricatorEditField',
Add /status/
2011-04-08 20:13:29 +02:00
'PhabricatorStatusController' => 'PhabricatorController',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorStatusUIExample' => 'PhabricatorUIExample',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorStorageFixtureScopeGuard' => 'Phobject',
'PhabricatorStorageManagementAPI' => 'Phobject',
Add `bin/storage adjust`, for adjusting schemata Summary: Ref T1191. Adds a new workflow which can apply schema adjustments. For now, it only performs database and table collation/charset adjustments. I believe these are extremely safe/minor, because they only affect the default values for newly created columns. Test Plan: - Ran migration on various database states, database/table changes went through cleanly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10595
2014-10-01 17:16:31 +02:00
'PhabricatorStorageManagementAdjustWorkflow' => 'PhabricatorStorageManagementWorkflow',
Make SQL patch management DAG-based and provide namespace support Summary: This addresses three issues with the current patch management system: # Two people developing at the same time often pick the same SQL patch number, and then have to go rename it. The system catches this, but it's silly. # Second/third-party developers can't use the same system to manage auxiliary storage they may want to add. # There's no way to build mock databases for unit tests that need to do reads. To resolve these things, you can now name your patches whatever you want and conflicts are just merge conflicts, which are less of a pain to fix than filename conflicts. Dependencies are now a DAG, with implicit dependencies created on the prior patch if no dependencies are specified. Developers can add new concrete subclasses of `PhabricatorSQLPatchList` to add storage management, and define the dependency branchpoint of their patches so they apply in the correct order (although, generally, they should not depend on the mainline patches, presumably). The commands `storage upgrade --namespace test1234` and `storage destroy --namespace test1234` will allow unit tests to build and destroy MySQL storage. A "quickstart" mode allows an upgrade from scratch in ~1200ms. Destruction takes about 200ms. These seem like fairily reasonable costs to actually use in tests. Building from scratch patch-by-patch takes about 6000ms. Test Plan: - Created new databases from scratch with and without quickstart in a separate test namespace. Pointed the webapp at the test namespaces, browsed around, everything looked good. - Compared quickstart and no-quickstart dump states, they're identical except for mysqldump timestamps and a few similar things. - Upgraded a legacy database to the new storage format. - Destroyed / dumped storage. Reviewers: edward, vrana, btrahan, jungejason Reviewed By: btrahan CC: aran, nh Maniphest Tasks: T140, T345 Differential Revision: https://secure.phabricator.com/D2323
2012-04-30 16:54:00 +02:00
'PhabricatorStorageManagementDatabasesWorkflow' => 'PhabricatorStorageManagementWorkflow',
'PhabricatorStorageManagementDestroyWorkflow' => 'PhabricatorStorageManagementWorkflow',
'PhabricatorStorageManagementDumpWorkflow' => 'PhabricatorStorageManagementWorkflow',
Move "scripts/sql/probe.php" to "bin/storage probe" Summary: This makes it namespace/database/connection aware and a little easier to find. Also use pht() / PhutilConsole. Test Plan: Ran `bin/storage probe`. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6341
2013-07-03 01:34:17 +02:00
'PhabricatorStorageManagementProbeWorkflow' => 'PhabricatorStorageManagementWorkflow',
Provide `bin/storage quickstart` to automate generation of `quickstart.sql` Summary: Ref T1191. Currently, the `quickstart.sql` gets generated in a pretty manual fashion. This is a pain, and will become more of a pain in the world of utf8mb4. Provide a workflow which does upgrade + adjust + dump + destroy, then massages the output to produce a workable `quickstart.sql`. Test Plan: Inspected output; I'll test this more throughly before actually generating a new quickstart, but that's some ways away. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10603
2014-10-01 17:22:37 +02:00
'PhabricatorStorageManagementQuickstartWorkflow' => 'PhabricatorStorageManagementWorkflow',
Add a `storage renamespace` for mangling SQL dumpfiles into a new namespace Summary: Ref T7149. When users give us dumpfiles for import, they will almost inevitably use the `phabricator` namespace. They need to be renamed to use an instance namespace. We can do this either by: - importing the data first, then renaming; or - renaming first, then importing. This implements the second one, basically `storage renamespace --in dump.sql --from phabricator --to instancename > instance.sql`. Renaming first is a little hackier since we have to `preg_match()` a SQL dump file, but I think it's better overall: - With only one database, it lets you dump/import without downtime. - If you have development stuff in a development environment in the `phabricator` namespace, you don't have to move it aside to do an import. - No possibility that two people doing an import at the same time on the same box will collide with each other. - You can do the rename once and then repeat the import process with the renamed dump more easily. - No tricky stuff with modern Phabricator running against an old dump and the database names not matching up. None of this is super important, but it just makes large dumps a bit easier to work with, and the dumpfile format is regular enough that this seems unlikely to ever really not work. Test Plan: Renamespaced a dump, did a `diff -u`, saw all the relevant parts changed (and only those parts changed). Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7149 Differential Revision: https://secure.phabricator.com/D12105
2015-03-18 02:29:01 +01:00
'PhabricatorStorageManagementRenamespaceWorkflow' => 'PhabricatorStorageManagementWorkflow',
Add a `./bin/storage shell` command Summary: Fixes T7078. Adds a `./bin/storage shell` command which passes through to a MySQL shell. This is slightly more convenient than running `mysql` manually. Test Plan: Ran `./bin/storage shell` and got a MySQL shell. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T7078 Differential Revision: https://secure.phabricator.com/D11548
2015-01-29 21:15:27 +01:00
'PhabricatorStorageManagementShellWorkflow' => 'PhabricatorStorageManagementWorkflow',
Make SQL patch management DAG-based and provide namespace support Summary: This addresses three issues with the current patch management system: # Two people developing at the same time often pick the same SQL patch number, and then have to go rename it. The system catches this, but it's silly. # Second/third-party developers can't use the same system to manage auxiliary storage they may want to add. # There's no way to build mock databases for unit tests that need to do reads. To resolve these things, you can now name your patches whatever you want and conflicts are just merge conflicts, which are less of a pain to fix than filename conflicts. Dependencies are now a DAG, with implicit dependencies created on the prior patch if no dependencies are specified. Developers can add new concrete subclasses of `PhabricatorSQLPatchList` to add storage management, and define the dependency branchpoint of their patches so they apply in the correct order (although, generally, they should not depend on the mainline patches, presumably). The commands `storage upgrade --namespace test1234` and `storage destroy --namespace test1234` will allow unit tests to build and destroy MySQL storage. A "quickstart" mode allows an upgrade from scratch in ~1200ms. Destruction takes about 200ms. These seem like fairily reasonable costs to actually use in tests. Building from scratch patch-by-patch takes about 6000ms. Test Plan: - Created new databases from scratch with and without quickstart in a separate test namespace. Pointed the webapp at the test namespaces, browsed around, everything looked good. - Compared quickstart and no-quickstart dump states, they're identical except for mysqldump timestamps and a few similar things. - Upgraded a legacy database to the new storage format. - Destroyed / dumped storage. Reviewers: edward, vrana, btrahan, jungejason Reviewed By: btrahan CC: aran, nh Maniphest Tasks: T140, T345 Differential Revision: https://secure.phabricator.com/D2323
2012-04-30 16:54:00 +02:00
'PhabricatorStorageManagementStatusWorkflow' => 'PhabricatorStorageManagementWorkflow',
'PhabricatorStorageManagementUpgradeWorkflow' => 'PhabricatorStorageManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorStorageManagementWorkflow' => 'PhabricatorManagementWorkflow',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorStoragePatch' => 'Phobject',
Generate expected schemata for MetaMTA, Nuance, MetaData, OAuthServer Summary: Ref T1191. Handful of minor things here (T6150, T6149, T6148, T6147, T6146) but nothing very noteworthy. Test Plan: Viewed web UI, saw fewer errors. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10527
2014-09-24 22:50:00 +02:00
'PhabricatorStorageSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorStorageSetupCheck' => 'PhabricatorSetupCheck',
Rename protocol adapter classes Summary: Ref T5655. Rename protocol adapter classes to remove `Base` from the class name. Test Plan: Unit tests still pass. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D12563
2015-05-18 00:20:11 +02:00
'PhabricatorStreamingProtocolAdapter' => 'PhabricatorProtocolAdapter',
Convert projects to EditEngine Summary: Ref T10010. This is pretty straightforward with a couple of very minor new behaviors, like the icon selector edit field. Test Plan: - Created projects. - Edited projects. - Saw "Create Project" in quick create menu. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14896
2015-12-27 15:45:53 +01:00
'PhabricatorStringListEditField' => 'PhabricatorEditField',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorSubscribedToObjectEdgeType' => 'PhabricatorEdgeType',
Provide formal Users/Projects/Mailable fields for EditEngine Summary: Ref T9132. This allows you to prefill EditEngine forms with stuff like `?subscribers=epriestley`, and we'll figure out what you mean. Test Plan: - Did `/?subscribers=...` with various values (good, bad, mis-capitalized). - Did `/?projects=...` with various values (good, bad, mis-capitalized). - Reviewed documentation. - Reviewed {nav Config > HTTP Parameter Types}. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14404
2015-11-04 19:20:38 +01:00
'PhabricatorSubscribersEditField' => 'PhabricatorTokenizerEditField',
Add basic "Subscriptions" application Summary: Basic infrastructure for generalizing subscriptions/CCs for T1808, T1514 and T1663. - Implement `PhabricatorSubscribableInterface` and you'll get a subscribe/unsubscribe button for free. - If there are any auto-subscribed users (like the question author) you can specify them; this makes more sense for Tasks and Revisions than Ponder probably, but maybe the author should be auto-subscribed. - Subscriptions are either "explicit" (the user clicked 'subscribe') or "implicit" (the user did something which causes them to become subscribed naturally). If a user unsubscribes, they'll no longer be added by implicit subscriptions. This may or may not be relevant to Ponder but is an existing Herald feature in Differential. - Helper method on PhabricatorSubscribersQuery to load subscribers. - This doesn't handle actually sending email, etc. I think that's all so application-specific that it doesn't belong here. - Now seems to work. Test Plan: {F20552} {F20553} Reviewers: pieter, btrahan Reviewed By: pieter CC: aran Maniphest Tasks: T1663, T1514, T1808 Differential Revision: https://secure.phabricator.com/D3637
2012-10-05 22:18:05 +02:00
'PhabricatorSubscribersQuery' => 'PhabricatorQuery',
Implement "trigger clocks" for scheduling events Summary: Ref T6881. This will probably make more sense in a couple of diffs, but this is a class that implements scheduling/recurrence rules. Two rules are provided: - Trigger an event at a specific time (e.g., a meeting reminder notification). - Trigger an event on the Nth day of every month (e.g., a subscription bill). At some point, we'll presumably add a rule for T2896 (maybe using the "RRULE" spec) so you can do stuff like "the second to last thursday of every month", etc., but we don't need that for now. (The "Nth day of every month, or move it back if no such day exists" rule doesn't seem to be expressible with the "RRULE" format, so implementing that wouldn't give us a superset of this. I think this rule is correct and desirable for this purpose, though.) Test Plan: Added and executed unit tests. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11403
2015-01-16 00:57:45 +01:00
'PhabricatorSubscriptionTriggerClock' => 'PhabricatorTriggerClock',
Make "Add Subscribers" and "Remove Subscribers" Herald actions modular Summary: Ref T8726. Converts these actions to be modular. No real surprises in this change. Test Plan: {F658709} - Wrote some rules. - Migrated them forward. - Used a bunch of these rules. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13699
2015-07-18 17:07:31 +02:00
'PhabricatorSubscriptionsAddSelfHeraldAction' => 'PhabricatorSubscriptionsHeraldAction',
'PhabricatorSubscriptionsAddSubscribersHeraldAction' => 'PhabricatorSubscriptionsHeraldAction',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorSubscriptionsApplication' => 'PhabricatorApplication',
Introduce "Curtain" views, panels, and extensions Summary: This opens up the new action column to have specialized rendering and behavior. Briefly: - Converted applications (right now, only Paste) render a `CurtainView` to build the column content. - This view uses new extensions to build panels (projects, subscribers, tokens). - The panel extension code and rendering can be changed without breaking old stuff. Minor changes: - Token awards now load their tokens, for consistency/simplicity. - Removed the rest of the "fork of" / "forked from" UI in Paste -- I essentially removed these features a while ago, and no one has complained. Test Plan: UI is a bit rough, but works, and it's going to get changed now anyway: {F1160550} {F1160551} Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15414
2016-03-05 23:45:56 +01:00
'PhabricatorSubscriptionsCurtainExtension' => 'PHUICurtainExtension',
Add basic "Subscriptions" application Summary: Basic infrastructure for generalizing subscriptions/CCs for T1808, T1514 and T1663. - Implement `PhabricatorSubscribableInterface` and you'll get a subscribe/unsubscribe button for free. - If there are any auto-subscribed users (like the question author) you can specify them; this makes more sense for Tasks and Revisions than Ponder probably, but maybe the author should be auto-subscribed. - Subscriptions are either "explicit" (the user clicked 'subscribe') or "implicit" (the user did something which causes them to become subscribed naturally). If a user unsubscribes, they'll no longer be added by implicit subscriptions. This may or may not be relevant to Ponder but is an existing Herald feature in Differential. - Helper method on PhabricatorSubscribersQuery to load subscribers. - This doesn't handle actually sending email, etc. I think that's all so application-specific that it doesn't belong here. - Now seems to work. Test Plan: {F20552} {F20553} Reviewers: pieter, btrahan Reviewed By: pieter CC: aran Maniphest Tasks: T1663, T1514, T1808 Differential Revision: https://secure.phabricator.com/D3637
2012-10-05 22:18:05 +02:00
'PhabricatorSubscriptionsEditController' => 'PhabricatorController',
Modularize application extensions to EditEngine Summary: Ref T9132. Currently, EditEngine had some branchy-`instanceof` code like this: ``` if ($object instanceof Whatever) { do_magic(); } if ($object instanceof SomethingElse) { do_other_magic(); } ``` ...where `Whatever` and `SomethingElse` are first-party applications like ProjectsInterface and SubscribersInterface. This kind of code is generally bad because third-parties can't add new stuff, and it suggest something is kind of hacky in its architecture. Ideally, we would eventually get rid of almost all of this. T9789 is a similar discussion of this for the next layer down (`TransactionEditor`) and plans to get rid of branchy-instanceofs there too. Since I'm about to add more stuff here (for Custom Fields), split it out first so I'm not digging us any deeper than I already dug us. Broadly, this allows third-party extensions to add fields to every EditEngine UI if they want, like we do for Policies, Subscribers, Projects and Comments today (and CustomFields soon). Test Plan: {F1007575} - Observed that all fields still appear on the form and seem to work correctly. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14599
2015-11-29 19:05:41 +01:00
'PhabricatorSubscriptionsEditEngineExtension' => 'PhabricatorEditEngineExtension',
If users are on the email to Phabricator, do not send them the Phabricator reply. Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email. Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected. Reviewers: epriestley, vrana Reviewed By: vrana CC: aran, Korvin, vrana Maniphest Tasks: T1676 Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 19:18:23 +02:00
'PhabricatorSubscriptionsEditor' => 'PhabricatorEditor',
Modularize fulltext indexing of Projects, Subscriptions and Custom Fields Summary: Ref T9979. This is going to become `FulltextEngine`, but pave the way for that by pulling extensions out of it. Test Plan: {F1036624} - Used `bin/search index Txxx`, saw projects, subscribers and custom fields rebuild in the index. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14835
2015-12-21 15:31:31 +01:00
'PhabricatorSubscriptionsFulltextEngineExtension' => 'PhabricatorFulltextEngineExtension',
Make "Add Subscribers" and "Remove Subscribers" Herald actions modular Summary: Ref T8726. Converts these actions to be modular. No real surprises in this change. Test Plan: {F658709} - Wrote some rules. - Migrated them forward. - Used a bunch of these rules. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13699
2015-07-18 17:07:31 +02:00
'PhabricatorSubscriptionsHeraldAction' => 'HeraldAction',
Subscriptions - make a dialog for massive subscription lists Summary: Ref T4430. This just deploys it on the property lists. (Help on how to do translations better? I tried a more traditional pht('%s, %s, %s, and %d other(s)') but I think the string lookup assumes the %d comes as the second param or something?) Test Plan: Made a Maniphest Task with a hojillion subscribers and noted the working dialogue. Also made a Pholio Mock with lots of subscribers and it worked. Reviewers: epriestley Reviewed By: epriestley Subscribers: aran, epriestley, Korvin, chad Maniphest Tasks: T4430 Differential Revision: https://secure.phabricator.com/D8525
2014-03-14 19:22:00 +01:00
'PhabricatorSubscriptionsListController' => 'PhabricatorController',
Make "Add Subscribers" and "Remove Subscribers" Herald actions modular Summary: Ref T8726. Converts these actions to be modular. No real surprises in this change. Test Plan: {F658709} - Wrote some rules. - Migrated them forward. - Used a bunch of these rules. Reviewers: btrahan Reviewed By: btrahan Subscribers: joshuaspence, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13699
2015-07-18 17:07:31 +02:00
'PhabricatorSubscriptionsRemoveSelfHeraldAction' => 'PhabricatorSubscriptionsHeraldAction',
'PhabricatorSubscriptionsRemoveSubscribersHeraldAction' => 'PhabricatorSubscriptionsHeraldAction',
Implement an "Attachments" behavior for Conduit Search APIs Summary: Ref T9964. We have various kinds of secondary data on objects (like subscribers, projects, paste content, Owners paths, file attachments, etc) which is somewhat slow, or somewhat large, or both. Some approaches to handling this in the API include: - Always return all of it (very easy, but slow). - Require users to make separate API calls to get each piece of data (very simple, but inefficient and really cumbersome to use). - Implement a hierarchical query language like GraphQL (powerful, but very complex). - Kind of mix-and-match a half-power query language and some extra calls? (fairly simple, not too terrible?) We currently mix-and-match internally, with `->needStuff(true)`. This is not a general-purpose, full-power graph query language like GraphQL, and it occasionally does limit us. For example, there is no way to do this sort of thing: $conpherence_thread_query = id(new ConpherenceThreadQuery()) ->setViewer($viewer) // ... ->setNeedMessages(true) ->setWhenYouLoadTheMessagesTheyNeedProfilePictures(true); However, we almost never actually need to do this and when we do want to do it we usually don't //really// want to do it, so I don't think this is a major limit to the practical power of the system for the kinds of things we really want to do with it. Put another way, we have a lot of 1-level hierarchical queries (get pictures or repositories or projects or files or content for these objects) but few-to-no 2+ level queries (get files for these objects, then get all the projects for those files). So even though 1-level hierarchies are not a beautiful, general-purpose, fully-abstract system, they've worked well so far in practice and I'm comfortable moving forward with them in the API. If we do need N-level queries in the future, there is no technical reason we can't put GraphQL (or something similar) on top of this eventually, and this would represent a solid step toward that. However, I suspect we'll never need them. Upshot: I'm pretty happy with "->needX()" for all practical purposes, so this is just adding a way to say "->needX()" to the API. Specifically, you say: ``` { "attachments": { "subscribers": true, } } ``` ...and get back subscriber data. In the future (or for certain attachments), `true` might become a dictionary of extra parameters, if necessary, and could do so without breaking the API. Test Plan: - Ran queries to get attachments. {F1025449} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14772
2015-12-14 13:58:34 +01:00
'PhabricatorSubscriptionsSearchEngineAttachment' => 'PhabricatorSearchEngineAttachment',
Modularize SearchEngine extensions Summary: Ref T9964. ApplicationSearch currently has a bunch of hard-coded `if ($object instanceof thing)` stuff. Pull that out so it can live in extensions. Test Plan: - Searched by spaces, subscribers, projects. {F1023921} Reviewers: chad Reviewed By: chad Maniphest Tasks: T9964 Differential Revision: https://secure.phabricator.com/D14764
2015-12-13 13:12:34 +01:00
'PhabricatorSubscriptionsSearchEngineExtension' => 'PhabricatorSearchEngineExtension',
Implement a "!subscribe" mail command Summary: Ref T7199. Implements "!subscribe". Test Plan: Used `bin/mail receive-test` to apply the command to objects. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12247
2015-04-01 18:45:18 +02:00
'PhabricatorSubscriptionsSubscribeEmailCommand' => 'MetaMTAEmailTransactionCommand',
Add a "Subscribers" object policy Summary: Ref T5681. Getting this to work correctly is a bit tricky, mostly because of the policy checks we do prior to applying an edit. I think I came up with a mostly-reasonable approach, although it's a little bit gross. It uses `spl_object_hash()` so it shouldn't be able to do anything bad/dangerous (the hints are strictly bound to the hinted object, which is a clone that we destroy moments later). Test Plan: - Added + ran a unit test. - Created a task with a "Subscribers" policy with me as a subscriber (without the hint stuff, this isn't possible: since you aren't a subscriber *yet*, you get a "you won't be able to see it" error). - Unsubscribed from a task with a "Subscribers" policy, was immediately unable to see it. - Created a task with a "subscribers" policy and a project subscriber with/without me as a member (error / success, respectively). Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5681 Differential Revision: https://secure.phabricator.com/D13259
2015-06-14 00:45:17 +02:00
'PhabricatorSubscriptionsSubscribersPolicyRule' => 'PhabricatorPolicyRule',
Transactions - add "and X others" dialog support to application transactions Summary: Fixes T4430. Basically does a little code massage from the new stuff in D8525 and application transactions to get this working. Adds a new controller to the subscriptions app to make rendering these pretty easy peasy. Test Plan: Used my test task in D8525 to verify both add and rem versions of these dialogs worked correctly. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, chad, Korvin Maniphest Tasks: T4430 Differential Revision: https://secure.phabricator.com/D8540
2014-03-14 22:27:45 +01:00
'PhabricatorSubscriptionsTransactionController' => 'PhabricatorController',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'PhabricatorSubscriptionsUIEventListener' => 'PhabricatorEventListener',
Fully modularize mail commands Summary: Ref T7199. Everyone can have a mail command! You can have a mail command! You can have a mail command! Mail commands for everyone! Test Plan: Used `bin/mail receive-test` to issue commands against files and pastes. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12238
2015-04-01 17:40:00 +02:00
'PhabricatorSubscriptionsUnsubscribeEmailCommand' => 'MetaMTAEmailTransactionCommand',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorSupportApplication' => 'PhabricatorApplication',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorSyntaxHighlighter' => 'Phobject',
Add syntax highlighting options. Test Plan: Quick view of each option in the web interface. Reviewers: epriestley, btrahan, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4386
2013-01-10 18:56:36 +01:00
'PhabricatorSyntaxHighlightingConfigOptions' => 'PhabricatorApplicationConfigOptions',
Generate syntax highlighting CSS from a reusable map Summary: Ref T9790. This prepares the syntax color rules to be reused in mail. This goes about halfway toward T5701 by sort-of supporting different styles but not really. Test Plan: - Ran `bin/celerity syntax` to regenerate syntax map. - Viewed some highlighted code, didn't see any differences. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9790 Differential Revision: https://secure.phabricator.com/D15846
2016-05-05 03:24:59 +02:00
'PhabricatorSyntaxStyle' => 'Phobject',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorSystemAction' => 'Phobject',
Add semi-generic rate limiting infrastructure Summary: This adds a system which basically keeps a record of recent actions, who took them, and how many "points" they were worth, like: epriestley email.add 1 1233989813 epriestley email.add 1 1234298239 epriestley email.add 1 1238293981 We can use this to rate-limit actions by examining how many actions the user has taken in the past hour (i.e., their total score) and comparing that to an allowed limit. One major thing I want to use this for is to limit the amount of error email we'll send to an email address. A big concern I have with sending more error email is that we'll end up in loops. We have some protections against this in headers already, but hard-limiting the system so it won't send more than a few errors to a particular address per hour should provide a reasonable secondary layer of protection. This use case (where the "actor" needs to be an email address) is why the table uses strings + hashes instead of PHIDs. For external users, it might be appropriate to rate limit by cookies or IPs, too. To prove it works, I rate limited adding email addresses. This is a very, very low-risk security thing where a user with an account can enumerate addresses (by checking if they get an error) and sort of spam/annoy people (by adding their address over and over again). Limiting them to 6 actions / hour should satisfy all real users while preventing these behaviors. Test Plan: This dialog is uggos but I'll fix that in a sec: {F137406} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8683
2014-04-03 20:22:38 +02:00
'PhabricatorSystemActionEngine' => 'Phobject',
'PhabricatorSystemActionGarbageCollector' => 'PhabricatorGarbageCollector',
'PhabricatorSystemActionLog' => 'PhabricatorSystemDAO',
'PhabricatorSystemActionRateLimitException' => 'Exception',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorSystemApplication' => 'PhabricatorApplication',
Add semi-generic rate limiting infrastructure Summary: This adds a system which basically keeps a record of recent actions, who took them, and how many "points" they were worth, like: epriestley email.add 1 1233989813 epriestley email.add 1 1234298239 epriestley email.add 1 1238293981 We can use this to rate-limit actions by examining how many actions the user has taken in the past hour (i.e., their total score) and comparing that to an allowed limit. One major thing I want to use this for is to limit the amount of error email we'll send to an email address. A big concern I have with sending more error email is that we'll end up in loops. We have some protections against this in headers already, but hard-limiting the system so it won't send more than a few errors to a particular address per hour should provide a reasonable secondary layer of protection. This use case (where the "actor" needs to be an email address) is why the table uses strings + hashes instead of PHIDs. For external users, it might be appropriate to rate limit by cookies or IPs, too. To prove it works, I rate limited adding email addresses. This is a very, very low-risk security thing where a user with an account can enumerate addresses (by checking if they get an error) and sort of spam/annoy people (by adding their address over and over again). Limiting them to 6 actions / hour should satisfy all real users while preventing these behaviors. Test Plan: This dialog is uggos but I'll fix that in a sec: {F137406} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8683
2014-04-03 20:22:38 +02:00
'PhabricatorSystemDAO' => 'PhabricatorLiskDAO',
Implement bin/remove, for structured destruction of objects Summary: Ref T4749. Ref T3265. Ref T4909. Several goals here: - Move user destruction to the CLI to limit the power of rogue admins. - Start consolidating all "destroy named object" scripts into a single UI, to make it easier to know how to destroy things. - Structure object destruction so we can do a better and more automatic job of cleaning up transactions, edges, search indexes, etc. - Log when we destroy objects so there's a record if data goes missing. Test Plan: Used `bin/remove destroy` to destroy several users. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3265, T4749, T4909 Differential Revision: https://secure.phabricator.com/D8940
2014-05-02 03:23:31 +02:00
'PhabricatorSystemDestructionGarbageCollector' => 'PhabricatorGarbageCollector',
'PhabricatorSystemDestructionLog' => 'PhabricatorSystemDAO',
When Phabricator is in read-only mode, explain why Summary: Ref T4571. Allows users to click the "read-only mode" notification to get more information about why an install is in read-only mode. Installs can be in this mode for several reasons (explicit administrative action, no masters defined, no masters reachable), and it's useful to be able to tell the difference. Test Plan: {F1212930} Reviewers: chad Reviewed By: chad Maniphest Tasks: T4571 Differential Revision: https://secure.phabricator.com/D15671
2016-04-10 13:26:53 +02:00
'PhabricatorSystemReadOnlyController' => 'PhabricatorController',
Implement bin/remove, for structured destruction of objects Summary: Ref T4749. Ref T3265. Ref T4909. Several goals here: - Move user destruction to the CLI to limit the power of rogue admins. - Start consolidating all "destroy named object" scripts into a single UI, to make it easier to know how to destroy things. - Structure object destruction so we can do a better and more automatic job of cleaning up transactions, edges, search indexes, etc. - Log when we destroy objects so there's a record if data goes missing. Test Plan: Used `bin/remove destroy` to destroy several users. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3265, T4749, T4909 Differential Revision: https://secure.phabricator.com/D8940
2014-05-02 03:23:31 +02:00
'PhabricatorSystemRemoveDestroyWorkflow' => 'PhabricatorSystemRemoveWorkflow',
'PhabricatorSystemRemoveLogWorkflow' => 'PhabricatorSystemRemoveWorkflow',
'PhabricatorSystemRemoveWorkflow' => 'PhabricatorManagementWorkflow',
Substantially support character encodings and "Highlight As" in changesets Summary: Ref T5179. Ref T4045. Ref T832. We can now write non-utf8 hunks into the database, so try to do more reasonable things with them in the UI. Test Plan: (See screenshots...) Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T832, T4045, T5179 Differential Revision: https://secure.phabricator.com/D9294
2014-06-20 20:49:41 +02:00
'PhabricatorSystemSelectEncodingController' => 'PhabricatorController',
'PhabricatorSystemSelectHighlightController' => 'PhabricatorController',
Rename the `PhabricatorAuthFactorTOTP` class for consistency Summary: Ref T5655. Test Plan: `grep` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11191
2015-01-06 12:56:03 +01:00
'PhabricatorTOTPAuthFactor' => 'PhabricatorAuthFactor',
'PhabricatorTOTPAuthFactorTestCase' => 'PhabricatorTestCase',
Rough cut of Workers Summary: workers do work, provided I have written them correctly. perhaps it is so. Test Plan: Reviewers: CC:
2011-03-10 22:48:29 +01:00
'PhabricatorTaskmasterDaemon' => 'PhabricatorDaemon',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorTestApplication' => 'PhabricatorApplication',
Replace ArcanistPhutilTestCase refs with PhutilTestCase Summary: Ref T7977. Remove the `PhabricatorTestCase::getLink` method. Depends on D12665. Test Plan: `arc unit`. Reviewers: avivey, #blessed_reviewers, epriestley Reviewed By: avivey, #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7977 Differential Revision: https://secure.phabricator.com/D12667
2015-05-20 01:37:39 +02:00
'PhabricatorTestCase' => 'PhutilTestCase',
Fix controller-level access rules Summary: Ref T603. I had to partially revert this earlier because it accidentally blocked access to Conduit and File data for installs without "policy.allow-public", since the applications are available to "all users" but some endpoints actually need to be available even when not logged in. This readjusts the gating in the controller to properly apply application visibility restrictions, and then adds a giant pile of unit test coverage to make sure it sticks and all the weird cases are covered. Test Plan: - Added and executed unit tests. - Executed most of the tests manually, by using logged in / admin / public / disabled users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7211
2013-10-04 04:05:47 +02:00
'PhabricatorTestController' => 'PhabricatorController',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorTestDataGenerator' => 'Phobject',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorTestNoCycleEdgeType' => 'PhabricatorEdgeType',
Make file storage more testable Summary: Fixes T2474. Adds a storage dummy storage engine for unit tests, and adds a couple of simple tests for basic file storage. Test Plan: Ran `arc unit` to execute unit tests. Reviewers: kwadwon Reviewed By: kwadwon CC: aran Maniphest Tasks: T2474 Differential Revision: https://secure.phabricator.com/D4777
2013-02-06 22:37:42 +01:00
'PhabricatorTestStorageEngine' => 'PhabricatorFileStorageEngine',
Factor out task execution and formalize permanent failures Summary: - Clean up a TODO about permanent failures. - Clean up a TODO about failing tasks after too many retries. - Clean up a TODO about testing for bad leases. - Make the lease/retry implementation more flexible and natural. - Make completely bogus tasks fail permanently. - Make PhabricatorMetaMTAWorker use new `getWaitBeforeRetry()` (as intended), not hackily implement logic in `getRequiredLeaseTime()`. - Document worker hooks for failures and retries. - Provide coverage on everything. Test Plan: Ran unit tests. Ran `bin/phd debug taskmaster`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3859
2012-11-01 19:30:23 +01:00
'PhabricatorTestWorker' => 'PhabricatorWorker',
Implement a basic version of ApplicationEditor in Paste Summary: Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste. This mostly looks and works like ApplicationSearch, and is heavily modeled on it. Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else. This has no functional changes, except: - I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it. - Subscribers are now editable. - Form field order is a little goofy (this will be fixed in a future diff). - Subscribers and projects are now race-resistant. The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits. Test Plan: - Created pastes. - Created pastes via API. - Edited pastes. - Edited every field. - Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected. Reviewers: chad Reviewed By: chad Maniphest Tasks: T4768, T9132 Differential Revision: https://secure.phabricator.com/D14390
2015-11-03 03:58:32 +01:00
'PhabricatorTextAreaEditField' => 'PhabricatorEditField',
'PhabricatorTextEditField' => 'PhabricatorEditField',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorTime' => 'Phobject',
'PhabricatorTimeGuard' => 'Phobject',
Consolidate some datetime code and add unit tests Summary: See D6115. Test Plan: - Ran unit tests. - Viewed reports. - Created a countdown. - Searched chatlog. - Searched pastes by created date. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6116
2013-06-03 21:58:11 +02:00
'PhabricatorTimeTestCase' => 'PhabricatorTestCase',
Rename `PhabricatorSetupCheck` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11130
2015-01-02 05:27:45 +01:00
'PhabricatorTimezoneSetupCheck' => 'PhabricatorSetupCheck',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorToken' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorTokenDAO',
'PhabricatorPolicyInterface',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
),
'PhabricatorTokenController' => 'PhabricatorController',
'PhabricatorTokenCount' => 'PhabricatorTokenDAO',
Surface token counts for Pholio Summary: Provide this data so the list view can present it somehow. Test Plan: {F34520} Reviewers: chad Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D5210
2013-03-04 20:47:58 +01:00
'PhabricatorTokenCountQuery' => 'PhabricatorOffsetPagedQuery',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorTokenDAO' => 'PhabricatorLiskDAO',
Fully modularize DestructionEngine Summary: Ref T9979. Convert all DestructionEngine behaviors to extensions. Test Plan: {F1033244} Destroyed an object, verifying: - Herald transcripts were destroyed; - edges were destroyed; - flags were destroyed; - tokens were destroyed; - transactions were destroyed; - worker tasks were cancelled. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14832
2015-12-20 17:11:59 +01:00
'PhabricatorTokenDestructionEngineExtension' => 'PhabricatorDestructionEngineExtension',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorTokenGiveController' => 'PhabricatorTokenController',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorTokenGiven' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorTokenDAO',
'PhabricatorPolicyInterface',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
),
'PhabricatorTokenGivenController' => 'PhabricatorTokenController',
'PhabricatorTokenGivenEditor' => 'PhabricatorEditor',
Notify users when an object they created gets awarded a token Summary: - Publish feed/notification. - I think this is too lightweight for an email? - We don't tell them which token right now. Laziness? Or intentional aura of mystery?! - For tasks, notify both author and current owner. - Fixes T2562. Test Plan: {F33187} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2562 Differential Revision: https://secure.phabricator.com/D5007
2013-02-19 02:44:45 +01:00
'PhabricatorTokenGivenFeedStory' => 'PhabricatorFeedStory',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorTokenGivenQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add basic token leader board functionality. Summary: Implement basic token leader board. No pagination yet. Test Plan: Assign some tasks tokens and check that they are displayed properly. Reviewers: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2689 Differential Revision: https://secure.phabricator.com/D5379
2013-03-22 00:04:29 +01:00
'PhabricatorTokenLeaderController' => 'PhabricatorTokenController',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorTokenQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add basic token leader board functionality. Summary: Implement basic token leader board. No pagination yet. Test Plan: Assign some tasks tokens and check that they are displayed properly. Reviewers: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2689 Differential Revision: https://secure.phabricator.com/D5379
2013-03-22 00:04:29 +01:00
'PhabricatorTokenReceiverQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhabricatorTokenTokenPHIDType' => 'PhabricatorPHIDType',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'PhabricatorTokenUIEventListener' => 'PhabricatorEventListener',
Improve code structure of PHID fields in EditEngine Summary: Ref T9132. I had some hacks in place for dealing with Edge/Subscribers stuff. Clean that up so it's structured a little better. Test Plan: - Edited subscribers and projects. - Verified things still show up in Conduit. - Made concurrent edits (added a project in one window, removed it in another window, got a clean result with a correct merge of the two edits). Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14601
2015-11-29 22:24:47 +01:00
'PhabricatorTokenizerEditField' => 'PhabricatorPHIDListEditField',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorTokensApplication' => 'PhabricatorApplication',
Introduce "Curtain" views, panels, and extensions Summary: This opens up the new action column to have specialized rendering and behavior. Briefly: - Converted applications (right now, only Paste) render a `CurtainView` to build the column content. - This view uses new extensions to build panels (projects, subscribers, tokens). - The panel extension code and rendering can be changed without breaking old stuff. Minor changes: - Token awards now load their tokens, for consistency/simplicity. - Removed the rest of the "fork of" / "forked from" UI in Paste -- I essentially removed these features a while ago, and no one has complained. Test Plan: UI is a bit rough, but works, and it's going to get changed now anyway: {F1160550} {F1160551} Reviewers: chad Reviewed By: chad Differential Revision: https://secure.phabricator.com/D15414
2016-03-05 23:45:56 +01:00
'PhabricatorTokensCurtainExtension' => 'PHUICurtainExtension',
Rename `PhabricatorSettingsPanel` subclasses for consistency Summary: Ref T5655. Test Plan: `arc lint` and `arc unit` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 05:20:08 +01:00
'PhabricatorTokensSettingsPanel' => 'PhabricatorSettingsPanel',
Rename `PhabricatorUIExample` subclasses for consistency Summary: Ref T5655. Basically, rename all `PhabricatorUIExample` subclasses to be either `Phabricator*UIExample` or `PHUI*Example`. Test Plan: `arc lint` and `arc unit`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D11177
2015-01-03 22:36:47 +01:00
'PhabricatorTooltipUIExample' => 'PhabricatorUIExample',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorTransactions' => 'Phobject',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorTransactionsApplication' => 'PhabricatorApplication',
Fully modularize DestructionEngine Summary: Ref T9979. Convert all DestructionEngine behaviors to extensions. Test Plan: {F1033244} Destroyed an object, verifying: - Herald transcripts were destroyed; - edges were destroyed; - flags were destroyed; - tokens were destroyed; - transactions were destroyed; - worker tasks were cancelled. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14832
2015-12-20 17:11:59 +01:00
'PhabricatorTransactionsDestructionEngineExtension' => 'PhabricatorDestructionEngineExtension',
Modularize transaction/comment indexing in the FulltextEngine Summary: Ref T9979. This is currently hard-coded but can be done in a generic way. This has one minor behavioral changes: answer text is no longer included in the question text index in Ponder. I'm not planning to accommodate that for now since I don't want to dig this hole any deeper than I already have. This behavior should be different anyway (e.g., index the answer, then show the question in the results or something). Test Plan: - Put a unique word in a Maniphest comment. - Searched for the word. - Found the task. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14837
2015-12-21 16:08:17 +01:00
'PhabricatorTransactionsFulltextEngineExtension' => 'PhabricatorFulltextEngineExtension',
Basic image thumbnailing Summary: This is still very rough but provides basic support for generating image thumbnails. I need to separate stuff out a bit but I'm going to integrate into Maniphest before I hit the profile stuff so this seems like a reasonable starting point. Test Plan: Generated some image thumbnails in various sizes. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran CC: aran Differential Revision: 333
2011-05-22 23:40:51 +02:00
'PhabricatorTransformedFile' => 'PhabricatorFileDAO',
Add translations config group. Summary: Adds the translations group as per T2255. Currently `translation.override` is `wild` -- it should be changed to dict<string, string> when that exists. Also fixes a small bug from D4326 which caused "class" types to not ever validate. Test Plan: - Looked at the settings. - Successfully saved a setting relating to classes. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4350
2013-01-05 01:22:52 +01:00
'PhabricatorTranslationsConfigOptions' => 'PhabricatorApplicationConfigOptions',
Implement clock/trigger infrastructure for scheduling actions Summary: Ref T6881. Hopefully, this is the hard part. This adds a new daemon (the "trigger" daemon) which processes triggers, schedules them, and then executes them at the scheduled time. The design is a little complicated, but has these goals: - High resistance to race conditions: only the application writes to the trigger table; only the daemon writes to the event table. We won't lose events if someone saves a meeting at the same time as we're sending a reminder out for it. - Execution guarantees: scheduled events are guaranteed to execute exactly once. - Support for arbitrarily large queues: the daemon will make progress even if there are millions of triggers in queue. The cost to update the queue is proportional to the number of changes in it; the cost to process the queue is proportional to the number of events to execute. - Relatively good observability: you can monitor the state of the trigger queue reasonably well from the web UI. - Modular Infrastructure: this is a very low-level construct that Calendar, Phortune, etc., should be able to build on top of. It doesn't have this stuff yet: - Not very robust to bad actions: a misbehaving trigger can stop the queue fairly easily. This is OK for now since we aren't planning to make it part of any other applications for a while. We do still get execute-exaclty-once, but it might not happen for a long time (until someone goes and fixes the queue), when we could theoretically continue executing other events. - Doesn't start automatically: normal users don't need to run this thing yet so I'm not starting it by default. - Not super well tested: I've vetted the basics but haven't run real workloads through this yet. - No sophisticated tooling: I added some basic stuff but it's missing some pieces we'll have to build sooner or later, e.g. `bin/trigger cancel` or whatever. - Intentionally not realtime: This design puts execution guarantees far above realtime concerns, and will not give you precise event execution at 1-second resolution. I think this is the correct goal to pursue architecturally, and certainly correct for subscriptions and meeting reminders. Events which execute after they have become irrelevant can simply decline to do anything (like a meeting reminder which executes after the meeting is over). In general, the expectation for applications is: - When creating an object (like a calendar event) that needs to trigger a scheduled action, write a trigger (and save the PHID if you plan to update it later). - The daemon will process the event and schedule the action efficiently, in a race-free way. - If you want to move the action, update the trigger and the daemon will take care of it. - Your action will eventually dump a task into the task queue, and the task daemons will actually perform it. Test Plan: Using a test script like this: ``` <?php require_once 'scripts/__init_script__.php'; $trigger = id(new PhabricatorWorkerTrigger()) ->setAction( new PhabricatorLogTriggerAction( array( 'message' => 'test', ))) ->setClock( new PhabricatorMetronomicTriggerClock( array( 'period' => 33, ))) ->save(); var_dump($trigger); ``` ...I queued triggers and ran the daemon: - Verified triggers fire; - verified triggers reschedule; - verified trigger events show up in the web UI; - tried different periods; - added some triggers while the daemon was running; - examined `phd debug` output for anything suspicious. It seems to work in trivial use case, at least. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11419
2015-01-16 21:13:31 +01:00
'PhabricatorTriggerAction' => 'Phobject',
Implement "trigger clocks" for scheduling events Summary: Ref T6881. This will probably make more sense in a couple of diffs, but this is a class that implements scheduling/recurrence rules. Two rules are provided: - Trigger an event at a specific time (e.g., a meeting reminder notification). - Trigger an event on the Nth day of every month (e.g., a subscription bill). At some point, we'll presumably add a rule for T2896 (maybe using the "RRULE" spec) so you can do stuff like "the second to last thursday of every month", etc., but we don't need that for now. (The "Nth day of every month, or move it back if no such day exists" rule doesn't seem to be expressible with the "RRULE" format, so implementing that wouldn't give us a superset of this. I think this rule is correct and desirable for this purpose, though.) Test Plan: Added and executed unit tests. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11403
2015-01-16 00:57:45 +01:00
'PhabricatorTriggerClock' => 'Phobject',
'PhabricatorTriggerClockTestCase' => 'PhabricatorTestCase',
Implement clock/trigger infrastructure for scheduling actions Summary: Ref T6881. Hopefully, this is the hard part. This adds a new daemon (the "trigger" daemon) which processes triggers, schedules them, and then executes them at the scheduled time. The design is a little complicated, but has these goals: - High resistance to race conditions: only the application writes to the trigger table; only the daemon writes to the event table. We won't lose events if someone saves a meeting at the same time as we're sending a reminder out for it. - Execution guarantees: scheduled events are guaranteed to execute exactly once. - Support for arbitrarily large queues: the daemon will make progress even if there are millions of triggers in queue. The cost to update the queue is proportional to the number of changes in it; the cost to process the queue is proportional to the number of events to execute. - Relatively good observability: you can monitor the state of the trigger queue reasonably well from the web UI. - Modular Infrastructure: this is a very low-level construct that Calendar, Phortune, etc., should be able to build on top of. It doesn't have this stuff yet: - Not very robust to bad actions: a misbehaving trigger can stop the queue fairly easily. This is OK for now since we aren't planning to make it part of any other applications for a while. We do still get execute-exaclty-once, but it might not happen for a long time (until someone goes and fixes the queue), when we could theoretically continue executing other events. - Doesn't start automatically: normal users don't need to run this thing yet so I'm not starting it by default. - Not super well tested: I've vetted the basics but haven't run real workloads through this yet. - No sophisticated tooling: I added some basic stuff but it's missing some pieces we'll have to build sooner or later, e.g. `bin/trigger cancel` or whatever. - Intentionally not realtime: This design puts execution guarantees far above realtime concerns, and will not give you precise event execution at 1-second resolution. I think this is the correct goal to pursue architecturally, and certainly correct for subscriptions and meeting reminders. Events which execute after they have become irrelevant can simply decline to do anything (like a meeting reminder which executes after the meeting is over). In general, the expectation for applications is: - When creating an object (like a calendar event) that needs to trigger a scheduled action, write a trigger (and save the PHID if you plan to update it later). - The daemon will process the event and schedule the action efficiently, in a race-free way. - If you want to move the action, update the trigger and the daemon will take care of it. - Your action will eventually dump a task into the task queue, and the task daemons will actually perform it. Test Plan: Using a test script like this: ``` <?php require_once 'scripts/__init_script__.php'; $trigger = id(new PhabricatorWorkerTrigger()) ->setAction( new PhabricatorLogTriggerAction( array( 'message' => 'test', ))) ->setClock( new PhabricatorMetronomicTriggerClock( array( 'period' => 33, ))) ->save(); var_dump($trigger); ``` ...I queued triggers and ran the daemon: - Verified triggers fire; - verified triggers reschedule; - verified trigger events show up in the web UI; - tried different periods; - added some triggers while the daemon was running; - examined `phd debug` output for anything suspicious. It seems to work in trivial use case, at least. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11419
2015-01-16 21:13:31 +01:00
'PhabricatorTriggerDaemon' => 'PhabricatorDaemon',
Add a little more unit test documentation, fail loudly when isolation prevents a query Summary: - Provide an example unit test, and document it. - Document database isolation better. - When we issue an unsimulated query to the isolated connection, throw a helpful message. - Pygments is complaining about my madeup "lang=demo", change it to "lang=text". Test Plan: - Ran the unit test (sanity check). - Ran all other unit tests (verify I didn't break isolation). - Added a queryfx(..., 'SELECT 1') to a test and verified it throws. - Read the documentation. Reviewed By: edward Reviewers: edward, jungejason, tuomaspelkonen, aran CC: aran, edward Differential Revision: 773
2011-08-03 17:17:53 +02:00
'PhabricatorTrivialTestCase' => 'PhabricatorTestCase',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorTwitchAuthProvider' => 'PhabricatorOAuth2AuthProvider',
'PhabricatorTwitterAuthProvider' => 'PhabricatorOAuth1AuthProvider',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorTypeaheadApplication' => 'PhabricatorApplication',
Begin modularizing typeahead sources Summary: Ref T4420. This sets up the basics for modular typeahead sources. Basically, the huge `switch()` is just replaced with class-based runtime dispatch. The only clever bit I'm doing here is with `CompositeDatasource`, which pretty much just combines the results from several other datasources. We can use this to implement some of the weird cases where we need multiple types of results, although I think I can entirely eliminate many of them entirely. It also makes top-level implementation simpler, since more logic can go inside the sources. Sources are also application-aware, will be responsible for placeholder text, and have a slightly nicer debug view. Test Plan: {F112859} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D8228
2014-02-14 19:23:25 +01:00
'PhabricatorTypeaheadCompositeDatasource' => 'PhabricatorTypeaheadDatasource',
'PhabricatorTypeaheadDatasource' => 'Phobject',
Typeaheads
2011-01-25 22:48:05 +01:00
'PhabricatorTypeaheadDatasourceController' => 'PhabricatorController',
Add contextual typeahead function documentation Summary: Ref T4100. This integration into the "Browse" dialog is probably a little more heavy-handed than we should shoot for. Test Plan: {F377131} {F377132} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12482
2015-04-20 22:43:07 +02:00
'PhabricatorTypeaheadFunctionHelpController' => 'PhabricatorTypeaheadDatasourceController',
Implement viewer() and members(project) typeahead functions Summary: Ref T4100. This is still a bit rough around the edges, but mostly does what we're after. - Implements viewer() and members(...) functions. - The new browse workflow makes these discoverable. Test Plan: {F374201} Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12444
2015-04-17 00:30:41 +02:00
'PhabricatorTypeaheadInvalidTokenException' => 'Exception',
Begin modularizing typeahead sources Summary: Ref T4420. This sets up the basics for modular typeahead sources. Basically, the huge `switch()` is just replaced with class-based runtime dispatch. The only clever bit I'm doing here is with `CompositeDatasource`, which pretty much just combines the results from several other datasources. We can use this to implement some of the weird cases where we need multiple types of results, although I think I can entirely eliminate many of them entirely. It also makes top-level implementation simpler, since more logic can go inside the sources. Sources are also application-aware, will be responsible for placeholder text, and have a slightly nicer debug view. Test Plan: {F112859} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D8228
2014-02-14 19:23:25 +01:00
'PhabricatorTypeaheadModularDatasourceController' => 'PhabricatorTypeaheadDatasourceController',
'PhabricatorTypeaheadMonogramDatasource' => 'PhabricatorTypeaheadDatasource',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorTypeaheadResult' => 'Phobject',
Begin modularizing typeahead sources Summary: Ref T4420. This sets up the basics for modular typeahead sources. Basically, the huge `switch()` is just replaced with class-based runtime dispatch. The only clever bit I'm doing here is with `CompositeDatasource`, which pretty much just combines the results from several other datasources. We can use this to implement some of the weird cases where we need multiple types of results, although I think I can entirely eliminate many of them entirely. It also makes top-level implementation simpler, since more logic can go inside the sources. Sources are also application-aware, will be responsible for placeholder text, and have a slightly nicer debug view. Test Plan: {F112859} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D8228
2014-02-14 19:23:25 +01:00
'PhabricatorTypeaheadRuntimeCompositeDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Make browse view show tokens instead of raw data Summary: Ref T5750. Move the server-side token rendering code to a shared location and use it in the browse view. Test Plan: {F372252} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5750 Differential Revision: https://secure.phabricator.com/D12424
2015-04-15 18:16:26 +02:00
'PhabricatorTypeaheadTokenView' => 'AphrontTagView',
Add UI for choosing header color Summary: See D7731. Fixes T4194. Test Plan: {F88020} Reviewers: chad, btrahan Reviewed By: chad CC: aran, mbishopim3 Maniphest Tasks: T4194 Differential Revision: https://secure.phabricator.com/D7740
2013-12-07 19:46:09 +01:00
'PhabricatorUIConfigOptions' => 'PhabricatorApplicationConfigOptions',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorUIExample' => 'Phobject',
Modernize UIExamples Summary: - Get rid of an AphrontSideNavView callsite. - Modernize and simplify the application implementation. - Doesn't work perfectly on tablet/phone but that's because not all the UI examples work there yet. Test Plan: Looked at /applications/ and /uiexample/. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3431
2012-09-11 18:56:40 +02:00
'PhabricatorUIExampleRenderController' => 'PhabricatorController',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorUIExamplesApplication' => 'PhabricatorApplication',
Update Phabricator to work with more modular translations Summary: Ref T7152. Ref T1139. This updates Phabricator so third-party libraries can translate their own stuff. Also: - Hide "All Caps" when not in development mode, since some users have found this a little confusing. - With other changes, adds a "Raw Strings" mode (development mode only). - Add an example silly translation to make sure the serious business flag works. - Add a basic British English translation. - Simplify handling of translation overrides. Test Plan: - Flipped serious business / development on and off and saw silly/development translations drop off. - Switched to "All Caps" and saw all caps. - Switched to Very English, Wow! - Switched to British english and saw "colour". Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152, T1139 Differential Revision: https://secure.phabricator.com/D11747
2015-02-11 22:02:35 +01:00
'PhabricatorUSEnglishTranslation' => 'PhutilTranslation',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorUnitTestContentSource' => 'PhabricatorContentSource',
Document configuration of file upload limits Summary: I have a patch which makes uploads all fancy and adds progress bars, but document the landscape first since it's quite complicated. Test Plan: Generated, read docs. Configured `storage.upload-size-limit` to various values. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran Maniphest Tasks: T875 Differential Revision: https://secure.phabricator.com/D2381
2012-05-04 02:30:17 +02:00
'PhabricatorUnitsTestCase' => 'PhabricatorTestCase',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorUnknownContentSource' => 'PhabricatorContentSource',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorUnsubscribedFromObjectEdgeType' => 'PhabricatorEdgeType',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorUser' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorUserDAO',
'PhutilPerson',
'PhabricatorPolicyInterface',
'PhabricatorCustomFieldInterface',
'PhabricatorDestructibleInterface',
Separate SSH key management from the settings panel Summary: Ref T5833. I want to add SSH keys to Almanac devices, but the edit workflows for them are currently bound tightly to users. Instead, decouple key management from users and the settings panel. Test Plan: - Uploaded, generated, edited and deleted SSH keys. - Hit missing name, missing key, bad key format, duplicate key errors. - Edited/generated/deleted/etc keys for a bot user as an administrator. - Got HiSec'd on everything. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5833 Differential Revision: https://secure.phabricator.com/D10824
2014-11-11 17:18:26 +01:00
'PhabricatorSSHPublicKeyInterface',
Allow People to be Flagged Summary: Ref T8888, Makes People Flaggable (and makes me wonder if we should rename Flags->Bookmarks). Test Plan: Flag myself. Get excited. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: joshuaspence, epriestley, Korvin Maniphest Tasks: T8888 Differential Revision: https://secure.phabricator.com/D13654
2015-07-20 22:43:58 +02:00
'PhabricatorFlaggableInterface',
Implement PhabricatorApplicationTransactionInterface on PhabricatorUser Summary: Right now, "Publish" workers for user profile edits (title / blub) can get gummed up in the daemons. Implement the interfaces and provide a Query so they can go through. Test Plan: - Made a profile "Title" edit. - Used `bin/worker execute --id <id>` to see task fail. - Applied patch. - Saw task work. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D13213
2015-06-08 22:35:57 +02:00
'PhabricatorApplicationTransactionInterface',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorFulltextInterface',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
),
Add "Title" and "Blurb" to new profile editor Summary: Ref T1703. - Adds "Title". - Adds "Blurb". - Adds `user.fields` config for selecting and reordering. This will get UI in the next patch. Test Plan: {F45689} {F45690} Edited the fields, too. Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6153
2013-06-07 19:22:45 +02:00
'PhabricatorUserBlurbField' => 'PhabricatorUserCustomField',
New People Hovercards Summary: Mimics the Project Hovercards, more custom UI. Test Plan: Hover over person with and without badges, hover over project. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D15253
2016-02-11 23:55:44 +01:00
'PhabricatorUserCardView' => 'AphrontTagView',
Add "Title" and "Blurb" to new profile editor Summary: Ref T1703. - Adds "Title". - Adds "Blurb". - Adds `user.fields` config for selecting and reordering. This will get UI in the next patch. Test Plan: {F45689} {F45690} Edited the fields, too. Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6153
2013-06-07 19:22:45 +02:00
'PhabricatorUserConfigOptions' => 'PhabricatorApplicationConfigOptions',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorUserConfiguredCustomField' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorUserCustomField',
'PhabricatorStandardCustomFieldInterface',
Allow user override translation and implement PhutilPerson Test Plan: Altered database. Wrote a custom translation and selected it in preferences. Verified that the text is custom translated. Set language back to default. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D2757
2012-06-15 03:08:06 +02:00
),
Support configuration-driven custom fields Summary: Ref T1702. Ref T3718. There are a couple of things going on here: **PhabricatorCustomFieldList**: I added `PhabricatorCustomFieldList`, which is just a convenience class for dealing with lists of fields. Often, current field code does something like this inline in a Controller: foreach ($fields as $field) { // do some junk } Often, that junk has some slightly subtle implications. Move all of it to `$list->doSomeJunk()` methods (like `appendFieldsToForm()`, `loadFieldsFromStorage()`) to reduce code duplication and prevent errors. This additionally moves an existing list-convenience method there, out of `PhabricatorPropertyListView`. **PhabricatorUserConfiguredCustomFieldStorage**: Adds `PhabricatorUserConfiguredCustomFieldStorage` for storing custom field data (like "ICQ Handle", "Phone Number", "Desk", "Favorite Flower", etc). **Configuration-Driven Custom Fields**: Previously, I was thinking about doing these with interfaces, but as I thought about it more I started to dislike that approach. Instead, I built proxies into `PhabricatorCustomField`. Basically, this means that fields (like a custom, configuration-driven "Favorite Flower" field) can just use some other Field to actually provide their implementation (like a "standard" field which knows how to render text areas). The previous approach would have involed subclasssing the "standard" field and implementing an interface, but that would mean that every application would have at least two "base" fields and generally just seemed bleh as I worked through it. The cost of this approach is that we need a bunch of `proxy` junk in the base class, but that's a one-time cost and I think it simplifies all the implementations and makes them a lot less magical (e.g., all of the custom fields now extend the right base field classes). **Fixed Some Bugs**: Some of this code hadn't really been run yet and had minor bugs. Test Plan: {F54240} {F54241} {F54242} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1702, T1703, T3718 Differential Revision: https://secure.phabricator.com/D6749
2013-08-14 17:10:16 +02:00
'PhabricatorUserConfiguredCustomFieldStorage' => 'PhabricatorCustomFieldStorage',
'PhabricatorUserCustomField' => 'PhabricatorCustomField',
Integrate ApplicationSearch with CustomField Summary: Ref T2625. Ref T3794. Ref T418. Ref T1703. This is a more general version of D5278. It expands CustomField support to include real integration with ApplicationSearch. Broadly, custom fields may elect to: - build indicies when objects are updated; - populate ApplicationSearch forms with new controls; - read inputs entered into those controls out of the request; and - apply constraints to search queries. Some utility/helper stuff is provided to make this easier. This part could be cleaner, but seems reasonable for a first cut. In particular, the Query and SearchEngine must manually call all the hooks right now instead of everything happening magically. I think that's fine for the moment; they're pretty easy to get right. Test Plan: I added a new searchable "Company" field to People: {F58229} This also cleaned up the disable/reorder view a little bit: {F58230} As it did before, this field appears on the edit screen: {F58231} However, because it has `search`, it also appears on the search screen: {F58232} When queried, it returns the expected results: {F58233} And the actually good bit of all this is that the query can take advantage of indexes: mysql> explain SELECT * FROM `user` user JOIN `user_customfieldstringindex` `appsearch_0` ON `appsearch_0`.objectPHID = user.phid AND `appsearch_0`.indexKey = 'mk3Ndy476ge6' AND `appsearch_0`.indexValue IN ('phacility') ORDER BY user.id DESC LIMIT 101; +----+-------------+-------------+--------+-------------------+----------+---------+------------------------------------------+------+----------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------------+--------+-------------------+----------+---------+------------------------------------------+------+----------------------------------------------+ | 1 | SIMPLE | appsearch_0 | ref | key_join,key_find | key_find | 232 | const,const | 1 | Using where; Using temporary; Using filesort | | 1 | SIMPLE | user | eq_ref | phid | phid | 194 | phabricator2_user.appsearch_0.objectPHID | 1 | | +----+-------------+-------------+--------+-------------------+----------+---------+------------------------------------------+------+----------------------------------------------+ 2 rows in set (0.00 sec) Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T1703, T2625, T3794 Differential Revision: https://secure.phabricator.com/D6992
2013-09-16 22:44:34 +02:00
'PhabricatorUserCustomFieldNumericIndex' => 'PhabricatorCustomFieldNumericIndexStorage',
'PhabricatorUserCustomFieldStringIndex' => 'PhabricatorCustomFieldStringIndexStorage',
Basic user/account tool.
2011-01-24 03:09:16 +01:00
'PhabricatorUserDAO' => 'PhabricatorLiskDAO',
If users are on the email to Phabricator, do not send them the Phabricator reply. Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email. Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected. Reviewers: epriestley, vrana Reviewed By: vrana CC: aran, Korvin, vrana Maniphest Tasks: T1676 Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 19:18:23 +02:00
'PhabricatorUserEditor' => 'PhabricatorEditor',
Disallow email addresses which will overflow MySQL storage Summary: Via HackerOne. An attacker can bypass `auth.email-domains` by registering with an email like: aaaaa...aaaaa@evil.com@company.com We'll validate the full string, then insert it into the database where it will be truncated, removing the `@company.com` part. Then we'll send an email to `@evil.com`. Instead, reject email addresses which won't fit in the table. `STRICT_ALL_TABLES` stops this attack, I'm going to add a setup warning encouraging it. Test Plan: - Set `auth.email-domains` to `@company.com`. - Registered with `aaa...aaa@evil.com@company.com`. Previously this worked, now it is rejected. - Did a valid registration. - Tried to add `aaa...aaaa@evil.com@company.com` as an email address. Previously this worked, now it is rejected. - Did a valid email add. - Added and executed unit tests. Reviewers: btrahan, arice Reviewed By: arice CC: aran, chad Differential Revision: https://secure.phabricator.com/D8308
2014-02-23 19:19:35 +01:00
'PhabricatorUserEditorTestCase' => 'PhabricatorTestCase',
Allow users to have multiple email addresses, and verify emails Summary: - Move email to a separate table. - Migrate existing email to new storage. - Allow users to add and remove email addresses. - Allow users to verify email addresses. - Allow users to change their primary email address. - Convert all the registration/reset/login code to understand these changes. - There are a few security considerations here but I think I've addressed them. Principally, it is important to never let a user acquire a verified email address they don't actually own. We ensure this by tightening the scoping of token generation rules to be (user, email) specific. - This should have essentially zero impact on Facebook, but may require some minor changes in the registration code -- I don't exactly remember how it is set up. Not included here (next steps): - Allow configuration to restrict email to certain domains. - Allow configuration to require validated email. Test Plan: This is a fairly extensive, difficult-to-test change. - From "Email Addresses" interface: - Added new email (verified email verifications sent). - Changed primary email (verified old/new notificactions sent). - Resent verification emails (verified they sent). - Removed email. - Tried to add already-owned email. - Created new users with "accountadmin". Edited existing users with "accountadmin". - Created new users with "add_user.php". - Created new users with web interface. - Clicked welcome email link, verified it verified email. - Reset password. - Linked/unlinked oauth accounts. - Logged in with oauth account. - Logged in with email. - Registered with Oauth account. - Tried to register with OAuth account with duplicate email. - Verified errors for email verification with bad tokens, etc. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1184 Differential Revision: https://secure.phabricator.com/D2393
2012-05-07 19:29:33 +02:00
'PhabricatorUserEmail' => 'PhabricatorUserDAO',
Add rough validation on email addresses Summary: Put a very rough filter on what we'll accept as an email address. We can expand this if anyone is actually using local delivery or other weird things. This is mostly to avoid a theoretical case where some input is parsed differently by `PhutilAddressParser` and the actual mail adapter, in some subtle hypothetical way. This should give us only "reasonable" email addresses which parsers would be hard-pressed to trip up on. Test Plan: Added and executed unit tests. Tried to add silly emails. Added valid emails. Reviewers: btrahan, arice Reviewed By: arice CC: arice, chad, aran Differential Revision: https://secure.phabricator.com/D8320
2014-02-24 02:31:46 +01:00
'PhabricatorUserEmailTestCase' => 'PhabricatorTestCase',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorUserFulltextEngine' => 'PhabricatorFulltextEngine',
Allow users to have profile icons Summary: Ref T10054. This primarily improves aesthetics and consistency for member/wathcher lists in projects. Test Plan: {F1068873} {F1068874} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10054 Differential Revision: https://secure.phabricator.com/D15103
2016-01-24 14:43:57 +01:00
'PhabricatorUserIconField' => 'PhabricatorUserCustomField',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhabricatorUserLog' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorUserDAO',
'PhabricatorPolicyInterface',
Modernize user activity logs (ApplicationSearch, policies) Summary: Ref T4398. Ref T4842. I want to let users review their own account activity, partly as a general security measure and partly to make some of the multi-factor stuff easier to build and debug. To support this, implement modern policies and application search. I also removed the "old" and "new" columns from this output, since they had limited utility and revealed email addresses to administrators for some actions. We don't let administrators access email addresses from other UIs, and the value of doing so here seems very small. Test Plan: Used interface to issue a bunch of queries against user logs, got reasonable/expected results. Reviewers: btrahan Reviewed By: btrahan Subscribers: keir, epriestley Maniphest Tasks: T4842, T4398 Differential Revision: https://secure.phabricator.com/D8856
2014-04-28 02:31:35 +02:00
),
Let users review their own account activity logs Summary: Ref T4398. This adds a settings panel for account activity so users can review activity on their own account. Some goals are: - Make it easier for us to develop and support auth and credential information, see T4398. This is the primary driver. - Make it easier for users to understand and review auth and credential information (see T4842 for an example -- this isn't there yet, but builds toward it). - Improve user confidence in security by making logging more apparent and accessible. Minor corresponding changes: - Entering and exiting hisec mode is now logged. - This, sessions, and OAuth authorizations have moved to a new "Sessions and Logs" area, since "Authentication" was getting huge. Test Plan: - Viewed new panel. - Viewed old UI. - Entered/exited hisec and got prompted. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8871
2014-04-28 02:32:09 +02:00
'PhabricatorUserLogView' => 'AphrontView',
Provide formal Users/Projects/Mailable fields for EditEngine Summary: Ref T9132. This allows you to prefill EditEngine forms with stuff like `?subscribers=epriestley`, and we'll figure out what you mean. Test Plan: - Did `/?subscribers=...` with various values (good, bad, mis-capitalized). - Did `/?projects=...` with various values (good, bad, mis-capitalized). - Reviewed documentation. - Reviewed {nav Config > HTTP Parameter Types}. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14404
2015-11-04 19:20:38 +01:00
'PhabricatorUserPHIDResolver' => 'PhabricatorPHIDResolver',
User preferences ported from tools Summary: Internal tools, e.g., differential and diffusion have user defined preferences for monospaced font and the option for showing either the name of the tool or the glyph of the tool in the title. These preferences were ported to phabricator. These preferences can be modified in /preferences/ and they both affect diffusion and differential at the moment. Test Plan: * Created an empty database * Loaded /preferences/ and modified the monospaced font and clicked save * Confirmed that the same page was loaded with the message that preferences have been saved and that the example text used the user defined font * in /preferences/ changed the option to show tool names as plain text and clicked save * Confirmed that the same page was loaded with '[Preferences]' in the title instead of a glyph * These same tests were also executed for differential and diffusion Reviewers: epriestley CC: jungejason Differential Revision: 91
2011-03-31 04:21:09 +02:00
'PhabricatorUserPreferences' => 'PhabricatorUserDAO',
Slightly more sophisticated profiles. Summary: Test Plan: Reviewers: CC:
2011-02-20 03:28:41 +01:00
'PhabricatorUserProfile' => 'PhabricatorUserDAO',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
'PhabricatorUserProfileEditor' => 'PhabricatorApplicationTransactionEditor',
'PhabricatorUserRealNameField' => 'PhabricatorUserCustomField',
Move roles and status into properties on profile view Summary: See discussion in D6403. Test Plan: {F49488} Reviewers: chad, btrahan Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6409
2013-07-10 21:34:09 +02:00
'PhabricatorUserRolesField' => 'PhabricatorUserCustomField',
Generate expected schemata for User/People tables Summary: Ref T1191. Some notes here: - Drops the old LDAP and OAuth info tables. These were migrated to the ExternalAccount table a very long time ago. - Separates surplus/missing keys from other types of surplus/missing things. In the long run, my plan is to have only two notice levels: - Error: something we can't fix (missing database, table, or column; overlong key). - Warning: something we can fix (surplus anything, missing key, bad column type, bad key columns, bad uniqueness, bad collation or charset). - For now, retaining three levels is helpful in generating all the expected scheamta. Test Plan: - Saw ~200 issues resolve, leaving ~1,300. - Grepped for removed tables. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10580
2014-10-01 16:36:47 +02:00
'PhabricatorUserSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Merge profile "About" into main profile and simplify some custom field stuff Summary: Ref T1703. Drive "user since" with a custom field and make the other fields render into a property list. Users can make their profiles a little more personal/obnoxious now. Also delete a bunch of code. Test Plan: {F49415} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6401
2013-07-10 14:09:59 +02:00
'PhabricatorUserSinceField' => 'PhabricatorUserCustomField',
Move roles and status into properties on profile view Summary: See discussion in D6403. Test Plan: {F49488} Reviewers: chad, btrahan Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6409
2013-07-10 21:34:09 +02:00
'PhabricatorUserStatusField' => 'PhabricatorUserCustomField',
Unify logic for username validation Summary: Revisit of D1254. Don't require lowercase, just standardize the logic. The current implementation has nonuniform logic -- PeopleEditController forbids uppercase. Test Plan: Ran unit tests, see also D1254. Reviewers: btrahan, jungejason, aran Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1415
2012-01-16 16:30:28 +01:00
'PhabricatorUserTestCase' => 'PhabricatorTestCase',
Add "Title" and "Blurb" to new profile editor Summary: Ref T1703. - Adds "Title". - Adds "Blurb". - Adds `user.fields` config for selecting and reordering. This will get UI in the next patch. Test Plan: {F45689} {F45690} Edited the fields, too. Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6153
2013-06-07 19:22:45 +02:00
'PhabricatorUserTitleField' => 'PhabricatorUserCustomField',
Flesh out ApplicationTransactions/CustomField integration Summary: None of this code is reachable yet. See discussion in D6147. Ref T1703. Provide tighter integration between ApplicationTransactions and CustomField. Basically, I'm just trying to get all the shared stuff into the base implementation. Test Plan: Code not reachable. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6149
2013-06-06 23:53:07 +02:00
'PhabricatorUserTransaction' => 'PhabricatorApplicationTransaction',
Provide formal Users/Projects/Mailable fields for EditEngine Summary: Ref T9132. This allows you to prefill EditEngine forms with stuff like `?subscribers=epriestley`, and we'll figure out what you mean. Test Plan: - Did `/?subscribers=...` with various values (good, bad, mis-capitalized). - Did `/?projects=...` with various values (good, bad, mis-capitalized). - Reviewed documentation. - Reviewed {nav Config > HTTP Parameter Types}. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9132 Differential Revision: https://secure.phabricator.com/D14404
2015-11-04 19:20:38 +01:00
'PhabricatorUsersEditField' => 'PhabricatorTokenizerEditField',
Rename `PhabricatorPolicyRule` subclasses for consistency Summary: Ref T5655. Fixes T6849. This is another take on D11131, which was missing the DB migration and was reverted in rP7c4de0f6be77ddaea593e1f41ae27211ec179a55. Test Plan: Ran `./bin/storage upgrade` and verified that the classes were renamed in the `phabricator_policy.policy` table. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6849, T5655 Differential Revision: https://secure.phabricator.com/D11166
2015-01-03 13:48:19 +01:00
'PhabricatorUsersPolicyRule' => 'PhabricatorPolicyRule',
Move some PhabricatorSearchField subclasses Summary: Move some `PhabricatorSearchField` subclasses to be adjacent to the application to which they belong. This seems generally better to me than lumping them all together in the `src/applications/search/field/` directory. I was also wondering if it makes sense to rename these subclasses as `PhabricatorXSearchField` rather than `PhabricatorSearchXField` (as per T5655), but wasn't really sure if these objects are meant to be search-fields, or just fields belonging to the #search application. Test Plan: N/A. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13374
2015-07-06 14:52:04 +02:00
'PhabricatorUsersSearchField' => 'PhabricatorSearchTokenizerField',
Accept and route VCS HTTP requests Summary: Mostly ripped from D7391, with some changes: - Serve repositories at `/diffusion/X/`, with no special `/git/` or `/serve/` URI component. - This requires a little bit of magic, but I got the magic working for Git, Mercurial and SVN, and it seems reasonable. - I think having one URI for everything will make it easier for users to understand. - One downside is that git will clone into `X` by default, but I think that's not a big deal, and we can work around that in the future easily enough. - Accept HTTP requests for Git, SVN and Mercurial repositories. - Auth logic is a little different in order to be more consistent with how other things work. - Instead of AphrontBasicAuthResponse, added "VCSResponse". Mercurial can print strings we send it on the CLI if we're careful, so support that. I did a fair amount of digging and didn't have any luck with git or svn. - Commands we don't know about are assumed to require "Push" capability by default. No actual VCS data going over the wire yet. Test Plan: Ran a bunch of stuff like this: $ hg clone http://local.aphront.com:8080/diffusion/P/ abort: HTTP Error 403: This repository is not available over HTTP. ...and got pretty reasonable-seeming errors in all cases. All this can do is produce errors for now. Reviewers: hach-que, btrahan Reviewed By: hach-que CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7417
2013-10-26 16:56:17 +02:00
'PhabricatorVCSResponse' => 'AphrontResponse',
Implement versioned drafts in EditEngine comment forms Summary: Ref T9132. Fixes T5031. This approximately implements the plan described in T5031#67988: When we recieve a preview request, don't write a draft if the form is from a version of the object before the last update the viewer made. This should fix the race-related (?) zombie draft comments that sometimes show up. I just added a new object for this stuff to make it easier to do stacked actions (or whatever we end up with) a little later, since I needed to do some schema adjustments anyway. Test Plan: - Typed some text. - Reloaded page. - Draft stayed there. - Tried real hard to get it to ghost by submitting stuff in multiple windows and typing a lot and couldn't, although I didn't bother specifically narrowing down the race condition. Reviewers: chad Reviewed By: chad Maniphest Tasks: T5031, T9132 Differential Revision: https://secure.phabricator.com/D14640
2015-12-02 21:25:24 +01:00
'PhabricatorVersionedDraft' => 'PhabricatorDraftDAO',
Update Phabricator to work with more modular translations Summary: Ref T7152. Ref T1139. This updates Phabricator so third-party libraries can translate their own stuff. Also: - Hide "All Caps" when not in development mode, since some users have found this a little confusing. - With other changes, adds a "Raw Strings" mode (development mode only). - Add an example silly translation to make sure the serious business flag works. - Add a basic British English translation. - Simplify handling of translation overrides. Test Plan: - Flipped serious business / development on and off and saw silly/development translations drop off. - Switched to "All Caps" and saw all caps. - Switched to Very English, Wow! - Switched to British english and saw "colour". Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7152, T1139 Differential Revision: https://secure.phabricator.com/D11747
2015-02-11 22:02:35 +01:00
'PhabricatorVeryWowEnglishTranslation' => 'PhutilTranslation',
Implement viewer() and members(project) typeahead functions Summary: Ref T4100. This is still a bit rough around the edges, but mostly does what we're after. - Implements viewer() and members(...) functions. - The new browse workflow makes these discoverable. Test Plan: {F374201} Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T4100 Differential Revision: https://secure.phabricator.com/D12444
2015-04-17 00:30:41 +02:00
'PhabricatorViewerDatasource' => 'PhabricatorTypeaheadDatasource',
Modernize remaining edge types Summary: Modernize remaining edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Browsed around and performed various actions include subscribing, unsubscribing and watching. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D11116
2015-01-03 00:33:25 +01:00
'PhabricatorWatcherHasObjectEdgeType' => 'PhabricatorEdgeType',
Modularize content sources Summary: Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually. Split ContentSource apart so applications can add new content sources. Test Plan: This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours. - Viewed new module page. - Grepped for all removed functions/constants. - Viewed some transactions. - Hovered over timestamps to get content source details. - Added a comment via Conduit. - Added a comment via web. - Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations. - Generated some objects with `bin/lipsum`. - Ran a bulk job on some tasks. - Ran unit tests. {F1190182} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10537 Differential Revision: https://secure.phabricator.com/D15521
2016-03-25 13:56:16 +01:00
'PhabricatorWebContentSource' => 'PhabricatorContentSource',
Rename auth classes for consistency Summary: Ref T5655. Depends on D9998. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: 20after4, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9999
2014-07-22 13:04:13 +02:00
'PhabricatorWordPressAuthProvider' => 'PhabricatorOAuth2AuthProvider',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhabricatorWorker' => 'Phobject',
Move completed tasks to an "archive" table and delete them in the GC Summary: Currently, when taskmasters complete a task it is immediately deleted. This prevents us from doing some general things, like: - Supporting the idea of permanent failure (e.g., after N failures just stop trying). - Showing the user how fast taskmasters are completing tasks. - Showing the user how long tasks took to complete. Having better visibility into this is important to Drydock, which builds on the task system. Also, generally buff debug output for task execution. Test Plan: Ran `bin/phd debug taskmaster`. Ran `bin/phd debug garbage`. Queued some tasks via various systems. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3852
2012-10-31 23:22:16 +01:00
'PhabricatorWorkerActiveTask' => 'PhabricatorWorkerTask',
'PhabricatorWorkerArchiveTask' => 'PhabricatorWorkerTask',
Daemons - introduce PhabricatorWorkerArchiveTaskQuery Summary: Ref T5402. This cleans up some code and sets us up to use this sort of data more easily later. Test Plan: viewed the daemon console from the web and the log of a specific archived daemon. both looked good. for other callsites looked really, really carefully. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T5402 Differential Revision: https://secure.phabricator.com/D11042
2014-12-24 00:45:42 +01:00
'PhabricatorWorkerArchiveTaskQuery' => 'PhabricatorQuery',
Execute Maniphest batch edits in the background with a web UI progress bar Summary: Ref T8637. This does nothing interesting, just has empty scaffolding for a bulk job queue. Basic idea is that when you do something like a batch edit in Maniphest, we: - Create a BulkJob with all the details. - Queue a worker to start the job. - Send you to a progress bar page for the job. In the background: - The "start job" worker creates a ton of Task objects, then queues worker tasks to do the work. In the foreground: - Fancy ajax animates the progress bar and it goes wooosh. In general: - Big jobs actually work. - Jobs get logged. - You can monitor jobs. - Terrible junk like T8637 should be much harder to write and much easier to catch and diagnose. Test Plan: No interesting code/beahavior yet. Clean `storage adjust`. {F526411} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8637 Differential Revision: https://secure.phabricator.com/D13392
2015-06-23 22:36:16 +02:00
'PhabricatorWorkerBulkJob' => array(
'PhabricatorWorkerDAO',
'PhabricatorPolicyInterface',
'PhabricatorSubscribableInterface',
'PhabricatorApplicationTransactionInterface',
'PhabricatorDestructibleInterface',
),
'PhabricatorWorkerBulkJobCreateWorker' => 'PhabricatorWorkerBulkJobWorker',
'PhabricatorWorkerBulkJobEditor' => 'PhabricatorApplicationTransactionEditor',
'PhabricatorWorkerBulkJobPHIDType' => 'PhabricatorPHIDType',
'PhabricatorWorkerBulkJobQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhabricatorWorkerBulkJobSearchEngine' => 'PhabricatorApplicationSearchEngine',
'PhabricatorWorkerBulkJobTaskWorker' => 'PhabricatorWorkerBulkJobWorker',
'PhabricatorWorkerBulkJobTestCase' => 'PhabricatorTestCase',
'PhabricatorWorkerBulkJobTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorWorkerBulkJobTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'PhabricatorWorkerBulkJobType' => 'Phobject',
'PhabricatorWorkerBulkJobWorker' => 'PhabricatorWorker',
'PhabricatorWorkerBulkTask' => 'PhabricatorWorkerDAO',
Rough cut of Workers Summary: workers do work, provided I have written them correctly. perhaps it is so. Test Plan: Reviewers: CC:
2011-03-10 22:48:29 +01:00
'PhabricatorWorkerDAO' => 'PhabricatorLiskDAO',
Fully modularize DestructionEngine Summary: Ref T9979. Convert all DestructionEngine behaviors to extensions. Test Plan: {F1033244} Destroyed an object, verifying: - Herald transcripts were destroyed; - edges were destroyed; - flags were destroyed; - tokens were destroyed; - transactions were destroyed; - worker tasks were cancelled. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14832
2015-12-20 17:11:59 +01:00
'PhabricatorWorkerDestructionEngineExtension' => 'PhabricatorDestructionEngineExtension',
Move task leasing to a dedicated query Summary: This simplifies the fairly thorny logic of leasing tasks a bit. I'm planning to introduce another callsite shortly for Drydock. Test Plan: Ran `bin/phd debug taskmaster`, observed sensible queries and correct operation. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3855
2012-11-01 19:30:16 +01:00
'PhabricatorWorkerLeaseQuery' => 'PhabricatorQuery',
Move cancel/retry/free task queue actions to bin/worker Summary: Fixes T6702. Ref T3554. Currently, tasks can be cancelled, retried and freed from the web UI by any logged in user. This isn't appreciably dangerous (I can't come up with a way that a user could do anything security-affecting), but I think I probably intended this to be admin-only, but these actions should move to the CLI anyway. Move them to the CLI. Lay some groundwork for some future `bin/worker cancel --class SomeTaskClass`, but don't implement that yet. Test Plan: Used `cancel`, `retry` and `free` from the CLI. Hit all the error/success states. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3554, T6702 Differential Revision: https://secure.phabricator.com/D10939
2014-12-06 18:14:16 +01:00
'PhabricatorWorkerManagementCancelWorkflow' => 'PhabricatorWorkerManagementWorkflow',
Send emails for email invites Summary: Ref T7152. Ref T3554. - When an administrator clicks "send invites", queue tasks to send the invites. - Then, actually send the invites. - Make the links in the invites work properly. - Also provide `bin/worker execute` to make debugging one-off workers like this easier. - Clean up some UI, too. Test Plan: We now get as far as the exception which is a placeholder for a registration workflow. {F291213} {F291214} {F291215} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3554, T7152 Differential Revision: https://secure.phabricator.com/D11736
2015-02-11 15:06:09 +01:00
'PhabricatorWorkerManagementExecuteWorkflow' => 'PhabricatorWorkerManagementWorkflow',
Add `bin/worker flood`, for flooding the task queue with work Summary: Ref T6615. Ref T3554. We need better tooling around the queue eventually, so start here. Test Plan: Added 100K+ tasks locally with `bin/worker flood`. Executed some of them with `bin/phd debug taskmaster` (we already have a TestWorker, used in unit tests). Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3554, T6615 Differential Revision: https://secure.phabricator.com/D10894
2014-11-24 20:10:15 +01:00
'PhabricatorWorkerManagementFloodWorkflow' => 'PhabricatorWorkerManagementWorkflow',
Move cancel/retry/free task queue actions to bin/worker Summary: Fixes T6702. Ref T3554. Currently, tasks can be cancelled, retried and freed from the web UI by any logged in user. This isn't appreciably dangerous (I can't come up with a way that a user could do anything security-affecting), but I think I probably intended this to be admin-only, but these actions should move to the CLI anyway. Move them to the CLI. Lay some groundwork for some future `bin/worker cancel --class SomeTaskClass`, but don't implement that yet. Test Plan: Used `cancel`, `retry` and `free` from the CLI. Hit all the error/success states. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3554, T6702 Differential Revision: https://secure.phabricator.com/D10939
2014-12-06 18:14:16 +01:00
'PhabricatorWorkerManagementFreeWorkflow' => 'PhabricatorWorkerManagementWorkflow',
'PhabricatorWorkerManagementRetryWorkflow' => 'PhabricatorWorkerManagementWorkflow',
Add `bin/worker flood`, for flooding the task queue with work Summary: Ref T6615. Ref T3554. We need better tooling around the queue eventually, so start here. Test Plan: Added 100K+ tasks locally with `bin/worker flood`. Executed some of them with `bin/phd debug taskmaster` (we already have a TestWorker, used in unit tests). Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3554, T6615 Differential Revision: https://secure.phabricator.com/D10894
2014-11-24 20:10:15 +01:00
'PhabricatorWorkerManagementWorkflow' => 'PhabricatorManagementWorkflow',
Factor out task execution and formalize permanent failures Summary: - Clean up a TODO about permanent failures. - Clean up a TODO about failing tasks after too many retries. - Clean up a TODO about testing for bad leases. - Make the lease/retry implementation more flexible and natural. - Make completely bogus tasks fail permanently. - Make PhabricatorMetaMTAWorker use new `getWaitBeforeRetry()` (as intended), not hackily implement logic in `getRequiredLeaseTime()`. - Document worker hooks for failures and retries. - Provide coverage on everything. Test Plan: Ran unit tests. Ran `bin/phd debug taskmaster`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3859
2012-11-01 19:30:23 +01:00
'PhabricatorWorkerPermanentFailureException' => 'Exception',
Execute Maniphest batch edits in the background with a web UI progress bar Summary: Ref T8637. This does nothing interesting, just has empty scaffolding for a bulk job queue. Basic idea is that when you do something like a batch edit in Maniphest, we: - Create a BulkJob with all the details. - Queue a worker to start the job. - Send you to a progress bar page for the job. In the background: - The "start job" worker creates a ton of Task objects, then queues worker tasks to do the work. In the foreground: - Fancy ajax animates the progress bar and it goes wooosh. In general: - Big jobs actually work. - Jobs get logged. - You can monitor jobs. - Terrible junk like T8637 should be much harder to write and much easier to catch and diagnose. Test Plan: No interesting code/beahavior yet. Clean `storage adjust`. {F526411} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8637 Differential Revision: https://secure.phabricator.com/D13392
2015-06-23 22:36:16 +02:00
'PhabricatorWorkerSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Rough cut of Workers Summary: workers do work, provided I have written them correctly. perhaps it is so. Test Plan: Reviewers: CC:
2011-03-10 22:48:29 +01:00
'PhabricatorWorkerTask' => 'PhabricatorWorkerDAO',
'PhabricatorWorkerTaskData' => 'PhabricatorWorkerDAO',
Improve daemon console.
2011-03-27 07:55:18 +02:00
'PhabricatorWorkerTaskDetailController' => 'PhabricatorDaemonController',
Factor out task execution and formalize permanent failures Summary: - Clean up a TODO about permanent failures. - Clean up a TODO about failing tasks after too many retries. - Clean up a TODO about testing for bad leases. - Make the lease/retry implementation more flexible and natural. - Make completely bogus tasks fail permanently. - Make PhabricatorMetaMTAWorker use new `getWaitBeforeRetry()` (as intended), not hackily implement logic in `getRequiredLeaseTime()`. - Document worker hooks for failures and retries. - Provide coverage on everything. Test Plan: Ran unit tests. Ran `bin/phd debug taskmaster`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3859
2012-11-01 19:30:23 +01:00
'PhabricatorWorkerTestCase' => 'PhabricatorTestCase',
Implement PhabricatorDestructibleInterface for event triggers Summary: Ref T6881. When stuff with triggers is destroyed, it should destroy the triggers. Test Plan: Will test in Instances. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11435
2015-01-20 01:55:38 +01:00
'PhabricatorWorkerTrigger' => array(
'PhabricatorWorkerDAO',
'PhabricatorDestructibleInterface',
Implement PolicyAwareQuery for triggers Summary: Ref T6881. I tried to cheat here by not implementing this, but we need it for destroying triggers directly with `bin/remove destroy`, since that needs to load them by PHID. So, cheat slightly less. Implement PolicyAware but not CursorPagedPolicyAware. Test Plan: - Used `bin/remove destroy` to destroy a trigger by PHID. - Browsed daemon console. - Ran trigger daemon. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11445
2015-01-20 22:32:43 +01:00
'PhabricatorPolicyInterface',
Implement PhabricatorDestructibleInterface for event triggers Summary: Ref T6881. When stuff with triggers is destroyed, it should destroy the triggers. Test Plan: Will test in Instances. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11435
2015-01-20 01:55:38 +01:00
),
Implement clock/trigger infrastructure for scheduling actions Summary: Ref T6881. Hopefully, this is the hard part. This adds a new daemon (the "trigger" daemon) which processes triggers, schedules them, and then executes them at the scheduled time. The design is a little complicated, but has these goals: - High resistance to race conditions: only the application writes to the trigger table; only the daemon writes to the event table. We won't lose events if someone saves a meeting at the same time as we're sending a reminder out for it. - Execution guarantees: scheduled events are guaranteed to execute exactly once. - Support for arbitrarily large queues: the daemon will make progress even if there are millions of triggers in queue. The cost to update the queue is proportional to the number of changes in it; the cost to process the queue is proportional to the number of events to execute. - Relatively good observability: you can monitor the state of the trigger queue reasonably well from the web UI. - Modular Infrastructure: this is a very low-level construct that Calendar, Phortune, etc., should be able to build on top of. It doesn't have this stuff yet: - Not very robust to bad actions: a misbehaving trigger can stop the queue fairly easily. This is OK for now since we aren't planning to make it part of any other applications for a while. We do still get execute-exaclty-once, but it might not happen for a long time (until someone goes and fixes the queue), when we could theoretically continue executing other events. - Doesn't start automatically: normal users don't need to run this thing yet so I'm not starting it by default. - Not super well tested: I've vetted the basics but haven't run real workloads through this yet. - No sophisticated tooling: I added some basic stuff but it's missing some pieces we'll have to build sooner or later, e.g. `bin/trigger cancel` or whatever. - Intentionally not realtime: This design puts execution guarantees far above realtime concerns, and will not give you precise event execution at 1-second resolution. I think this is the correct goal to pursue architecturally, and certainly correct for subscriptions and meeting reminders. Events which execute after they have become irrelevant can simply decline to do anything (like a meeting reminder which executes after the meeting is over). In general, the expectation for applications is: - When creating an object (like a calendar event) that needs to trigger a scheduled action, write a trigger (and save the PHID if you plan to update it later). - The daemon will process the event and schedule the action efficiently, in a race-free way. - If you want to move the action, update the trigger and the daemon will take care of it. - Your action will eventually dump a task into the task queue, and the task daemons will actually perform it. Test Plan: Using a test script like this: ``` <?php require_once 'scripts/__init_script__.php'; $trigger = id(new PhabricatorWorkerTrigger()) ->setAction( new PhabricatorLogTriggerAction( array( 'message' => 'test', ))) ->setClock( new PhabricatorMetronomicTriggerClock( array( 'period' => 33, ))) ->save(); var_dump($trigger); ``` ...I queued triggers and ran the daemon: - Verified triggers fire; - verified triggers reschedule; - verified trigger events show up in the web UI; - tried different periods; - added some triggers while the daemon was running; - examined `phd debug` output for anything suspicious. It seems to work in trivial use case, at least. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11419
2015-01-16 21:13:31 +01:00
'PhabricatorWorkerTriggerEvent' => 'PhabricatorWorkerDAO',
Add bin/trigger, for testing event triggers Summary: Ref T6881. This makes it easier to fire a trigger and make sure it works properly. You can use the `--now` flag to travel through time, and test scheduling conditions with `--last` and `--next`. It will tell you when the trigger would reschedule. Better than waiting 24 hours to see if things work. Test Plan: Fired some backups, got useful output which made me think my code probably works correctly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11438
2015-01-20 20:31:32 +01:00
'PhabricatorWorkerTriggerManagementFireWorkflow' => 'PhabricatorWorkerTriggerManagementWorkflow',
'PhabricatorWorkerTriggerManagementWorkflow' => 'PhabricatorManagementWorkflow',
Implement clock/trigger infrastructure for scheduling actions Summary: Ref T6881. Hopefully, this is the hard part. This adds a new daemon (the "trigger" daemon) which processes triggers, schedules them, and then executes them at the scheduled time. The design is a little complicated, but has these goals: - High resistance to race conditions: only the application writes to the trigger table; only the daemon writes to the event table. We won't lose events if someone saves a meeting at the same time as we're sending a reminder out for it. - Execution guarantees: scheduled events are guaranteed to execute exactly once. - Support for arbitrarily large queues: the daemon will make progress even if there are millions of triggers in queue. The cost to update the queue is proportional to the number of changes in it; the cost to process the queue is proportional to the number of events to execute. - Relatively good observability: you can monitor the state of the trigger queue reasonably well from the web UI. - Modular Infrastructure: this is a very low-level construct that Calendar, Phortune, etc., should be able to build on top of. It doesn't have this stuff yet: - Not very robust to bad actions: a misbehaving trigger can stop the queue fairly easily. This is OK for now since we aren't planning to make it part of any other applications for a while. We do still get execute-exaclty-once, but it might not happen for a long time (until someone goes and fixes the queue), when we could theoretically continue executing other events. - Doesn't start automatically: normal users don't need to run this thing yet so I'm not starting it by default. - Not super well tested: I've vetted the basics but haven't run real workloads through this yet. - No sophisticated tooling: I added some basic stuff but it's missing some pieces we'll have to build sooner or later, e.g. `bin/trigger cancel` or whatever. - Intentionally not realtime: This design puts execution guarantees far above realtime concerns, and will not give you precise event execution at 1-second resolution. I think this is the correct goal to pursue architecturally, and certainly correct for subscriptions and meeting reminders. Events which execute after they have become irrelevant can simply decline to do anything (like a meeting reminder which executes after the meeting is over). In general, the expectation for applications is: - When creating an object (like a calendar event) that needs to trigger a scheduled action, write a trigger (and save the PHID if you plan to update it later). - The daemon will process the event and schedule the action efficiently, in a race-free way. - If you want to move the action, update the trigger and the daemon will take care of it. - Your action will eventually dump a task into the task queue, and the task daemons will actually perform it. Test Plan: Using a test script like this: ``` <?php require_once 'scripts/__init_script__.php'; $trigger = id(new PhabricatorWorkerTrigger()) ->setAction( new PhabricatorLogTriggerAction( array( 'message' => 'test', ))) ->setClock( new PhabricatorMetronomicTriggerClock( array( 'period' => 33, ))) ->save(); var_dump($trigger); ``` ...I queued triggers and ran the daemon: - Verified triggers fire; - verified triggers reschedule; - verified trigger events show up in the web UI; - tried different periods; - added some triggers while the daemon was running; - examined `phd debug` output for anything suspicious. It seems to work in trivial use case, at least. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11419
2015-01-16 21:13:31 +01:00
'PhabricatorWorkerTriggerPHIDType' => 'PhabricatorPHIDType',
Implement PolicyAwareQuery for triggers Summary: Ref T6881. I tried to cheat here by not implementing this, but we need it for destroying triggers directly with `bin/remove destroy`, since that needs to load them by PHID. So, cheat slightly less. Implement PolicyAware but not CursorPagedPolicyAware. Test Plan: - Used `bin/remove destroy` to destroy a trigger by PHID. - Browsed daemon console. - Ran trigger daemon. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11445
2015-01-20 22:32:43 +01:00
'PhabricatorWorkerTriggerQuery' => 'PhabricatorPolicyAwareQuery',
Allow tasks to yield to other tasks Summary: For Harbormaster tasks which want to poll or wait, this lets them say "try again a little later" without having to sleep and hold a queue slot. This is basically the same as failing, except that we don't increment the failure counter. Instead, we just set the current lease to the correct length and then exit. The task will be retried after the lease expires. Test Plan: Using both `bin/harbormaster` and `phd debug taskmaster`, ran a lot of waiting tasks through the queue, faking them to either yield or not yield in a controlled manner. The queue responded as expected, yielding tasks appropraitely and retrying them later. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8792
2014-04-16 22:02:12 +02:00
'PhabricatorWorkerYieldException' => 'Exception',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorWorkingCopyDiscoveryTestCase' => 'PhabricatorWorkingCopyTestCase',
Make repository pulls testable Summary: Ref T2784. This moves us toward being able to test the background and Conduit pipelines for repositories. In particular: - Separate the logic for pulling repositories (`git pull`, `hg pull`) out of `PhabricatorRepositoryPullLocalDaemon` and put it in `PhabricatorRepositoryPullEngine`. This allows repositories to be pulled directly without invoking the daemons. - Add tests for the engine, including a future-looking base test case. - Add basic `PhutilDirectoryFixture`-based repositories. Next steps: # Do the same for repo discovery. # Then we can start writing tests against specific Conduit methods. Test Plan: Ran unit tests. Ran `bin/repository pull` on SVN, Hg and Git repositories. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran, nh Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5904
2013-05-13 04:05:52 +02:00
'PhabricatorWorkingCopyPullTestCase' => 'PhabricatorWorkingCopyTestCase',
'PhabricatorWorkingCopyTestCase' => 'PhabricatorTestCase',
Rename XHPAST database Summary: Rename the XHPAST database from `{$NAMESPACE}_xpastview` to `{$NAMESPACE}_xhpast`. Test Plan: Ran `./bin/storage --namespace test upgrade --no-quickstart`. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14442
2015-11-14 11:41:27 +01:00
'PhabricatorXHPASTDAO' => 'PhabricatorLiskDAO',
'PhabricatorXHPASTParseTree' => 'PhabricatorXHPASTDAO',
xhpastview
2011-04-07 04:17:05 +02:00
'PhabricatorXHPASTViewController' => 'PhabricatorController',
'PhabricatorXHPASTViewFrameController' => 'PhabricatorXHPASTViewController',
'PhabricatorXHPASTViewFramesetController' => 'PhabricatorXHPASTViewController',
'PhabricatorXHPASTViewInputController' => 'PhabricatorXHPASTViewPanelController',
'PhabricatorXHPASTViewPanelController' => 'PhabricatorXHPASTViewController',
'PhabricatorXHPASTViewRunController' => 'PhabricatorXHPASTViewController',
'PhabricatorXHPASTViewStreamController' => 'PhabricatorXHPASTViewPanelController',
'PhabricatorXHPASTViewTreeController' => 'PhabricatorXHPASTViewPanelController',
Rename `PhabricatorApplication` subclasses Summary: Ref T5655. Some discussion in D9839. Generally speaking, `Phabricator{$name}Application` is clearer than `PhabricatorApplication{$name}`. Test Plan: # Pinned and uninstalled some applications. # Applied patch and performed migrations. # Verified that the pinned applications were still pinned and that the uninstalled applications were still uninstalled. # Performed a sanity check on the database contents. Reviewers: btrahan, epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9982
2014-07-23 02:03:09 +02:00
'PhabricatorXHProfApplication' => 'PhabricatorApplication',
Very rough cut of DarkConsole + XHProf
2011-02-02 22:48:52 +01:00
'PhabricatorXHProfController' => 'PhabricatorController',
Do sampled profiling of requests Summary: People have occasionally complained about phabricator being slow. We have the access log to look at to see when slowness happens, but it doesn't tell us much about why it happened. Since it's usually a sporadic issue that's reported, it's hard to reproduce and then profile. This change will allow us to collect sampled profiles so we can look at them when slowness occurs. Test Plan: checking that sampling works correctly: - set rate to 0; do several page loads; check no new entries in table - set rate to 1; check that there's a new row in the table for each page load - set rate to 10; check that some requests write to table and some don't check new ui for samples: - load /xhprof/list/all/, see a list with a lot of samples - load /xhprof/list/sampled/, see only sampled runs - load /xhprof/list/manual/, see only non-sampled runs - load /xhprof/list/my-runs/, se only my manual runs Reviewers: vrana, epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3458
2012-08-25 00:14:38 +02:00
'PhabricatorXHProfDAO' => 'PhabricatorLiskDAO',
Very rough cut of DarkConsole + XHProf
2011-02-02 22:48:52 +01:00
'PhabricatorXHProfProfileController' => 'PhabricatorXHProfController',
Fix iframe issue for XHProf DarkConsole plugin Summary: While sort of gross, this seems fairly reasonable overall? I guess? (This patch clearly does more good than harm, although it could just do the good without the harm.) Test Plan: Clicked XHProf links from the frame and from the /xhprof/ tool. Reviewers: btrahan, aran, jungejason, ide Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T453 Differential Revision: https://secure.phabricator.com/D1498
2012-01-28 20:17:19 +01:00
'PhabricatorXHProfProfileSymbolView' => 'PhabricatorXHProfProfileView',
'PhabricatorXHProfProfileTopLevelView' => 'PhabricatorXHProfProfileView',
'PhabricatorXHProfProfileView' => 'AphrontView',
Do sampled profiling of requests Summary: People have occasionally complained about phabricator being slow. We have the access log to look at to see when slowness happens, but it doesn't tell us much about why it happened. Since it's usually a sporadic issue that's reported, it's hard to reproduce and then profile. This change will allow us to collect sampled profiles so we can look at them when slowness occurs. Test Plan: checking that sampling works correctly: - set rate to 0; do several page loads; check no new entries in table - set rate to 1; check that there's a new row in the table for each page load - set rate to 10; check that some requests write to table and some don't check new ui for samples: - load /xhprof/list/all/, see a list with a lot of samples - load /xhprof/list/sampled/, see only sampled runs - load /xhprof/list/manual/, see only non-sampled runs - load /xhprof/list/my-runs/, se only my manual runs Reviewers: vrana, epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3458
2012-08-25 00:14:38 +02:00
'PhabricatorXHProfSample' => 'PhabricatorXHProfDAO',
'PhabricatorXHProfSampleListController' => 'PhabricatorXHProfController',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PhabricatorYoutubeRemarkupRule' => 'PhutilRemarkupRule',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhameBlog' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhameDAO',
'PhabricatorPolicyInterface',
'PhabricatorMarkupInterface',
Add Subscribers to Phame Posts and Blogs Summary: Makes it possible to subscribe to blogs and posts Test Plan: Verify I can subscribe to blogs and posts. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13672
2015-07-22 16:00:36 +02:00
'PhabricatorSubscribableInterface',
Make Phame Blogs and Posts Flaggable Summary: Will attempt at modernizing Phame in smaller pieces. First up, flagging. Test Plan: Flag a Post, Flag a Blog Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13668
2015-07-22 16:04:21 +02:00
'PhabricatorFlaggableInterface',
Add Projects to Phame Blog and Phame Post Summary: Allows setting of Projects to Blogs and Posts. Test Plan: Set a Project on a post and a blog, see on view page. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13669
2015-07-22 16:08:00 +02:00
'PhabricatorProjectInterface',
Implement PhabricatorDestructibleInterface in Phame Summary: Allows Blogs and Posts to be destroyed. Fixes T9756 Test Plan: Test `bin/remove destroy POST` and `bin/remove destroy BLOG` to great success. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9756 Differential Revision: https://secure.phabricator.com/D14586
2015-11-28 22:01:11 +01:00
'PhabricatorDestructibleInterface',
Make PhameBlog implement PhabricatorApplicationTransactionInterface Summary: Ref T6367. Test Plan: Static correctness. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6367 Differential Revision: https://secure.phabricator.com/D13143
2015-06-03 23:24:21 +02:00
'PhabricatorApplicationTransactionInterface',
Add phame.blog.search Conduit API endpoint Summary: Ref T9897. Adds basic blog query support. Test Plan: Ran some queries. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14900
2015-12-28 12:58:43 +01:00
'PhabricatorConduitResultInterface',
Make PhameBlogs respect policies Summary: Adds "can view" and "can edit" policies to blogs. Replaces "bloggers" with "can join". This doesn't fully remove "bloggers" because I didn't want this to get too crazy/huge. Test Plan: Created, edited, deleted blogs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3693
2012-10-15 23:49:52 +02:00
),
Allow Phame Blogs to be archived instead of deleted Summary: Removes "delete" and uses "archive/activate" instead for Phame Blogs. Ref T9756 Test Plan: Archive a blog, see in search, activate blog, see in other search. Reviewers: epriestley Reviewed By: epriestley Subscribers: joshuaspence, Korvin Maniphest Tasks: T9756 Differential Revision: https://secure.phabricator.com/D14465
2015-11-21 17:51:07 +01:00
'PhameBlogArchiveController' => 'PhameBlogController',
Modernize Phame Summary: Updates Phame for new modern methods. Test Plan: New blog, edit blog, new post, edit post, publish post. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14419
2015-11-05 23:53:24 +01:00
'PhameBlogController' => 'PhameController',
Add Can Create Policy Capability to Phame Blogs Summary: Larger (open) installs may want to restrict Blog to formal entities, like with Phriction. Test Plan: Set policy to administrators, have notchad try to create a blog. See error. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14433
2015-11-07 20:57:34 +01:00
'PhameBlogCreateCapability' => 'PhabricatorPolicyCapability',
Add a phame.blog.edit Conduit API endpoint Summary: Ref T9897. Test Plan: Used API to make a few changes to a blog. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14899
2015-12-28 12:57:03 +01:00
'PhameBlogEditConduitAPIMethod' => 'PhabricatorEditEngineAPIMethod',
Modernize Phame Summary: Updates Phame for new modern methods. Test Plan: New blog, edit blog, new post, edit post, publish post. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14419
2015-11-05 23:53:24 +01:00
'PhameBlogEditController' => 'PhameBlogController',
Give PhameBlog an EditEngine Summary: This seems to work, but I couldn't figure out how to pass over a Caption for a text field. Test Plan: New blog, Edit blog. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14770
2015-12-16 20:56:41 +01:00
'PhameBlogEditEngine' => 'PhabricatorEditEngine',
Phame - move over blog create + edit to transactions + editor Summary: Ref T7626. Modernizes the code a bit here so we can eventually make progress on T7626 and other stuff. Test Plan: made a blog, edited a blog, made errors - stuff looked good Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7626 Differential Revision: https://secure.phabricator.com/D12849
2015-05-15 02:05:58 +02:00
'PhameBlogEditor' => 'PhabricatorApplicationTransactionEditor',
Modernize Phame Summary: Updates Phame for new modern methods. Test Plan: New blog, edit blog, new post, edit post, publish post. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14419
2015-11-05 23:53:24 +01:00
'PhameBlogFeedController' => 'PhameBlogController',
'PhameBlogListController' => 'PhameBlogController',
Add "Blogs" section to PhameHome Summary: Ref T9927. Adds a "Blogs" section to PhameHome. Removes "New Post" Controller. Adds flipped layout for PHUITwoColumnView Test Plan: Test PhameHome, Ponder, New Post, etc. Mobile and Desktop states. {F1022080} Reviewers: epriestley Reviewed By: epriestley Subscribers: johnny-bit, Korvin Maniphest Tasks: T9927 Differential Revision: https://secure.phabricator.com/D14744
2015-12-12 02:23:09 +01:00
'PhameBlogListView' => 'AphrontTagView',
Update PhameBlogView UI Summary: Creates a new PhameBlogView which is more of a blog landing page with the latest posts. Management has moved to PhameManageController with a new timeline. Test Plan: Edit Blog, Publish, Subscribe, view posts. {F1008400} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9360 Differential Revision: https://secure.phabricator.com/D14608
2015-11-30 17:47:46 +01:00
'PhameBlogManageController' => 'PhameBlogController',
Add Profile Images to PhameBlog Summary: Will use these more in the upcoming unbeta design of PhameBlog, likely. Also curious how this works. Test Plan: Add an image to a blog, remove an image from a blog. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14587
2015-11-28 21:42:36 +01:00
'PhameBlogProfilePictureController' => 'PhameBlogController',
Make PhameBlogs respect policies Summary: Adds "can view" and "can edit" policies to blogs. Replaces "bloggers" with "can join". This doesn't fully remove "bloggers" because I didn't want this to get too crazy/huge. Test Plan: Created, edited, deleted blogs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3693
2012-10-15 23:49:52 +02:00
'PhameBlogQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add mail support to PhameBlog Summary: Add some mailkeys, allow feed stories to be published. Test Plan: New Blog, Edit Blog Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14434
2015-11-08 16:50:01 +01:00
'PhameBlogReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Add phame.blog.search Conduit API endpoint Summary: Ref T9897. Adds basic blog query support. Test Plan: Ran some queries. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14900
2015-12-28 12:58:43 +01:00
'PhameBlogSearchConduitAPIMethod' => 'PhabricatorSearchEngineAPIMethod',
PhameBlogSearchEngine Summary: Modernize PhameBlogQuery, create a skeleton Search Engine. Test Plan: Built a dashboard for testing, verify view pages still work. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T6269 Differential Revision: https://secure.phabricator.com/D13670
2015-07-22 22:31:47 +02:00
'PhameBlogSearchEngine' => 'PhabricatorApplicationSearchEngine',
Modularize Aphront "sites" Summary: Fixes T5702. The path here is long and windy: - I want to move `blog.phacility.com` to the new `secure` host. - That host has `security.require-https` set, which I want to keep set (before, this was handled in a sort of hacky way at the nginx/preamble level, but I've cleaned up everything else now). - Currently, that setting forces blogs to HTTPS too, which won't work. - To let blogs be individually configurable, we need to either modularize site config or make things hackier. - Modularize rather than increasing hackiness. - Also add a little "modules" panel in Config. See T6859. This feels like a reasonable middle ground between putting this stuff in Applications and burying it in `bin/somewhere`. Test Plan: - Visited normal site. - Visited phame on-domain site. - Visited phame off-domain site. - Viewed static resources. {F561897} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D13474
2015-06-29 23:04:48 +02:00
'PhameBlogSite' => 'PhameSite',
Phame - move over blog create + edit to transactions + editor Summary: Ref T7626. Modernizes the code a bit here so we can eventually make progress on T7626 and other stuff. Test Plan: made a blog, edited a blog, made errors - stuff looked good Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7626 Differential Revision: https://secure.phabricator.com/D12849
2015-05-15 02:05:58 +02:00
'PhameBlogTransaction' => 'PhabricatorApplicationTransaction',
Add mail support to PhameBlog Summary: Add some mailkeys, allow feed stories to be published. Test Plan: New Blog, Edit Blog Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14434
2015-11-08 16:50:01 +01:00
'PhameBlogTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Remove skins from Phame Summary: Ref T9897. Purge a bunch of stuff: - Remove skins. - Remove all custom sites for skin resources. - Remove "framed", "notlive", "preview", separate "live" controllers (see below). - Merge "publish" and "unpublish" controllers into one. New behavior: - Blogs and posts have three views: - "View": Internal view URI, which is a normal detail page. - "Internal Live": Internal view URI which is a little prettier. - "External Live": External view URI for an external domain. Right now, the differences are pretty minor (basically, different crumbs/chrome). This mostly gives us room to put some milder flavor of skins back later (photography or more "presentation" elements, for example). This removes 9 million lines of code so I probably missed a couple of things, but I think it's like 95% of the way there. Test Plan: Here are some examples of what the "view", "internal" and "external" views look like for blogs (posts are similar): "View": Unchanged {F1021634} "Internal": No chrome or footer. Still write actions (edit, post commments). Has crumbs to get back into Phame. {F1021635} "External": No chrome or footer. No write actions. No Phabricator crumbs. No policy/status information. {F1021638} I figure we'll probably tweak these a bit to figure out what makes sense (like: maybe no actions on "internal, live"? and "external, live" probably needs a way to set a root "Company >" crumb?) but that they're reasonable-ish as a first cut? Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14740
2015-12-11 16:07:45 +01:00
'PhameBlogViewController' => 'PhameLiveController',
Add a transaction for PhamePost visibility Summary: Adds ability to set visibility when authoring a Post. New default is "Visible". If you write a post and save it as a Draft, and later click publish, a feed story and mail will go out. Test Plan: Write a new Post, see feed story and get email. Write a new Draft, get nothing. Click Publish, see story and email. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9360 Differential Revision: https://secure.phabricator.com/D14429
2015-11-07 15:52:42 +01:00
'PhameConstants' => 'Phobject',
Phame V1 - Phabricator blogging software Summary: 'cuz we need to be phamous! V1 feature set - posts -- standard thing you'd expect - a title and a remarkup-powered body and... -- "phame" title - a short string that can be used to reference the story. this gets auto-updated when you mess with the title. -- configuration - for now, do you want Facebook, Disqus or no comments? this is a per-post thing but feeds from an instance-wide configuration Please do toss out any must have features or changes. Test Plan: played around with this bad boy like whoa Reviewers: epriestley Reviewed By: epriestley CC: aran, vrana Maniphest Tasks: T1111 Differential Revision: https://secure.phabricator.com/D2202
2012-04-12 22:09:04 +02:00
'PhameController' => 'PhabricatorController',
'PhameDAO' => 'PhabricatorLiskDAO',
Separate out PhameDescriptionView Summary: Make this function re-usable in other views. Ref T9897 Test Plan: View a blog, see the same information Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14658
2015-12-03 23:28:44 +01:00
'PhameDescriptionView' => 'AphrontTagView',
Add Drafts to PhameHome Summary: Adds a list of your drafts. Fixes T9927y Test Plan: Load up home, see my drafts. Fake 0 drafts, see fallback message. {F1023139} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14756
2015-12-12 22:19:21 +01:00
'PhameDraftListView' => 'AphrontTagView',
Add a homepage for Phame Summary: Sends `/phame/` to PhameHomeController, which is all published posts. Still some rough edges to work out for new posts, new blogs, but I think this is the right direction. Test Plan: go to Phame, see most recent posts, no drafts. click on find posts, see post list, click on find blogs, see blogs. {F1008800} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9742 Differential Revision: https://secure.phabricator.com/D14618
2015-12-01 01:25:59 +01:00
'PhameHomeController' => 'PhamePostController',
Remove skins from Phame Summary: Ref T9897. Purge a bunch of stuff: - Remove skins. - Remove all custom sites for skin resources. - Remove "framed", "notlive", "preview", separate "live" controllers (see below). - Merge "publish" and "unpublish" controllers into one. New behavior: - Blogs and posts have three views: - "View": Internal view URI, which is a normal detail page. - "Internal Live": Internal view URI which is a little prettier. - "External Live": External view URI for an external domain. Right now, the differences are pretty minor (basically, different crumbs/chrome). This mostly gives us room to put some milder flavor of skins back later (photography or more "presentation" elements, for example). This removes 9 million lines of code so I probably missed a couple of things, but I think it's like 95% of the way there. Test Plan: Here are some examples of what the "view", "internal" and "external" views look like for blogs (posts are similar): "View": Unchanged {F1021634} "Internal": No chrome or footer. Still write actions (edit, post commments). Has crumbs to get back into Phame. {F1021635} "External": No chrome or footer. No write actions. No Phabricator crumbs. No policy/status information. {F1021638} I figure we'll probably tweak these a bit to figure out what makes sense (like: maybe no actions on "internal, live"? and "external, live" probably needs a way to set a root "Company >" crumb?) but that they're reasonable-ish as a first cut? Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14740
2015-12-11 16:07:45 +01:00
'PhameLiveController' => 'PhameController',
Add Next and Previous UI to PhamePostView Summary: Creates a new next/previous UI for PhamePosts, and adds a setFoot to PHUIDocumentViewPro for future use in other apps. Test Plan: Test first, next, last posts on Phame in mobile, desktop, and tablet breakpoints. {F1050152} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14919
2015-12-31 22:08:33 +01:00
'PhameNextPostView' => 'AphrontTagView',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhamePost' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhameDAO',
'PhabricatorPolicyInterface',
'PhabricatorMarkupInterface',
Make Phame Blogs and Posts Flaggable Summary: Will attempt at modernizing Phame in smaller pieces. First up, flagging. Test Plan: Flag a Post, Flag a Blog Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13668
2015-07-22 16:04:21 +02:00
'PhabricatorFlaggableInterface',
Add Projects to Phame Blog and Phame Post Summary: Allows setting of Projects to Blogs and Posts. Test Plan: Set a Project on a post and a blog, see on view page. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13669
2015-07-22 16:08:00 +02:00
'PhabricatorProjectInterface',
Phame - move over post creation and edit to use an editor Summary: This adds the bare minimum transaction set for editing posts. Fixes T7626 because now files will be correctly attached to phame posts on subsequent edits. Future work here should be adding transaction types like `TYPE_BLOG` for when posts are moved between blogs, `TYPE_VISIBILITY` for when posts are moved to published, etc. Nothing too tricky there but keeping this diff relatively small seems prudent. Test Plan: made posts successfully. also made errors like no title, no phame title, and duplicate phame title and got correct errors. added a file to a post and verified file has phame post in "attached" tab, which should fix T7626. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7626 Differential Revision: https://secure.phabricator.com/D12864
2015-05-15 22:07:45 +02:00
'PhabricatorApplicationTransactionInterface',
Add Subscribers to Phame Posts and Blogs Summary: Makes it possible to subscribe to blogs and posts Test Plan: Verify I can subscribe to blogs and posts. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13672
2015-07-22 16:00:36 +02:00
'PhabricatorSubscribableInterface',
Implement PhabricatorDestructibleInterface in Phame Summary: Allows Blogs and Posts to be destroyed. Fixes T9756 Test Plan: Test `bin/remove destroy POST` and `bin/remove destroy BLOG` to great success. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9756 Differential Revision: https://secure.phabricator.com/D14586
2015-11-28 22:01:11 +01:00
'PhabricatorDestructibleInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorTokenReceiverInterface',
Add phame.post.search Conduit API endpoint Summary: Ref T9897. Mostly straightforward, but also modernize/fixup the Query a little so that posts never load with no blog. Test Plan: Queried posts via API. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14901
2015-12-28 13:25:01 +01:00
'PhabricatorConduitResultInterface',
Modernize blog UI Summary: Cleans up some of the mess I made in D3694. Basically: - All blogs have an "internal" view with posts that uses mobile-friendly UIs, etc., so we don't have to do as much work with skins -- they just have to look pretty. - Blogs now have a separate "live" view that we use to handle domains / skins. - Simplified some views and use IDs in some URLs for consistency. - Delete a bunch of edge/blogger/multi-blog code that's now obsolete. Test Plan: Will attach screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3695
2012-10-15 23:50:12 +02:00
),
Add comments to internal Phame Posts Summary: Adds commenting to Phame Posts, also testing a new "document comment style". Unsure about it but Phame is a prototype so good place to explore. Test Plan: Leave some comments, see some comments, test show/hide. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9746 Differential Revision: https://secure.phabricator.com/D14451
2015-11-10 06:20:35 +01:00
'PhamePostCommentController' => 'PhamePostController',
Modernize Phame Summary: Updates Phame for new modern methods. Test Plan: New blog, edit blog, new post, edit post, publish post. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14419
2015-11-05 23:53:24 +01:00
'PhamePostController' => 'PhameController',
Provide phame.post.edit Conduit API method Summary: Ref T9897. This one is a little more involved because of how getting a post on a blog works. I also changed moving posts to be a real transaction (which shows up in history, now). Test Plan: Created posts from web UI and conduit. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14902
2015-12-28 14:46:22 +01:00
'PhamePostEditConduitAPIMethod' => 'PhabricatorEditEngineAPIMethod',
Modernize Phame Summary: Updates Phame for new modern methods. Test Plan: New blog, edit blog, new post, edit post, publish post. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14419
2015-11-05 23:53:24 +01:00
'PhamePostEditController' => 'PhamePostController',
Update PhamePost to EditEngine Summary: Allows create and edit workflows through EditEngine. Not sure I did the 'blog' stuff correct. Test Plan: Create a new post, edit a post, move a post. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14802
2015-12-28 02:38:25 +01:00
'PhamePostEditEngine' => 'PhabricatorEditEngine',
Phame - move over post creation and edit to use an editor Summary: This adds the bare minimum transaction set for editing posts. Fixes T7626 because now files will be correctly attached to phame posts on subsequent edits. Future work here should be adding transaction types like `TYPE_BLOG` for when posts are moved between blogs, `TYPE_VISIBILITY` for when posts are moved to published, etc. Nothing too tricky there but keeping this diff relatively small seems prudent. Test Plan: made posts successfully. also made errors like no title, no phame title, and duplicate phame title and got correct errors. added a file to a post and verified file has phame post in "attached" tab, which should fix T7626. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7626 Differential Revision: https://secure.phabricator.com/D12864
2015-05-15 22:07:45 +02:00
'PhamePostEditor' => 'PhabricatorApplicationTransactionEditor',
Spiffy up PhamePostView Summary: Cleaner Author information, less "Properties", Build a History Page. Ref T9897 Test Plan: Review New Posts, Draft Posts, View History {F1012934} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14660
2015-12-04 00:27:01 +01:00
'PhamePostHistoryController' => 'PhamePostController',
Modernize Phame Summary: Updates Phame for new modern methods. Test Plan: New blog, edit blog, new post, edit post, publish post. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14419
2015-11-05 23:53:24 +01:00
'PhamePostListController' => 'PhamePostController',
Add a homepage for Phame Summary: Sends `/phame/` to PhameHomeController, which is all published posts. Still some rough edges to work out for new posts, new blogs, but I think this is the right direction. Test Plan: go to Phame, see most recent posts, no drafts. click on find posts, see post list, click on find blogs, see blogs. {F1008800} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9742 Differential Revision: https://secure.phabricator.com/D14618
2015-12-01 01:25:59 +01:00
'PhamePostListView' => 'AphrontTagView',
Allow mail replies to Phame Posts Summary: Adds mail reply support to Phame Posts. Test Plan: Comment on a post, get mail. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9746 Differential Revision: https://secure.phabricator.com/D14454
2015-11-10 18:41:05 +01:00
'PhamePostMailReceiver' => 'PhabricatorObjectMailReceiver',
Use AphrontDialog for New/Move Phame Posts Summary: Moves New Post and Move Post to be separate Controllers with Dialogs. Ref T9897 Test Plan: Move a post to a new blog, see message and see post. Click New Post, get dialog, pick blog, edit new post. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14698
2015-12-07 23:12:05 +01:00
'PhamePostMoveController' => 'PhamePostController',
Modernize Phame Summary: Updates Phame for new modern methods. Test Plan: New blog, edit blog, new post, edit post, publish post. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14419
2015-11-05 23:53:24 +01:00
'PhamePostPublishController' => 'PhamePostController',
Modernize blog UI Summary: Cleans up some of the mess I made in D3694. Basically: - All blogs have an "internal" view with posts that uses mobile-friendly UIs, etc., so we don't have to do as much work with skins -- they just have to look pretty. - Blogs now have a separate "live" view that we use to handle domains / skins. - Simplified some views and use IDs in some URLs for consistency. - Delete a bunch of edge/blogger/multi-blog code that's now obsolete. Test Plan: Will attach screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3695
2012-10-15 23:50:12 +02:00
'PhamePostQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add mail/feed support to PhamePost Summary: Allows feed stories and mail for new Phame Posts. Test Plan: Write Post, Get Mail Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Differential Revision: https://secure.phabricator.com/D14426
2015-11-07 02:40:13 +01:00
'PhamePostReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Add phame.post.search Conduit API endpoint Summary: Ref T9897. Mostly straightforward, but also modernize/fixup the Query a little so that posts never load with no blog. Test Plan: Queried posts via API. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14901
2015-12-28 13:25:01 +01:00
'PhamePostSearchConduitAPIMethod' => 'PhabricatorSearchEngineAPIMethod',
PhamePostSearchEngine Summary: A very basic search engine for Phame Posts Test Plan: Built a dashboard to test various queries. Saw posts. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T6269 Differential Revision: https://secure.phabricator.com/D13671
2015-07-22 16:30:52 +02:00
'PhamePostSearchEngine' => 'PhabricatorApplicationSearchEngine',
Phame - move over post creation and edit to use an editor Summary: This adds the bare minimum transaction set for editing posts. Fixes T7626 because now files will be correctly attached to phame posts on subsequent edits. Future work here should be adding transaction types like `TYPE_BLOG` for when posts are moved between blogs, `TYPE_VISIBILITY` for when posts are moved to published, etc. Nothing too tricky there but keeping this diff relatively small seems prudent. Test Plan: made posts successfully. also made errors like no title, no phame title, and duplicate phame title and got correct errors. added a file to a post and verified file has phame post in "attached" tab, which should fix T7626. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7626 Differential Revision: https://secure.phabricator.com/D12864
2015-05-15 22:07:45 +02:00
'PhamePostTransaction' => 'PhabricatorApplicationTransaction',
Add comments to internal Phame Posts Summary: Adds commenting to Phame Posts, also testing a new "document comment style". Unsure about it but Phame is a prototype so good place to explore. Test Plan: Leave some comments, see some comments, test show/hide. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9746 Differential Revision: https://secure.phabricator.com/D14451
2015-11-10 06:20:35 +01:00
'PhamePostTransactionComment' => 'PhabricatorApplicationTransactionComment',
Phame - move over post creation and edit to use an editor Summary: This adds the bare minimum transaction set for editing posts. Fixes T7626 because now files will be correctly attached to phame posts on subsequent edits. Future work here should be adding transaction types like `TYPE_BLOG` for when posts are moved between blogs, `TYPE_VISIBILITY` for when posts are moved to published, etc. Nothing too tricky there but keeping this diff relatively small seems prudent. Test Plan: made posts successfully. also made errors like no title, no phame title, and duplicate phame title and got correct errors. added a file to a post and verified file has phame post in "attached" tab, which should fix T7626. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T7626 Differential Revision: https://secure.phabricator.com/D12864
2015-05-15 22:07:45 +02:00
'PhamePostTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Remove skins from Phame Summary: Ref T9897. Purge a bunch of stuff: - Remove skins. - Remove all custom sites for skin resources. - Remove "framed", "notlive", "preview", separate "live" controllers (see below). - Merge "publish" and "unpublish" controllers into one. New behavior: - Blogs and posts have three views: - "View": Internal view URI, which is a normal detail page. - "Internal Live": Internal view URI which is a little prettier. - "External Live": External view URI for an external domain. Right now, the differences are pretty minor (basically, different crumbs/chrome). This mostly gives us room to put some milder flavor of skins back later (photography or more "presentation" elements, for example). This removes 9 million lines of code so I probably missed a couple of things, but I think it's like 95% of the way there. Test Plan: Here are some examples of what the "view", "internal" and "external" views look like for blogs (posts are similar): "View": Unchanged {F1021634} "Internal": No chrome or footer. Still write actions (edit, post commments). Has crumbs to get back into Phame. {F1021635} "External": No chrome or footer. No write actions. No Phabricator crumbs. No policy/status information. {F1021638} I figure we'll probably tweak these a bit to figure out what makes sense (like: maybe no actions on "internal, live"? and "external, live" probably needs a way to set a root "Company >" crumb?) but that they're reasonable-ish as a first cut? Reviewers: chad Reviewed By: chad Maniphest Tasks: T9897 Differential Revision: https://secure.phabricator.com/D14740
2015-12-11 16:07:45 +01:00
'PhamePostViewController' => 'PhameLiveController',
Generate expected scheamta for Passphrase, Paste, Phlux, Phame Summary: Ref T1191. Nothing notable in these. Test Plan: Viewed web UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10528
2014-09-24 22:50:57 +02:00
'PhameSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Modularize Aphront "sites" Summary: Fixes T5702. The path here is long and windy: - I want to move `blog.phacility.com` to the new `secure` host. - That host has `security.require-https` set, which I want to keep set (before, this was handled in a sort of hacky way at the nginx/preamble level, but I've cleaned up everything else now). - Currently, that setting forces blogs to HTTPS too, which won't work. - To let blogs be individually configurable, we need to either modularize site config or make things hackier. - Modularize rather than increasing hackiness. - Also add a little "modules" panel in Config. See T6859. This feels like a reasonable middle ground between putting this stuff in Applications and burying it in `bin/somewhere`. Test Plan: - Visited normal site. - Visited phame on-domain site. - Visited phame off-domain site. - Viewed static resources. {F561897} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5702 Differential Revision: https://secure.phabricator.com/D13474
2015-06-29 23:04:48 +02:00
'PhameSite' => 'PhabricatorSite',
Phlux v0 Summary: Yup, it's sitevars. No conduit or caching or fancy stuff yet. Ref T2793. Test Plan: {F36525} {F36526} {F36527} {F36528} {F36529} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2793 Differential Revision: https://secure.phabricator.com/D5397
2013-03-21 02:01:52 +01:00
'PhluxController' => 'PhabricatorController',
'PhluxDAO' => 'PhabricatorLiskDAO',
'PhluxEditController' => 'PhluxController',
'PhluxListController' => 'PhluxController',
'PhluxTransaction' => 'PhabricatorApplicationTransaction',
'PhluxTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhluxVariable' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhluxDAO',
Transactions - land buildTransactionTimeline in a bunch more apps Summary: Ref T4712. Specifically... - Dashboards - two objects needed PhabricatorApplicationTransactionInterface - Macros - Paste - Phlux - one object needed PhabricatorApplicationTransactionInterface - added setShouldTerminate(true) - Files - one object needed PhabricatorApplicationTransactionInterface - Passphrase - one object needed PhabricatorApplicationTransactionInterface - added setShouldTerminate(true) - Drydock - one object needed PhabricatorApplicationTransactionInterface - added setShouldTerminate(true) Test Plan: foreach application, verify that the timeline(s) showed up correctly, including with appropriate setShouldTerminate-ness Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10924
2014-12-03 22:16:15 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorFlaggableInterface',
'PhabricatorPolicyInterface',
Phlux v0 Summary: Yup, it's sitevars. No conduit or caching or fancy stuff yet. Ref T2793. Test Plan: {F36525} {F36526} {F36527} {F36528} {F36529} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2793 Differential Revision: https://secure.phabricator.com/D5397
2013-03-21 02:01:52 +01:00
),
'PhluxVariableEditor' => 'PhabricatorApplicationTransactionEditor',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhluxVariablePHIDType' => 'PhabricatorPHIDType',
Phlux v0 Summary: Yup, it's sitevars. No conduit or caching or fancy stuff yet. Ref T2793. Test Plan: {F36525} {F36526} {F36527} {F36528} {F36529} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2793 Differential Revision: https://secure.phabricator.com/D5397
2013-03-21 02:01:52 +01:00
'PhluxVariableQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhluxViewController' => 'PhluxController',
Make event-triggered actions more aware of application access Summary: Fixes T3675. - Maniphest had a couple of old non-event listeners; move them to events. - Make most of the similar listeners a little more similar. - Add checks for access to the application. Test Plan: - Viewed profile, project, task, revision. - Clicked all the actions. - Blocked access to various applications and verified the actions vanished. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7365
2013-10-22 02:00:50 +02:00
'PholioActionMenuEventListener' => 'PhabricatorEventListener',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioController' => 'PhabricatorController',
'PholioDAO' => 'PhabricatorLiskDAO',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'PholioDefaultEditCapability' => 'PhabricatorPolicyCapability',
'PholioDefaultViewCapability' => 'PhabricatorPolicyCapability',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PholioImage' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PholioDAO',
'PhabricatorMarkupInterface',
'PhabricatorPolicyInterface',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
),
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PholioImagePHIDType' => 'PhabricatorPHIDType',
Pholio - add concept of replacing images and primitive history view Summary: Now you can actually replace an image! Ref T3572. This ended up needing a wee bit of infrastructure to work... - add replace image transaction to pholio - add replacesImagePHID to PholioImage - tweaks to editor to properly update images with respect to replacement - add edges to track replacement - expose getNodes on graph query infrastructure to query the entire graph of who replaced who - move pholio image to new phid infrastructure Still TODO - the history view should get chopped out a bit from the current view - no more inline comments / generally less functionality plus maybe a tweak or two to make this more sensical. Test Plan: replaced images and played with history controller a little. works okay. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3572 Differential Revision: https://secure.phabricator.com/D6560
2013-07-26 01:59:25 +02:00
'PholioImageQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Pholio - make the form maintain client side edits between file uploads Summary: Fixes T3553. Did it by adding some code that refreshes the File object on keyup events within a given file entry. also fixes an html derp I found trying to fix this. Test Plan: added cool things like 'bbb' to every field and noted they were maintained when I added more files Reviewers: btrahan Reviewed By: btrahan CC: aran, Korvin, chad Maniphest Tasks: T3553 Differential Revision: https://secure.phabricator.com/D6488
2013-07-19 00:04:08 +02:00
'PholioImageUploadController' => 'PholioController',
Show saved inline comments Summary: Saved inline comments are now shown for images. Test Plan: Verified that inline comments are loaded and shown. Reviewers: epriestley CC: aran, Korvin Maniphest Tasks: T2446 Differential Revision: https://secure.phabricator.com/D4866
2013-02-08 16:24:17 +01:00
'PholioInlineController' => 'PholioController',
Remove inline gutter in Pholio Summary: This greatly simplifies inline comments while retaining their functionality. This is probably not where we want to end up, but will let us figure out what we're doing with the stage without worrying about inlines. Test Plan: See screenshots. Reviewers: chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9537
2014-06-15 03:41:45 +02:00
'PholioInlineListController' => 'PholioController',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PholioMock' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PholioDAO',
'PhabricatorMarkupInterface',
'PhabricatorPolicyInterface',
'PhabricatorSubscribableInterface',
'PhabricatorTokenReceiverInterface',
'PhabricatorFlaggableInterface',
'PhabricatorApplicationTransactionInterface',
'PhabricatorProjectInterface',
'PhabricatorDestructibleInterface',
Support Spaces in Pholio Summary: Ref T8493. Add Spaces support to Pholio. This is straightforward; Pholio has no clone/copy/fork or weird parent/child stuff going on. Test Plan: Created a mock, put it in a space, looked at it as another user, searched for stuff in spaces, viewed Macros. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T8493 Differential Revision: https://secure.phabricator.com/D13231
2015-06-11 00:52:49 +02:00
'PhabricatorSpacesInterface',
Implemented Mentionable interface in Pholio Summary: closes T8486 Test Plan: Create a pholio mock. In an already existing object mention the pholio mock. Verify that the reference to the object exists in the pholio mock's timeline. Reviewers: lpriestley, #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T8486 Differential Revision: https://secure.phabricator.com/D13402
2015-06-23 19:05:15 +02:00
'PhabricatorMentionableInterface',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorFulltextInterface',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
),
Add PholioMockArchiveController Summary: Allows closing a mock from the action list. Ref T9414 Test Plan: New Mock, Edit Mock, Close Mock, Open Mock Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9414 Differential Revision: https://secure.phabricator.com/D14726
2015-12-09 21:56:27 +01:00
'PholioMockArchiveController' => 'PholioController',
Modularize all remaining Pholio Herald fields Summary: Ref T8726. Use modular fields for the Pholio adapter. Test Plan: - Created rule using all the old fields. - Migrated, saw upgrade apply correctly. - Created mock, reviewed transcript. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13513
2015-07-06 22:17:33 +02:00
'PholioMockAuthorHeraldField' => 'PholioMockHeraldField',
Allow users to add comments in Pholio Summary: Basic support for adding comments. Missing a lot of frills. Uses new comment/transaction UI. Test Plan: Added some comments. Tried to add an empty comment. Some comments: {F22361} No text provided: {F22362} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3834
2012-11-22 02:27:20 +01:00
'PholioMockCommentController' => 'PholioController',
Modularize all remaining Pholio Herald fields Summary: Ref T8726. Use modular fields for the Pholio adapter. Test Plan: - Created rule using all the old fields. - Migrated, saw upgrade apply correctly. - Created mock, reviewed transcript. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13513
2015-07-06 22:17:33 +02:00
'PholioMockDescriptionHeraldField' => 'PholioMockHeraldField',
Add very basic create interface for Pholio Summary: Nothing app-specific yet, just stitching groundwork together from readymade components. {F22347} Test Plan: Created some mocks via web UI. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3830
2012-11-22 02:23:28 +01:00
'PholioMockEditController' => 'PholioController',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PholioMockEditor' => 'PhabricatorApplicationTransactionEditor',
Pholio mocks embed in a fancy way Summary: Pholio mocks are now embed in a fancy way Test Plan: {F34804} Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin, AnhNhan Maniphest Tasks: T2626 Differential Revision: https://secure.phabricator.com/D5249
2013-03-07 17:23:40 +01:00
'PholioMockEmbedView' => 'AphrontView',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PholioMockFulltextEngine' => 'PhabricatorFulltextEngine',
Modernize Pholio edges Summary: Modernize Pholio edges to subclass `PhabricatorEdgeType`. Largely based on D11045. Test Plan: Attached a mock to a task, observed the expected comment in the transaction view (both ways). Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Differential Revision: https://secure.phabricator.com/D11113
2015-01-02 00:11:41 +01:00
'PholioMockHasTaskEdgeType' => 'PhabricatorEdgeType',
Modularize all remaining Pholio Herald fields Summary: Ref T8726. Use modular fields for the Pholio adapter. Test Plan: - Created rule using all the old fields. - Migrated, saw upgrade apply correctly. - Created mock, reviewed transcript. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13513
2015-07-06 22:17:33 +02:00
'PholioMockHeraldField' => 'HeraldField',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'PholioMockHeraldFieldGroup' => 'HeraldFieldGroup',
Pholio tile to home page and mock to show first image Summary: Pholio tile to show up on home page First image is shown at mock page. Test Plan: Pholio app shows up on home page. First image is shown at mock page. Reviewers: epriestley CC: aran, Korvin Maniphest Tasks: T2356 Differential Revision: https://secure.phabricator.com/D4553
2013-01-20 18:29:34 +01:00
'PholioMockImagesView' => 'AphrontView',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'PholioMockListController' => 'PholioController',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PholioMockMailReceiver' => 'PhabricatorObjectMailReceiver',
Modularize all remaining Pholio Herald fields Summary: Ref T8726. Use modular fields for the Pholio adapter. Test Plan: - Created rule using all the old fields. - Migrated, saw upgrade apply correctly. - Created mock, reviewed transcript. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13513
2015-07-06 22:17:33 +02:00
'PholioMockNameHeraldField' => 'PholioMockHeraldField',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PholioMockPHIDType' => 'PhabricatorPHIDType',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioMockQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Use ApplicationSearch in Pholio Summary: Ref T2637. Ref T2625. Convert Pholio to use ApplicationSearch. Test Plan: Viewed mocks, changed filters. Verified edit page works and no longer has a weird side nav on it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2625, T2637 Differential Revision: https://secure.phabricator.com/D6530
2013-07-22 21:21:15 +02:00
'PholioMockSearchEngine' => 'PhabricatorApplicationSearchEngine',
Turn thumbs into a history grid thing Summary: This could probably use some refinement (and, like, explanatory text, and stronger cues about what rows and columns mean) but feels fairly good to me, at least on test data. I didn't do any scrolling for now since we have to do full height on mobile anyway I think. I did swap it so the newer ones are on top. Left/right navigate you among current images only, but you can click any thumb to review history. Removed history view since it's no longer useful. Some things that would probably help: - Some kind of header explaining what this is ("Mock History" or something). - Stronger visual cue that columns are related by being the same image. - Clearer cues about obsolete/deleted images (e.g., on the stage itself?) - Maybe general tweaks. - Maybe a placeholder (like a grey "X") for images which have been deleted. (I'm planning to add comment counts too, which I think will be pretty useful, but that felt good to put in another diff.) Test Plan: See screenshots. Reviewers: chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9543
2014-06-15 06:12:19 +02:00
'PholioMockThumbGridView' => 'AphrontView',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioMockViewController' => 'PholioController',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PholioRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Subclass most ReplyHandlers from TransactionReplyHandler Summary: Ref T7199. Half of these aren't even reachable, but make some progress toward reducing the amount of nonsense and garbage in mail handling. Test Plan: Tested all reachable handlers with `bin/mail receive-test`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12237
2015-04-01 17:39:50 +02:00
'PholioReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Generate expected schemata for Pholio, Phortune, Phragment, Phriction and Policy Summary: Ref T1191. Nothing too out-of-the-ordinary here. Test Plan: Saw fewer than 500 remaining issues. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley, hach-que Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10587
2014-10-01 16:52:26 +02:00
'PholioSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PholioTransaction' => 'PhabricatorApplicationTransaction',
'PholioTransactionComment' => 'PhabricatorApplicationTransactionComment',
Add feed integration to generic transactions Summary: Publish feed stories, including from Pholio. Actual stories are somewhat garbage but it's all display-time; I'm going to do a pass on feed in general. Test Plan: {F26832} Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4140
2012-12-11 23:00:21 +01:00
'PholioTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Group inline transactions in Pholio Summary: Fixes T2639 by grouping related transactions at display time, so all the inlines merge into a nice block. (Note that this does not do anything about T2709 yet, so there's still no way to figure out where the inlines actually are.) Test Plan: {F35262} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2639 Differential Revision: https://secure.phabricator.com/D5313
2013-03-10 04:23:50 +01:00
'PholioTransactionView' => 'PhabricatorApplicationTransactionView',
Pholio - make the form maintain client side edits between file uploads Summary: Fixes T3553. Did it by adding some code that refreshes the File object on keyup events within a given file entry. also fixes an html derp I found trying to fix this. Test Plan: added cool things like 'bbb' to every field and noted they were maintained when I added more files Reviewers: btrahan Reviewed By: btrahan CC: aran, Korvin, chad Maniphest Tasks: T3553 Differential Revision: https://secure.phabricator.com/D6488
2013-07-19 00:04:08 +02:00
'PholioUploadedImageView' => 'AphrontView',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhortuneAccount' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhortuneDAO',
Transactions - deploy buildTransactionTimeline to remaining applications Summary: Ref T4712. Specifically... - Differential - needed getApplicationTransactionViewObject() implemented - Audit - needed getApplicationTransactionViewObject() implemented - Repository - one object needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) - Ponder - BONUS BUG FIX - leaving a comment on an answer had a bad redirect URI - both PonderQuestion and PonderAnswer needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on both "history" controllers - left a "TODO" on buildAnswers on the question view controller, which is non-standard and should be re-written eventually - Phortune - BONUS BUG FIX - fix new user "createNewAccount" code to not fatal - PhortuneAccount, PhortuneMerchant, and PhortuneCart needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on Account view, merchant view, and cart view controller - Fund - Legalpad - Nuance - NuanceSource needed PhabricatorApplicationTransactionInterface implemented - Releeph (this product is kind of a mess...) - HACKQUEST - had to manually create an arcanist project to even be able to make a "product" and get started...! - BONUS BUG FIX - make sure to "setName" on product edit - ReleephProject (should be ReleepProduct...?), ReleephBranch, and ReleepRequest needed PhabricatorApplicationTransactionInterface implemented - Harbormaster - HarbormasterBuildable, HarbormasterBuild, HarbormasterBuildPlan, and HarbormasterBuildStep all needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) all over the place Test Plan: foreach application, viewed the timeline(s) and made sure they still rendered Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10925
2014-12-04 00:35:47 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
),
Support multiple payment accounts and account switching in Phortune Summary: Ref T2787. Support multiple payment accounts so you can have personal vs company payment accounts. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10673
2014-10-10 01:59:03 +02:00
'PhortuneAccountEditController' => 'PhortuneController',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneAccountEditor' => 'PhabricatorApplicationTransactionEditor',
Make Phortune account members editable and modernize the edge constant Summary: Ref T2787. - Account members can add and remove other members (major use case is corporate accounts). - Use a modern edge constant setup. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10678
2014-10-11 00:00:06 +02:00
'PhortuneAccountHasMemberEdgeType' => 'PhabricatorEdgeType',
Support multiple payment accounts and account switching in Phortune Summary: Ref T2787. Support multiple payment accounts so you can have personal vs company payment accounts. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10673
2014-10-10 01:59:03 +02:00
'PhortuneAccountListController' => 'PhortuneController',
Modernize Phortune PHID constants Summary: Ref T2787. These were still stuck in the stone ages. (The handles are pretty skeletal but most aren't used anywehre.) Test Plan: Funded an initiative without anything breaking. Grepped for removed constants. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10647
2014-10-07 01:48:16 +02:00
'PhortuneAccountPHIDType' => 'PhabricatorPHIDType',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneAccountQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhortuneAccountTransaction' => 'PhabricatorApplicationTransaction',
'PhortuneAccountTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'PhortuneAccountViewController' => 'PhortuneController',
Support basic ad-hoc invoices in Phortune Summary: This allows a merchant to send a user an invoice for something arbitrary, like services rendered. Two major missing parts: - These don't actually get marked as invoices. I'll fix that in the next diff, but it's not entirely trivial because `subscriptionPHID` is currently overloaded to also mean "is invoice". - We don't send email automatically. I don't plan to fix that for now, since all our invoicing needs are covered by personal email. Test Plan: Merchants have a new "new invoice" option: {F376999} This leads to selecting a user and account, and then you can generate the invoice (only one actual "purchase" / line item for the moment). You can add a longer-form remarkup description to contextualize the billable items: {F377001} This sends the invoice and takes you to the merchant order overview screen: {F377002} For now, you copy/paste that link into a nice personal enterprisey business-to-business email; the recipient sees this: {F377003} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D12478
2015-04-20 19:05:22 +02:00
'PhortuneAdHocCart' => 'PhortuneCartImplementation',
'PhortuneAdHocProduct' => 'PhortuneProductImplementation',
Phortune Carts and Purchases Summary: Ref T2787. Make carts and purchases real objects, with storage, that kind-of work. Roughly, the idea here is that applications create "purchases" (like "1 large t-shirt") and add them to "carts" (a user can have a lot of different carts at the same time), then hand things off to Phortune to deal with actualy charging a card. Roughly this works like Paypal or other similar systems do, except Phortune is the thing the user gets handed off to. This doesn't do anything interesting/useful yet. Also fix some bugs and update some UI. Test Plan: Added a product to a cart, saw it in cart screen. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10001
2014-07-23 19:34:08 +02:00
'PhortuneCart' => array(
'PhortuneDAO',
Transactions - deploy buildTransactionTimeline to remaining applications Summary: Ref T4712. Specifically... - Differential - needed getApplicationTransactionViewObject() implemented - Audit - needed getApplicationTransactionViewObject() implemented - Repository - one object needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) - Ponder - BONUS BUG FIX - leaving a comment on an answer had a bad redirect URI - both PonderQuestion and PonderAnswer needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on both "history" controllers - left a "TODO" on buildAnswers on the question view controller, which is non-standard and should be re-written eventually - Phortune - BONUS BUG FIX - fix new user "createNewAccount" code to not fatal - PhortuneAccount, PhortuneMerchant, and PhortuneCart needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on Account view, merchant view, and cart view controller - Fund - Legalpad - Nuance - NuanceSource needed PhabricatorApplicationTransactionInterface implemented - Releeph (this product is kind of a mess...) - HACKQUEST - had to manually create an arcanist project to even be able to make a "product" and get started...! - BONUS BUG FIX - make sure to "setName" on product edit - ReleephProject (should be ReleepProduct...?), ReleephBranch, and ReleepRequest needed PhabricatorApplicationTransactionInterface implemented - Harbormaster - HarbormasterBuildable, HarbormasterBuild, HarbormasterBuildPlan, and HarbormasterBuildStep all needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) all over the place Test Plan: foreach application, viewed the timeline(s) and made sure they still rendered Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10925
2014-12-04 00:35:47 +01:00
'PhabricatorApplicationTransactionInterface',
Phortune Carts and Purchases Summary: Ref T2787. Make carts and purchases real objects, with storage, that kind-of work. Roughly, the idea here is that applications create "purchases" (like "1 large t-shirt") and add them to "carts" (a user can have a lot of different carts at the same time), then hand things off to Phortune to deal with actualy charging a card. Roughly this works like Paypal or other similar systems do, except Phortune is the thing the user gets handed off to. This doesn't do anything interesting/useful yet. Also fix some bugs and update some UI. Test Plan: Added a product to a cart, saw it in cart screen. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10001
2014-07-23 19:34:08 +02:00
'PhabricatorPolicyInterface',
),
Add a "Review" status to Phortune Summary: Ref T2787. Allow merchants to flag orders for review. For now, all orders are flagged for review. Eventually, I could imagine Herald rules for coarse things (e.g., require review of all orders over $1,000, or require review of all orders by users not on a whitelist) and maybe examining fraud data for the providers which support it. Test Plan: {F215848} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10675
2014-10-10 20:29:13 +02:00
'PhortuneCartAcceptController' => 'PhortuneCartController',
Mostly implement order refunds and cancellations Summary: Ref T2787. This has some rough edges but basically works. - Users can cancel orders that are in incomplete states (or in complete states, if the application allows them to -- for example, some future application might allow cancellation of billed-but-not-shipped orders). - Merchant controllers can partially or fully refund orders from any state after payment. Test Plan: This is still rough around the edges, but issued Stripe and WePay refunds. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10664
2014-10-09 00:33:25 +02:00
'PhortuneCartCancelController' => 'PhortuneCartController',
Phortune Cart Status, some one-time support Summary: Ref T2787. Carts need a status so we can tell if they've been purchased. Also kind of get WePay working as a one-time provider, and let charges not have a methodPHID (they won't for one-time providers). All the status stuff is still super crazy rough and you can do things like start a checkout, add a bunch of stuff to your cart, complete the checkout, and have Phabricator think you paid for all the stuff you added. But this is fine for now since you can't actually edit carts, and also none of this is at all usable anyway. I'll refine some of the workflows in future diffs, for now I'm just getting things hooked up and technically working. Test Plan: - Purcahsed a cart and got a sort of status/done screen instead of a "your money is gone" exception. - Went through the WePay flow and got a successful test checkout. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10003
2014-07-23 19:36:25 +02:00
'PhortuneCartCheckoutController' => 'PhortuneCartController',
'PhortuneCartController' => 'PhortuneController',
Add cart transactions to Phortune Summary: Ref T2787. I mostly just want these in place so I can glue emails to them, but they're also useful on their own. Test Plan: {F216515} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10688
2014-10-13 20:16:27 +02:00
'PhortuneCartEditor' => 'PhabricatorApplicationTransactionEditor',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhortuneCartImplementation' => 'Phobject',
Allow merchant controllers to review orders in Phortune Summary: Ref T2787. Sets the stage for administrating / cancelling / refunding orders and hold orders. Test Plan: {F215140} {F215141} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10663
2014-10-08 23:40:02 +02:00
'PhortuneCartListController' => 'PhortuneController',
Modernize Phortune PHID constants Summary: Ref T2787. These were still stuck in the stone ages. (The handles are pretty skeletal but most aren't used anywehre.) Test Plan: Funded an initiative without anything breaking. Grepped for removed constants. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10647
2014-10-07 01:48:16 +02:00
'PhortuneCartPHIDType' => 'PhabricatorPHIDType',
Phortune Carts and Purchases Summary: Ref T2787. Make carts and purchases real objects, with storage, that kind-of work. Roughly, the idea here is that applications create "purchases" (like "1 large t-shirt") and add them to "carts" (a user can have a lot of different carts at the same time), then hand things off to Phortune to deal with actualy charging a card. Roughly this works like Paypal or other similar systems do, except Phortune is the thing the user gets handed off to. This doesn't do anything interesting/useful yet. Also fix some bugs and update some UI. Test Plan: Added a product to a cart, saw it in cart screen. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10001
2014-07-23 19:34:08 +02:00
'PhortuneCartQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Subclass most ReplyHandlers from TransactionReplyHandler Summary: Ref T7199. Half of these aren't even reachable, but make some progress toward reducing the amount of nonsense and garbage in mail handling. Test Plan: Tested all reachable handlers with `bin/mail receive-test`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12237
2015-04-01 17:39:50 +02:00
'PhortuneCartReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Allow merchant controllers to review orders in Phortune Summary: Ref T2787. Sets the stage for administrating / cancelling / refunding orders and hold orders. Test Plan: {F215140} {F215141} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10663
2014-10-08 23:40:02 +02:00
'PhortuneCartSearchEngine' => 'PhabricatorApplicationSearchEngine',
Add cart transactions to Phortune Summary: Ref T2787. I mostly just want these in place so I can glue emails to them, but they're also useful on their own. Test Plan: {F216515} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10688
2014-10-13 20:16:27 +02:00
'PhortuneCartTransaction' => 'PhabricatorApplicationTransaction',
'PhortuneCartTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Add a HOLD state to Phortune and handle unusual states better Summary: Ref T2787. When Paypal comes back to us with funds on hold, dead-end the transaction but handle it properly. Generally, smooth out the user interaction on weird states. Implement refudnds/cancels for Paypal. Test Plan: {F215230} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10667
2014-10-09 13:30:47 +02:00
'PhortuneCartUpdateController' => 'PhortuneCartController',
Phortune Cart Status, some one-time support Summary: Ref T2787. Carts need a status so we can tell if they've been purchased. Also kind of get WePay working as a one-time provider, and let charges not have a methodPHID (they won't for one-time providers). All the status stuff is still super crazy rough and you can do things like start a checkout, add a bunch of stuff to your cart, complete the checkout, and have Phabricator think you paid for all the stuff you added. But this is fine for now since you can't actually edit carts, and also none of this is at all usable anyway. I'll refine some of the workflows in future diffs, for now I'm just getting things hooked up and technically working. Test Plan: - Purcahsed a cart and got a sort of status/done screen instead of a "your money is gone" exception. - Went through the WePay flow and got a successful test checkout. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10003
2014-07-23 19:36:25 +02:00
'PhortuneCartViewController' => 'PhortuneCartController',
Phortune Charges Summary: Ref T2787. Makes charges a real object, allows providers to apply them. We are now (just barely) capable of stealing users' money. Test Plan: {F179584} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10002
2014-07-23 19:36:12 +02:00
'PhortuneCharge' => array(
'PhortuneDAO',
'PhabricatorPolicyInterface',
),
Show only recent orders and charges on Phortune account profile page Summary: Ref T2787. Currently, we show all orders/charges, which won't scale well. Show the 10 most recent and link to full order/charge history. Test Plan: {F216325} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10685
2014-10-13 20:14:50 +02:00
'PhortuneChargeListController' => 'PhortuneController',
Modernize Phortune PHID constants Summary: Ref T2787. These were still stuck in the stone ages. (The handles are pretty skeletal but most aren't used anywehre.) Test Plan: Funded an initiative without anything breaking. Grepped for removed constants. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10647
2014-10-07 01:48:16 +02:00
'PhortuneChargePHIDType' => 'PhabricatorPHIDType',
Phortune Charges Summary: Ref T2787. Makes charges a real object, allows providers to apply them. We are now (just barely) capable of stealing users' money. Test Plan: {F179584} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10002
2014-07-23 19:36:12 +02:00
'PhortuneChargeQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Show only recent orders and charges on Phortune account profile page Summary: Ref T2787. Currently, we show all orders/charges, which won't scale well. Show the 10 most recent and link to full order/charge history. Test Plan: {F216325} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10685
2014-10-13 20:14:50 +02:00
'PhortuneChargeSearchEngine' => 'PhabricatorApplicationSearchEngine',
'PhortuneChargeTableView' => 'AphrontView',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhortuneConstants' => 'Phobject',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneController' => 'PhabricatorController',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhortuneCreditCardForm' => 'Phobject',
Phortune Charges Summary: Ref T2787. Makes charges a real object, allows providers to apply them. We are now (just barely) capable of stealing users' money. Test Plan: {F179584} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10002
2014-07-23 19:36:12 +02:00
'PhortuneCurrency' => 'Phobject',
Make Currency a more formal type Summary: Ref T2787. Phortune currently stores a bunch of stuff as `...inUSDCents`. This ends up being pretty cumbersome and I worry it will create a huge headache down the road (and possibly not that far off if we do Coinbase/Bitcoin soon). Even now, it's more of a pain than I figured it would be. Instead: - Provide an application-level serialization mechanism. - Provide currency serialization. - Store currency in an abstract way (currently, as "1.23 USD") that can handle currencies in the future. - Change all `...inUSDCents` to `..asCurrency`. - This generally simplifies all the application code. - Also remove some columns which don't make sense or don't make sense anymore. Notably, `Product` is going to get more abstract and mostly be provided by applications. Test Plan: - Created a new product. - Purchased a product. - Backed an initiative. - Ran unit tests. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10633
2014-10-06 19:26:48 +02:00
'PhortuneCurrencySerializer' => 'PhabricatorLiskSerializer',
Show prices in "$... USD" in Phortune Summary: Ref T2787. See discussion in D5834. - Replace `PhortuneUtil` with `PhortuneCurrency`, which feels a little better and more flexible / future-proof. - Add unit tests. - Display prices explicitly as "$... USD". Test Plan: Hit product list, cart, purchase flow, verified displays. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5841
2013-05-07 03:04:45 +02:00
'PhortuneCurrencyTestCase' => 'PhabricatorTestCase',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneDAO' => 'PhabricatorLiskDAO',
General cleanup for adding payment methods in Phortune Summary: This has no real behavioral changes (except better error handling), it just factors things out to be a bit cleaner. In particular: - Move more shared form behaviors into the common JS form component. - Move more error handling into shared pathways. - Make the specialized Stripe / Balanced methods do less work. This needs some more polish for nontrival errors (especially on the Balanced side) but none of the error behavior is worse than it was and a lot of it is much better. Ref T2787. Test Plan: Hit all invalid form errors, added valid payment methods with Stripe and Balacned. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5771
2013-04-25 18:49:32 +02:00
'PhortuneErrCode' => 'PhortuneConstants',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneLandingController' => 'PhortuneController',
Make Phortune account members editable and modernize the edge constant Summary: Ref T2787. - Account members can add and remove other members (major use case is corporate accounts). - Use a modern edge constant setup. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10678
2014-10-11 00:00:06 +02:00
'PhortuneMemberHasAccountEdgeType' => 'PhabricatorEdgeType',
Give Phortune merchants explicit members Summary: Ref T2787. Make this a little more concrete with explicit membership instead of a general edit policy. In particular, we need to know who to email when orders happen, and can't reasonably do that with an edit policy. I imagine this might eventually get more nuanced (e.g., users who can only approve orders vs users who can manage the merchant itself) but that's a long ways away. Test Plan: {F216284} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10681
2014-10-13 20:13:50 +02:00
'PhortuneMemberHasMerchantEdgeType' => 'PhabricatorEdgeType',
Add Merchants to Phortune Summary: Ref T2787. Currently, you add payment providers (Stripe, Paypal, etc) in global configuration. Generally, this approach is cumbersome, limiting, and often hard for users to figure out. It also doesn't provide a natural way to segment payment receivers or provide web access to administrative payment functions like issuing refunds, canceling orders, etc. I think that stuff definitely needs to be in the web UI, and the rule for access to it can't reasonably just be "all administrators" in a lot of reasonable cases. The only real advantage is that it prevents an attacker from adjusting settings and pointing something at an account they control. But this attack can be mitigated through notifications, some sort of CLI-only merchant lock, payment accounts being relatively identifiable, etc. So introduce "merchants", which are basically payable entities. An individual merchant will have attached Paypal, Stripe, etc., accounts, and access rules. When you buy something in an application, the merchant to pay is also specified. They also provide an umbrella for dealing with permissions down the line. This may get a //little// cumbersome because if there are several merchants your saved card information is not shared across them. I think that will be fine in the normal case (most installs will have only one merchant). Even if it isn't and we leave providers global, I think introducing this is the right call from a web UI / permissions point of view. I'll play around with it in the next couple of diffs and figure out exactly where the line goes. Test Plan: Listed, created, edited, viewed merchants. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10648
2014-10-07 19:55:16 +02:00
'PhortuneMerchant' => array(
'PhortuneDAO',
Transactions - deploy buildTransactionTimeline to remaining applications Summary: Ref T4712. Specifically... - Differential - needed getApplicationTransactionViewObject() implemented - Audit - needed getApplicationTransactionViewObject() implemented - Repository - one object needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) - Ponder - BONUS BUG FIX - leaving a comment on an answer had a bad redirect URI - both PonderQuestion and PonderAnswer needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on both "history" controllers - left a "TODO" on buildAnswers on the question view controller, which is non-standard and should be re-written eventually - Phortune - BONUS BUG FIX - fix new user "createNewAccount" code to not fatal - PhortuneAccount, PhortuneMerchant, and PhortuneCart needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on Account view, merchant view, and cart view controller - Fund - Legalpad - Nuance - NuanceSource needed PhabricatorApplicationTransactionInterface implemented - Releeph (this product is kind of a mess...) - HACKQUEST - had to manually create an arcanist project to even be able to make a "product" and get started...! - BONUS BUG FIX - make sure to "setName" on product edit - ReleephProject (should be ReleepProduct...?), ReleephBranch, and ReleepRequest needed PhabricatorApplicationTransactionInterface implemented - Harbormaster - HarbormasterBuildable, HarbormasterBuild, HarbormasterBuildPlan, and HarbormasterBuildStep all needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) all over the place Test Plan: foreach application, viewed the timeline(s) and made sure they still rendered Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10925
2014-12-04 00:35:47 +01:00
'PhabricatorApplicationTransactionInterface',
Add Merchants to Phortune Summary: Ref T2787. Currently, you add payment providers (Stripe, Paypal, etc) in global configuration. Generally, this approach is cumbersome, limiting, and often hard for users to figure out. It also doesn't provide a natural way to segment payment receivers or provide web access to administrative payment functions like issuing refunds, canceling orders, etc. I think that stuff definitely needs to be in the web UI, and the rule for access to it can't reasonably just be "all administrators" in a lot of reasonable cases. The only real advantage is that it prevents an attacker from adjusting settings and pointing something at an account they control. But this attack can be mitigated through notifications, some sort of CLI-only merchant lock, payment accounts being relatively identifiable, etc. So introduce "merchants", which are basically payable entities. An individual merchant will have attached Paypal, Stripe, etc., accounts, and access rules. When you buy something in an application, the merchant to pay is also specified. They also provide an umbrella for dealing with permissions down the line. This may get a //little// cumbersome because if there are several merchants your saved card information is not shared across them. I think that will be fine in the normal case (most installs will have only one merchant). Even if it isn't and we leave providers global, I think introducing this is the right call from a web UI / permissions point of view. I'll play around with it in the next couple of diffs and figure out exactly where the line goes. Test Plan: Listed, created, edited, viewed merchants. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10648
2014-10-07 19:55:16 +02:00
'PhabricatorPolicyInterface',
),
'PhortuneMerchantCapability' => 'PhabricatorPolicyCapability',
'PhortuneMerchantController' => 'PhortuneController',
'PhortuneMerchantEditController' => 'PhortuneMerchantController',
'PhortuneMerchantEditor' => 'PhabricatorApplicationTransactionEditor',
Give Phortune merchants explicit members Summary: Ref T2787. Make this a little more concrete with explicit membership instead of a general edit policy. In particular, we need to know who to email when orders happen, and can't reasonably do that with an edit policy. I imagine this might eventually get more nuanced (e.g., users who can only approve orders vs users who can manage the merchant itself) but that's a long ways away. Test Plan: {F216284} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10681
2014-10-13 20:13:50 +02:00
'PhortuneMerchantHasMemberEdgeType' => 'PhabricatorEdgeType',
Support basic ad-hoc invoices in Phortune Summary: This allows a merchant to send a user an invoice for something arbitrary, like services rendered. Two major missing parts: - These don't actually get marked as invoices. I'll fix that in the next diff, but it's not entirely trivial because `subscriptionPHID` is currently overloaded to also mean "is invoice". - We don't send email automatically. I don't plan to fix that for now, since all our invoicing needs are covered by personal email. Test Plan: Merchants have a new "new invoice" option: {F376999} This leads to selecting a user and account, and then you can generate the invoice (only one actual "purchase" / line item for the moment). You can add a longer-form remarkup description to contextualize the billable items: {F377001} This sends the invoice and takes you to the merchant order overview screen: {F377002} For now, you copy/paste that link into a nice personal enterprisey business-to-business email; the recipient sees this: {F377003} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D12478
2015-04-20 19:05:22 +02:00
'PhortuneMerchantInvoiceCreateController' => 'PhortuneMerchantController',
Add Merchants to Phortune Summary: Ref T2787. Currently, you add payment providers (Stripe, Paypal, etc) in global configuration. Generally, this approach is cumbersome, limiting, and often hard for users to figure out. It also doesn't provide a natural way to segment payment receivers or provide web access to administrative payment functions like issuing refunds, canceling orders, etc. I think that stuff definitely needs to be in the web UI, and the rule for access to it can't reasonably just be "all administrators" in a lot of reasonable cases. The only real advantage is that it prevents an attacker from adjusting settings and pointing something at an account they control. But this attack can be mitigated through notifications, some sort of CLI-only merchant lock, payment accounts being relatively identifiable, etc. So introduce "merchants", which are basically payable entities. An individual merchant will have attached Paypal, Stripe, etc., accounts, and access rules. When you buy something in an application, the merchant to pay is also specified. They also provide an umbrella for dealing with permissions down the line. This may get a //little// cumbersome because if there are several merchants your saved card information is not shared across them. I think that will be fine in the normal case (most installs will have only one merchant). Even if it isn't and we leave providers global, I think introducing this is the right call from a web UI / permissions point of view. I'll play around with it in the next couple of diffs and figure out exactly where the line goes. Test Plan: Listed, created, edited, viewed merchants. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10648
2014-10-07 19:55:16 +02:00
'PhortuneMerchantListController' => 'PhortuneMerchantController',
'PhortuneMerchantPHIDType' => 'PhabricatorPHIDType',
'PhortuneMerchantQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhortuneMerchantSearchEngine' => 'PhabricatorApplicationSearchEngine',
'PhortuneMerchantTransaction' => 'PhabricatorApplicationTransaction',
'PhortuneMerchantTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'PhortuneMerchantViewController' => 'PhortuneMerchantController',
For discussion -- Stripe integration Summary: various stripe stuff, including - external stripe library - payment form - test controller to play with payment form, sample business logic My main questions / discussion topics are... - is the stripe PHP library too big? (ie should I write something more simple just for phabricator?) -- if its cool, what is the best way to include the client? (ie should I make it a submodule rather than the flat copy here?) - is the JS I wrote (too) ridiculous? -- particularly unhappy with the error message stuff being in JS *but* it seemed the best choice given the most juicy error messages come from the stripe JS such that the overall code complexity is lowest this way. - how should the stripe JS be included? -- flat copy like I did here? -- some sort of external? -- can we just load it off stripe servers at request time? (I like that from the "if stripe is down, stripe is down" perspective) - wasn't sure if the date control was too silly and should just be baked into the form? -- for some reason I feel like its good to be prepared to walk away from Stripe / switch providers here, though I think this is on the wrong side of pragmatic Test Plan: - played around with sample client form Reviewers: epriestley Reviewed By: epriestley CC: aran Differential Revision: https://secure.phabricator.com/D2096
2012-04-05 01:09:29 +02:00
'PhortuneMonthYearExpiryControl' => 'AphrontFormControl',
Show only recent orders and charges on Phortune account profile page Summary: Ref T2787. Currently, we show all orders/charges, which won't scale well. Show the 10 most recent and link to full order/charge history. Test Plan: {F216325} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10685
2014-10-13 20:14:50 +02:00
'PhortuneOrderTableView' => 'AphrontView',
Make payment providers a configurable property of Merchants in Phortune Summary: Ref T2787. Instead of making providers global configuration, make them a thing on merchants with web configuration. Payment methods and some of the pyament workflow needs to be retooled a bit after this, but this seemed like a reasonable cutoff point for this diff. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10649
2014-10-07 23:41:41 +02:00
'PhortunePayPalPaymentProvider' => 'PhortunePaymentProvider',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhortunePaymentMethod' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhortuneDAO',
'PhabricatorPolicyInterface',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
),
Make payment method management somewhat more reasonable in Phortune Summary: Ref T2787. Shows somewhat-useful information, allows payment methods to be disabled and renamed. Test Plan: Created, renamed, disabled payment methods. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10203
2014-08-11 21:07:35 +02:00
'PhortunePaymentMethodCreateController' => 'PhortuneController',
'PhortunePaymentMethodDisableController' => 'PhortuneController',
Phortune v0.1: add payment methods Summary: Hook @btrahan's Stripe form to the rest of Phortune. - Users can add payment methods. - They are saved to Stripe and associated with PhortunePaymentMethods on our side. - Payment methods appear on account overview. Test Plan: {F37548} {F37549} {F37550} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5438
2013-03-28 17:11:42 +01:00
'PhortunePaymentMethodEditController' => 'PhortuneController',
Modernize Phortune PHID constants Summary: Ref T2787. These were still stuck in the stone ages. (The handles are pretty skeletal but most aren't used anywehre.) Test Plan: Funded an initiative without anything breaking. Grepped for removed constants. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10647
2014-10-07 01:48:16 +02:00
'PhortunePaymentMethodPHIDType' => 'PhabricatorPHIDType',
Phortune v0.1: add payment methods Summary: Hook @btrahan's Stripe form to the rest of Phortune. - Users can add payment methods. - They are saved to Stripe and associated with PhortunePaymentMethods on our side. - Payment methods appear on account overview. Test Plan: {F37548} {F37549} {F37550} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5438
2013-03-28 17:11:42 +01:00
'PhortunePaymentMethodQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhortunePaymentProvider' => 'Phobject',
Make payment providers a configurable property of Merchants in Phortune Summary: Ref T2787. Instead of making providers global configuration, make them a thing on merchants with web configuration. Payment methods and some of the pyament workflow needs to be retooled a bit after this, but this seemed like a reasonable cutoff point for this diff. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10649
2014-10-07 23:41:41 +02:00
'PhortunePaymentProviderConfig' => array(
'PhortuneDAO',
'PhabricatorPolicyInterface',
),
'PhortunePaymentProviderConfigEditor' => 'PhabricatorApplicationTransactionEditor',
'PhortunePaymentProviderConfigQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhortunePaymentProviderConfigTransaction' => 'PhabricatorApplicationTransaction',
'PhortunePaymentProviderConfigTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'PhortunePaymentProviderPHIDType' => 'PhabricatorPHIDType',
Add a bunch of tests for subclass implementations Summary: Add a bunch of tests to ensure that subclasses behave. Test Plan: `arc unit` Reviewers: eadler, #blessed_reviewers, epriestley Reviewed By: eadler, #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13272
2015-06-15 10:07:06 +02:00
'PhortunePaymentProviderTestCase' => 'PhabricatorTestCase',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhortuneProduct' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhortuneDAO',
'PhabricatorPolicyInterface',
Phortune v0.1: products Summary: Ref T2787. A product is the abstract representation of something you can buy or rent/subscribe to. Although the interface isn't locked down yet, this would ultimately be internal/administrative. Products likely have some user-facing skin on top of them: plans would have a purchasing/comparison flow, physical goods would have a storefront, etc., so products don't have any information like descriptions or images, just the data that Phortune needs to correctly bill accounts. Generally, this is very basic for the moment. Test Plan: {F37594} {F37595} {F37596} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5441
2013-03-28 17:13:07 +01:00
),
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhortuneProductImplementation' => 'Phobject',
Phortune v0.1: products Summary: Ref T2787. A product is the abstract representation of something you can buy or rent/subscribe to. Although the interface isn't locked down yet, this would ultimately be internal/administrative. Products likely have some user-facing skin on top of them: plans would have a purchasing/comparison flow, physical goods would have a storefront, etc., so products don't have any information like descriptions or images, just the data that Phortune needs to correctly bill accounts. Generally, this is very basic for the moment. Test Plan: {F37594} {F37595} {F37596} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5441
2013-03-28 17:13:07 +01:00
'PhortuneProductListController' => 'PhabricatorController',
Modernize Phortune PHID constants Summary: Ref T2787. These were still stuck in the stone ages. (The handles are pretty skeletal but most aren't used anywehre.) Test Plan: Funded an initiative without anything breaking. Grepped for removed constants. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10647
2014-10-07 01:48:16 +02:00
'PhortuneProductPHIDType' => 'PhabricatorPHIDType',
Phortune v0.1: products Summary: Ref T2787. A product is the abstract representation of something you can buy or rent/subscribe to. Although the interface isn't locked down yet, this would ultimately be internal/administrative. Products likely have some user-facing skin on top of them: plans would have a purchasing/comparison flow, physical goods would have a storefront, etc., so products don't have any information like descriptions or images, just the data that Phortune needs to correctly bill accounts. Generally, this is very basic for the moment. Test Plan: {F37594} {F37595} {F37596} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5441
2013-03-28 17:13:07 +01:00
'PhortuneProductQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add "Carts" to Phortune Summary: Although I imagine we aren't really going to have an "add to cart" type storefront, putting this in place makes a lot of other workflows simpler. No storage yet, just allows reasonable construction of a "buy stuff" page. Test Plan: {F41342} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5745
2013-04-25 18:45:07 +02:00
'PhortuneProductViewController' => 'PhortuneController',
Make payment providers a configurable property of Merchants in Phortune Summary: Ref T2787. Instead of making providers global configuration, make them a thing on merchants with web configuration. Payment methods and some of the pyament workflow needs to be retooled a bit after this, but this seemed like a reasonable cutoff point for this diff. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10649
2014-10-07 23:41:41 +02:00
'PhortuneProviderActionController' => 'PhortuneController',
Allow merchants to disable payment providers and show more UI info Summary: Ref T2787. - Allow merchants to disable payment providers. - Show more useful information about providers on the payments page. - Make test vs live more clear. - Show merchant status. - Add a description to merchants to flesh them out a bit -- the merchant areas of responsibilities seem to be fitting well with accounts, etc. Test Plan: {F215109} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10662
2014-10-08 17:31:24 +02:00
'PhortuneProviderDisableController' => 'PhortuneMerchantController',
Make payment providers a configurable property of Merchants in Phortune Summary: Ref T2787. Instead of making providers global configuration, make them a thing on merchants with web configuration. Payment methods and some of the pyament workflow needs to be retooled a bit after this, but this seemed like a reasonable cutoff point for this diff. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10649
2014-10-07 23:41:41 +02:00
'PhortuneProviderEditController' => 'PhortuneMerchantController',
Phortune Carts and Purchases Summary: Ref T2787. Make carts and purchases real objects, with storage, that kind-of work. Roughly, the idea here is that applications create "purchases" (like "1 large t-shirt") and add them to "carts" (a user can have a lot of different carts at the same time), then hand things off to Phortune to deal with actualy charging a card. Roughly this works like Paypal or other similar systems do, except Phortune is the thing the user gets handed off to. This doesn't do anything interesting/useful yet. Also fix some bugs and update some UI. Test Plan: Added a product to a cart, saw it in cart screen. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10001
2014-07-23 19:34:08 +02:00
'PhortunePurchase' => array(
'PhortuneDAO',
'PhabricatorPolicyInterface',
),
Modernize Phortune PHID constants Summary: Ref T2787. These were still stuck in the stone ages. (The handles are pretty skeletal but most aren't used anywehre.) Test Plan: Funded an initiative without anything breaking. Grepped for removed constants. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10647
2014-10-07 01:48:16 +02:00
'PhortunePurchasePHIDType' => 'PhabricatorPHIDType',
Phortune Carts and Purchases Summary: Ref T2787. Make carts and purchases real objects, with storage, that kind-of work. Roughly, the idea here is that applications create "purchases" (like "1 large t-shirt") and add them to "carts" (a user can have a lot of different carts at the same time), then hand things off to Phortune to deal with actualy charging a card. Roughly this works like Paypal or other similar systems do, except Phortune is the thing the user gets handed off to. This doesn't do anything interesting/useful yet. Also fix some bugs and update some UI. Test Plan: Added a product to a cart, saw it in cart screen. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D10001
2014-07-23 19:34:08 +02:00
'PhortunePurchaseQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Generate expected schemata for Pholio, Phortune, Phragment, Phriction and Policy Summary: Ref T1191. Nothing too out-of-the-ordinary here. Test Plan: Saw fewer than 500 remaining issues. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley, hach-que Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10587
2014-10-01 16:52:26 +02:00
'PhortuneSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Add basic payment providers to Phortune Summary: Abstract out the Stripiness of payment providers so we can add a Test provider (and maybe MtGox / Balanced / Paypal / etc). Ref T2787. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5752
2013-04-25 18:45:43 +02:00
'PhortuneStripePaymentProvider' => 'PhortunePaymentProvider',
Add boilerplate scaffolding for Phortune subscriptions Summary: Ref T6881. This roughs in the major objects, support classes, and controllers. - Show subscriptions on account detail. - Browse all account subscriptions. - Link to active subsciptions from merchant detail. Test Plan: Clicked around in the UI. There's no way to create subscriptions yet, so I basically just kicked the tires on this. I probably missed a few things that I'll clean up in followups. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11482
2015-01-27 23:50:20 +01:00
'PhortuneSubscription' => array(
'PhortuneDAO',
'PhabricatorPolicyInterface',
),
Kind of generate a bill for users Summary: Ref T6881. This generates a product, purchase and invoice for users, and there's sort of some UI for them. Stuff it doesn't do yet: - Try to autobill when we have a CC; - actually tell the user they should pay it; - ask the application for anything like "how much should we charge", or tell the application anything like "the user paid". However, these work: - You can //technically// pay the invoices. - You can see the invoices you paid in the past. Test Plan: Used `bin/phriction invoice` to double-bill myself over and over again. Paid one of the invoices. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11580
2015-01-30 20:52:50 +01:00
'PhortuneSubscriptionCart' => 'PhortuneCartImplementation',
Automatically bill subscriptions when a payment method is available Summary: Ref T6881. - Allow users to set a default payment method for a subscription, which we'll try to autobill (not all payment methods are autobillable, so we can't require this in the general case, and a charge might fail anyway). - If a subscription has an autopay method, try to automatically bill it. - Otherwise, we'll send them an email like "hey here's a bill, it couldn't autopay for some reasons, go pay it and fix those if you want". - (That email doesn't exist yet but there's a comment about it.) - Also some UI cleanup. Test Plan: - Used `bin/phortune invoice` to autobill myself some fake test money. {F279416} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11596
2015-02-01 21:31:46 +01:00
'PhortuneSubscriptionEditController' => 'PhortuneController',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhortuneSubscriptionImplementation' => 'Phobject',
Add boilerplate scaffolding for Phortune subscriptions Summary: Ref T6881. This roughs in the major objects, support classes, and controllers. - Show subscriptions on account detail. - Browse all account subscriptions. - Link to active subsciptions from merchant detail. Test Plan: Clicked around in the UI. There's no way to create subscriptions yet, so I basically just kicked the tires on this. I probably missed a few things that I'll clean up in followups. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11482
2015-01-27 23:50:20 +01:00
'PhortuneSubscriptionListController' => 'PhortuneController',
'PhortuneSubscriptionPHIDType' => 'PhabricatorPHIDType',
Kind of generate a bill for users Summary: Ref T6881. This generates a product, purchase and invoice for users, and there's sort of some UI for them. Stuff it doesn't do yet: - Try to autobill when we have a CC; - actually tell the user they should pay it; - ask the application for anything like "how much should we charge", or tell the application anything like "the user paid". However, these work: - You can //technically// pay the invoices. - You can see the invoices you paid in the past. Test Plan: Used `bin/phriction invoice` to double-bill myself over and over again. Paid one of the invoices. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11580
2015-01-30 20:52:50 +01:00
'PhortuneSubscriptionProduct' => 'PhortuneProductImplementation',
Add boilerplate scaffolding for Phortune subscriptions Summary: Ref T6881. This roughs in the major objects, support classes, and controllers. - Show subscriptions on account detail. - Browse all account subscriptions. - Link to active subsciptions from merchant detail. Test Plan: Clicked around in the UI. There's no way to create subscriptions yet, so I basically just kicked the tires on this. I probably missed a few things that I'll clean up in followups. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11482
2015-01-27 23:50:20 +01:00
'PhortuneSubscriptionQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhortuneSubscriptionSearchEngine' => 'PhabricatorApplicationSearchEngine',
'PhortuneSubscriptionTableView' => 'AphrontView',
Build a very basic subscription detail page in Phortune Summary: Ref T6881. - Add a subscription detail page. Minor cosmetics: - Fix glyph, from "X" (old "X marks the spot" icon) to "diamond" (new gem icon). - Name the initial account "Default Account" instead of "Personal Account", since this seems more general. Test Plan: {F278623} And I got two full days to test that Jan 30/31 -> Feb 28 billing logic! Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11576
2015-01-30 20:28:49 +01:00
'PhortuneSubscriptionViewController' => 'PhortuneController',
Add some of a billing daemon skeleton Summary: Ref T6881. This adds the worker, and a script to make it easier to test. It doesn't actually invoice anything. I'm intentionally allowing the script to double-bill since it makes testing way easier (by letting you bill the same period over and over again), and provides a tool for recovery if billing screws up. (This diff isn't very interesting, just trying to avoid a 5K-line diff at the end.) Test Plan: Used `bin/phortune invoice ...` to get the worker to print out some date ranges which it would theoretically invoice. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6881 Differential Revision: https://secure.phabricator.com/D11577
2015-01-30 20:29:05 +01:00
'PhortuneSubscriptionWorker' => 'PhabricatorWorker',
Add basic payment providers to Phortune Summary: Abstract out the Stripiness of payment providers so we can add a Test provider (and maybe MtGox / Balanced / Paypal / etc). Ref T2787. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5752
2013-04-25 18:45:43 +02:00
'PhortuneTestPaymentProvider' => 'PhortunePaymentProvider',
Add WePay as a one-time payment provider Summary: Ref T2787. I //think// we could also use WePay as a recurring payment provider, but this is somewhat messy (OAuth + requires account) -- basically it's "add a WePay account" instead of "add a credit card". The WePay checkout workflow is a bit upsell-y but basically reasonable. I like that their API just has a `request($method, $params)` method instead of 30,000 lines of methods for each request type. I did hit one bug; I'll send a pull for that. Test Plan: Got as far as the charge callback in testing; the rest isn't implemented for any provider yet. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5982
2013-05-22 00:34:46 +02:00
'PhortuneWePayPaymentProvider' => 'PhortunePaymentProvider',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhragmentBrowseController' => 'PhragmentController',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'PhragmentCanCreateCapability' => 'PhabricatorPolicyCapability',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhragmentConduitAPIMethod' => 'ConduitAPIMethod',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhragmentController' => 'PhabricatorController',
'PhragmentCreateController' => 'PhragmentController',
'PhragmentDAO' => 'PhabricatorLiskDAO',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhragmentFragment' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhragmentDAO',
'PhabricatorPolicyInterface',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
),
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhragmentFragmentPHIDType' => 'PhabricatorPHIDType',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhragmentFragmentQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhragmentFragmentVersion' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhragmentDAO',
'PhabricatorPolicyInterface',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
),
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhragmentFragmentVersionPHIDType' => 'PhabricatorPHIDType',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhragmentFragmentVersionQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhragmentGetPatchConduitAPIMethod' => 'PhragmentConduitAPIMethod',
Implement update and history controllers in Phragment Summary: Depends on D7726. This adds a history controller (for viewing a list of patches associated with a fragment) and an update controller, for creating a new patch of a fragment. Test Plan: Updated and viewed history of fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7727
2013-12-07 02:56:55 +01:00
'PhragmentHistoryController' => 'PhragmentController',
Implement viewing versions and downloading patches in Phragment Summary: This adds support for viewing individual versions on a fragment as well as comparing versions and downloading diff_match_patch-based patches. It does not use the side-by-side diff format as while it works for small changes, it quickly becomes impossible to distingush what changes have been made due to the diff_match_patch format. Test Plan: Clicked on versions and downloaded patches. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7734
2013-12-08 02:14:34 +01:00
'PhragmentPatchController' => 'PhragmentController',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhragmentPatchUtil' => 'Phobject',
Implement policies in Phragment Summary: This implements support for enforcing and setting policies in Phragment. Test Plan: Set policies and ensured they were enforced successfully. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7751
2013-12-13 04:42:12 +01:00
'PhragmentPolicyController' => 'PhragmentController',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhragmentQueryFragmentsConduitAPIMethod' => 'PhragmentConduitAPIMethod',
Implement "Revert to Version" functionality in Phragment Summary: This functionality allows users to revert a fragment to a previous version from the history page. Reverting a version actually creates a new version pointing at the same file as the version being "reverted" to. In this sense it acts pretty much like Git and other distributed VCS where once you have published a commit the only way to undo your changes is to create a new commit that reverts those changes. Test Plan: Reverted a fragment to a version before it was deleted, then reverted it to when it was deleted and saw the new versions have the correct file PHIDs (including null for the deletion). Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7738
2013-12-08 21:57:53 +01:00
'PhragmentRevertController' => 'PhragmentController',
Generate expected schemata for Pholio, Phortune, Phragment, Phriction and Policy Summary: Ref T1191. Nothing too out-of-the-ordinary here. Test Plan: Saw fewer than 500 remaining issues. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley, hach-que Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10587
2014-10-01 16:52:26 +02:00
'PhragmentSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhragmentSnapshot' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhragmentDAO',
'PhabricatorPolicyInterface',
Implement snapshots in Phragment Summary: Ref T4212. This implements snapshots in Phragment, which allows you to take a snapshot of a fragment at a given point in time, and download a ZIP of the snapshot as it was in this state. There's also functionality for deleting and promoting snapshots. You can promote a snapshot to either the latest version or any other snapshot of the fragment. Test Plan: Clicked around, took some snapshots, promoted them to different points and deleted snapshots. Also downloaded ZIPs of the snapshots and saw the right versions coming through for all the files downloaded. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205, T4212 Differential Revision: https://secure.phabricator.com/D7741
2013-12-08 22:24:50 +01:00
),
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhragmentSnapshotChild' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhragmentDAO',
'PhabricatorPolicyInterface',
Implement snapshots in Phragment Summary: Ref T4212. This implements snapshots in Phragment, which allows you to take a snapshot of a fragment at a given point in time, and download a ZIP of the snapshot as it was in this state. There's also functionality for deleting and promoting snapshots. You can promote a snapshot to either the latest version or any other snapshot of the fragment. Test Plan: Clicked around, took some snapshots, promoted them to different points and deleted snapshots. Also downloaded ZIPs of the snapshots and saw the right versions coming through for all the files downloaded. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205, T4212 Differential Revision: https://secure.phabricator.com/D7741
2013-12-08 22:24:50 +01:00
),
'PhragmentSnapshotChildQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhragmentSnapshotCreateController' => 'PhragmentController',
'PhragmentSnapshotDeleteController' => 'PhragmentController',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhragmentSnapshotPHIDType' => 'PhabricatorPHIDType',
Implement snapshots in Phragment Summary: Ref T4212. This implements snapshots in Phragment, which allows you to take a snapshot of a fragment at a given point in time, and download a ZIP of the snapshot as it was in this state. There's also functionality for deleting and promoting snapshots. You can promote a snapshot to either the latest version or any other snapshot of the fragment. Test Plan: Clicked around, took some snapshots, promoted them to different points and deleted snapshots. Also downloaded ZIPs of the snapshots and saw the right versions coming through for all the files downloaded. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205, T4212 Differential Revision: https://secure.phabricator.com/D7741
2013-12-08 22:24:50 +01:00
'PhragmentSnapshotPromoteController' => 'PhragmentController',
'PhragmentSnapshotQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhragmentSnapshotViewController' => 'PhragmentController',
Implement update and history controllers in Phragment Summary: Depends on D7726. This adds a history controller (for viewing a list of patches associated with a fragment) and an update controller, for creating a new patch of a fragment. Test Plan: Updated and viewed history of fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7727
2013-12-07 02:56:55 +01:00
'PhragmentUpdateController' => 'PhragmentController',
Implement viewing versions and downloading patches in Phragment Summary: This adds support for viewing individual versions on a fragment as well as comparing versions and downloading diff_match_patch-based patches. It does not use the side-by-side diff format as while it works for small changes, it quickly becomes impossible to distingush what changes have been made due to the diff_match_patch format. Test Plan: Clicked on versions and downloaded patches. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7734
2013-12-08 02:14:34 +01:00
'PhragmentVersionController' => 'PhragmentController',
Implement "Download ZIP" controller for Phragment Summary: Depends on D7727. This adds support for downloading a fragment and all it's children as a ZIP file. Fragments that have children automatically become directories in the ZIP file. Test Plan: Downloaded a fragment as a ZIP and was able to extract the contents successfully. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7728
2013-12-07 03:25:22 +01:00
'PhragmentZIPController' => 'PhragmentController',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhrequentConduitAPIMethod' => 'ConduitAPIMethod',
Implemented Phrequent time tracking functionality. Summary: This differential implements Phrequent's time tracking functionality for users and hooks it up to Maniphest. It also includes a basic "Time Tracked" list for the Phrequent application, where users can review what they've spent time working on. Test Plan: Apply the patch and track some things in Maniphest. They should appear in the "Time Tracked" view of Phrequent. There is also a `phrequent.show-prompt` option which toggles whether to display a prompt when tracking time. I'm unsure of whether the prompt is useful or is more likely to cause people to click "Track Time", go off and do the task and then come back to the prompt still waiting for them to confirm. A potential solution to the "accidentally clicking the button and recording 2 seconds of time" might be to show a prompt on stop if the total time is under 10 seconds, asking whether the user wants to keep or discard the tracked time. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2857 Differential Revision: https://secure.phabricator.com/D5479
2013-03-30 17:32:29 +01:00
'PhrequentController' => 'PhabricatorController',
Add a Phrequent curtain extension Summary: Fixes T10546. Some day, decades from now, we can revisit this when we iterate on Phrequent. Just don't regress for no real reason in the meantime, since it's easy enough to keep it working in reasonable shape. Test Plan: {F1169096} Reviewers: chad Reviewed By: chad Maniphest Tasks: T10546 Differential Revision: https://secure.phabricator.com/D15461
2016-03-11 03:11:12 +01:00
'PhrequentCurtainExtension' => 'PHUICurtainExtension',
Implemented Phrequent time tracking functionality. Summary: This differential implements Phrequent's time tracking functionality for users and hooks it up to Maniphest. It also includes a basic "Time Tracked" list for the Phrequent application, where users can review what they've spent time working on. Test Plan: Apply the patch and track some things in Maniphest. They should appear in the "Time Tracked" view of Phrequent. There is also a `phrequent.show-prompt` option which toggles whether to display a prompt when tracking time. I'm unsure of whether the prompt is useful or is more likely to cause people to click "Track Time", go off and do the task and then come back to the prompt still waiting for them to confirm. A potential solution to the "accidentally clicking the button and recording 2 seconds of time" might be to show a prompt on stop if the total time is under 10 seconds, asking whether the user wants to keep or discard the tracked time. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2857 Differential Revision: https://secure.phabricator.com/D5479
2013-03-30 17:32:29 +01:00
'PhrequentDAO' => 'PhabricatorLiskDAO',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'PhrequentListController' => 'PhrequentController',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhrequentPopConduitAPIMethod' => 'PhrequentConduitAPIMethod',
'PhrequentPushConduitAPIMethod' => 'PhrequentConduitAPIMethod',
Update Phrequent to use new search infrastructure. Summary: This updates Phrequent to use new the search infrastructure. Now it looks like: {F60141} I've also added the policy infrastructure stubs, but it's probably not even close to being right in terms of enforcing policies (in particular being able to see time tracked against objects the user wouldn't normally be able to see). At some point I'd like to be able to filter on the objects that the time is tracked against, but I don't believe there's a tokenizer / readahead control that allows you to type any kind of object. Test Plan: Clicked around the new interface, created some custom queries and saved them. Reviewers: epriestley CC: Korvin, aran Maniphest Tasks: T3870 Differential Revision: https://secure.phabricator.com/D7163
2013-10-01 22:04:47 +02:00
'PhrequentSearchEngine' => 'PhabricatorApplicationSearchEngine',
Make Phrequent time accounting aware of the stack Summary: Ref T3569. Fixes T3567. When figuring out how much time has been spent on an object, subtract "preemptive" events which interrupted the object. Also, make the UI look vaguely sane: {F72773} Test Plan: Added a bunch of unit tests, mucked around in the UI. Reviewers: btrahan Reviewed By: btrahan CC: hach-que, skyronic, aran Maniphest Tasks: T3567, T3569 Differential Revision: https://secure.phabricator.com/D7349
2013-10-18 21:47:36 +02:00
'PhrequentTimeBlock' => 'Phobject',
'PhrequentTimeBlockTestCase' => 'PhabricatorTestCase',
Emit more usable results from phrequent.tracking Summary: I think this pretty much does what you would expect? The "active" item is always at the top of the stack. Test Plan: Called `phrequent.tracking` and got reasonable results. Reviewers: hach-que Reviewed By: hach-que Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9939
2014-07-17 02:12:38 +02:00
'PhrequentTimeSlices' => 'Phobject',
Prevent double-submit with control + enter Summary: Fixes T2833. Lock forms and prevent double submit on control + enter. Test Plan: Mashed control + enter a whole bunch in Maniphest, got one comment instead of several. Reviewers: btrahan, edward Reviewed By: btrahan CC: aran Maniphest Tasks: T2833 Differential Revision: https://secure.phabricator.com/D5473
2013-03-31 13:52:35 +02:00
'PhrequentTrackController' => 'PhrequentController',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhrequentTrackingConduitAPIMethod' => 'PhrequentConduitAPIMethod',
Conduit APIs to start and stop tracking time in phrequent Summary: This adds methods to start and stop tracking any arbitrary PHID in phrequent. Currently, this uses copy-pasted code from PhrequentTrackController. I had to do this because the code to start/stop was not abstracted into a common class. Once the code to start/stop working is extracted into a re-usable class, the conduit API can use this as well. Test Plan: I called the functions with a PHID of a task and ensured that the fields in the phrequent database table was being updated correctly. Reviewers: skyronic, #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: maxhodak, erik.fercak, aran, epriestley, Korvin Maniphest Tasks: T3569, T3970 Differential Revision: https://secure.phabricator.com/D7326
2014-07-12 03:42:32 +02:00
'PhrequentTrackingEditor' => 'PhabricatorEditor',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'PhrequentUIEventListener' => 'PhabricatorEventListener',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhrequentUserTime' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhrequentDAO',
'PhabricatorPolicyInterface',
Update Phrequent to use new search infrastructure. Summary: This updates Phrequent to use new the search infrastructure. Now it looks like: {F60141} I've also added the policy infrastructure stubs, but it's probably not even close to being right in terms of enforcing policies (in particular being able to see time tracked against objects the user wouldn't normally be able to see). At some point I'd like to be able to filter on the objects that the time is tracked against, but I don't believe there's a tokenizer / readahead control that allows you to type any kind of object. Test Plan: Clicked around the new interface, created some custom queries and saved them. Reviewers: epriestley CC: Korvin, aran Maniphest Tasks: T3870 Differential Revision: https://secure.phabricator.com/D7163
2013-10-01 22:04:47 +02:00
),
'PhrequentUserTimeQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Allow Phriction documents to be deleted Summary: - Add a "delete" operation. Delete is just a special edit which removes the page from indexes and shows a notice that the document has been deleted. - When a user deletes all the content on a page, treat it as a delete. - When a conduit call deletes all the content on a page, treat it as a delete. - Add page status to Conduit. - Add change type field to history. - Added a couple of constants to support a future 'move' change, which would move content from one document to another. Test Plan: - Verified deleted pages vanish from the document index (and restoring them puts them back). - Verified deleted pages show "This page has been deleted...". - Created, edited and deleted a document via Conduit. - Deleted pages via "delete" button. - Deleted pages via editing content to nothing. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: skrul, aran, btrahan, epriestley Maniphest Tasks: T680 Differential Revision: 1230
2011-12-17 18:19:08 +01:00
'PhrictionChangeType' => 'PhrictionConstants',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhrictionConduitAPIMethod' => 'ConduitAPIMethod',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PhrictionConstants' => 'Phobject',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhrictionContent' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhrictionDAO',
'PhabricatorMarkupInterface',
Add a generic multistep Markup cache Summary: The immediate issue this addresses is T1366, adding a rendering cache to Phriction. For wiki pages with code blocks especially, rerendering them each time is expensive. The broader issue is that out markup caches aren't very good right now. They have three major problems: **Problem 1: the data is stored in the wrong place.** We currently store remarkup caches on objects. This means we're always loading it and passing it around even when we don't need it, can't genericize cache management code (e.g., have one simple script to drop/GC caches), need to update authoritative rows to clear caches, and can't genericize rendering code since each object is different. To solve this, I created a dedicated cache database that I plan to move all markup caches to use. **Problem 2: time-variant rules break when cached.** Some rules like `**bold**` are time-invariant and always produce the same output, but some rules like `{Tnnn}` and `@username` are variant and may render differently (because a task was closed or a user is on vacation). Currently, we cache the raw output, so these time-variant rules get locked at whatever values they had when they were first rendered. This is the main reason Phriction doesn't have a cache right now -- I wanted `{Tnnn}` rules to reflect open/closed tasks. To solve this, I split markup into a "preprocessing" phase (which does all the parsing and evaluates all time-invariant rules) and a "postprocessing" phase (which evaluates time-variant rules only). The preprocessing phase is most of the expense (and, notably, includes syntax highlighting) so this is nearly as good as caching the final output. I did most of the work here in D737 / D738, but we never moved to use it in Phabricator -- we currently just do the two operations serially in all cases. This diff splits them apart and caches the output of preprocessing only, so we benefit from caching but also get accurate time-variant rendering. **Problem 3: cache access isn't batched/pipelined optimally.** When we're rendering a list of markup blocks, we should be able to batch datafetching better than we do. D738 helped with this (fetching is batched within a single hunk of markup) and this improves batching on cache access. We could still do better here, but this is at least a step forward. Also fixes a bug with generating a link in the Phriction history interface ($uri gets clobbered). I'm using PHP serialization instead of JSON serialization because Remarkup does some stuff with non-ascii characters that might not survive JSON. Test Plan: - Created a Phriction document and verified that previews don't go to cache (no rows appear in the cache table). - Verified that published documents come out of cache. - Verified that caches generate/regenerate correctly, time-variant rules render properly and old documents hit the right caches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1366 Differential Revision: https://secure.phabricator.com/D2945
2012-07-10 00:20:56 +02:00
),
Add a differential.createinline method to Conduit Summary: a silly thing because I was bored Test Plan: and I said "arc call-conduit", and there were comments Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1500 Differential Revision: https://secure.phabricator.com/D2971
2012-07-16 20:49:06 +02:00
'PhrictionController' => 'PhabricatorController',
Phriction - add "create" conduit endpoint Summary: Fixes T6262. Ref T4029. Also gets us ready for T5873 for these end points. I can file something new about someday adding phriction.query, etc but I think we'll remember and can look at that post T5873. Test Plan: made a document via conduit and it worked! Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6262, T4029 Differential Revision: https://secure.phabricator.com/D10813
2014-11-07 20:46:25 +01:00
'PhrictionCreateConduitAPIMethod' => 'PhrictionConduitAPIMethod',
Add a differential.createinline method to Conduit Summary: a silly thing because I was bored Test Plan: and I said "arc call-conduit", and there were comments Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1500 Differential Revision: https://secure.phabricator.com/D2971
2012-07-16 20:49:06 +02:00
'PhrictionDAO' => 'PhabricatorLiskDAO',
'PhrictionDeleteController' => 'PhrictionController',
'PhrictionDiffController' => 'PhrictionController',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PhrictionDocument' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhrictionDAO',
'PhabricatorPolicyInterface',
'PhabricatorSubscribableInterface',
'PhabricatorFlaggableInterface',
'PhabricatorTokenReceiverInterface',
'PhabricatorDestructibleInterface',
T4666, Support Herald in Phriction Summary: Fixes T4666, add Herald rules to Phriction Documents Test Plan: add Herald rule to flag if title contains "xyz", create Phriction Document with title "xyz". Phriction Document should be flagged. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T4666 Differential Revision: https://secure.phabricator.com/D10830
2014-11-12 03:29:36 +01:00
'PhabricatorApplicationTransactionInterface',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorFulltextInterface',
Search options. Test Plan: - Looked at the new options - Saved `search.engine-selector` successfully. Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4410
2013-01-12 00:28:16 +01:00
),
Modularize all remaining Phriction Herald fields Summary: Ref T8726. Test Plan: - Created a rule using all the fields. - Updated documents, saw rule apply, reviewed transcript. - Migrated stuff. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13514
2015-07-06 22:17:50 +02:00
'PhrictionDocumentAuthorHeraldField' => 'PhrictionDocumentHeraldField',
'PhrictionDocumentContentHeraldField' => 'PhrictionDocumentHeraldField',
Phriction basics Summary: Basically a copy/paste of parts of D636, but with two changes: - Fully separate the index table ("document") from the content table ("content"). I think this will be a cleaner solution in the long run. - Build slugs into the document structure. This doesn't do anything useful, it just normalizes slugs and lays some groundwork. Test Plan: - Visited various /w/ pages and saw them normalize correctly. - Verified the DAO works by inserting dummy rows. Reviewed By: codeblock Reviewers: hsb, codeblock, jungejason, aran, tuomaspelkonen CC: aran, codeblock, epriestley Differential Revision: 638
2011-07-11 17:54:22 +02:00
'PhrictionDocumentController' => 'PhrictionController',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhrictionDocumentFulltextEngine' => 'PhabricatorFulltextEngine',
T4666, Support Herald in Phriction Summary: Fixes T4666, add Herald rules to Phriction Documents Test Plan: add Herald rule to flag if title contains "xyz", create Phriction Document with title "xyz". Phriction Document should be flagged. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: Korvin, epriestley Maniphest Tasks: T4666 Differential Revision: https://secure.phabricator.com/D10830
2014-11-12 03:29:36 +01:00
'PhrictionDocumentHeraldAdapter' => 'HeraldAdapter',
Modularize all remaining Phriction Herald fields Summary: Ref T8726. Test Plan: - Created a rule using all the fields. - Updated documents, saw rule apply, reviewed transcript. - Migrated stuff. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13514
2015-07-06 22:17:50 +02:00
'PhrictionDocumentHeraldField' => 'HeraldField',
Group and order Herald fields Summary: Ref T8726. Some adapters now have a large number of fields, and we lost the sort-of-human-readable implicit ordering when fields were modularized. Instead, group and sort fields. Test Plan: {F603066} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13619
2015-07-16 23:13:13 +02:00
'PhrictionDocumentHeraldFieldGroup' => 'HeraldFieldGroup',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PhrictionDocumentPHIDType' => 'PhabricatorPHIDType',
Modularize all remaining Phriction Herald fields Summary: Ref T8726. Test Plan: - Created a rule using all the fields. - Updated documents, saw rule apply, reviewed transcript. - Migrated stuff. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13514
2015-07-06 22:17:50 +02:00
'PhrictionDocumentPathHeraldField' => 'PhrictionDocumentHeraldField',
Implement PhrictionDocumentQuery Summary: Companion for D5284. Move all the query logic to a policy-aware query class. In particular: - Currently, anyone can view and edit a project's wiki documents. For callsites using this query class, you must be able to view or edit the project to view or edit its documents. - There's some very sketchy logic with the content/document joins. This cleans that up. - This cleans up loading projects by moving it inside the query. We need to do this anyway to perform policy checks. Test Plan: Viewed active/all/updated. Set page size to 2, verified pager works. Reviewers: AnhNhan, chad Reviewed By: AnhNhan CC: aran Differential Revision: https://secure.phabricator.com/D5285
2013-03-08 16:12:24 +01:00
'PhrictionDocumentQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Allow Phriction documents to be deleted Summary: - Add a "delete" operation. Delete is just a special edit which removes the page from indexes and shows a notice that the document has been deleted. - When a user deletes all the content on a page, treat it as a delete. - When a conduit call deletes all the content on a page, treat it as a delete. - Add page status to Conduit. - Add change type field to history. - Added a couple of constants to support a future 'move' change, which would move content from one document to another. Test Plan: - Verified deleted pages vanish from the document index (and restoring them puts them back). - Verified deleted pages show "This page has been deleted...". - Created, edited and deleted a document via Conduit. - Deleted pages via "delete" button. - Deleted pages via editing content to nothing. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: skrul, aran, btrahan, epriestley Maniphest Tasks: T680 Differential Revision: 1230
2011-12-17 18:19:08 +01:00
'PhrictionDocumentStatus' => 'PhrictionConstants',
Modularize all remaining Phriction Herald fields Summary: Ref T8726. Test Plan: - Created a rule using all the fields. - Updated documents, saw rule apply, reviewed transcript. - Migrated stuff. Reviewers: btrahan Reviewed By: btrahan Subscribers: eadler, epriestley Maniphest Tasks: T8726 Differential Revision: https://secure.phabricator.com/D13514
2015-07-06 22:17:50 +02:00
'PhrictionDocumentTitleHeraldField' => 'PhrictionDocumentHeraldField',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhrictionEditConduitAPIMethod' => 'PhrictionConduitAPIMethod',
Basic edit/create workflow for Phriction Summary: This is another chunk of D636, I just simplified it a bit and added slugs. When you go to a page like /w/pokemon/, it allows you to create or edit the page. Title vs slug stuff is a little funky but I think mostly-reasonable. Test Plan: Created and edited /w/, /w/pokemon/, etc. Reviewed By: hsb Reviewers: hsb, codeblock, jungejason, aran, tuomaspelkonen CC: aran, hsb Differential Revision: 643
2011-07-11 21:34:53 +02:00
'PhrictionEditController' => 'PhrictionController',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhrictionHistoryConduitAPIMethod' => 'PhrictionConduitAPIMethod',
Very basic Phriction history view Summary: Provide a (mostly useless, currently) table of document edits. Test Plan: Looked at document history for several of my high-quality sandbox wiki pages. Reviewed By: hsb Reviewers: hsb, codeblock, jungejason, aran, tuomaspelkonen CC: aran, hsb Differential Revision: 644
2011-07-12 00:06:19 +02:00
'PhrictionHistoryController' => 'PhrictionController',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'PhrictionInfoConduitAPIMethod' => 'PhrictionConduitAPIMethod',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'PhrictionListController' => 'PhrictionController',
Support relative links in Phriction Summary: Resolves T7691. This turned out more complex than I really wanted, mainly because I needed to feed the slug information through to both the document renderer and the preview window that appears in the edit controller. After this change, you can now create relative links in Phriction by doing `[[ ./../some/relative/path ]]`. Relative paths aren't handled anywhere else (they'll still render, but the dots are turned into a literal 'dot' as per existing behaviour). Test Plan: Created some Phriction documents with relative links, saw them all link correctly. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: Korvin Maniphest Tasks: T7691 Differential Revision: https://secure.phabricator.com/D15732
2016-04-16 04:07:03 +02:00
'PhrictionMarkupPreviewController' => 'PhabricatorController',
Phriction Documents can be moved Summary: Refs T1575 Test Plan: created plenty of pages, did all kind of stuff with them, moved them around, verified expected behaviour. {F34453} {F34455} Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, epriestley, Korvin Maniphest Tasks: T1575 Differential Revision: https://secure.phabricator.com/D5198
2013-03-06 22:12:04 +01:00
'PhrictionMoveController' => 'PhrictionController',
Create a "New Document" button in phriction Summary: gives user a dialogue and they can fill out what comes after /w/ Test Plan: made some new wiki docs. played with garbage data and edit scenarios as well as vanilla create -- good ish Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1360 Differential Revision: https://secure.phabricator.com/D3946
2012-11-10 00:08:37 +01:00
'PhrictionNewController' => 'PhrictionController',
Pre-prepare for hovercards Summary: D5120 and followups refactor and generalize object references in Remarkup -- notably, they move remarkup rules from a central location to the implementing applications. Preserve blame by doing moves/renames only first. This change moves application remarkup rules into those applications, and renames the ones D5120 modifies. Test Plan: Typed some preview text into a textarea, got a valid Remarkup render. Reviewers: vrana, chad Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5123
2013-02-26 23:57:41 +01:00
'PhrictionRemarkupRule' => 'PhutilRemarkupRule',
Subclass most ReplyHandlers from TransactionReplyHandler Summary: Ref T7199. Half of these aren't even reachable, but make some progress toward reducing the amount of nonsense and garbage in mail handling. Test Plan: Tested all reachable handlers with `bin/mail receive-test`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12237
2015-04-01 17:39:50 +02:00
'PhrictionReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Generate expected schemata for Pholio, Phortune, Phragment, Phriction and Policy Summary: Ref T1191. Nothing too out-of-the-ordinary here. Test Plan: Saw fewer than 500 remaining issues. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley, hach-que Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10587
2014-10-01 16:52:26 +02:00
'PhrictionSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Add breadcrumbs and ApplicationSearch to Phriction Summary: Fixes T3631. Also adds ApplicationSearch. Test Plan: Viewed "New", "Edit"; saw breadcrumbs. Viewed "index", saw application search. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T3631 Differential Revision: https://secure.phabricator.com/D6593
2013-07-28 03:26:42 +02:00
'PhrictionSearchEngine' => 'PhabricatorApplicationSearchEngine',
Phriction - start the move towards transactions and an editor Summary: This implements as little as possible to stick a working transactions + editor codepath in the basic create / edit flow. Aside from the transaction tables, this also required adding a mailKey to a phrictionDocument. Future work would include adding more transactions types for things like "move" and all the pertinent support. Even future work is to add things like policies which will work easily in the transaction framework. Ref T4029. Test Plan: - made a wiki doc - edit a wiki doc - had someone subscribe to a wiki doc and edited it For all three, the edits worked, a reasonable email was sent out, and feed stories were generated. - made a wiki doc at a /location/like/this document "stubs" were made as expected in /location and /location/like Reviewers: epriestley Reviewed By: epriestley Subscribers: chad, Korvin, epriestley Maniphest Tasks: T4029 Differential Revision: https://secure.phabricator.com/D10756
2014-10-30 16:59:21 +01:00
'PhrictionTransaction' => 'PhabricatorApplicationTransaction',
'PhrictionTransactionComment' => 'PhabricatorApplicationTransactionComment',
'PhrictionTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
'PhrictionTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Config - add an option to lock policy settings Summary: Fixes T6947 Test Plan: locked people.create.user and noted the UI only showed a link to the existing policy with no way to edit it. tried to set the config to all the various bad things and saw helpful error messages telling me what I did wrong. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6947 Differential Revision: https://secure.phabricator.com/D11358
2015-01-13 20:46:29 +01:00
'PolicyLockOptionType' => 'PhabricatorConfigJSONOptionType',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderAddAnswerView' => 'AphrontView',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PonderAnswer' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PonderDAO',
Transactions - deploy buildTransactionTimeline to remaining applications Summary: Ref T4712. Specifically... - Differential - needed getApplicationTransactionViewObject() implemented - Audit - needed getApplicationTransactionViewObject() implemented - Repository - one object needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) - Ponder - BONUS BUG FIX - leaving a comment on an answer had a bad redirect URI - both PonderQuestion and PonderAnswer needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on both "history" controllers - left a "TODO" on buildAnswers on the question view controller, which is non-standard and should be re-written eventually - Phortune - BONUS BUG FIX - fix new user "createNewAccount" code to not fatal - PhortuneAccount, PhortuneMerchant, and PhortuneCart needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on Account view, merchant view, and cart view controller - Fund - Legalpad - Nuance - NuanceSource needed PhabricatorApplicationTransactionInterface implemented - Releeph (this product is kind of a mess...) - HACKQUEST - had to manually create an arcanist project to even be able to make a "product" and get started...! - BONUS BUG FIX - make sure to "setName" on product edit - ReleephProject (should be ReleepProduct...?), ReleephBranch, and ReleepRequest needed PhabricatorApplicationTransactionInterface implemented - Harbormaster - HarbormasterBuildable, HarbormasterBuild, HarbormasterBuildPlan, and HarbormasterBuildStep all needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) all over the place Test Plan: foreach application, viewed the timeline(s) and made sure they still rendered Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10925
2014-12-04 00:35:47 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorMarkupInterface',
'PhabricatorPolicyInterface',
'PhabricatorFlaggableInterface',
'PhabricatorSubscribableInterface',
Provide some hints for Amazon RDS configuration Summary: Fixes T2605. Provide some instructions on configuring RDS properly. The "DB Parameter Group" thing in the web UI seems pretty easy to use, it's just not obvious that it's what you should be using. Test Plan: Jiggled these warnings to trigger them, viewed the output, saw a table of values and a hint about RDS. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2605 Differential Revision: https://secure.phabricator.com/D10343
2014-08-25 20:41:40 +02:00
'PhabricatorDestructibleInterface',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
),
Restore comments on Ponder answers Summary: Ref T3373. This is still pretty messy: - The JS bugs out a bit with multiple primary object PHIDs on a single page. I'll fix this in a followup. - The comment form itself is enormous, I'll restore some show/hide stuff in a followup. Test Plan: Added answer comments in Ponder. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6608
2013-07-29 02:40:11 +02:00
'PonderAnswerCommentController' => 'PonderController',
Allow ponder answers to be edited Summary: Ref T3373. Use applicationtransactions to edit ponder answers. Also enable tokens and subscriptions. Test Plan: edited an answer Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6607
2013-07-29 02:23:04 +02:00
'PonderAnswerEditController' => 'PonderController',
Ponder - make feed stories and emails a bit better Summary: Also some random cleanup now and again. Note reply handler stuff is kind of bojangles bad right now. It didn't work before though either so hey. Test Plan: asked questions, answered questions, edited answers... the feed pleased my eye Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T3653 Differential Revision: https://secure.phabricator.com/D7027
2013-09-19 00:15:25 +02:00
'PonderAnswerEditor' => 'PonderEditor',
Move non-comment transactions to a separate history view in Ponder Summary: Ref T3373. Most edits aren't too interesting, put them on a separate history page. Test Plan: Viewed question page; viewed history page for question and answer. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6612
2013-07-29 03:32:55 +02:00
'PonderAnswerHistoryController' => 'PonderController',
Add ability to reply to Ponder Answer emails Summary: Ref T9068, Ref T3846. Maybe fixes both, but I'm having issues testing email replies in a sandbox. Moves answer feed/mail generation to the AnswerEditor, hides it in QuestionEditor. Test Plan: Write an answer, see feed story, check /mail/ for mail generation. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T3846, T9068 Differential Revision: https://secure.phabricator.com/D13905
2015-08-17 19:22:54 +02:00
'PonderAnswerMailReceiver' => 'PhabricatorObjectMailReceiver',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PonderAnswerPHIDType' => 'PhabricatorPHIDType',
Use Application PHIDs for ANSW Summary: Ref T2715. Ref T3578. - Use Application PHIDs for Ponder Answers. - Make Ponder answers policy-aware. - Make PonderAnswerQuery policy-aware. Test Plan: Used `phid.query`; browsed Ponder. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715, T3578 Differential Revision: https://secure.phabricator.com/D6582
2013-07-26 22:19:49 +02:00
'PonderAnswerQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add ability to reply to Ponder Answer emails Summary: Ref T9068, Ref T3846. Maybe fixes both, but I'm having issues testing email replies in a sandbox. Moves answer feed/mail generation to the AnswerEditor, hides it in QuestionEditor. Test Plan: Write an answer, see feed story, check /mail/ for mail generation. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T3846, T9068 Differential Revision: https://secure.phabricator.com/D13905
2015-08-17 19:22:54 +02:00
'PonderAnswerReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderAnswerSaveController' => 'PonderController',
Add ability to hide answers in Ponder Summary: Ref T9173, adds basic hide support for answers. Answer authors and Moderators can hide answers, unhide them. Test Plan: Hide answer, log into other account, see hidden message. Mark as visible, see answer again. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9173 Differential Revision: https://secure.phabricator.com/D13894
2015-08-14 18:25:02 +02:00
'PonderAnswerStatus' => 'PonderConstants',
Add question and answer transactions to Ponder Summary: Ref T3373. Test Plan: Ran this script, saw valid inserts: <?php $unguarded = AphrontWriteGuard::beginScopedUnguardedWrites(); id(new PonderQuestionTransaction()) ->setAuthorPHID('herp') ->setObjectPHID('derp') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setTransactionType('beep') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderAnswerTransaction()) ->setAuthorPHID('herp') ->setObjectPHID('derp') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setTransactionType('beep') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderQuestionTransactionComment()) ->setCommentVersion(1) ->setAuthorPHID('bloop') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setContent('blip') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderAnswerTransactionComment()) ->setCommentVersion(1) ->setAuthorPHID('bloop') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setContent('blip') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); unset($unguarded); echo "OK!\n"; Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6584
2013-07-26 22:52:57 +02:00
'PonderAnswerTransaction' => 'PhabricatorApplicationTransaction',
'PonderAnswerTransactionComment' => 'PhabricatorApplicationTransactionComment',
Make Ponder use ApplicationTransaction rendering for answers Summary: Ref T3373. This breaks some stuff, but future diffs will fix it. Test Plan: Viewed some questions, saw answer text. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6604
2013-07-29 01:17:51 +02:00
'PonderAnswerTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Update Ponder Answer layout Summary: Ref T9099, A step forward for the main Ponder UI. Mostly moving stuff into View classes and reducing clutter. Took a pass at keeping comments and helpfuls, but unclear what the 'final' UI will be (I'm just designing as I use the product). Test Plan: Review a number of questions and answers. {F702495} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9099 Differential Revision: https://secure.phabricator.com/D13872
2015-08-11 19:42:40 +02:00
'PonderAnswerView' => 'AphrontTagView',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'PonderConstants' => 'Phobject',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderController' => 'PhabricatorController',
'PonderDAO' => 'PhabricatorLiskDAO',
Add a default moderation policy to Ponder Summary: This allows installs to essentially set a "moderator" for Ponder, who can clean up answers. Fixes T9098 Test Plan: Edit an answer I don't own. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9098 Differential Revision: https://secure.phabricator.com/D13818
2015-08-08 21:20:01 +02:00
'PonderDefaultViewCapability' => 'PhabricatorPolicyCapability',
Ponder - make feed stories and emails a bit better Summary: Also some random cleanup now and again. Note reply handler stuff is kind of bojangles bad right now. It didn't work before though either so hey. Test Plan: asked questions, answered questions, edited answers... the feed pleased my eye Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T3653 Differential Revision: https://secure.phabricator.com/D7027
2013-09-19 00:15:25 +02:00
'PonderEditor' => 'PhabricatorApplicationTransactionEditor',
Update Ponder Answer layout Summary: Ref T9099, A step forward for the main Ponder UI. Mostly moving stuff into View classes and reducing clutter. Took a pass at keeping comments and helpfuls, but unclear what the 'final' UI will be (I'm just designing as I use the product). Test Plan: Review a number of questions and answers. {F702495} Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9099 Differential Revision: https://secure.phabricator.com/D13872
2015-08-11 19:42:40 +02:00
'PonderFooterView' => 'AphrontTagView',
Add a default moderation policy to Ponder Summary: This allows installs to essentially set a "moderator" for Ponder, who can clean up answers. Fixes T9098 Test Plan: Edit an answer I don't own. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T9098 Differential Revision: https://secure.phabricator.com/D13818
2015-08-08 21:20:01 +02:00
'PonderModerateCapability' => 'PhabricatorPolicyCapability',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'PonderQuestion' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PonderDAO',
Transactions - deploy buildTransactionTimeline to remaining applications Summary: Ref T4712. Specifically... - Differential - needed getApplicationTransactionViewObject() implemented - Audit - needed getApplicationTransactionViewObject() implemented - Repository - one object needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) - Ponder - BONUS BUG FIX - leaving a comment on an answer had a bad redirect URI - both PonderQuestion and PonderAnswer needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on both "history" controllers - left a "TODO" on buildAnswers on the question view controller, which is non-standard and should be re-written eventually - Phortune - BONUS BUG FIX - fix new user "createNewAccount" code to not fatal - PhortuneAccount, PhortuneMerchant, and PhortuneCart needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on Account view, merchant view, and cart view controller - Fund - Legalpad - Nuance - NuanceSource needed PhabricatorApplicationTransactionInterface implemented - Releeph (this product is kind of a mess...) - HACKQUEST - had to manually create an arcanist project to even be able to make a "product" and get started...! - BONUS BUG FIX - make sure to "setName" on product edit - ReleephProject (should be ReleepProduct...?), ReleephBranch, and ReleepRequest needed PhabricatorApplicationTransactionInterface implemented - Harbormaster - HarbormasterBuildable, HarbormasterBuild, HarbormasterBuildPlan, and HarbormasterBuildStep all needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) all over the place Test Plan: foreach application, viewed the timeline(s) and made sure they still rendered Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10925
2014-12-04 00:35:47 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorMarkupInterface',
'PhabricatorSubscribableInterface',
'PhabricatorFlaggableInterface',
'PhabricatorPolicyInterface',
'PhabricatorTokenReceiverInterface',
'PhabricatorProjectInterface',
Provide some hints for Amazon RDS configuration Summary: Fixes T2605. Provide some instructions on configuring RDS properly. The "DB Parameter Group" thing in the web UI seems pretty easy to use, it's just not obvious that it's what you should be using. Test Plan: Jiggled these warnings to trigger them, viewed the output, saw a table of values and a hint about RDS. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2605 Differential Revision: https://secure.phabricator.com/D10343
2014-08-25 20:41:40 +02:00
'PhabricatorDestructibleInterface',
Add Spaces to Ponder Summary: Ref T8493, Ref T3578. Adds spaces support to ponder. Test Plan: Ask a question in a new space, see new question. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin Maniphest Tasks: T3578, T8493 Differential Revision: https://secure.phabricator.com/D13792
2015-08-05 18:38:14 +02:00
'PhabricatorSpacesInterface',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PhabricatorFulltextInterface',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
),
Restore Ponder question commenting Summary: Ref T3373. Same issues as the other commenting patch; it's huge and the JS is a bit buggy. Backend is fine, though. Test Plan: Made some comments on a question. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6610
2013-07-29 02:58:34 +02:00
'PonderQuestionCommentController' => 'PonderController',
Make PonderQuestionEditor use ApplicationTransactions Summary: Ref T3373. Make PonderQuestions editable and use transactions. This temporarily disables some stuff: - email; - feed; - comments; - voting. I'll restore those in followups and wait to land this until they're at least mostly back online. The transactions themselves also need more string/color/icon work. Test Plan: Created and edited questions. Viewed transactions. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6601
2013-07-29 00:02:18 +02:00
'PonderQuestionEditController' => 'PonderController',
Ponder - make feed stories and emails a bit better Summary: Also some random cleanup now and again. Note reply handler stuff is kind of bojangles bad right now. It didn't work before though either so hey. Test Plan: asked questions, answered questions, edited answers... the feed pleased my eye Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T3653 Differential Revision: https://secure.phabricator.com/D7027
2013-09-19 00:15:25 +02:00
'PonderQuestionEditor' => 'PonderEditor',
Convert all "DocumentIndexers" into "FulltextEngines" Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure. Test Plan: - Used `bin/search index --type ...` to index documents of every indexable type. - Searched for documents by unique text, found them. Reviewers: chad Reviewed By: chad Maniphest Tasks: T9979 Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 18:02:55 +01:00
'PonderQuestionFulltextEngine' => 'PhabricatorFulltextEngine',
Move non-comment transactions to a separate history view in Ponder Summary: Ref T3373. Most edits aren't too interesting, put them on a separate history page. Test Plan: Viewed question page; viewed history page for question and answer. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6612
2013-07-29 03:32:55 +02:00
'PonderQuestionHistoryController' => 'PonderController',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'PonderQuestionListController' => 'PonderController',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PonderQuestionMailReceiver' => 'PhabricatorObjectMailReceiver',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'PonderQuestionPHIDType' => 'PhabricatorPHIDType',
upgrade diffusion to use modern header UI and fix a few quirks Summary: upgrades are CrumbsView, HeaderView, PropertyListView, and ActionListView. I had to modify CrumbsView stuff a bit to handle the "advanced" diffusion crumbs. Quirks fixed include making file tree view show up in diffusion, the page not have extra space when the file tree is hidden, links no longer breaking once you visit files (since without the change the files always got "/" appended and thus 404'd), and a differential quirk where it read "next step:" and that colon is a no no, Test Plan: played around in diffusion and differential Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2048, T2178 Differential Revision: https://secure.phabricator.com/D4169
2012-12-13 02:50:42 +01:00
'PonderQuestionQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Subclass most ReplyHandlers from TransactionReplyHandler Summary: Ref T7199. Half of these aren't even reachable, but make some progress toward reducing the amount of nonsense and garbage in mail handling. Test Plan: Tested all reachable handlers with `bin/mail receive-test`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12237
2015-04-01 17:39:50 +02:00
'PonderQuestionReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Use ApplicationSearch in Ponder Summary: Ref T2625. Also modernize some other things: - Fix double-"subscribers". - Use byline and more standard date. - Modernize some of the use of crumbs and navigation. - Delete some dead / uncalled code. Test Plan: {F50669} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3578, T2625 Differential Revision: https://secure.phabricator.com/D6486
2013-07-18 21:40:51 +02:00
'PonderQuestionSearchEngine' => 'PhabricatorApplicationSearchEngine',
Allowing Closing of questions Summary: Fixes T3579 As a basic overview, this enables the author of a question to open/close a question. Other bits; - Add "Open" filter to the builtin queries - Add "Status" to search form - Refactor ponder constants - Add coloured bars for different question statuses Test Plan: - Open/Close questions - Search for some bits - Use filters Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3579 Differential Revision: https://secure.phabricator.com/D6590 Conflicts: src/infrastructure/storage/patch/PhabricatorBuiltinPatchList.php
2013-07-28 03:37:17 +02:00
'PonderQuestionStatus' => 'PonderConstants',
'PonderQuestionStatusController' => 'PonderController',
Add question and answer transactions to Ponder Summary: Ref T3373. Test Plan: Ran this script, saw valid inserts: <?php $unguarded = AphrontWriteGuard::beginScopedUnguardedWrites(); id(new PonderQuestionTransaction()) ->setAuthorPHID('herp') ->setObjectPHID('derp') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setTransactionType('beep') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderAnswerTransaction()) ->setAuthorPHID('herp') ->setObjectPHID('derp') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setTransactionType('beep') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderQuestionTransactionComment()) ->setCommentVersion(1) ->setAuthorPHID('bloop') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setContent('blip') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderAnswerTransactionComment()) ->setCommentVersion(1) ->setAuthorPHID('bloop') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setContent('blip') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); unset($unguarded); echo "OK!\n"; Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6584
2013-07-26 22:52:57 +02:00
'PonderQuestionTransaction' => 'PhabricatorApplicationTransaction',
'PonderQuestionTransactionComment' => 'PhabricatorApplicationTransactionComment',
Make PonderQuestionEditor use ApplicationTransactions Summary: Ref T3373. Make PonderQuestions editable and use transactions. This temporarily disables some stuff: - email; - feed; - comments; - voting. I'll restore those in followups and wait to land this until they're at least mostly back online. The transactions themselves also need more string/color/icon work. Test Plan: Created and edited questions. Viewed transactions. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6601
2013-07-29 00:02:18 +02:00
'PonderQuestionTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderQuestionViewController' => 'PonderController',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'PonderRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Generate expected Ponder schemata Summary: Ref T1191. - Removes ponder comment table. This was migrated a very long time ago. Test Plan: - Grepped for removed table. - Saw ~100 fewer issues in web UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1191 Differential Revision: https://secure.phabricator.com/D10582
2014-10-01 16:37:14 +02:00
'PonderSchemaSpec' => 'PhabricatorConfigSchemaSpec',
Implement a "!projects" mail command Summary: Ref T7199. Implements `!projects` for all objects which implement `PhabricatorProjectInterface`. Test Plan: Added projects to a task via email. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12246
2015-04-01 18:40:12 +02:00
'ProjectAddProjectsEmailCommand' => 'MetaMTAEmailTransactionCommand',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'ProjectBoardTaskCard' => 'Phobject',
Projects - add "lock membership", which prevents people from leaving Summary: Fixes T5603. Puts the toggling of locking membership into the editor so we get exceptions and all that. I think the dialogue when you try to leave a project that is locked could be a little better maybe? Right now it just says "You can't leave" and "The membership is locked" more or less; should I surface a link to the policy stuff there too? Test Plan: - made a project, toggled the "lock" setting, observed stickiness and good transactions being made - locked a project and tried to leave as a non-editor - got a dialogue letting me know i couldn't - locked a project and tried to leave as an editor - left successfully Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5603 Differential Revision: https://secure.phabricator.com/D10508
2014-09-18 20:00:50 +02:00
'ProjectCanLockProjectsCapability' => 'PhabricatorPolicyCapability',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ProjectConduitAPIMethod' => 'ConduitAPIMethod',
Workboards - add new "initialization" flow Summary: Currently, we just create a default "backlog" column if / when you visit a workboard for the first time. Post this patch, instead you see a blocking dialog that lets you either create the default backlog column or import columns from another project. In the case of the latter, the user gets another dialog which lets them select any project of which they are a member that also has columns in it. Note that only not hidden columns get imported. Fixes T4431. Test Plan: - made a new workboard and got my new dialog. made a default backlog and it worked! - made a new workboard again and tried the import flow - it also worked. - verified projects with no columns do not show up in import dialog - verified project with / without columns still all show up in maniphest project typeahead Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4431 Differential Revision: https://secure.phabricator.com/D10153
2014-08-05 22:40:41 +02:00
'ProjectCreateConduitAPIMethod' => 'ProjectConduitAPIMethod',
Rename policy capabilities Summary: Ref T5655. Rename `PhabricatorPolicyCapability` subclasses for consistency. Test Plan: Browsed a few applications, nothing seemed broken. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D10037
2014-07-25 00:20:39 +02:00
'ProjectCreateProjectsCapability' => 'PhabricatorPolicyCapability',
Add default View, Edit, and Join Policies to Projects Summary: Fixes T6567, lets admins set a default policy for new Projects. Test Plan: Changed the default Policy, created a new Project. Project had correct defaults. Reviewers: btrahan, epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T6567 Differential Revision: https://secure.phabricator.com/D10890
2014-11-21 20:22:17 +01:00
'ProjectDefaultEditCapability' => 'PhabricatorPolicyCapability',
'ProjectDefaultJoinCapability' => 'PhabricatorPolicyCapability',
'ProjectDefaultViewCapability' => 'PhabricatorPolicyCapability',
Convert projects to EditEngine Summary: Ref T10010. This is pretty straightforward with a couple of very minor new behaviors, like the icon selector edit field. Test Plan: - Created projects. - Edited projects. - Saw "Create Project" in quick create menu. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14896
2015-12-27 15:45:53 +01:00
'ProjectEditConduitAPIMethod' => 'PhabricatorEditEngineAPIMethod',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ProjectQueryConduitAPIMethod' => 'ProjectConduitAPIMethod',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'ProjectRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Fix project hashtag regexp to stop matching terminal periods Summary: Fixes T6416. The comment is consistent with intent, but the actual regexp doesn't quite work right. In particular, we incorrectly match `#security.` as `security.` (with a period) instead of `security` (with no period). Since this stuff is a pain to test and I evidently got it wrong in this case in D8703, make it unit testable. Test Plan: Added unit tests. Also: {F227181} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T6416 Differential Revision: https://secure.phabricator.com/D10753
2014-10-29 16:13:38 +01:00
'ProjectRemarkupRuleTestCase' => 'PhabricatorTestCase',
Projects - add mail to project updates Summary: ...which lets all the fancy settings for Email | Notify | Off be possible. Fixes T8164. Wasn't too sure the best way to break things up but members vs watchers felt meaningful to break out to me. Also fixes a small bug where we were generating bad slug updated stories by messing with the signature of the slug data. Perhaps this fix isn't even good enough (the array_keys()) call and instead we'll need to implement transaction has effect and do a sort? Test Plan: used ./bin/mail list-outbound and ./bin/mail show-outbound --id XX to verify reasonable emails were being generated. saw new preferences in settings. Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T8164 Differential Revision: https://secure.phabricator.com/D12868
2015-05-16 01:33:31 +02:00
'ProjectReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Implement a basic project.search third-generation API method Summary: Ref T10010. This still needs support for attachments (to get members) and more constraints (like slugs), but mostly works. Test Plan: Ran query, saw basically sensible results. Reviewers: chad Reviewed By: chad Maniphest Tasks: T10010 Differential Revision: https://secure.phabricator.com/D14889
2015-12-27 11:44:07 +01:00
'ProjectSearchConduitAPIMethod' => 'PhabricatorSearchEngineAPIMethod',
Move qsprintf() test cases from libphutil to Phabricator Summary: Also move the other tests up so they'll trigger when this stuff is touched. Test Plan: liberate Reviewers: nh, btrahan, vrana Reviewed By: nh CC: aran Maniphest Tasks: T1283 Differential Revision: https://secure.phabricator.com/D3074
2012-07-26 21:01:47 +02:00
'QueryFormattingTestCase' => 'PhabricatorTestCase',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephAuthorFieldSpecification' => 'ReleephFieldSpecification',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'ReleephBranch' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'ReleephDAO',
Transactions - deploy buildTransactionTimeline to remaining applications Summary: Ref T4712. Specifically... - Differential - needed getApplicationTransactionViewObject() implemented - Audit - needed getApplicationTransactionViewObject() implemented - Repository - one object needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) - Ponder - BONUS BUG FIX - leaving a comment on an answer had a bad redirect URI - both PonderQuestion and PonderAnswer needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on both "history" controllers - left a "TODO" on buildAnswers on the question view controller, which is non-standard and should be re-written eventually - Phortune - BONUS BUG FIX - fix new user "createNewAccount" code to not fatal - PhortuneAccount, PhortuneMerchant, and PhortuneCart needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on Account view, merchant view, and cart view controller - Fund - Legalpad - Nuance - NuanceSource needed PhabricatorApplicationTransactionInterface implemented - Releeph (this product is kind of a mess...) - HACKQUEST - had to manually create an arcanist project to even be able to make a "product" and get started...! - BONUS BUG FIX - make sure to "setName" on product edit - ReleephProject (should be ReleepProduct...?), ReleephBranch, and ReleepRequest needed PhabricatorApplicationTransactionInterface implemented - Harbormaster - HarbormasterBuildable, HarbormasterBuild, HarbormasterBuildPlan, and HarbormasterBuildStep all needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) all over the place Test Plan: foreach application, viewed the timeline(s) and made sure they still rendered Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10925
2014-12-04 00:35:47 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
Use application PHIDs in Releeph, plus more Summary: Ref T2715. Ref T3551. Ref T603. This does a few things, but they're all sort of small: - We commonly use a `getX()` / `attachX()` pattern, but have very similar code in the `getX()` method every time. Provide a convenience method to make this pattern easier to write. - We use `willFilterPage()` in many queries, but it currently is called with zero or more results. This means we have a lot of "if no results, return nothing" boilerplate. Make it call only for one or more results. - Implement `PhabricatorPolicyInterface` on `ReleephBranch`. A branch has the same policy as its project. - Implement `ReleephBranchQuery`. - Move the branch PHID type to application PHID infrastructure. Test Plan: Browsed Releeph. Used `phid.query` to query branch PHIDs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2715, T3551 Differential Revision: https://secure.phabricator.com/D6512
2013-07-21 18:27:00 +02:00
),
Move Releeph branch controllers toward a modern/stable state Summary: Ref T3644. Ref T3657. Ref T3549. Basically: - Move these controllers to modern query/policy infrastructure. - Move them to consistent, ID-based URIs. - Rename "Project" to "Product"; "Pick Request" to "Pull Request". - Clean up a few UI things here and there. Test Plan: - Created and edited branches. - Opened and closed branches. - Viewed branch history. - Searched within a branch. - Browsed to branches from products. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3644, T3549, T3657 Differential Revision: https://secure.phabricator.com/D8646
2014-04-13 01:53:51 +02:00
'ReleephBranchAccessController' => 'ReleephBranchController',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephBranchCommitFieldSpecification' => 'ReleephFieldSpecification',
Move Releeph branch controllers toward a modern/stable state Summary: Ref T3644. Ref T3657. Ref T3549. Basically: - Move these controllers to modern query/policy infrastructure. - Move them to consistent, ID-based URIs. - Rename "Project" to "Product"; "Pick Request" to "Pull Request". - Clean up a few UI things here and there. Test Plan: - Created and edited branches. - Opened and closed branches. - Viewed branch history. - Searched within a branch. - Browsed to branches from products. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3644, T3549, T3657 Differential Revision: https://secure.phabricator.com/D8646
2014-04-13 01:53:51 +02:00
'ReleephBranchController' => 'ReleephController',
'ReleephBranchCreateController' => 'ReleephProductController',
'ReleephBranchEditController' => 'ReleephBranchController',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephBranchEditor' => 'PhabricatorEditor',
Move Releeph branch controllers toward a modern/stable state Summary: Ref T3644. Ref T3657. Ref T3549. Basically: - Move these controllers to modern query/policy infrastructure. - Move them to consistent, ID-based URIs. - Rename "Project" to "Product"; "Pick Request" to "Pull Request". - Clean up a few UI things here and there. Test Plan: - Created and edited branches. - Opened and closed branches. - Viewed branch history. - Searched within a branch. - Browsed to branches from products. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3644, T3549, T3657 Differential Revision: https://secure.phabricator.com/D8646
2014-04-13 01:53:51 +02:00
'ReleephBranchHistoryController' => 'ReleephBranchController',
Use ApplicationSearch in Releeph project list Summary: Ref T3092. Convert Releeph project list to ApplicationSearch. Test Plan: {F50333} Reviewers: btrahan, edward Reviewed By: edward CC: aran Maniphest Tasks: T3092 Differential Revision: https://secure.phabricator.com/D6474
2013-07-21 17:44:53 +02:00
'ReleephBranchNamePreviewController' => 'ReleephController',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'ReleephBranchPHIDType' => 'PhabricatorPHIDType',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephBranchPreviewView' => 'AphrontFormControl',
Use application PHIDs in Releeph, plus more Summary: Ref T2715. Ref T3551. Ref T603. This does a few things, but they're all sort of small: - We commonly use a `getX()` / `attachX()` pattern, but have very similar code in the `getX()` method every time. Provide a convenience method to make this pattern easier to write. - We use `willFilterPage()` in many queries, but it currently is called with zero or more results. This means we have a lot of "if no results, return nothing" boilerplate. Make it call only for one or more results. - Implement `PhabricatorPolicyInterface` on `ReleephBranch`. A branch has the same policy as its project. - Implement `ReleephBranchQuery`. - Move the branch PHID type to application PHID infrastructure. Test Plan: Browsed Releeph. Used `phid.query` to query branch PHIDs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2715, T3551 Differential Revision: https://secure.phabricator.com/D6512
2013-07-21 18:27:00 +02:00
'ReleephBranchQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Use ApplicationSearch for Releeph branch lists Summary: Releeph branch lists in project views have a bunch of custom UI right now; give them more standard UI and ApplicationSearch. This drops a small piece of functionality: we now show only a total open request count instead of a detailed enumeration of each request status. I assume this is reasonable (that is, the important piece is "is there something to do on this branch?"), but we can muck with it if the more detailed status is important. Test Plan: {F54344} Reviewers: btrahan Reviewed By: btrahan CC: LegNeato, aran Maniphest Tasks: T3656 Differential Revision: https://secure.phabricator.com/D6764
2013-08-17 03:55:35 +02:00
'ReleephBranchSearchEngine' => 'PhabricatorApplicationSearchEngine',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'ReleephBranchTemplate' => 'Phobject',
Remove ReleephBranchBoxView Summary: Ref T3092. This was obsoleted recently and has no more call/use sites. Test Plan: `grep` Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3092 Differential Revision: https://secure.phabricator.com/D6779
2013-08-20 18:31:27 +02:00
'ReleephBranchTransaction' => 'PhabricatorApplicationTransaction',
Provide a history controller for Releeph branches Summary: Ref T3663. Same as D6785, but for branches. No writes to this table yet. Test Plan: Clicked "View History", got a blank but non-broken page. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3663 Differential Revision: https://secure.phabricator.com/D6787
2013-08-20 19:11:52 +02:00
'ReleephBranchTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Fix some Releeph jankiness in interacting with the redesign Summary: Releeph does some really old sketchy stuff in result rendering. Modernize it, remove the holdover/oldschool interface (these were the last two implementors) and make errors a little softer. Test Plan: Viewed Releeph products and branches. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D13604
2015-07-08 17:10:58 +02:00
'ReleephBranchViewController' => 'ReleephBranchController',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'ReleephCommitFinder' => 'Phobject',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephCommitFinderException' => 'Exception',
'ReleephCommitMessageFieldSpecification' => 'ReleephFieldSpecification',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ReleephConduitAPIMethod' => 'ConduitAPIMethod',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephController' => 'PhabricatorController',
'ReleephDAO' => 'PhabricatorLiskDAO',
'ReleephDefaultFieldSelector' => 'ReleephFieldSelector',
Add dependencies to releeph Summary: Add the 'Depends On' field to releeph requests. This will help the release engineers to be aware of the dependencies and make sure pick them altogether. Test Plan: Check sandbox. This field shows up when a revision has some dependencies. Reviewers: JoelB, lifeihuang, epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7946
2014-01-14 03:18:26 +01:00
'ReleephDependsOnFieldSpecification' => 'ReleephFieldSpecification',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephDiffChurnFieldSpecification' => 'ReleephFieldSpecification',
'ReleephDiffMessageFieldSpecification' => 'ReleephFieldSpecification',
'ReleephDiffSizeFieldSpecification' => 'ReleephFieldSpecification',
'ReleephFieldParseException' => 'Exception',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'ReleephFieldSelector' => 'Phobject',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'ReleephFieldSpecification' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorCustomField',
'PhabricatorMarkupInterface',
Partially move Releeph custom fields to PhabricatorCustomField Summary: Fixes T3661. Ref T3718. This makes Releeph custom fields extend PhabricatorCustomField so we can start moving over other pieces of infrastructure (rendering, storage, etc) to run through the same pathways. It's roughly the minimum amount of work required to be able to move forward. NOTE: This removes per-project custom field selectors. Fields are now configured for an entire install. My understanding is that Facebook does not use this feature, and modern field infrastructure has moved away from selectors. Test Plan: Viewed and edited projects, branches, and requests in Releeph. Grepped for removed config. Grepped for `field_selector`. Reviewers: btrahan Reviewed By: btrahan CC: LegNeato, aran Maniphest Tasks: T3661, T3718 Differential Revision: https://secure.phabricator.com/D6750
2013-08-14 17:58:54 +02:00
),
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ReleephGetBranchesConduitAPIMethod' => 'ReleephConduitAPIMethod',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephIntentFieldSpecification' => 'ReleephFieldSpecification',
'ReleephLevelFieldSpecification' => 'ReleephFieldSpecification',
'ReleephOriginalCommitFieldSpecification' => 'ReleephFieldSpecification',
Modernize Releeph "Product Activate" controller Summary: Ref T3549. A few things here: - Releeph has an object called a "Project". We'd like to call this a "Product" instead. See T3549. Rename easy instances that don't break URIs. - Releeph has a "ProjectController" which tries to be smart about loading objects. However, it's big and messy and doesn't have the finesse to do policies or `needX(...)` correctly. It also generates URIs which collide with one another. Introduce "ProductController" to start to move away from it. - Some small modernizations to this controller to take advantage of newer infrastructure (like easier dialog rendering). Test Plan: Deactivated and reactivated products. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8632
2014-03-29 17:14:44 +01:00
'ReleephProductActionController' => 'ReleephProductController',
'ReleephProductController' => 'ReleephController',
Remove ReleephProjectController Summary: Ref T3657. General changes here: - Removes `ReleephProjectController`, which is the source of T3657. - Mostly moves requests from "RQ" as a monogram to "Y" (looks like a merge, mnemonic for "yank"?, we don't have too many characters left). This should be essentially only cosmetic. This reduces ambiguity with "rQ" and "R123", which are current and future repository monograms. This will continue in the next few diffs. - Makes requests implement policies correctly. Test Plan: Created, edited, browsed requests. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3657 Differential Revision: https://secure.phabricator.com/D8766
2014-04-14 21:06:56 +02:00
'ReleephProductCreateController' => 'ReleephProductController',
Rename project -> product on edit/create UIs Summary: Ref T3092. Ref T3549. Modernize the product creation and edit UIs and make them say "product" instead of "project". Test Plan: - Created products. - Edited products. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3092, T3549 Differential Revision: https://secure.phabricator.com/D8636
2014-03-29 17:16:40 +01:00
'ReleephProductEditController' => 'ReleephProductController',
Use ApplicationTransactions for Releeph product activity Summary: Ref T3549. Ref T3663. - Use transactions for activate/deactivate. - Rename some "project" -> "product". Test Plan: - Activated products. - Deactivated products. {F135480} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3663, T3549 Differential Revision: https://secure.phabricator.com/D8634
2014-03-29 17:16:02 +01:00
'ReleephProductEditor' => 'PhabricatorApplicationTransactionEditor',
'ReleephProductHistoryController' => 'ReleephProductController',
Move even more rendering into SearchEngine Summary: Ref T4986. I think this is the last of the easy ones, there are about 10 not-quite-so-trivial ones left. Test Plan: - Viewed app results. - Created panels. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9025
2014-05-09 21:28:02 +02:00
'ReleephProductListController' => 'ReleephController',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'ReleephProductPHIDType' => 'PhabricatorPHIDType',
Rename ReleephProjectQuery to ReleephProductQuery Summary: Ref T3549. Test Plan: grep/lint Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8815
2014-04-20 20:51:02 +02:00
'ReleephProductQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Rename more project -> product in Releeph Summary: Ref T3549. - Renames most "project" in view/list controllers. - Moves away from "ProjectController". - Modernizes some modern UI. Test Plan: - Viewed product lists. - Viewed product detail pages. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8635
2014-03-29 17:16:24 +01:00
'ReleephProductSearchEngine' => 'PhabricatorApplicationSearchEngine',
Rename Releeph "Project" transactions to "Product" Summary: Ref T3549. This table isn't written to yet; rename it and the DAOs and modernize the history controller. Test Plan: Viewed history page for a product. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8633
2014-03-29 17:15:09 +01:00
'ReleephProductTransaction' => 'PhabricatorApplicationTransaction',
'ReleephProductTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Fix some Releeph jankiness in interacting with the redesign Summary: Releeph does some really old sketchy stuff in result rendering. Modernize it, remove the holdover/oldschool interface (these were the last two implementors) and make errors a little softer. Test Plan: Viewed Releeph products and branches. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D13604
2015-07-08 17:10:58 +02:00
'ReleephProductViewController' => 'ReleephProductController',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'ReleephProject' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'ReleephDAO',
Transactions - deploy buildTransactionTimeline to remaining applications Summary: Ref T4712. Specifically... - Differential - needed getApplicationTransactionViewObject() implemented - Audit - needed getApplicationTransactionViewObject() implemented - Repository - one object needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) - Ponder - BONUS BUG FIX - leaving a comment on an answer had a bad redirect URI - both PonderQuestion and PonderAnswer needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on both "history" controllers - left a "TODO" on buildAnswers on the question view controller, which is non-standard and should be re-written eventually - Phortune - BONUS BUG FIX - fix new user "createNewAccount" code to not fatal - PhortuneAccount, PhortuneMerchant, and PhortuneCart needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on Account view, merchant view, and cart view controller - Fund - Legalpad - Nuance - NuanceSource needed PhabricatorApplicationTransactionInterface implemented - Releeph (this product is kind of a mess...) - HACKQUEST - had to manually create an arcanist project to even be able to make a "product" and get started...! - BONUS BUG FIX - make sure to "setName" on product edit - ReleephProject (should be ReleepProduct...?), ReleephBranch, and ReleepRequest needed PhabricatorApplicationTransactionInterface implemented - Harbormaster - HarbormasterBuildable, HarbormasterBuild, HarbormasterBuildPlan, and HarbormasterBuildStep all needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) all over the place Test Plan: foreach application, viewed the timeline(s) and made sure they still rendered Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10925
2014-12-04 00:35:47 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
Introduce ReleephProjectQuery Summary: Adds a policy-aware query class for selecting Releeph projects. This doesn't really change anything. - Make `ReleephProject` implment `PhabricatorPolicyInterface`, beginning the long journey to make it policy-aware. - Implement `ReleephProjectQuery`, for querying projects using cursor-based, policy-aware paging. - Use it on the list view, so we load only ~100 projects instead of all of them. - Tweaked some of the URI routing stuff to make it a little more consistent with common practices. Ref T2714. Test Plan: {F36434} {F36435} Reviewers: edward Reviewed By: edward CC: aran Maniphest Tasks: T2714 Differential Revision: https://secure.phabricator.com/D5390
2013-03-22 14:29:37 +01:00
),
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ReleephQueryBranchesConduitAPIMethod' => 'ReleephConduitAPIMethod',
'ReleephQueryProductsConduitAPIMethod' => 'ReleephConduitAPIMethod',
'ReleephQueryRequestsConduitAPIMethod' => 'ReleephConduitAPIMethod',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephReasonFieldSpecification' => 'ReleephFieldSpecification',
Fix HTTP 400 from notification server for JSON subscription objects Summary: Fixes T5651. Sometime we'll send an object to the notification server for `subscribers`, which it will choke on. Use `array_values()` to make sure we're sending an array. Test Plan: With `(object)` instead, got a consistent error ("no .filter method on object"). With `array_values()`, no error. Reviewers: joshuaspence Reviewed By: joshuaspence Subscribers: epriestley Maniphest Tasks: T5651 Differential Revision: https://secure.phabricator.com/D9963
2014-07-17 23:48:54 +02:00
'ReleephRequest' => array(
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'ReleephDAO',
Transactions - deploy buildTransactionTimeline to remaining applications Summary: Ref T4712. Specifically... - Differential - needed getApplicationTransactionViewObject() implemented - Audit - needed getApplicationTransactionViewObject() implemented - Repository - one object needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) - Ponder - BONUS BUG FIX - leaving a comment on an answer had a bad redirect URI - both PonderQuestion and PonderAnswer needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on both "history" controllers - left a "TODO" on buildAnswers on the question view controller, which is non-standard and should be re-written eventually - Phortune - BONUS BUG FIX - fix new user "createNewAccount" code to not fatal - PhortuneAccount, PhortuneMerchant, and PhortuneCart needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) on Account view, merchant view, and cart view controller - Fund - Legalpad - Nuance - NuanceSource needed PhabricatorApplicationTransactionInterface implemented - Releeph (this product is kind of a mess...) - HACKQUEST - had to manually create an arcanist project to even be able to make a "product" and get started...! - BONUS BUG FIX - make sure to "setName" on product edit - ReleephProject (should be ReleepProduct...?), ReleephBranch, and ReleepRequest needed PhabricatorApplicationTransactionInterface implemented - Harbormaster - HarbormasterBuildable, HarbormasterBuild, HarbormasterBuildPlan, and HarbormasterBuildStep all needed PhabricatorApplicationTransactionInterface implemented - setShouldTerminate(true) all over the place Test Plan: foreach application, viewed the timeline(s) and made sure they still rendered Reviewers: epriestley Reviewed By: epriestley Subscribers: Korvin, epriestley Maniphest Tasks: T4712 Differential Revision: https://secure.phabricator.com/D10925
2014-12-04 00:35:47 +01:00
'PhabricatorApplicationTransactionInterface',
Rename `PhabricatorDestructableInterface` interface Summary: Ref T5655. The `PhabricatorDestructibleInterface` interface is misspelled as `PhabricatorDestructableInterface`. Fix the spelling mistake. Test Plan: `grep`. Seeing as this interface is fairly recent, I don't expect that this would cause any widespread breakages. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9988
2014-07-21 15:59:22 +02:00
'PhabricatorPolicyInterface',
'PhabricatorCustomFieldInterface',
Add get Releeph Requests conduit method Summary: Added "getrequests" conduit method Test Plan: Open /conduit/method/differential.getrequests/ and try different inputs. Reviewers: edward, epriestley Reviewed By: edward CC: aran, epriestley, Korvin Maniphest Tasks: T3057 Differential Revision: https://secure.phabricator.com/D5788
2013-04-26 18:07:38 +02:00
),
Remove ReleephProjectController Summary: Ref T3657. General changes here: - Removes `ReleephProjectController`, which is the source of T3657. - Mostly moves requests from "RQ" as a monogram to "Y" (looks like a merge, mnemonic for "yank"?, we don't have too many characters left). This should be essentially only cosmetic. This reduces ambiguity with "rQ" and "R123", which are current and future repository monograms. This will continue in the next few diffs. - Makes requests implement policies correctly. Test Plan: Created, edited, browsed requests. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3657 Differential Revision: https://secure.phabricator.com/D8766
2014-04-14 21:06:56 +02:00
'ReleephRequestActionController' => 'ReleephRequestController',
'ReleephRequestCommentController' => 'ReleephRequestController',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ReleephRequestConduitAPIMethod' => 'ReleephConduitAPIMethod',
Remove ReleephProjectController Summary: Ref T3657. General changes here: - Removes `ReleephProjectController`, which is the source of T3657. - Mostly moves requests from "RQ" as a monogram to "Y" (looks like a merge, mnemonic for "yank"?, we don't have too many characters left). This should be essentially only cosmetic. This reduces ambiguity with "rQ" and "R123", which are current and future repository monograms. This will continue in the next few diffs. - Makes requests implement policies correctly. Test Plan: Created, edited, browsed requests. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3657 Differential Revision: https://secure.phabricator.com/D8766
2014-04-14 21:06:56 +02:00
'ReleephRequestController' => 'ReleephController',
'ReleephRequestDifferentialCreateController' => 'ReleephController',
'ReleephRequestEditController' => 'ReleephBranchController',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ReleephRequestMailReceiver' => 'PhabricatorObjectMailReceiver',
Rename `PHIDType` classes Summary: Ref T5655. Rename `PhabricatorPHIDType` subclasses for clarity (see discussion in D9839). I'm not too keen on some of the resulting class names, so feel free to suggest alternatives. Test Plan: Ran unit tests. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9986
2014-07-24 00:05:46 +02:00
'ReleephRequestPHIDType' => 'PhabricatorPHIDType',
Add unit tests to cover PhabricatorMailReceiver::matchAddresses() Summary: Ref T3183. We should accept addresses like `"New Bug" <bugs@example.com>` to match `bugs@example.com`. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3183 Differential Revision: https://secure.phabricator.com/D5923
2013-05-15 00:04:17 +02:00
'ReleephRequestQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Subclass most ReplyHandlers from TransactionReplyHandler Summary: Ref T7199. Half of these aren't even reachable, but make some progress toward reducing the amount of nonsense and garbage in mail handling. Test Plan: Tested all reachable handlers with `bin/mail receive-test`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T7199 Differential Revision: https://secure.phabricator.com/D12237
2015-04-01 17:39:50 +02:00
'ReleephRequestReplyHandler' => 'PhabricatorApplicationTransactionReplyHandler',
Use ApplicationSearch in ReleephBranchView Summary: Ref T3721. Releeph currently attempts to implement a flexible, field-driven search for branches, but it's building all of its own infrastructure and it ends up heading down some weird paths. In particular, it loads **every** request and then makes calls into fields to filter them. It also tries to be very very general, which isn't really necessary (for example, I think it's reasonable for us to assume that we won't let you disable the "requestor" field). ApplicationSearch and CustomField provide more scalable approaches to this problem; move search on top of them. The query still ends up doing some filtering in-process, but it's now far more limited in scope and can be denormalized later. Test Plan: {F54304} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T3721 Differential Revision: https://secure.phabricator.com/D6758
2013-08-15 00:38:52 +02:00
'ReleephRequestSearchEngine' => 'PhabricatorApplicationSearchEngine',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'ReleephRequestStatus' => 'Phobject',
ReleephRequest xactions Summary: Migrate to `PhabricatorApplicationTransactions` (`ReleephRequestTransactions` applied by `ReleephRequestTransactionalEditor`, instead of `ReleephRequestEvents` created by `ReleephRequestEditor`) and migrate all the old events into transactions. Email is supported in the standard way (no more `ReleephRequestMail`) as well. This also collapses the Releeph request create and edit controllers into one class, as well as breaking everyone's subject-based mail rules by standardising them (but which should be more easily filtered by looking at headers.) Test Plan: * Make requests, then pick them. * Pick and revert the same request so that discovery happens way after `arc` has told Releeph about what's been happening. * Try to pick something that fails to pick in a project with pick instructions (and see the instructions are in the email.) * Load all of FB's Releeph data into my DB and run the `storage upgrade` script. * Request a commit via the "action" in a Differential revision. Reviewers: epriestley Reviewed By: epriestley CC: epriestley, aran, Korvin, wez Maniphest Tasks: T3092, T2720 Differential Revision: https://secure.phabricator.com/D5868
2013-04-08 17:34:21 +02:00
'ReleephRequestTransaction' => 'PhabricatorApplicationTransaction',
'ReleephRequestTransactionComment' => 'PhabricatorApplicationTransactionComment',
'ReleephRequestTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'ReleephRequestTransactionalEditor' => 'PhabricatorApplicationTransactionEditor',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephRequestTypeaheadControl' => 'AphrontFormControl',
'ReleephRequestTypeaheadController' => 'PhabricatorTypeaheadDatasourceController',
Use standard UI elements to render pull requests in Releeph Summary: Ref T3718. Ref T3644. Ref T3092. Switches from the Releeph UI elements to standard ones. I'll attach some screenshots. Also fixes CSRF against the request action endpoint. Test Plan: - Viewed request details. - Took actions on a request from detail page. - Viewed request list. - Took actions on a request from list page. - Used keyboard shortcuts to navigate list. - Used keyboard shortcuts to take actions. - Simulated errors. - Viewed on devices. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: grp, FacebookPOC, mattlqx, tala, beng, LegNeato, epriestley Maniphest Tasks: T3718, T3092, T3644 Differential Revision: https://secure.phabricator.com/D8771
2014-04-18 15:44:45 +02:00
'ReleephRequestView' => 'AphrontView',
Remove ReleephProjectController Summary: Ref T3657. General changes here: - Removes `ReleephProjectController`, which is the source of T3657. - Mostly moves requests from "RQ" as a monogram to "Y" (looks like a merge, mnemonic for "yank"?, we don't have too many characters left). This should be essentially only cosmetic. This reduces ambiguity with "rQ" and "R123", which are current and future repository monograms. This will continue in the next few diffs. - Makes requests implement policies correctly. Test Plan: Created, edited, browsed requests. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3657 Differential Revision: https://secure.phabricator.com/D8766
2014-04-14 21:06:56 +02:00
'ReleephRequestViewController' => 'ReleephBranchController',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephRequestorFieldSpecification' => 'ReleephFieldSpecification',
'ReleephRevisionFieldSpecification' => 'ReleephFieldSpecification',
'ReleephSeverityFieldSpecification' => 'ReleephLevelFieldSpecification',
'ReleephSummaryFieldSpecification' => 'ReleephFieldSpecification',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'ReleephWorkCanPushConduitAPIMethod' => 'ReleephConduitAPIMethod',
'ReleephWorkGetAuthorInfoConduitAPIMethod' => 'ReleephConduitAPIMethod',
'ReleephWorkGetBranchCommitMessageConduitAPIMethod' => 'ReleephConduitAPIMethod',
'ReleephWorkGetBranchConduitAPIMethod' => 'ReleephConduitAPIMethod',
'ReleephWorkGetCommitMessageConduitAPIMethod' => 'ReleephConduitAPIMethod',
'ReleephWorkNextRequestConduitAPIMethod' => 'ReleephConduitAPIMethod',
'ReleephWorkRecordConduitAPIMethod' => 'ReleephConduitAPIMethod',
'ReleephWorkRecordPickStatusConduitAPIMethod' => 'ReleephConduitAPIMethod',
'RemarkupProcessConduitAPIMethod' => 'ConduitAPIMethod',
'RepositoryConduitAPIMethod' => 'ConduitAPIMethod',
'RepositoryQueryConduitAPIMethod' => 'RepositoryConduitAPIMethod',
Implemented support for build logs Summary: Depends on D7519. This implements support for build logs in Harbormaster. This includes support for appending to a log from the "Run Remote Command" build step. It also adds the ability to cancel builds. Currently the build view page doesn't update the logs live; I'm sure this can be achieved with Javelin, but I don't have enough experience with Javelin to actually make it poll from updates to content in the background. {F79151} {F79153} {F79150} {F79152} Test Plan: Tested this by setting up SSH on a Windows machine and using a Remote Command configured with: ``` C:\Windows\system32\cmd.exe /C cd C:\Build && mkdir Build_${timestamp} && cd Build_${timestamp} && git clone --recursive https://github.com/hach-que/Tychaia.git && cd Tychaia && Protobuild.exe && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Tychaia.Windows.sln ``` and observed the output of the build stream from the Windows machine into Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7521
2013-11-09 03:09:03 +01:00
'ShellLogView' => 'AphrontView',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'SlowvoteConduitAPIMethod' => 'ConduitAPIMethod',
v0 embedding slowvotes Summary: Slowvotes can now be embed using {V*} syntax. Nothing fancy there yet. Test Plan: {F40842} Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2883 Differential Revision: https://secure.phabricator.com/D5713
2013-04-16 17:18:52 +02:00
'SlowvoteEmbedView' => 'AphrontView',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'SlowvoteInfoConduitAPIMethod' => 'SlowvoteConduitAPIMethod',
Rename `PhutilRemarkupRule` subclasses Summary: Ref T5655. Depends on D9993. Test Plan: See D9993. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9994
2014-08-04 16:55:43 +02:00
'SlowvoteRemarkupRule' => 'PhabricatorObjectRemarkupRule',
Extend from Phobject Summary: All classes should extend from some other class. See D13275 for some explanation. Test Plan: `arc unit` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 10:02:26 +02:00
'SubscriptionListDialogBuilder' => 'Phobject',
'SubscriptionListStringBuilder' => 'Phobject',
Rename Conduit classes Summary: Ref T5655. Rename Conduit classes and provide a `getAPIMethodName` method to declare the API method. Test Plan: ``` > echo '{}' | arc --conduit-uri='http://phabricator.joshuaspence.com' call-conduit user.whoami Waiting for JSON parameters on stdin... {"error":null,"errorMessage":null,"response":{"phid":"PHID-USER-lioqffnwn6y475mu5ndb","userName":"josh","realName":"Joshua Spence","image":"http:\/\/phabricator.joshuaspence.com\/res\/1404425321T\/phabricator\/3eb28cd9\/rsrc\/image\/avatar.png","uri":"http:\/\/phabricator.joshuaspence.com\/p\/josh\/","roles":["admin","verified","approved","activated"]}} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin, hach-que Maniphest Tasks: T5655 Differential Revision: https://secure.phabricator.com/D9991
2014-07-25 02:54:15 +02:00
'TokenConduitAPIMethod' => 'ConduitAPIMethod',
'TokenGiveConduitAPIMethod' => 'TokenConduitAPIMethod',
'TokenGivenConduitAPIMethod' => 'TokenConduitAPIMethod',
'TokenQueryConduitAPIMethod' => 'TokenConduitAPIMethod',
'UserConduitAPIMethod' => 'ConduitAPIMethod',
'UserDisableConduitAPIMethod' => 'UserConduitAPIMethod',
'UserEnableConduitAPIMethod' => 'UserConduitAPIMethod',
'UserFindConduitAPIMethod' => 'UserConduitAPIMethod',
'UserQueryConduitAPIMethod' => 'UserConduitAPIMethod',
'UserWhoAmIConduitAPIMethod' => 'UserConduitAPIMethod',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
),
));
Copy permalink