revi-archive/phorge-phorge
1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-26 07:20:57 +01:00
Code Issues Releases Wiki Activity
phorge-phorge/src/__phutil_library_map__.php

2163 lines
178 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.
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,
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'class' =>
array(
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontAttachedFileView' => 'view/control/AphrontAttachedFileView.php',
'AphrontCSRFException' => 'aphront/exception/AphrontCSRFException.php',
'AphrontCalendarEventView' => 'applications/calendar/view/AphrontCalendarEventView.php',
'AphrontCalendarMonthView' => 'applications/calendar/view/AphrontCalendarMonthView.php',
'AphrontContextBarView' => 'view/layout/AphrontContextBarView.php',
'AphrontController' => 'aphront/AphrontController.php',
'AphrontCrumbsView' => 'view/layout/AphrontCrumbsView.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',
'AphrontErrorView' => 'view/form/AphrontErrorView.php',
'AphrontException' => 'aphront/exception/AphrontException.php',
'AphrontFilePreviewView' => 'view/layout/AphrontFilePreviewView.php',
'AphrontFileResponse' => 'aphront/response/AphrontFileResponse.php',
'AphrontFormCheckboxControl' => 'view/form/control/AphrontFormCheckboxControl.php',
'AphrontFormControl' => 'view/form/control/AphrontFormControl.php',
'AphrontFormDateControl' => 'view/form/control/AphrontFormDateControl.php',
'AphrontFormDividerControl' => 'view/form/control/AphrontFormDividerControl.php',
'AphrontFormDragAndDropUploadControl' => 'view/form/control/AphrontFormDragAndDropUploadControl.php',
'AphrontFormFileControl' => 'view/form/control/AphrontFormFileControl.php',
Robustify profile image controls ever so slightly Summary: show project profile image on pertinent edit page. also add a "Use Default Image" checkbox for both project and user profiles. Also added a function for projects to get the profile picture to prevent some copy + paste action. Test Plan: set my user profile and project profile image. clicked "Use Default Image" and got the default image back. Reviewers: epriestley, floatinglomas Reviewed By: floatinglomas CC: aran, Korvin Maniphest Tasks: T1307 Differential Revision: https://secure.phabricator.com/D2852
2012-06-26 17:14:15 +02:00
'AphrontFormImageControl' => 'view/form/control/AphrontFormImageControl.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontFormInsetView' => 'view/form/AphrontFormInsetView.php',
'AphrontFormLayoutView' => 'view/form/AphrontFormLayoutView.php',
'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',
'AphrontFormToggleButtonsControl' => 'view/form/control/AphrontFormToggleButtonsControl.php',
'AphrontFormTokenizerControl' => 'view/form/control/AphrontFormTokenizerControl.php',
'AphrontFormView' => 'view/form/AphrontFormView.php',
'AphrontHTTPSink' => 'aphront/sink/AphrontHTTPSink.php',
'AphrontHTTPSinkTestCase' => 'aphront/sink/__tests__/AphrontHTTPSinkTestCase.php',
'AphrontHeadsupActionListView' => 'view/layout/headsup/AphrontHeadsupActionListView.php',
'AphrontHeadsupActionView' => 'view/layout/headsup/AphrontHeadsupActionView.php',
'AphrontHeadsupView' => 'view/layout/headsup/AphrontHeadsupView.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',
'AphrontMiniPanelView' => 'view/layout/AphrontMiniPanelView.php',
'AphrontMoreView' => 'view/layout/AphrontMoreView.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',
'AphrontPHPHTTPSink' => 'aphront/sink/AphrontPHPHTTPSink.php',
'AphrontPageView' => 'view/page/AphrontPageView.php',
'AphrontPagerView' => 'view/control/AphrontPagerView.php',
'AphrontPanelView' => 'view/layout/AphrontPanelView.php',
'AphrontPlainTextResponse' => 'aphront/response/AphrontPlainTextResponse.php',
'AphrontProxyResponse' => 'aphront/response/AphrontProxyResponse.php',
'AphrontRedirectException' => 'aphront/exception/AphrontRedirectException.php',
'AphrontRedirectResponse' => 'aphront/response/AphrontRedirectResponse.php',
'AphrontReloadResponse' => 'aphront/response/AphrontReloadResponse.php',
'AphrontRequest' => 'aphront/AphrontRequest.php',
'AphrontRequestFailureView' => 'view/page/AphrontRequestFailureView.php',
'AphrontRequestTestCase' => 'aphront/__tests__/AphrontRequestTestCase.php',
'AphrontResponse' => 'aphront/response/AphrontResponse.php',
'AphrontSideNavFilterView' => 'view/layout/AphrontSideNavFilterView.php',
'AphrontSideNavView' => 'view/layout/AphrontSideNavView.php',
'AphrontTableView' => 'view/control/AphrontTableView.php',
'AphrontTokenizerTemplateView' => 'view/control/AphrontTokenizerTemplateView.php',
'AphrontTypeaheadTemplateView' => 'view/control/AphrontTypeaheadTemplateView.php',
'AphrontURIMapper' => 'aphront/AphrontURIMapper.php',
'AphrontUsageException' => 'aphront/exception/AphrontUsageException.php',
'AphrontView' => 'view/AphrontView.php',
'AphrontWebpageResponse' => 'aphront/response/AphrontWebpageResponse.php',
'CelerityAPI' => 'infrastructure/celerity/CelerityAPI.php',
'CelerityResourceController' => 'infrastructure/celerity/CelerityResourceController.php',
'CelerityResourceGraph' => 'infrastructure/celerity/CelerityResourceGraph.php',
'CelerityResourceMap' => 'infrastructure/celerity/CelerityResourceMap.php',
'CelerityResourceTransformer' => 'infrastructure/celerity/CelerityResourceTransformer.php',
'CelerityResourceTransformerTestCase' => 'infrastructure/celerity/__tests__/CelerityResourceTransformerTestCase.php',
'CelerityStaticResourceResponse' => 'infrastructure/celerity/CelerityStaticResourceResponse.php',
'ConduitAPIMethod' => 'applications/conduit/method/ConduitAPIMethod.php',
'ConduitAPIRequest' => 'applications/conduit/protocol/ConduitAPIRequest.php',
'ConduitAPIResponse' => 'applications/conduit/protocol/ConduitAPIResponse.php',
'ConduitAPI_arcanist_Method' => 'applications/conduit/method/arcanist/ConduitAPI_arcanist_Method.php',
'ConduitAPI_arcanist_projectinfo_Method' => 'applications/conduit/method/arcanist/ConduitAPI_arcanist_projectinfo_Method.php',
'ConduitAPI_audit_Method' => 'applications/conduit/method/audit/ConduitAPI_audit_Method.php',
'ConduitAPI_audit_query_Method' => 'applications/conduit/method/audit/ConduitAPI_audit_query_Method.php',
'ConduitAPI_chatlog_Method' => 'applications/conduit/method/chatlog/ConduitAPI_chatlog_Method.php',
'ConduitAPI_chatlog_query_Method' => 'applications/conduit/method/chatlog/ConduitAPI_chatlog_query_Method.php',
'ConduitAPI_chatlog_record_Method' => 'applications/conduit/method/chatlog/ConduitAPI_chatlog_record_Method.php',
'ConduitAPI_conduit_connect_Method' => 'applications/conduit/method/conduit/ConduitAPI_conduit_connect_Method.php',
'ConduitAPI_conduit_getcertificate_Method' => 'applications/conduit/method/conduit/ConduitAPI_conduit_getcertificate_Method.php',
'ConduitAPI_conduit_ping_Method' => 'applications/conduit/method/conduit/ConduitAPI_conduit_ping_Method.php',
'ConduitAPI_daemon_launched_Method' => 'applications/conduit/method/daemon/ConduitAPI_daemon_launched_Method.php',
'ConduitAPI_daemon_log_Method' => 'applications/conduit/method/daemon/ConduitAPI_daemon_log_Method.php',
Save daemon state to database Summary: To make it easier to monitor daemons, let's store their current state (running, died, exited, or unknown) to the db. The purpose of this is to provide more information on the daemon console about the status of daemons, especially when they are running on multiple machines. This is mostly backend work, with only a few frontend changes. (It is also dependent on a change to libphutil.) These changes will make dead or stuck daemons more obvious, and will allow more work on the frontend to hide daemons (and logs) that have exited cleanly, i.e. ones we don't care about any more. Test Plan: - run db migration, check in db that all daemons were marked as exited - start up a daemon, check in db that it is marked as running - open web interface, check that daemon is listed as running - after daemon has been running for a little bit, check in db that dateModified is being updated (indicating daemon is properly sending heartbeat) - kill -9 daemon (but don't run bin/phd yet), and check that db still shows it as running - edit daemon db entry to show it as being on a different host, and backdate dateModified field by 3 minutes, and check the web ui to show that the status is unknown. - change db entry to have proper host, check in web ui that daemon status is displayed as dead. Check db to see that the status was saved. - run bin/phd stop, and see that the formerly dead daemon is now exited. Reviewers: epriestley, vrana Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3126
2012-08-02 02:06:04 +02:00
'ConduitAPI_daemon_setstatus_Method' => 'applications/conduit/method/daemon/ConduitAPI_daemon_setstatus_Method.php',
Add a "differential.createrawdiff" Conduit method Summary: "differential.creatediff" requires a mostly-parsed diff, but there's no reason we can't make DifferentialDiffs out of raw diffs. This mainly serves to lower the adoption barrier if getting "arc" distributed is too much of a hassle. Test Plan: Made a diff out of a raw block of diff text. Reviewers: ffx, vrana, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2751
2012-06-20 21:35:04 +02:00
'ConduitAPI_differential_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_Method.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ConduitAPI_differential_close_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_close_Method.php',
'ConduitAPI_differential_createcomment_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_createcomment_Method.php',
'ConduitAPI_differential_creatediff_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_creatediff_Method.php',
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
'ConduitAPI_differential_createinline_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_createinline_Method.php',
Add a "differential.createrawdiff" Conduit method Summary: "differential.creatediff" requires a mostly-parsed diff, but there's no reason we can't make DifferentialDiffs out of raw diffs. This mainly serves to lower the adoption barrier if getting "arc" distributed is too much of a hassle. Test Plan: Made a diff out of a raw block of diff text. Reviewers: ffx, vrana, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2751
2012-06-20 21:35:04 +02:00
'ConduitAPI_differential_createrawdiff_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_createrawdiff_Method.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ConduitAPI_differential_createrevision_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_createrevision_Method.php',
'ConduitAPI_differential_find_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_find_Method.php',
Add support for postponed linters Summary: This adds: 1) A new "arc:lint-postponed" diff property which stores a list of lint names that are postponed and a finishpostponedlinters conduit method which removes linters from this list. Postponed linters are shown in the lint details. 2) A updatelintmessages conduit message, which adds additional lint messages to the "arc:lint" diff property. In combination, this provides very basic support for running asynchronous static analysis tools. When the diff is being created, a list of asynchronous static analysis runs can be added to the diff's postponed linters list. As these postponed linters finish up, then can report new lint messages back to the diff then mark themselves as complete. The client is currently responsible for filtering the lint messages by things like affected lines and files. Test Plan: Used conduit call API to add lint messages and remove postponed linters from a test diff. Reviewers: epriestley, vrana, nh, jungejason Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1332 Differential Revision: https://secure.phabricator.com/D2792
2012-06-15 02:09:24 +02:00
'ConduitAPI_differential_finishpostponedlinters_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_finishpostponedlinters_Method.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ConduitAPI_differential_getalldiffs_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_getalldiffs_Method.php',
'ConduitAPI_differential_getcommitmessage_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_getcommitmessage_Method.php',
'ConduitAPI_differential_getcommitpaths_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_getcommitpaths_Method.php',
'ConduitAPI_differential_getdiff_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_getdiff_Method.php',
'ConduitAPI_differential_getrevision_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_getrevision_Method.php',
'ConduitAPI_differential_getrevisioncomments_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_getrevisioncomments_Method.php',
'ConduitAPI_differential_getrevisionfeedback_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_getrevisionfeedback_Method.php',
'ConduitAPI_differential_markcommitted_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_markcommitted_Method.php',
'ConduitAPI_differential_parsecommitmessage_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_parsecommitmessage_Method.php',
'ConduitAPI_differential_query_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_query_Method.php',
'ConduitAPI_differential_setdiffproperty_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_setdiffproperty_Method.php',
'ConduitAPI_differential_updaterevision_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_updaterevision_Method.php',
'ConduitAPI_differential_updatetaskrevisionassoc_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_updatetaskrevisionassoc_Method.php',
'ConduitAPI_differential_updateunitresults_Method' => 'applications/conduit/method/differential/ConduitAPI_differential_updateunitresults_Method.php',
'ConduitAPI_diffusion_findsymbols_Method' => 'applications/conduit/method/diffusion/ConduitAPI_diffusion_findsymbols_Method.php',
'ConduitAPI_diffusion_getcommits_Method' => 'applications/conduit/method/diffusion/ConduitAPI_diffusion_getcommits_Method.php',
'ConduitAPI_diffusion_getrecentcommitsbypath_Method' => 'applications/conduit/method/diffusion/ConduitAPI_diffusion_getrecentcommitsbypath_Method.php',
'ConduitAPI_feed_publish_Method' => 'applications/conduit/method/feed/ConduitAPI_feed_publish_Method.php',
'ConduitAPI_feed_query_Method' => 'applications/conduit/method/feed/ConduitAPI_feed_query_Method.php',
'ConduitAPI_file_download_Method' => 'applications/conduit/method/file/ConduitAPI_file_download_Method.php',
'ConduitAPI_file_info_Method' => 'applications/conduit/method/file/ConduitAPI_file_info_Method.php',
'ConduitAPI_file_upload_Method' => 'applications/conduit/method/file/ConduitAPI_file_upload_Method.php',
'ConduitAPI_flag_Method' => 'applications/conduit/method/flag/ConduitAPI_flag_Method.php',
Add a flag.delete Conduit method Summary: Fairly straightforward: allow deletion of flags from Conduit. Test Plan: Try arc call-conduit with different ids. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1556 Differential Revision: https://secure.phabricator.com/D3132
2012-08-02 21:25:01 +02:00
'ConduitAPI_flag_delete_Method' => 'applications/conduit/method/flag/ConduitAPI_flag_delete_Method.php',
Improve the flag.* Conduit methods Summary: - Put the code to generate informational dicts about flags into the base class. - Update flag.delete to accept an object PHID in order to delete the flag on that object, since currently the model is that each object may have at most one flag, and each flag has exactly one object, although the former is not enforced. - Add flag.edit, which creates or updates a flag, optionally with the given color and note. Test Plan: Spend endless hours repeatedly running arc call-conduit and arc flag. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3141
2012-08-03 20:41:33 +02:00
'ConduitAPI_flag_edit_Method' => 'applications/conduit/method/flag/ConduitAPI_flag_edit_Method.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ConduitAPI_flag_query_Method' => 'applications/conduit/method/flag/ConduitAPI_flag_query_Method.php',
'ConduitAPI_macro_Method' => 'applications/conduit/method/macro/ConduitAPI_macro_Method.php',
'ConduitAPI_macro_query_Method' => 'applications/conduit/method/macro/ConduitAPI_macro_query_Method.php',
'ConduitAPI_maniphest_Method' => 'applications/conduit/method/maniphest/ConduitAPI_maniphest_Method.php',
'ConduitAPI_maniphest_createtask_Method' => 'applications/conduit/method/maniphest/ConduitAPI_maniphest_createtask_Method.php',
'ConduitAPI_maniphest_find_Method' => 'applications/conduit/method/maniphest/ConduitAPI_maniphest_find_Method.php',
'ConduitAPI_maniphest_gettasktransactions_Method' => 'applications/conduit/method/maniphest/ConduitAPI_maniphest_gettasktransactions_Method.php',
'ConduitAPI_maniphest_info_Method' => 'applications/conduit/method/maniphest/ConduitAPI_maniphest_info_Method.php',
Add specific close status queries to maniphest.find (and rename it to maniphest.query) Summary: - Allow clients to query for specific closed statuses (invalid, resolved, wontfix, etc), not just "closed" tasks. - Rename this method to maniphest.query and deprecate maniphest.find as an alias to maniphest.query, for API consistency. Test Plan: Ran queries for all tasks, "wontfix" tasks, closed tasks. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2887
2012-06-29 18:17:19 +02:00
'ConduitAPI_maniphest_query_Method' => 'applications/conduit/method/maniphest/ConduitAPI_maniphest_query_Method.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ConduitAPI_maniphest_update_Method' => 'applications/conduit/method/maniphest/ConduitAPI_maniphest_update_Method.php',
'ConduitAPI_owners_query_Method' => 'applications/conduit/method/owners/ConduitAPI_owners_query_Method.php',
'ConduitAPI_paste_Method' => 'applications/conduit/method/paste/ConduitAPI_paste_Method.php',
'ConduitAPI_paste_create_Method' => 'applications/conduit/method/paste/ConduitAPI_paste_create_Method.php',
'ConduitAPI_paste_info_Method' => 'applications/conduit/method/paste/ConduitAPI_paste_info_Method.php',
'ConduitAPI_path_getowners_Method' => 'applications/conduit/method/path/ConduitAPI_path_getowners_Method.php',
'ConduitAPI_phid_Method' => 'applications/conduit/method/phid/ConduitAPI_phid_Method.php',
'ConduitAPI_phid_info_Method' => 'applications/conduit/method/phid/ConduitAPI_phid_info_Method.php',
Improve the flag.* Conduit methods Summary: - Put the code to generate informational dicts about flags into the base class. - Update flag.delete to accept an object PHID in order to delete the flag on that object, since currently the model is that each object may have at most one flag, and each flag has exactly one object, although the former is not enforced. - Add flag.edit, which creates or updates a flag, optionally with the given color and note. Test Plan: Spend endless hours repeatedly running arc call-conduit and arc flag. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3141
2012-08-03 20:41:33 +02:00
'ConduitAPI_phid_lookup_Method' => 'applications/conduit/method/phid/ConduitAPI_phid_lookup_Method.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ConduitAPI_phid_query_Method' => 'applications/conduit/method/phid/ConduitAPI_phid_query_Method.php',
'ConduitAPI_phriction_Method' => 'applications/conduit/method/phriction/ConduitAPI_phriction_Method.php',
'ConduitAPI_phriction_edit_Method' => 'applications/conduit/method/phriction/ConduitAPI_phriction_edit_Method.php',
'ConduitAPI_phriction_history_Method' => 'applications/conduit/method/phriction/ConduitAPI_phriction_history_Method.php',
'ConduitAPI_phriction_info_Method' => 'applications/conduit/method/phriction/ConduitAPI_phriction_info_Method.php',
'ConduitAPI_project_Method' => 'applications/conduit/method/project/ConduitAPI_project_Method.php',
'ConduitAPI_project_query_Method' => 'applications/conduit/method/project/ConduitAPI_project_query_Method.php',
'ConduitAPI_remarkup_process_Method' => 'applications/conduit/method/remarkup/ConduitAPI_remarkup_process_Method.php',
'ConduitAPI_repository_Method' => 'applications/conduit/method/repository/ConduitAPI_repository_Method.php',
'ConduitAPI_repository_create_Method' => 'applications/conduit/method/repository/ConduitAPI_repository_create_Method.php',
'ConduitAPI_repository_query_Method' => 'applications/conduit/method/repository/ConduitAPI_repository_query_Method.php',
'ConduitAPI_slowvote_info_Method' => 'applications/conduit/method/slowvote/ConduitAPI_slowvote_info_Method.php',
'ConduitAPI_user_Method' => 'applications/conduit/method/user/ConduitAPI_user_Method.php',
'ConduitAPI_user_addstatus_Method' => 'applications/conduit/method/user/ConduitAPI_user_addstatus_Method.php',
'ConduitAPI_user_disable_Method' => 'applications/conduit/method/user/ConduitAPI_user_disable_Method.php',
Add user.enable conduit method Test Plan: enabled a disabled user Reviewers: vrana, epriestley Reviewed By: vrana CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D2800
2012-06-19 23:36:08 +02:00
'ConduitAPI_user_enable_Method' => 'applications/conduit/method/user/ConduitAPI_user_enable_Method.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ConduitAPI_user_find_Method' => 'applications/conduit/method/user/ConduitAPI_user_find_Method.php',
'ConduitAPI_user_info_Method' => 'applications/conduit/method/user/ConduitAPI_user_info_Method.php',
'ConduitAPI_user_query_Method' => 'applications/conduit/method/user/ConduitAPI_user_query_Method.php',
'ConduitAPI_user_removestatus_Method' => 'applications/conduit/method/user/ConduitAPI_user_removestatus_Method.php',
'ConduitAPI_user_whoami_Method' => 'applications/conduit/method/user/ConduitAPI_user_whoami_Method.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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ConduitException' => 'applications/conduit/protocol/ConduitException.php',
'DarkConsoleConfigPlugin' => 'aphront/console/plugin/DarkConsoleConfigPlugin.php',
'DarkConsoleController' => 'aphront/console/DarkConsoleController.php',
'DarkConsoleCore' => 'aphront/console/DarkConsoleCore.php',
'DarkConsoleErrorLogPlugin' => 'aphront/console/plugin/DarkConsoleErrorLogPlugin.php',
'DarkConsoleErrorLogPluginAPI' => 'aphront/console/plugin/errorlog/DarkConsoleErrorLogPluginAPI.php',
'DarkConsoleEventPlugin' => 'aphront/console/plugin/DarkConsoleEventPlugin.php',
'DarkConsoleEventPluginAPI' => 'aphront/console/plugin/event/DarkConsoleEventPluginAPI.php',
'DarkConsolePlugin' => 'aphront/console/plugin/DarkConsolePlugin.php',
'DarkConsoleRequestPlugin' => 'aphront/console/plugin/DarkConsoleRequestPlugin.php',
'DarkConsoleServicesPlugin' => 'aphront/console/plugin/DarkConsoleServicesPlugin.php',
'DarkConsoleXHProfPlugin' => 'aphront/console/plugin/DarkConsoleXHProfPlugin.php',
'DarkConsoleXHProfPluginAPI' => 'aphront/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',
'DifferentialActionHasNoEffectException' => 'applications/differential/exception/DifferentialActionHasNoEffectException.php',
'DifferentialAddCommentView' => 'applications/differential/view/DifferentialAddCommentView.php',
'DifferentialAffectedPath' => 'applications/differential/storage/DifferentialAffectedPath.php',
'DifferentialApplyPatchFieldSpecification' => 'applications/differential/field/specification/DifferentialApplyPatchFieldSpecification.php',
'DifferentialArcanistProjectFieldSpecification' => 'applications/differential/field/specification/DifferentialArcanistProjectFieldSpecification.php',
'DifferentialAuditorsFieldSpecification' => 'applications/differential/field/specification/DifferentialAuditorsFieldSpecification.php',
'DifferentialAuthorFieldSpecification' => 'applications/differential/field/specification/DifferentialAuthorFieldSpecification.php',
'DifferentialAuxiliaryField' => 'applications/differential/storage/DifferentialAuxiliaryField.php',
'DifferentialBlameRevisionFieldSpecification' => 'applications/differential/field/specification/DifferentialBlameRevisionFieldSpecification.php',
'DifferentialBranchFieldSpecification' => 'applications/differential/field/specification/DifferentialBranchFieldSpecification.php',
'DifferentialCCWelcomeMail' => 'applications/differential/mail/DifferentialCCWelcomeMail.php',
'DifferentialCCsFieldSpecification' => 'applications/differential/field/specification/DifferentialCCsFieldSpecification.php',
'DifferentialChangeType' => 'applications/differential/constants/DifferentialChangeType.php',
'DifferentialChangeset' => 'applications/differential/storage/DifferentialChangeset.php',
'DifferentialChangesetDetailView' => 'applications/differential/view/DifferentialChangesetDetailView.php',
'DifferentialChangesetListView' => 'applications/differential/view/DifferentialChangesetListView.php',
'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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'DifferentialComment' => 'applications/differential/storage/DifferentialComment.php',
'DifferentialCommentEditor' => 'applications/differential/editor/DifferentialCommentEditor.php',
'DifferentialCommentMail' => 'applications/differential/mail/DifferentialCommentMail.php',
'DifferentialCommentPreviewController' => 'applications/differential/controller/DifferentialCommentPreviewController.php',
'DifferentialCommentSaveController' => 'applications/differential/controller/DifferentialCommentSaveController.php',
'DifferentialCommitsFieldSpecification' => 'applications/differential/field/specification/DifferentialCommitsFieldSpecification.php',
'DifferentialController' => 'applications/differential/controller/DifferentialController.php',
'DifferentialDAO' => 'applications/differential/storage/DifferentialDAO.php',
'DifferentialDateCreatedFieldSpecification' => 'applications/differential/field/specification/DifferentialDateCreatedFieldSpecification.php',
'DifferentialDateModifiedFieldSpecification' => 'applications/differential/field/specification/DifferentialDateModifiedFieldSpecification.php',
'DifferentialDefaultFieldSelector' => 'applications/differential/field/selector/DifferentialDefaultFieldSelector.php',
'DifferentialDependenciesFieldSpecification' => 'applications/differential/field/specification/DifferentialDependenciesFieldSpecification.php',
'DifferentialDiff' => 'applications/differential/storage/DifferentialDiff.php',
'DifferentialDiffContentMail' => 'applications/differential/mail/DifferentialDiffContentMail.php',
'DifferentialDiffCreateController' => 'applications/differential/controller/DifferentialDiffCreateController.php',
'DifferentialDiffProperty' => 'applications/differential/storage/DifferentialDiffProperty.php',
'DifferentialDiffTableOfContentsView' => 'applications/differential/view/DifferentialDiffTableOfContentsView.php',
'DifferentialDiffViewController' => 'applications/differential/controller/DifferentialDiffViewController.php',
'DifferentialException' => 'applications/differential/exception/DifferentialException.php',
'DifferentialExceptionMail' => 'applications/differential/mail/DifferentialExceptionMail.php',
'DifferentialExportPatchFieldSpecification' => 'applications/differential/field/specification/DifferentialExportPatchFieldSpecification.php',
'DifferentialFieldDataNotAvailableException' => 'applications/differential/field/exception/DifferentialFieldDataNotAvailableException.php',
'DifferentialFieldParseException' => 'applications/differential/field/exception/DifferentialFieldParseException.php',
'DifferentialFieldSelector' => 'applications/differential/field/selector/DifferentialFieldSelector.php',
'DifferentialFieldSpecification' => 'applications/differential/field/specification/DifferentialFieldSpecification.php',
'DifferentialFieldSpecificationIncompleteException' => 'applications/differential/field/exception/DifferentialFieldSpecificationIncompleteException.php',
'DifferentialFieldValidationException' => 'applications/differential/field/exception/DifferentialFieldValidationException.php',
'DifferentialGitSVNIDFieldSpecification' => 'applications/differential/field/specification/DifferentialGitSVNIDFieldSpecification.php',
'DifferentialHostFieldSpecification' => 'applications/differential/field/specification/DifferentialHostFieldSpecification.php',
'DifferentialHunk' => 'applications/differential/storage/DifferentialHunk.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',
'DifferentialInlineCommentEditView' => 'applications/differential/view/DifferentialInlineCommentEditView.php',
'DifferentialInlineCommentPreviewController' => 'applications/differential/controller/DifferentialInlineCommentPreviewController.php',
'DifferentialInlineCommentView' => 'applications/differential/view/DifferentialInlineCommentView.php',
'DifferentialLinesFieldSpecification' => 'applications/differential/field/specification/DifferentialLinesFieldSpecification.php',
'DifferentialLintFieldSpecification' => 'applications/differential/field/specification/DifferentialLintFieldSpecification.php',
'DifferentialLintStatus' => 'applications/differential/constants/DifferentialLintStatus.php',
'DifferentialLocalCommitsView' => 'applications/differential/view/DifferentialLocalCommitsView.php',
'DifferentialMail' => 'applications/differential/mail/DifferentialMail.php',
Drive Differential review request e-mail message by field specification Summary: This also changes some stuff: - Reviewers used to be at top, now they are under comments. - Primary reviewer is now rendered as first. Test Plan: Added `renderValueForMail()` to a custom field, created diff, commented on it and verified e-mails. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D2664
2012-06-06 19:52:17 +02:00
'DifferentialMailPhase' => 'applications/differential/constants/DifferentialMailPhase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialManiphestTasksFieldSpecification' => 'applications/differential/field/specification/DifferentialManiphestTasksFieldSpecification.php',
'DifferentialNewDiffMail' => 'applications/differential/mail/DifferentialNewDiffMail.php',
'DifferentialPathFieldSpecification' => 'applications/differential/field/specification/DifferentialPathFieldSpecification.php',
'DifferentialPrimaryPaneView' => 'applications/differential/view/DifferentialPrimaryPaneView.php',
'DifferentialReplyHandler' => 'applications/differential/DifferentialReplyHandler.php',
'DifferentialResultsTableView' => 'applications/differential/view/DifferentialResultsTableView.php',
'DifferentialRevertPlanFieldSpecification' => 'applications/differential/field/specification/DifferentialRevertPlanFieldSpecification.php',
'DifferentialReviewRequestMail' => 'applications/differential/mail/DifferentialReviewRequestMail.php',
'DifferentialReviewedByFieldSpecification' => 'applications/differential/field/specification/DifferentialReviewedByFieldSpecification.php',
Compute reviewer stats Summary: The final goal is to display reviewers response time on homepage. This is a building block for it. The algorithm is quite strict - it doesn't count simple comment as response because reviewers would be able to cheat with comments like "I'm overwhelmed right now and will review next week". We are more liberate in Phabricator where reviewers response with comments without changing the status quite often but I'm not trying to improve response times in Phabricator so this is irrelevant. Reviewers in Facebook changes status more often (to clean their queue) so I follow this approach. There is currently no way to track reviewers silently added and removed in Edit Revision but it's not a big deal. The algorithm doesn't track commandeered revision, there's a TODO for it. Response times are put in two buckets: `$reviewed` and `$not_reviewed`. `$reviewed` contains reviewers who took action, `$not_reviewed` contains reviewers who didn't respond on time. I will probably compute average time from `$reviewed` and raise it for those `$not_reviewed` that are higher than this average. The idea is to not favor reviewers who were only lucky for being in a group with someone fast. Test Plan: Passed test. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3062
2012-07-25 02:58:33 +02:00
'DifferentialReviewerStats' => 'applications/differential/stats/DifferentialReviewerStats.php',
'DifferentialReviewerStatsTestCase' => 'applications/differential/stats/__tests__/DifferentialReviewerStatsTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialReviewersFieldSpecification' => 'applications/differential/field/specification/DifferentialReviewersFieldSpecification.php',
'DifferentialRevision' => 'applications/differential/storage/DifferentialRevision.php',
'DifferentialRevisionCommentListView' => 'applications/differential/view/DifferentialRevisionCommentListView.php',
'DifferentialRevisionCommentView' => 'applications/differential/view/DifferentialRevisionCommentView.php',
'DifferentialRevisionControlSystem' => 'applications/differential/constants/DifferentialRevisionControlSystem.php',
'DifferentialRevisionDetailRenderer' => 'applications/differential/controller/DifferentialRevisionDetailRenderer.php',
'DifferentialRevisionDetailView' => 'applications/differential/view/DifferentialRevisionDetailView.php',
'DifferentialRevisionEditController' => 'applications/differential/controller/DifferentialRevisionEditController.php',
'DifferentialRevisionEditor' => 'applications/differential/editor/DifferentialRevisionEditor.php',
'DifferentialRevisionIDFieldParserTestCase' => 'applications/differential/field/specification/__tests__/DifferentialRevisionIDFieldParserTestCase.php',
'DifferentialRevisionIDFieldSpecification' => 'applications/differential/field/specification/DifferentialRevisionIDFieldSpecification.php',
'DifferentialRevisionListController' => 'applications/differential/controller/DifferentialRevisionListController.php',
'DifferentialRevisionListData' => 'applications/differential/data/DifferentialRevisionListData.php',
'DifferentialRevisionListView' => 'applications/differential/view/DifferentialRevisionListView.php',
'DifferentialRevisionQuery' => 'applications/differential/query/DifferentialRevisionQuery.php',
'DifferentialRevisionStatsController' => 'applications/differential/controller/DifferentialRevisionStatsController.php',
'DifferentialRevisionStatsView' => 'applications/differential/view/DifferentialRevisionStatsView.php',
'DifferentialRevisionStatusFieldSpecification' => 'applications/differential/field/specification/DifferentialRevisionStatusFieldSpecification.php',
'DifferentialRevisionUpdateHistoryView' => 'applications/differential/view/DifferentialRevisionUpdateHistoryView.php',
'DifferentialRevisionViewController' => 'applications/differential/controller/DifferentialRevisionViewController.php',
'DifferentialSubscribeController' => 'applications/differential/controller/DifferentialSubscribeController.php',
'DifferentialSummaryFieldSpecification' => 'applications/differential/field/specification/DifferentialSummaryFieldSpecification.php',
'DifferentialTasksAttacher' => 'applications/differential/DifferentialTasksAttacher.php',
'DifferentialTestPlanFieldSpecification' => 'applications/differential/field/specification/DifferentialTestPlanFieldSpecification.php',
'DifferentialTitleFieldSpecification' => 'applications/differential/field/specification/DifferentialTitleFieldSpecification.php',
'DifferentialUnitFieldSpecification' => 'applications/differential/field/specification/DifferentialUnitFieldSpecification.php',
'DifferentialUnitStatus' => 'applications/differential/constants/DifferentialUnitStatus.php',
'DifferentialUnitTestResult' => 'applications/differential/constants/DifferentialUnitTestResult.php',
'DiffusionBranchInformation' => 'applications/diffusion/data/DiffusionBranchInformation.php',
'DiffusionBranchQuery' => 'applications/diffusion/query/branch/DiffusionBranchQuery.php',
'DiffusionBranchTableController' => 'applications/diffusion/controller/DiffusionBranchTableController.php',
'DiffusionBranchTableView' => 'applications/diffusion/view/DiffusionBranchTableView.php',
'DiffusionBrowseController' => 'applications/diffusion/controller/DiffusionBrowseController.php',
'DiffusionBrowseFileController' => 'applications/diffusion/controller/DiffusionBrowseFileController.php',
'DiffusionBrowseQuery' => 'applications/diffusion/query/browse/DiffusionBrowseQuery.php',
'DiffusionBrowseTableView' => 'applications/diffusion/view/DiffusionBrowseTableView.php',
'DiffusionChangeController' => 'applications/diffusion/controller/DiffusionChangeController.php',
'DiffusionCommentListView' => 'applications/diffusion/view/DiffusionCommentListView.php',
'DiffusionCommentView' => 'applications/diffusion/view/DiffusionCommentView.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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionCommitChangeTableView' => 'applications/diffusion/view/DiffusionCommitChangeTableView.php',
'DiffusionCommitController' => 'applications/diffusion/controller/DiffusionCommitController.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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionCommitParentsQuery' => 'applications/diffusion/query/parents/DiffusionCommitParentsQuery.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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionCommitTagsQuery' => 'applications/diffusion/query/committags/DiffusionCommitTagsQuery.php',
'DiffusionContainsQuery' => 'applications/diffusion/query/contains/DiffusionContainsQuery.php',
'DiffusionController' => 'applications/diffusion/controller/DiffusionController.php',
'DiffusionDiffController' => 'applications/diffusion/controller/DiffusionDiffController.php',
'DiffusionDiffQuery' => 'applications/diffusion/query/diff/DiffusionDiffQuery.php',
'DiffusionEmptyResultView' => 'applications/diffusion/view/DiffusionEmptyResultView.php',
'DiffusionExternalController' => 'applications/diffusion/controller/DiffusionExternalController.php',
'DiffusionFileContent' => 'applications/diffusion/data/DiffusionFileContent.php',
'DiffusionFileContentQuery' => 'applications/diffusion/query/filecontent/DiffusionFileContentQuery.php',
'DiffusionGitBranchQuery' => 'applications/diffusion/query/branch/DiffusionGitBranchQuery.php',
'DiffusionGitBranchQueryTestCase' => 'applications/diffusion/query/branch/__tests__/DiffusionGitBranchQueryTestCase.php',
'DiffusionGitBrowseQuery' => 'applications/diffusion/query/browse/DiffusionGitBrowseQuery.php',
'DiffusionGitCommitParentsQuery' => 'applications/diffusion/query/parents/DiffusionGitCommitParentsQuery.php',
'DiffusionGitCommitTagsQuery' => 'applications/diffusion/query/committags/DiffusionGitCommitTagsQuery.php',
'DiffusionGitContainsQuery' => 'applications/diffusion/query/contains/DiffusionGitContainsQuery.php',
'DiffusionGitDiffQuery' => 'applications/diffusion/query/diff/DiffusionGitDiffQuery.php',
'DiffusionGitFileContentQuery' => 'applications/diffusion/query/filecontent/DiffusionGitFileContentQuery.php',
'DiffusionGitHistoryQuery' => 'applications/diffusion/query/history/DiffusionGitHistoryQuery.php',
'DiffusionGitLastModifiedQuery' => 'applications/diffusion/query/lastmodified/DiffusionGitLastModifiedQuery.php',
'DiffusionGitMergedCommitsQuery' => 'applications/diffusion/query/mergedcommits/DiffusionGitMergedCommitsQuery.php',
'DiffusionGitRawDiffQuery' => 'applications/diffusion/query/rawdiff/DiffusionGitRawDiffQuery.php',
'DiffusionGitRenameHistoryQuery' => 'applications/diffusion/query/renamehistory/DiffusionGitRenameHistoryQuery.php',
'DiffusionGitRequest' => 'applications/diffusion/request/DiffusionGitRequest.php',
'DiffusionGitTagListQuery' => 'applications/diffusion/query/taglist/DiffusionGitTagListQuery.php',
'DiffusionHistoryController' => 'applications/diffusion/controller/DiffusionHistoryController.php',
'DiffusionHistoryQuery' => 'applications/diffusion/query/history/DiffusionHistoryQuery.php',
'DiffusionHistoryTableView' => 'applications/diffusion/view/DiffusionHistoryTableView.php',
'DiffusionHomeController' => 'applications/diffusion/controller/DiffusionHomeController.php',
'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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'DiffusionLastModifiedQuery' => 'applications/diffusion/query/lastmodified/DiffusionLastModifiedQuery.php',
'DiffusionMercurialBranchQuery' => 'applications/diffusion/query/branch/DiffusionMercurialBranchQuery.php',
'DiffusionMercurialBrowseQuery' => 'applications/diffusion/query/browse/DiffusionMercurialBrowseQuery.php',
'DiffusionMercurialCommitParentsQuery' => 'applications/diffusion/query/parents/DiffusionMercurialCommitParentsQuery.php',
'DiffusionMercurialCommitTagsQuery' => 'applications/diffusion/query/committags/DiffusionMercurialCommitTagsQuery.php',
'DiffusionMercurialContainsQuery' => 'applications/diffusion/query/contains/DiffusionMercurialContainsQuery.php',
'DiffusionMercurialDiffQuery' => 'applications/diffusion/query/diff/DiffusionMercurialDiffQuery.php',
'DiffusionMercurialFileContentQuery' => 'applications/diffusion/query/filecontent/DiffusionMercurialFileContentQuery.php',
'DiffusionMercurialHistoryQuery' => 'applications/diffusion/query/history/DiffusionMercurialHistoryQuery.php',
'DiffusionMercurialLastModifiedQuery' => 'applications/diffusion/query/lastmodified/DiffusionMercurialLastModifiedQuery.php',
'DiffusionMercurialMergedCommitsQuery' => 'applications/diffusion/query/mergedcommits/DiffusionMercurialMergedCommitsQuery.php',
'DiffusionMercurialRawDiffQuery' => 'applications/diffusion/query/rawdiff/DiffusionMercurialRawDiffQuery.php',
'DiffusionMercurialRenameHistoryQuery' => 'applications/diffusion/query/renamehistory/DiffusionMercurialRenameHistoryQuery.php',
'DiffusionMercurialRequest' => 'applications/diffusion/request/DiffusionMercurialRequest.php',
'DiffusionMercurialTagListQuery' => 'applications/diffusion/query/taglist/DiffusionMercurialTagListQuery.php',
'DiffusionMergedCommitsQuery' => 'applications/diffusion/query/mergedcommits/DiffusionMergedCommitsQuery.php',
'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',
'DiffusionPathValidateController' => 'applications/diffusion/controller/DiffusionPathValidateController.php',
'DiffusionQuery' => 'applications/diffusion/query/DiffusionQuery.php',
'DiffusionRawDiffQuery' => 'applications/diffusion/query/rawdiff/DiffusionRawDiffQuery.php',
'DiffusionRenameHistoryQuery' => 'applications/diffusion/query/renamehistory/DiffusionRenameHistoryQuery.php',
'DiffusionRepositoryController' => 'applications/diffusion/controller/DiffusionRepositoryController.php',
'DiffusionRepositoryPath' => 'applications/diffusion/data/DiffusionRepositoryPath.php',
'DiffusionRepositoryTag' => 'applications/diffusion/DiffusionRepositoryTag.php',
'DiffusionRequest' => 'applications/diffusion/request/DiffusionRequest.php',
'DiffusionSetupException' => 'applications/diffusion/exception/DiffusionSetupException.php',
'DiffusionSvnBrowseQuery' => 'applications/diffusion/query/browse/DiffusionSvnBrowseQuery.php',
'DiffusionSvnCommitParentsQuery' => 'applications/diffusion/query/parents/DiffusionSvnCommitParentsQuery.php',
'DiffusionSvnCommitTagsQuery' => 'applications/diffusion/query/committags/DiffusionSvnCommitTagsQuery.php',
'DiffusionSvnContainsQuery' => 'applications/diffusion/query/contains/DiffusionSvnContainsQuery.php',
'DiffusionSvnDiffQuery' => 'applications/diffusion/query/diff/DiffusionSvnDiffQuery.php',
'DiffusionSvnFileContentQuery' => 'applications/diffusion/query/filecontent/DiffusionSvnFileContentQuery.php',
'DiffusionSvnHistoryQuery' => 'applications/diffusion/query/history/DiffusionSvnHistoryQuery.php',
'DiffusionSvnLastModifiedQuery' => 'applications/diffusion/query/lastmodified/DiffusionSvnLastModifiedQuery.php',
'DiffusionSvnMergedCommitsQuery' => 'applications/diffusion/query/mergedcommits/DiffusionSvnMergedCommitsQuery.php',
'DiffusionSvnRawDiffQuery' => 'applications/diffusion/query/rawdiff/DiffusionSvnRawDiffQuery.php',
'DiffusionSvnRenameHistoryQuery' => 'applications/diffusion/query/renamehistory/DiffusionSvnRenameHistoryQuery.php',
'DiffusionSvnRequest' => 'applications/diffusion/request/DiffusionSvnRequest.php',
'DiffusionSvnTagListQuery' => 'applications/diffusion/query/taglist/DiffusionSvnTagListQuery.php',
'DiffusionSymbolController' => 'applications/diffusion/controller/DiffusionSymbolController.php',
'DiffusionSymbolQuery' => 'applications/diffusion/query/DiffusionSymbolQuery.php',
'DiffusionTagListController' => 'applications/diffusion/controller/DiffusionTagListController.php',
'DiffusionTagListQuery' => 'applications/diffusion/query/taglist/DiffusionTagListQuery.php',
'DiffusionTagListView' => 'applications/diffusion/view/DiffusionTagListView.php',
'DiffusionURITestCase' => 'applications/diffusion/request/__tests__/DiffusionURITestCase.php',
'DiffusionView' => 'applications/diffusion/view/DiffusionView.php',
'DrydockAllocator' => 'applications/drydock/allocator/DrydockAllocator.php',
'DrydockAllocatorWorker' => 'applications/drydock/allocator/DrydockAllocatorWorker.php',
'DrydockApacheWebrootBlueprint' => 'applications/drydock/blueprint/webroot/DrydockApacheWebrootBlueprint.php',
'DrydockApacheWebrootInterface' => 'applications/drydock/interface/webroot/DrydockApacheWebrootInterface.php',
'DrydockBlueprint' => 'applications/drydock/blueprint/DrydockBlueprint.php',
'DrydockCommandInterface' => 'applications/drydock/interface/command/DrydockCommandInterface.php',
'DrydockConstants' => 'applications/drydock/constants/DrydockConstants.php',
'DrydockController' => 'applications/drydock/controller/DrydockController.php',
'DrydockDAO' => 'applications/drydock/storage/DrydockDAO.php',
'DrydockEC2HostBlueprint' => 'applications/drydock/blueprint/DrydockEC2HostBlueprint.php',
'DrydockInterface' => 'applications/drydock/interface/DrydockInterface.php',
'DrydockLease' => 'applications/drydock/storage/DrydockLease.php',
'DrydockLeaseListController' => 'applications/drydock/controller/DrydockLeaseListController.php',
'DrydockLeaseStatus' => 'applications/drydock/constants/DrydockLeaseStatus.php',
'DrydockLocalCommandInterface' => 'applications/drydock/interface/command/DrydockLocalCommandInterface.php',
'DrydockLocalHostBlueprint' => 'applications/drydock/blueprint/DrydockLocalHostBlueprint.php',
'DrydockLog' => 'applications/drydock/storage/DrydockLog.php',
'DrydockLogController' => 'applications/drydock/controller/DrydockLogController.php',
'DrydockLogQuery' => 'applications/drydock/query/DrydockLogQuery.php',
'DrydockPhabricatorApplicationBlueprint' => 'applications/drydock/blueprint/application/DrydockPhabricatorApplicationBlueprint.php',
'DrydockRemoteHostBlueprint' => 'applications/drydock/blueprint/DrydockRemoteHostBlueprint.php',
'DrydockResource' => 'applications/drydock/storage/DrydockResource.php',
'DrydockResourceAllocateController' => 'applications/drydock/controller/DrydockResourceAllocateController.php',
'DrydockResourceListController' => 'applications/drydock/controller/DrydockResourceListController.php',
'DrydockResourceStatus' => 'applications/drydock/constants/DrydockResourceStatus.php',
'DrydockSSHCommandInterface' => 'applications/drydock/interface/command/DrydockSSHCommandInterface.php',
'DrydockWebrootInterface' => 'applications/drydock/interface/webroot/DrydockWebrootInterface.php',
'HarbormasterDAO' => 'applications/harbormaster/storage/HarbormasterDAO.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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'HeraldAction' => 'applications/herald/storage/HeraldAction.php',
'HeraldActionConfig' => 'applications/herald/config/HeraldActionConfig.php',
'HeraldApplyTranscript' => 'applications/herald/storage/transcript/HeraldApplyTranscript.php',
'HeraldCommitAdapter' => 'applications/herald/adapter/HeraldCommitAdapter.php',
'HeraldCondition' => 'applications/herald/storage/HeraldCondition.php',
'HeraldConditionConfig' => 'applications/herald/config/HeraldConditionConfig.php',
'HeraldConditionTranscript' => 'applications/herald/storage/transcript/HeraldConditionTranscript.php',
'HeraldContentTypeConfig' => 'applications/herald/config/HeraldContentTypeConfig.php',
'HeraldController' => 'applications/herald/controller/HeraldController.php',
'HeraldDAO' => 'applications/herald/storage/HeraldDAO.php',
'HeraldDeleteController' => 'applications/herald/controller/HeraldDeleteController.php',
'HeraldDifferentialRevisionAdapter' => 'applications/herald/adapter/HeraldDifferentialRevisionAdapter.php',
'HeraldDryRunAdapter' => 'applications/herald/adapter/HeraldDryRunAdapter.php',
'HeraldEditLogQuery' => 'applications/herald/query/HeraldEditLogQuery.php',
'HeraldEffect' => 'applications/herald/engine/HeraldEffect.php',
'HeraldEngine' => 'applications/herald/engine/HeraldEngine.php',
'HeraldFieldConfig' => 'applications/herald/config/HeraldFieldConfig.php',
'HeraldHomeController' => 'applications/herald/controller/HeraldHomeController.php',
'HeraldInvalidConditionException' => 'applications/herald/engine/engine/HeraldInvalidConditionException.php',
'HeraldInvalidFieldException' => 'applications/herald/engine/engine/HeraldInvalidFieldException.php',
'HeraldNewController' => 'applications/herald/controller/HeraldNewController.php',
'HeraldObjectAdapter' => 'applications/herald/adapter/HeraldObjectAdapter.php',
'HeraldObjectTranscript' => 'applications/herald/storage/transcript/HeraldObjectTranscript.php',
'HeraldRecursiveConditionsException' => 'applications/herald/engine/engine/HeraldRecursiveConditionsException.php',
'HeraldRepetitionPolicyConfig' => 'applications/herald/config/HeraldRepetitionPolicyConfig.php',
'HeraldRule' => 'applications/herald/storage/HeraldRule.php',
'HeraldRuleController' => 'applications/herald/controller/HeraldRuleController.php',
'HeraldRuleEdit' => 'applications/herald/storage/HeraldRuleEdit.php',
'HeraldRuleEditHistoryController' => 'applications/herald/controller/HeraldRuleEditHistoryController.php',
'HeraldRuleEditHistoryView' => 'applications/herald/view/HeraldRuleEditHistoryView.php',
'HeraldRuleListView' => 'applications/herald/view/HeraldRuleListView.php',
'HeraldRuleQuery' => 'applications/herald/query/HeraldRuleQuery.php',
'HeraldRuleTranscript' => 'applications/herald/storage/transcript/HeraldRuleTranscript.php',
'HeraldRuleTypeConfig' => 'applications/herald/config/HeraldRuleTypeConfig.php',
'HeraldTestConsoleController' => 'applications/herald/controller/HeraldTestConsoleController.php',
'HeraldTranscript' => 'applications/herald/storage/transcript/HeraldTranscript.php',
'HeraldTranscriptController' => 'applications/herald/controller/HeraldTranscriptController.php',
'HeraldTranscriptListController' => 'applications/herald/controller/HeraldTranscriptListController.php',
'HeraldValueTypeConfig' => 'applications/herald/config/HeraldValueTypeConfig.php',
'Javelin' => 'infrastructure/javelin/Javelin.php',
'JavelinReactorExample' => 'applications/uiexample/examples/JavelinReactorExample.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
'JavelinViewExample' => 'applications/uiexample/examples/JavelinViewExample.php',
'JavelinViewExampleServerView' => 'applications/uiexample/examples/JavelinViewExampleServerView.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',
'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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestAction' => 'applications/maniphest/constants/ManiphestAction.php',
'ManiphestAuxiliaryFieldDefaultSpecification' => 'applications/maniphest/auxiliaryfield/ManiphestAuxiliaryFieldDefaultSpecification.php',
'ManiphestAuxiliaryFieldSpecification' => 'applications/maniphest/auxiliaryfield/ManiphestAuxiliaryFieldSpecification.php',
'ManiphestAuxiliaryFieldTypeException' => 'applications/maniphest/auxiliaryfield/ManiphestAuxiliaryFieldTypeException.php',
'ManiphestAuxiliaryFieldValidationException' => 'applications/maniphest/auxiliaryfield/ManiphestAuxiliaryFieldValidationException.php',
'ManiphestBatchEditController' => 'applications/maniphest/controller/ManiphestBatchEditController.php',
'ManiphestConstants' => 'applications/maniphest/constants/ManiphestConstants.php',
'ManiphestController' => 'applications/maniphest/controller/ManiphestController.php',
'ManiphestDAO' => 'applications/maniphest/storage/ManiphestDAO.php',
'ManiphestDefaultTaskExtensions' => 'applications/maniphest/extensions/ManiphestDefaultTaskExtensions.php',
Insert Maniphest transactions when edges are edited Summary: - See D2741. - When EdgeEditor performs edits, emit events. - Listen for Maniphest edge events and save the changes as transactions. - Do all this in a reasonably generic way that won't take too much rewriting as we use edges more generally. Test Plan: Attached and detached commits from tasks, saw reasonable-looking transactions spring into existence. Reviewers: btrahan, davidreuss Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2906
2012-07-03 00:42:06 +02:00
'ManiphestEdgeEventListener' => 'applications/maniphest/event/ManiphestEdgeEventListener.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'ManiphestReplyHandler' => 'applications/maniphest/ManiphestReplyHandler.php',
'ManiphestReportController' => 'applications/maniphest/controller/ManiphestReportController.php',
'ManiphestSavedQuery' => 'applications/maniphest/storage/ManiphestSavedQuery.php',
'ManiphestSavedQueryDeleteController' => 'applications/maniphest/controller/ManiphestSavedQueryDeleteController.php',
'ManiphestSavedQueryEditController' => 'applications/maniphest/controller/ManiphestSavedQueryEditController.php',
'ManiphestSavedQueryListController' => 'applications/maniphest/controller/ManiphestSavedQueryListController.php',
'ManiphestSubpriorityController' => 'applications/maniphest/controller/ManiphestSubpriorityController.php',
'ManiphestTask' => 'applications/maniphest/storage/ManiphestTask.php',
'ManiphestTaskAuxiliaryStorage' => 'applications/maniphest/storage/ManiphestTaskAuxiliaryStorage.php',
'ManiphestTaskDescriptionChangeController' => 'applications/maniphest/controller/ManiphestTaskDescriptionChangeController.php',
'ManiphestTaskDescriptionPreviewController' => 'applications/maniphest/controller/ManiphestTaskDescriptionPreviewController.php',
'ManiphestTaskDetailController' => 'applications/maniphest/controller/ManiphestTaskDetailController.php',
'ManiphestTaskEditController' => 'applications/maniphest/controller/ManiphestTaskEditController.php',
'ManiphestTaskExtensions' => 'applications/maniphest/extensions/ManiphestTaskExtensions.php',
'ManiphestTaskListController' => 'applications/maniphest/controller/ManiphestTaskListController.php',
'ManiphestTaskListView' => 'applications/maniphest/view/ManiphestTaskListView.php',
'ManiphestTaskOwner' => 'applications/maniphest/constants/ManiphestTaskOwner.php',
'ManiphestTaskPriority' => 'applications/maniphest/constants/ManiphestTaskPriority.php',
'ManiphestTaskProject' => 'applications/maniphest/storage/ManiphestTaskProject.php',
'ManiphestTaskProjectsView' => 'applications/maniphest/view/ManiphestTaskProjectsView.php',
'ManiphestTaskQuery' => 'applications/maniphest/ManiphestTaskQuery.php',
'ManiphestTaskStatus' => 'applications/maniphest/constants/ManiphestTaskStatus.php',
'ManiphestTaskSubscriber' => 'applications/maniphest/storage/ManiphestTaskSubscriber.php',
'ManiphestTaskSummaryView' => 'applications/maniphest/view/ManiphestTaskSummaryView.php',
'ManiphestTransaction' => 'applications/maniphest/storage/ManiphestTransaction.php',
'ManiphestTransactionDetailView' => 'applications/maniphest/view/ManiphestTransactionDetailView.php',
'ManiphestTransactionEditor' => 'applications/maniphest/editor/ManiphestTransactionEditor.php',
'ManiphestTransactionListView' => 'applications/maniphest/view/ManiphestTransactionListView.php',
'ManiphestTransactionPreviewController' => 'applications/maniphest/controller/ManiphestTransactionPreviewController.php',
'ManiphestTransactionSaveController' => 'applications/maniphest/controller/ManiphestTransactionSaveController.php',
'ManiphestTransactionType' => 'applications/maniphest/constants/ManiphestTransactionType.php',
'ManiphestView' => 'applications/maniphest/view/ManiphestView.php',
'MetaMTAConstants' => 'applications/metamta/constants/MetaMTAConstants.php',
'MetaMTANotificationType' => 'applications/metamta/constants/MetaMTANotificationType.php',
'OwnersPackageReplyHandler' => 'applications/owners/OwnersPackageReplyHandler.php',
'PackageCreateMail' => 'applications/owners/mail/PackageCreateMail.php',
'PackageDeleteMail' => 'applications/owners/mail/PackageDeleteMail.php',
'PackageMail' => 'applications/owners/mail/PackageMail.php',
'PackageModifyMail' => 'applications/owners/mail/PackageModifyMail.php',
'Phabricator404Controller' => 'applications/base/controller/Phabricator404Controller.php',
'PhabricatorAccessLog' => 'infrastructure/PhabricatorAccessLog.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',
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
'PhabricatorApplicationApplications' => 'applications/meta/application/PhabricatorApplicationApplications.php',
'PhabricatorApplicationAudit' => 'applications/audit/application/PhabricatorApplicationAudit.php',
Drive menu icons from Applications Summary: This makes no changes, it just moves the menu icons to the applications instead of hard-coded on the page. I'm going to try to address some of the angst in T1593 next... Test Plan: Loaded logged-in / logged out pages. Clicked menu items. Looked at /applications/. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1593, T1569 Differential Revision: https://secure.phabricator.com/D3146
2012-08-05 23:12:43 +02:00
'PhabricatorApplicationAuth' => 'applications/auth/application/PhabricatorApplicationAuth.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
'PhabricatorApplicationDifferential' => 'applications/differential/application/PhabricatorApplicationDifferential.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
'PhabricatorApplicationDiffusion' => 'applications/diffusion/application/PhabricatorApplicationDiffusion.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
'PhabricatorApplicationFact' => 'applications/fact/application/PhabricatorApplicationFact.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
'PhabricatorApplicationFlags' => 'applications/flag/application/PhabricatorApplicationFlags.php',
'PhabricatorApplicationLaunchView' => 'applications/meta/view/PhabricatorApplicationLaunchView.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
'PhabricatorApplicationManiphest' => 'applications/maniphest/application/PhabricatorApplicationManiphest.php',
Drive menu icons from Applications Summary: This makes no changes, it just moves the menu icons to the applications instead of hard-coded on the page. I'm going to try to address some of the angst in T1593 next... Test Plan: Loaded logged-in / logged out pages. Clicked menu items. Looked at /applications/. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1593, T1569 Differential Revision: https://secure.phabricator.com/D3146
2012-08-05 23:12:43 +02:00
'PhabricatorApplicationPeople' => 'applications/people/application/PhabricatorApplicationPeople.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
'PhabricatorApplicationPhriction' => 'applications/phriction/application/PhabricatorApplicationPhriction.php',
Add a "Project" application Summary: Move routes into a formal application class. Test Plan: Checked /applications/, browsed various routes. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, floatinglomas Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3181
2012-08-07 20:54:49 +02:00
'PhabricatorApplicationProject' => 'applications/project/application/PhabricatorApplicationProject.php',
Drive menu icons from Applications Summary: This makes no changes, it just moves the menu icons to the applications instead of hard-coded on the page. I'm going to try to address some of the angst in T1593 next... Test Plan: Loaded logged-in / logged out pages. Clicked menu items. Looked at /applications/. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1593, T1569 Differential Revision: https://secure.phabricator.com/D3146
2012-08-05 23:12:43 +02:00
'PhabricatorApplicationSettings' => 'applications/people/application/PhabricatorApplicationSettings.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',
'PhabricatorApplicationsController' => 'applications/meta/controller/PhabricatorApplicationsController.php',
'PhabricatorApplicationsListController' => 'applications/meta/controller/PhabricatorApplicationsListController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'PhabricatorAuditComment' => 'applications/audit/storage/PhabricatorAuditComment.php',
'PhabricatorAuditCommentEditor' => 'applications/audit/editor/PhabricatorAuditCommentEditor.php',
'PhabricatorAuditCommitListView' => 'applications/audit/view/PhabricatorAuditCommitListView.php',
'PhabricatorAuditCommitQuery' => 'applications/audit/query/PhabricatorAuditCommitQuery.php',
'PhabricatorAuditCommitStatusConstants' => 'applications/audit/constants/PhabricatorAuditCommitStatusConstants.php',
'PhabricatorAuditController' => 'applications/audit/controller/PhabricatorAuditController.php',
'PhabricatorAuditDAO' => 'applications/audit/storage/PhabricatorAuditDAO.php',
'PhabricatorAuditInlineComment' => 'applications/audit/storage/PhabricatorAuditInlineComment.php',
'PhabricatorAuditListController' => 'applications/audit/controller/PhabricatorAuditListController.php',
'PhabricatorAuditListView' => 'applications/audit/view/PhabricatorAuditListView.php',
'PhabricatorAuditPreviewController' => 'applications/audit/controller/PhabricatorAuditPreviewController.php',
'PhabricatorAuditQuery' => 'applications/audit/query/PhabricatorAuditQuery.php',
'PhabricatorAuditReplyHandler' => 'applications/audit/PhabricatorAuditReplyHandler.php',
'PhabricatorAuditStatusConstants' => 'applications/audit/constants/PhabricatorAuditStatusConstants.php',
'PhabricatorAuthController' => 'applications/auth/controller/PhabricatorAuthController.php',
Allow extending English translation Test Plan: Displayed home. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D2759
2012-06-15 04:01:57 +02:00
'PhabricatorBaseEnglishTranslation' => 'infrastructure/internationalization/PhabricatorBaseEnglishTranslation.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',
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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorCalendarBrowseController' => 'applications/calendar/controller/PhabricatorCalendarBrowseController.php',
'PhabricatorCalendarController' => 'applications/calendar/controller/PhabricatorCalendarController.php',
'PhabricatorCalendarDAO' => 'applications/calendar/storage/PhabricatorCalendarDAO.php',
'PhabricatorCalendarHoliday' => 'applications/calendar/storage/PhabricatorCalendarHoliday.php',
'PhabricatorCalendarHolidayTestCase' => 'applications/calendar/storage/__tests__/PhabricatorCalendarHolidayTestCase.php',
'PhabricatorChangesetResponse' => 'infrastructure/diff/PhabricatorChangesetResponse.php',
'PhabricatorChatLogChannelListController' => 'applications/chatlog/controller/PhabricatorChatLogChannelListController.php',
'PhabricatorChatLogChannelLogController' => 'applications/chatlog/controller/PhabricatorChatLogChannelLogController.php',
'PhabricatorChatLogConstants' => 'applications/chatlog/constants/PhabricatorChatLogConstants.php',
'PhabricatorChatLogController' => 'applications/chatlog/controller/PhabricatorChatLogController.php',
'PhabricatorChatLogDAO' => 'applications/chatlog/storage/PhabricatorChatLogDAO.php',
'PhabricatorChatLogEvent' => 'applications/chatlog/storage/PhabricatorChatLogEvent.php',
'PhabricatorChatLogEventType' => 'applications/chatlog/constants/PhabricatorChatLogEventType.php',
'PhabricatorChatLogQuery' => 'applications/chatlog/PhabricatorChatLogQuery.php',
'PhabricatorConduitAPIController' => 'applications/conduit/controller/PhabricatorConduitAPIController.php',
'PhabricatorConduitCertificateToken' => 'applications/conduit/storage/PhabricatorConduitCertificateToken.php',
'PhabricatorConduitConnectionLog' => 'applications/conduit/storage/PhabricatorConduitConnectionLog.php',
'PhabricatorConduitConsoleController' => 'applications/conduit/controller/PhabricatorConduitConsoleController.php',
'PhabricatorConduitController' => 'applications/conduit/controller/PhabricatorConduitController.php',
'PhabricatorConduitDAO' => 'applications/conduit/storage/PhabricatorConduitDAO.php',
'PhabricatorConduitListController' => 'applications/conduit/controller/PhabricatorConduitListController.php',
'PhabricatorConduitLogController' => 'applications/conduit/controller/PhabricatorConduitLogController.php',
'PhabricatorConduitMethodCallLog' => 'applications/conduit/storage/PhabricatorConduitMethodCallLog.php',
'PhabricatorConduitTokenController' => 'applications/conduit/controller/PhabricatorConduitTokenController.php',
'PhabricatorContentSource' => 'applications/metamta/contentsource/PhabricatorContentSource.php',
'PhabricatorContentSourceView' => 'applications/metamta/contentsource/PhabricatorContentSourceView.php',
'PhabricatorController' => 'applications/base/controller/PhabricatorController.php',
'PhabricatorCountdownController' => 'applications/countdown/controller/PhabricatorCountdownController.php',
'PhabricatorCountdownDAO' => 'applications/countdown/storage/PhabricatorCountdownDAO.php',
'PhabricatorCountdownDeleteController' => 'applications/countdown/controller/PhabricatorCountdownDeleteController.php',
'PhabricatorCountdownEditController' => 'applications/countdown/controller/PhabricatorCountdownEditController.php',
'PhabricatorCountdownListController' => 'applications/countdown/controller/PhabricatorCountdownListController.php',
'PhabricatorCountdownViewController' => 'applications/countdown/controller/PhabricatorCountdownViewController.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
'PhabricatorCursorPagedPolicyQuery' => 'infrastructure/query/policy/PhabricatorCursorPagedPolicyQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'PhabricatorDaemonCombinedLogController' => 'applications/daemon/controller/PhabricatorDaemonCombinedLogController.php',
'PhabricatorDaemonConsoleController' => 'applications/daemon/controller/PhabricatorDaemonConsoleController.php',
'PhabricatorDaemonControl' => 'infrastructure/daemon/PhabricatorDaemonControl.php',
'PhabricatorDaemonController' => 'applications/daemon/controller/PhabricatorDaemonController.php',
'PhabricatorDaemonDAO' => 'infrastructure/daemon/storage/PhabricatorDaemonDAO.php',
'PhabricatorDaemonLog' => 'infrastructure/daemon/storage/PhabricatorDaemonLog.php',
'PhabricatorDaemonLogEvent' => 'infrastructure/daemon/storage/PhabricatorDaemonLogEvent.php',
'PhabricatorDaemonLogEventsView' => 'applications/daemon/view/PhabricatorDaemonLogEventsView.php',
'PhabricatorDaemonLogListController' => 'applications/daemon/controller/PhabricatorDaemonLogListController.php',
'PhabricatorDaemonLogListView' => 'applications/daemon/view/PhabricatorDaemonLogListView.php',
'PhabricatorDaemonLogViewController' => 'applications/daemon/controller/PhabricatorDaemonLogViewController.php',
'PhabricatorDaemonReference' => 'infrastructure/daemon/control/PhabricatorDaemonReference.php',
'PhabricatorDaemonTimelineConsoleController' => 'applications/daemon/controller/PhabricatorDaemonTimelineConsoleController.php',
'PhabricatorDaemonTimelineEventController' => 'applications/daemon/controller/PhabricatorDaemonTimelineEventController.php',
'PhabricatorDefaultFileStorageEngineSelector' => 'applications/files/engineselector/PhabricatorDefaultFileStorageEngineSelector.php',
'PhabricatorDefaultSearchEngineSelector' => 'applications/search/selector/PhabricatorDefaultSearchEngineSelector.php',
'PhabricatorDifferenceEngine' => 'infrastructure/diff/PhabricatorDifferenceEngine.php',
'PhabricatorDirectoryController' => 'applications/directory/controller/PhabricatorDirectoryController.php',
'PhabricatorDirectoryMainController' => 'applications/directory/controller/PhabricatorDirectoryMainController.php',
'PhabricatorDisabledUserController' => 'applications/auth/controller/PhabricatorDisabledUserController.php',
'PhabricatorDraft' => 'applications/draft/storage/PhabricatorDraft.php',
'PhabricatorDraftDAO' => 'applications/draft/storage/PhabricatorDraftDAO.php',
'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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'PhabricatorEmailTokenController' => 'applications/auth/controller/PhabricatorEmailTokenController.php',
'PhabricatorEmailVerificationController' => 'applications/people/controller/PhabricatorEmailVerificationController.php',
Use pht() Summary: This is the first step in Phabricator internationalization. It adds a translation selector and calls it at startup. Installations can add custom selectors to override some texts. We can add official translations in future. Next step is to allow user to choose his translation which will override the global one. This is currently used only for English plurals. Test Plan: Displayed a diff with unit test error, verified that it says 'Detail' or 'Details' and not 'Detail(s)'. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D2753
2012-06-14 22:43:09 +02:00
'PhabricatorEnglishTranslation' => 'infrastructure/internationalization/PhabricatorEnglishTranslation.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorEnv' => 'infrastructure/PhabricatorEnv.php',
'PhabricatorEnvTestCase' => 'infrastructure/__tests__/PhabricatorEnvTestCase.php',
'PhabricatorErrorExample' => 'applications/uiexample/examples/PhabricatorErrorExample.php',
'PhabricatorEvent' => 'infrastructure/events/PhabricatorEvent.php',
'PhabricatorEventEngine' => 'infrastructure/events/PhabricatorEventEngine.php',
'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',
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',
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 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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'PhabricatorFeedConstants' => 'applications/feed/constants/PhabricatorFeedConstants.php',
'PhabricatorFeedController' => 'applications/feed/controller/PhabricatorFeedController.php',
'PhabricatorFeedDAO' => 'applications/feed/storage/PhabricatorFeedDAO.php',
'PhabricatorFeedPublicStreamController' => 'applications/feed/controller/PhabricatorFeedPublicStreamController.php',
'PhabricatorFeedQuery' => 'applications/feed/PhabricatorFeedQuery.php',
'PhabricatorFeedStory' => 'applications/feed/story/PhabricatorFeedStory.php',
Support basic notification aggregation Summary: This is both only partially complete (supports Maniphest only) and somewhat overcomplicated (includes support for applying similar algorithms to Feed), but provides runtime aggregation of notifications. Test Plan: {F13502} Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2884
2012-07-01 20:08:59 +02:00
'PhabricatorFeedStoryAggregate' => 'applications/feed/story/PhabricatorFeedStoryAggregate.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFeedStoryAudit' => 'applications/feed/story/PhabricatorFeedStoryAudit.php',
Publish feed stories about commits Summary: When stuff gets committed, publish feed stories about it. Test Plan: {F13061} Reviewers: jungejason, vrana, voldern Reviewed By: jungejason CC: aran Maniphest Tasks: T1322 Differential Revision: https://secure.phabricator.com/D2805
2012-06-20 15:03:44 +02:00
'PhabricatorFeedStoryCommit' => 'applications/feed/story/PhabricatorFeedStoryCommit.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFeedStoryData' => 'applications/feed/storage/PhabricatorFeedStoryData.php',
'PhabricatorFeedStoryDifferential' => 'applications/feed/story/PhabricatorFeedStoryDifferential.php',
'PhabricatorFeedStoryManiphest' => 'applications/feed/story/PhabricatorFeedStoryManiphest.php',
Support basic notification aggregation Summary: This is both only partially complete (supports Maniphest only) and somewhat overcomplicated (includes support for applying similar algorithms to Feed), but provides runtime aggregation of notifications. Test Plan: {F13502} Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2884
2012-07-01 20:08:59 +02:00
'PhabricatorFeedStoryManiphestAggregate' => 'applications/feed/story/PhabricatorFeedStoryManiphestAggregate.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
'PhabricatorFeedStoryPhriction' => 'applications/feed/story/PhabricatorFeedStoryPhriction.php',
'PhabricatorFeedStoryProject' => 'applications/feed/story/PhabricatorFeedStoryProject.php',
'PhabricatorFeedStoryPublisher' => 'applications/feed/PhabricatorFeedStoryPublisher.php',
'PhabricatorFeedStoryReference' => 'applications/feed/storage/PhabricatorFeedStoryReference.php',
'PhabricatorFeedStoryStatus' => 'applications/feed/story/PhabricatorFeedStoryStatus.php',
'PhabricatorFeedStoryTypeConstants' => 'applications/feed/constants/PhabricatorFeedStoryTypeConstants.php',
'PhabricatorFeedStoryUnknown' => 'applications/feed/story/PhabricatorFeedStoryUnknown.php',
'PhabricatorFeedStoryView' => 'applications/feed/view/PhabricatorFeedStoryView.php',
'PhabricatorFeedView' => 'applications/feed/view/PhabricatorFeedView.php',
'PhabricatorFile' => 'applications/files/storage/PhabricatorFile.php',
'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',
'PhabricatorFileImageMacro' => 'applications/files/storage/PhabricatorFileImageMacro.php',
'PhabricatorFileInfoController' => 'applications/files/controller/PhabricatorFileInfoController.php',
'PhabricatorFileListController' => 'applications/files/controller/PhabricatorFileListController.php',
'PhabricatorFileMacroDeleteController' => 'applications/files/controller/PhabricatorFileMacroDeleteController.php',
'PhabricatorFileMacroEditController' => 'applications/files/controller/PhabricatorFileMacroEditController.php',
'PhabricatorFileMacroListController' => 'applications/files/controller/PhabricatorFileMacroListController.php',
'PhabricatorFileProxyController' => 'applications/files/controller/PhabricatorFileProxyController.php',
'PhabricatorFileProxyImage' => 'applications/files/storage/PhabricatorFileProxyImage.php',
'PhabricatorFileShortcutController' => 'applications/files/controller/PhabricatorFileShortcutController.php',
'PhabricatorFileSideNavView' => 'applications/files/view/PhabricatorFileSideNavView.php',
'PhabricatorFileStorageBlob' => 'applications/files/storage/PhabricatorFileStorageBlob.php',
'PhabricatorFileStorageConfigurationException' => 'applications/files/exception/PhabricatorFileStorageConfigurationException.php',
'PhabricatorFileStorageEngine' => 'applications/files/engine/PhabricatorFileStorageEngine.php',
'PhabricatorFileStorageEngineSelector' => 'applications/files/engineselector/PhabricatorFileStorageEngineSelector.php',
'PhabricatorFileTransformController' => 'applications/files/controller/PhabricatorFileTransformController.php',
'PhabricatorFileUploadController' => 'applications/files/controller/PhabricatorFileUploadController.php',
'PhabricatorFileUploadException' => 'applications/files/exception/PhabricatorFileUploadException.php',
'PhabricatorFileUploadView' => 'applications/files/view/PhabricatorFileUploadView.php',
'PhabricatorFlag' => 'applications/flag/storage/PhabricatorFlag.php',
'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',
'PhabricatorFlagEditController' => 'applications/flag/controller/PhabricatorFlagEditController.php',
'PhabricatorFlagListController' => 'applications/flag/controller/PhabricatorFlagListController.php',
'PhabricatorFlagListView' => 'applications/flag/view/PhabricatorFlagListView.php',
'PhabricatorFlagQuery' => 'applications/flag/query/PhabricatorFlagQuery.php',
'PhabricatorFormExample' => 'applications/uiexample/examples/PhabricatorFormExample.php',
'PhabricatorGarbageCollectorDaemon' => 'infrastructure/daemon/PhabricatorGarbageCollectorDaemon.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',
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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorGoodForNothingWorker' => 'infrastructure/daemon/workers/worker/PhabricatorGoodForNothingWorker.php',
'PhabricatorHandleObjectSelectorDataView' => 'applications/phid/handle/view/PhabricatorHandleObjectSelectorDataView.php',
'PhabricatorHash' => 'infrastructure/util/PhabricatorHash.php',
'PhabricatorHelpController' => 'applications/help/controller/PhabricatorHelpController.php',
'PhabricatorHelpKeyboardShortcutController' => 'applications/help/controller/PhabricatorHelpKeyboardShortcutController.php',
'PhabricatorIRCBot' => 'infrastructure/daemon/irc/PhabricatorIRCBot.php',
'PhabricatorIRCDifferentialNotificationHandler' => 'infrastructure/daemon/irc/handler/PhabricatorIRCDifferentialNotificationHandler.php',
'PhabricatorIRCHandler' => 'infrastructure/daemon/irc/handler/PhabricatorIRCHandler.php',
'PhabricatorIRCLogHandler' => 'infrastructure/daemon/irc/handler/PhabricatorIRCLogHandler.php',
'PhabricatorIRCMacroHandler' => 'infrastructure/daemon/irc/handler/PhabricatorIRCMacroHandler.php',
'PhabricatorIRCMessage' => 'infrastructure/daemon/irc/PhabricatorIRCMessage.php',
'PhabricatorIRCObjectNameHandler' => 'infrastructure/daemon/irc/handler/PhabricatorIRCObjectNameHandler.php',
'PhabricatorIRCProtocolHandler' => 'infrastructure/daemon/irc/handler/PhabricatorIRCProtocolHandler.php',
'PhabricatorIRCWhatsNewHandler' => 'infrastructure/daemon/irc/handler/PhabricatorIRCWhatsNewHandler.php',
'PhabricatorImageTransformer' => 'applications/files/PhabricatorImageTransformer.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
'PhabricatorInfrastructureTestCase' => 'infrastructure/__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',
'PhabricatorJavelinLinter' => 'infrastructure/lint/linter/PhabricatorJavelinLinter.php',
'PhabricatorJumpNavHandler' => 'applications/search/engine/PhabricatorJumpNavHandler.php',
Made it possible to login using LDAP Summary: Made it possible to link and unlink LDAP accounts with Phabricator accounts. Test Plan: I've tested this code locally and in production where I work. I've tried creating an account from scratch by logging in with LDAP and linking and unlinking an LDAP account with an existing account. I've tried to associate the same LDAP account with different Phabricator accounts and it failed as expected. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, auduny, svemir Maniphest Tasks: T742 Differential Revision: https://secure.phabricator.com/D2722
2012-06-13 17:52:05 +02:00
'PhabricatorLDAPLoginController' => 'applications/auth/controller/PhabricatorLDAPLoginController.php',
'PhabricatorLDAPProvider' => 'applications/auth/ldap/PhabricatorLDAPProvider.php',
'PhabricatorLDAPRegistrationController' => 'applications/auth/controller/PhabricatorLDAPRegistrationController.php',
Prevent the ability to scrape for valid usernames - return the same error message when either bind or the username search fails to find a user - config variables should use hypen and not underscore
2012-07-26 23:32:51 +02:00
'PhabricatorLDAPUnknownUserException' => 'applications/auth/ldap/PhabricatorLDAPUnknownUserException.php',
Made it possible to login using LDAP Summary: Made it possible to link and unlink LDAP accounts with Phabricator accounts. Test Plan: I've tested this code locally and in production where I work. I've tried creating an account from scratch by logging in with LDAP and linking and unlinking an LDAP account with an existing account. I've tried to associate the same LDAP account with different Phabricator accounts and it failed as expected. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, auduny, svemir Maniphest Tasks: T742 Differential Revision: https://secure.phabricator.com/D2722
2012-06-13 17:52:05 +02:00
'PhabricatorLDAPUnlinkController' => 'applications/auth/controller/PhabricatorLDAPUnlinkController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorLintEngine' => 'infrastructure/lint/PhabricatorLintEngine.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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'PhabricatorLoginController' => 'applications/auth/controller/PhabricatorLoginController.php',
'PhabricatorLoginValidateController' => 'applications/auth/controller/PhabricatorLoginValidateController.php',
'PhabricatorLogoutController' => 'applications/auth/controller/PhabricatorLogoutController.php',
'PhabricatorMailImplementationAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationAdapter.php',
'PhabricatorMailImplementationAmazonSESAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationAmazonSESAdapter.php',
'PhabricatorMailImplementationPHPMailerLiteAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationPHPMailerLiteAdapter.php',
'PhabricatorMailImplementationSendGridAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationSendGridAdapter.php',
'PhabricatorMailImplementationTestAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationTestAdapter.php',
'PhabricatorMailReplyHandler' => 'applications/metamta/replyhandler/PhabricatorMailReplyHandler.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
'PhabricatorMainMenuGroupView' => 'view/page/menu/PhabricatorMainMenuGroupView.php',
'PhabricatorMainMenuIconView' => 'view/page/menu/PhabricatorMainMenuIconView.php',
'PhabricatorMainMenuSearchView' => 'view/page/menu/PhabricatorMainMenuSearchView.php',
'PhabricatorMainMenuView' => 'view/page/menu/PhabricatorMainMenuView.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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'PhabricatorMetaMTAAttachment' => 'applications/metamta/storage/PhabricatorMetaMTAAttachment.php',
'PhabricatorMetaMTAController' => 'applications/metamta/controller/PhabricatorMetaMTAController.php',
'PhabricatorMetaMTADAO' => 'applications/metamta/storage/PhabricatorMetaMTADAO.php',
'PhabricatorMetaMTAEmailBodyParser' => 'applications/metamta/PhabricatorMetaMTAEmailBodyParser.php',
'PhabricatorMetaMTAEmailBodyParserTestCase' => 'applications/metamta/__tests__/PhabricatorMetaMTAEmailBodyParserTestCase.php',
'PhabricatorMetaMTAListController' => 'applications/metamta/controller/PhabricatorMetaMTAListController.php',
'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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'PhabricatorMetaMTAMailingList' => 'applications/metamta/storage/PhabricatorMetaMTAMailingList.php',
'PhabricatorMetaMTAMailingListEditController' => 'applications/metamta/controller/PhabricatorMetaMTAMailingListEditController.php',
'PhabricatorMetaMTAMailingListsController' => 'applications/metamta/controller/PhabricatorMetaMTAMailingListsController.php',
'PhabricatorMetaMTAReceiveController' => 'applications/metamta/controller/PhabricatorMetaMTAReceiveController.php',
'PhabricatorMetaMTAReceivedListController' => 'applications/metamta/controller/PhabricatorMetaMTAReceivedListController.php',
'PhabricatorMetaMTAReceivedMail' => 'applications/metamta/storage/PhabricatorMetaMTAReceivedMail.php',
'PhabricatorMetaMTASendController' => 'applications/metamta/controller/PhabricatorMetaMTASendController.php',
'PhabricatorMetaMTASendGridReceiveController' => 'applications/metamta/controller/PhabricatorMetaMTASendGridReceiveController.php',
'PhabricatorMetaMTAViewController' => 'applications/metamta/controller/PhabricatorMetaMTAViewController.php',
'PhabricatorMetaMTAWorker' => 'applications/metamta/PhabricatorMetaMTAWorker.php',
'PhabricatorMustVerifyEmailController' => 'applications/auth/controller/PhabricatorMustVerifyEmailController.php',
'PhabricatorMySQLFileStorageEngine' => 'applications/files/engine/PhabricatorMySQLFileStorageEngine.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',
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',
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',
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
'PhabricatorNotificationQuery' => 'applications/notification/PhabricatorNotificationQuery.php',
Add a server status page for notification server Summary: - Add a /notification/status/ page which shows server status. - Remove various test controllers and routes. - Make the "no notifications" message look better. - Move port/URI configuration to config file. Test Plan: Started server, hit /notification/status/, saw server status. Reviewers: allenjohnashton, ddfisher, keebuhm, jungejason Reviewed By: jungejason CC: aran Maniphest Tasks: T944 Differential Revision: https://secure.phabricator.com/D2756
2012-06-17 20:35:18 +02:00
'PhabricatorNotificationStatusController' => 'applications/notification/controller/PhabricatorNotificationStatusController.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
'PhabricatorNotificationStoryView' => 'applications/notification/view/PhabricatorNotificationStoryView.php',
'PhabricatorNotificationView' => 'applications/notification/view/PhabricatorNotificationView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'PhabricatorOAuthClientAuthorizationBaseController' => 'applications/oauthserver/controller/clientauthorization/PhabricatorOAuthClientAuthorizationBaseController.php',
'PhabricatorOAuthClientAuthorizationDeleteController' => 'applications/oauthserver/controller/clientauthorization/PhabricatorOAuthClientAuthorizationDeleteController.php',
'PhabricatorOAuthClientAuthorizationEditController' => 'applications/oauthserver/controller/clientauthorization/PhabricatorOAuthClientAuthorizationEditController.php',
'PhabricatorOAuthClientAuthorizationListController' => 'applications/oauthserver/controller/clientauthorization/PhabricatorOAuthClientAuthorizationListController.php',
'PhabricatorOAuthClientAuthorizationQuery' => 'applications/oauthserver/query/PhabricatorOAuthClientAuthorizationQuery.php',
'PhabricatorOAuthClientBaseController' => 'applications/oauthserver/controller/client/PhabricatorOAuthClientBaseController.php',
'PhabricatorOAuthClientDeleteController' => 'applications/oauthserver/controller/client/PhabricatorOAuthClientDeleteController.php',
'PhabricatorOAuthClientEditController' => 'applications/oauthserver/controller/client/PhabricatorOAuthClientEditController.php',
'PhabricatorOAuthClientListController' => 'applications/oauthserver/controller/client/PhabricatorOAuthClientListController.php',
'PhabricatorOAuthClientViewController' => 'applications/oauthserver/controller/client/PhabricatorOAuthClientViewController.php',
'PhabricatorOAuthDefaultRegistrationController' => 'applications/auth/controller/oauthregistration/PhabricatorOAuthDefaultRegistrationController.php',
'PhabricatorOAuthDiagnosticsController' => 'applications/auth/controller/PhabricatorOAuthDiagnosticsController.php',
'PhabricatorOAuthFailureView' => 'applications/auth/view/PhabricatorOAuthFailureView.php',
'PhabricatorOAuthLoginController' => 'applications/auth/controller/PhabricatorOAuthLoginController.php',
'PhabricatorOAuthProvider' => 'applications/auth/oauth/provider/PhabricatorOAuthProvider.php',
'PhabricatorOAuthProviderDisqus' => 'applications/auth/oauth/provider/PhabricatorOAuthProviderDisqus.php',
'PhabricatorOAuthProviderException' => 'applications/auth/oauth/provider/PhabricatorOAuthProviderException.php',
'PhabricatorOAuthProviderFacebook' => 'applications/auth/oauth/provider/PhabricatorOAuthProviderFacebook.php',
'PhabricatorOAuthProviderGitHub' => 'applications/auth/oauth/provider/PhabricatorOAuthProviderGitHub.php',
'PhabricatorOAuthProviderGoogle' => 'applications/auth/oauth/provider/PhabricatorOAuthProviderGoogle.php',
'PhabricatorOAuthProviderPhabricator' => 'applications/auth/oauth/provider/PhabricatorOAuthProviderPhabricator.php',
'PhabricatorOAuthRegistrationController' => 'applications/auth/controller/oauthregistration/PhabricatorOAuthRegistrationController.php',
'PhabricatorOAuthResponse' => 'applications/oauthserver/PhabricatorOAuthResponse.php',
'PhabricatorOAuthServer' => 'applications/oauthserver/PhabricatorOAuthServer.php',
'PhabricatorOAuthServerAccessToken' => 'applications/oauthserver/storage/PhabricatorOAuthServerAccessToken.php',
'PhabricatorOAuthServerAuthController' => 'applications/oauthserver/controller/PhabricatorOAuthServerAuthController.php',
'PhabricatorOAuthServerAuthorizationCode' => 'applications/oauthserver/storage/PhabricatorOAuthServerAuthorizationCode.php',
'PhabricatorOAuthServerClient' => 'applications/oauthserver/storage/PhabricatorOAuthServerClient.php',
'PhabricatorOAuthServerClientQuery' => 'applications/oauthserver/query/PhabricatorOAuthServerClientQuery.php',
'PhabricatorOAuthServerController' => 'applications/oauthserver/controller/PhabricatorOAuthServerController.php',
'PhabricatorOAuthServerDAO' => 'applications/oauthserver/storage/PhabricatorOAuthServerDAO.php',
'PhabricatorOAuthServerScope' => 'applications/oauthserver/PhabricatorOAuthServerScope.php',
'PhabricatorOAuthServerTestCase' => 'applications/oauthserver/__tests__/PhabricatorOAuthServerTestCase.php',
'PhabricatorOAuthServerTestController' => 'applications/oauthserver/controller/PhabricatorOAuthServerTestController.php',
'PhabricatorOAuthServerTokenController' => 'applications/oauthserver/controller/PhabricatorOAuthServerTokenController.php',
'PhabricatorOAuthUnlinkController' => 'applications/auth/controller/PhabricatorOAuthUnlinkController.php',
'PhabricatorObjectHandle' => 'applications/phid/PhabricatorObjectHandle.php',
'PhabricatorObjectHandleConstants' => 'applications/phid/handle/const/PhabricatorObjectHandleConstants.php',
'PhabricatorObjectHandleData' => 'applications/phid/handle/PhabricatorObjectHandleData.php',
'PhabricatorObjectHandleStatus' => 'applications/phid/handle/const/PhabricatorObjectHandleStatus.php',
Make project membership edits use transactions and PHIDs and not be awful Summary: - Split project profile editing apart from project membership editing. - Make project membership editing simpler and easier to use. - Drop role / owner stuff from the UI. Test Plan: Added and removed project members. Edited project profile information. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3184
2012-08-07 20:57:38 +02:00
'PhabricatorObjectListView' => 'view/control/PhabricatorObjectListView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'PhabricatorOffsetPagedQuery' => 'infrastructure/query/PhabricatorOffsetPagedQuery.php',
'PhabricatorOwnerPathQuery' => 'applications/owners/query/PhabricatorOwnerPathQuery.php',
'PhabricatorOwnersController' => 'applications/owners/controller/PhabricatorOwnersController.php',
'PhabricatorOwnersDAO' => 'applications/owners/storage/PhabricatorOwnersDAO.php',
'PhabricatorOwnersDeleteController' => 'applications/owners/controller/PhabricatorOwnersDeleteController.php',
'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',
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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'PhabricatorPHID' => 'applications/phid/storage/PhabricatorPHID.php',
'PhabricatorPHIDConstants' => 'applications/phid/PhabricatorPHIDConstants.php',
'PhabricatorPHIDController' => 'applications/phid/controller/PhabricatorPHIDController.php',
'PhabricatorPHIDLookupController' => 'applications/phid/controller/PhabricatorPHIDLookupController.php',
'PhabricatorPaste' => 'applications/paste/storage/PhabricatorPaste.php',
'PhabricatorPasteController' => 'applications/paste/controller/PhabricatorPasteController.php',
'PhabricatorPasteDAO' => 'applications/paste/storage/PhabricatorPasteDAO.php',
'PhabricatorPasteListController' => 'applications/paste/controller/PhabricatorPasteListController.php',
'PhabricatorPasteQuery' => 'applications/paste/query/PhabricatorPasteQuery.php',
'PhabricatorPasteViewController' => 'applications/paste/controller/PhabricatorPasteViewController.php',
'PhabricatorPeopleController' => 'applications/people/controller/PhabricatorPeopleController.php',
'PhabricatorPeopleEditController' => 'applications/people/controller/PhabricatorPeopleEditController.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',
'PhabricatorPeopleLogsController' => 'applications/people/controller/PhabricatorPeopleLogsController.php',
'PhabricatorPeopleProfileController' => 'applications/people/controller/PhabricatorPeopleProfileController.php',
'PhabricatorPeopleQuery' => 'applications/people/PhabricatorPeopleQuery.php',
'PhabricatorPolicies' => 'applications/policy/constants/PhabricatorPolicies.php',
'PhabricatorPolicyCapability' => 'applications/policy/constants/PhabricatorPolicyCapability.php',
'PhabricatorPolicyConstants' => 'applications/policy/constants/PhabricatorPolicyConstants.php',
'PhabricatorPolicyException' => 'applications/policy/exception/PhabricatorPolicyException.php',
'PhabricatorPolicyFilter' => 'applications/policy/filter/PhabricatorPolicyFilter.php',
'PhabricatorPolicyInterface' => 'applications/policy/interface/PhabricatorPolicyInterface.php',
'PhabricatorPolicyQuery' => 'infrastructure/query/policy/PhabricatorPolicyQuery.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',
'PhabricatorPolicyTestQuery' => 'applications/policy/__tests__/PhabricatorPolicyTestQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProfileHeaderView' => 'view/layout/PhabricatorProfileHeaderView.php',
'PhabricatorProject' => 'applications/project/storage/PhabricatorProject.php',
'PhabricatorProjectConstants' => 'applications/project/constants/PhabricatorProjectConstants.php',
'PhabricatorProjectController' => 'applications/project/controller/PhabricatorProjectController.php',
'PhabricatorProjectCreateController' => 'applications/project/controller/PhabricatorProjectCreateController.php',
'PhabricatorProjectDAO' => 'applications/project/storage/PhabricatorProjectDAO.php',
'PhabricatorProjectEditor' => 'applications/project/editor/PhabricatorProjectEditor.php',
'PhabricatorProjectListController' => 'applications/project/controller/PhabricatorProjectListController.php',
Make project membership edits use transactions and PHIDs and not be awful Summary: - Split project profile editing apart from project membership editing. - Make project membership editing simpler and easier to use. - Drop role / owner stuff from the UI. Test Plan: Added and removed project members. Edited project profile information. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3184
2012-08-07 20:57:38 +02:00
'PhabricatorProjectMembersEditController' => 'applications/project/controller/PhabricatorProjectMembersEditController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProjectNameCollisionException' => 'applications/project/exception/PhabricatorProjectNameCollisionException.php',
'PhabricatorProjectProfile' => 'applications/project/storage/PhabricatorProjectProfile.php',
'PhabricatorProjectProfileController' => 'applications/project/controller/PhabricatorProjectProfileController.php',
'PhabricatorProjectProfileEditController' => 'applications/project/controller/PhabricatorProjectProfileEditController.php',
'PhabricatorProjectQuery' => 'applications/project/query/PhabricatorProjectQuery.php',
'PhabricatorProjectStatus' => 'applications/project/constants/PhabricatorProjectStatus.php',
'PhabricatorProjectTransaction' => 'applications/project/storage/PhabricatorProjectTransaction.php',
'PhabricatorProjectTransactionType' => 'applications/project/constants/PhabricatorProjectTransactionType.php',
'PhabricatorProjectUpdateController' => 'applications/project/controller/PhabricatorProjectUpdateController.php',
'PhabricatorQuery' => 'infrastructure/query/PhabricatorQuery.php',
'PhabricatorRedirectController' => 'applications/base/controller/PhabricatorRedirectController.php',
'PhabricatorRefreshCSRFController' => 'applications/auth/controller/PhabricatorRefreshCSRFController.php',
Minor, move all remarkup code to src/infrastructure/markup/
2012-07-02 19:44:37 +02:00
'PhabricatorRemarkupRuleDifferential' => 'infrastructure/markup/rule/PhabricatorRemarkupRuleDifferential.php',
'PhabricatorRemarkupRuleDifferentialHandle' => 'infrastructure/markup/rule/handle/PhabricatorRemarkupRuleDifferentialHandle.php',
'PhabricatorRemarkupRuleDiffusion' => 'infrastructure/markup/rule/PhabricatorRemarkupRuleDiffusion.php',
'PhabricatorRemarkupRuleEmbedFile' => 'infrastructure/markup/rule/PhabricatorRemarkupRuleEmbedFile.php',
'PhabricatorRemarkupRuleImageMacro' => 'infrastructure/markup/rule/PhabricatorRemarkupRuleImageMacro.php',
'PhabricatorRemarkupRuleManiphest' => 'infrastructure/markup/rule/PhabricatorRemarkupRuleManiphest.php',
'PhabricatorRemarkupRuleManiphestHandle' => 'infrastructure/markup/rule/handle/PhabricatorRemarkupRuleManiphestHandle.php',
'PhabricatorRemarkupRuleMention' => 'infrastructure/markup/rule/PhabricatorRemarkupRuleMention.php',
'PhabricatorRemarkupRuleObjectHandle' => 'infrastructure/markup/rule/PhabricatorRemarkupRuleObjectHandle.php',
'PhabricatorRemarkupRuleObjectName' => 'infrastructure/markup/rule/PhabricatorRemarkupRuleObjectName.php',
'PhabricatorRemarkupRulePaste' => 'infrastructure/markup/rule/PhabricatorRemarkupRulePaste.php',
'PhabricatorRemarkupRulePhriction' => 'infrastructure/markup/rule/PhabricatorRemarkupRulePhriction.php',
'PhabricatorRemarkupRuleProxyImage' => 'infrastructure/markup/rule/PhabricatorRemarkupRuleProxyImage.php',
'PhabricatorRemarkupRuleYoutube' => 'infrastructure/markup/rule/PhabricatorRemarkupRuleYoutube.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'PhabricatorRepositoryArcanistProject' => 'applications/repository/storage/PhabricatorRepositoryArcanistProject.php',
'PhabricatorRepositoryArcanistProjectEditController' => 'applications/repository/controller/PhabricatorRepositoryArcanistProjectEditController.php',
'PhabricatorRepositoryAuditRequest' => 'applications/repository/storage/PhabricatorRepositoryAuditRequest.php',
'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',
'PhabricatorRepositoryCommitMessageDetailParser' => 'applications/repository/parser/PhabricatorRepositoryCommitMessageDetailParser.php',
'PhabricatorRepositoryCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/PhabricatorRepositoryCommitMessageParserWorker.php',
'PhabricatorRepositoryCommitOwnersWorker' => 'applications/repository/worker/PhabricatorRepositoryCommitOwnersWorker.php',
'PhabricatorRepositoryCommitParserWorker' => 'applications/repository/worker/PhabricatorRepositoryCommitParserWorker.php',
'PhabricatorRepositoryController' => 'applications/repository/controller/PhabricatorRepositoryController.php',
'PhabricatorRepositoryCreateController' => 'applications/repository/controller/PhabricatorRepositoryCreateController.php',
'PhabricatorRepositoryDAO' => 'applications/repository/storage/PhabricatorRepositoryDAO.php',
'PhabricatorRepositoryDefaultCommitMessageDetailParser' => 'applications/repository/parser/PhabricatorRepositoryDefaultCommitMessageDetailParser.php',
'PhabricatorRepositoryDeleteController' => 'applications/repository/controller/PhabricatorRepositoryDeleteController.php',
'PhabricatorRepositoryEditController' => 'applications/repository/controller/PhabricatorRepositoryEditController.php',
'PhabricatorRepositoryGitCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/PhabricatorRepositoryGitCommitChangeParserWorker.php',
'PhabricatorRepositoryGitCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/PhabricatorRepositoryGitCommitMessageParserWorker.php',
'PhabricatorRepositoryListController' => 'applications/repository/controller/PhabricatorRepositoryListController.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',
'PhabricatorRepositoryManagementListWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementListWorkflow.php',
'PhabricatorRepositoryManagementPullWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementPullWorkflow.php',
'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',
'PhabricatorRepositoryPullLocalDaemon' => 'applications/repository/daemon/PhabricatorRepositoryPullLocalDaemon.php',
'PhabricatorRepositoryPullLocalDaemonTestCase' => 'applications/repository/daemon/__tests__/PhabricatorRepositoryPullLocalDaemonTestCase.php',
'PhabricatorRepositoryShortcut' => 'applications/repository/storage/PhabricatorRepositoryShortcut.php',
'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',
'PhabricatorRepositoryType' => 'applications/repository/constants/PhabricatorRepositoryType.php',
'PhabricatorS3FileStorageEngine' => 'applications/files/engine/PhabricatorS3FileStorageEngine.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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorScopedEnv' => 'infrastructure/PhabricatorScopedEnv.php',
'PhabricatorSearchAbstractDocument' => 'applications/search/index/PhabricatorSearchAbstractDocument.php',
'PhabricatorSearchAttachController' => 'applications/search/controller/PhabricatorSearchAttachController.php',
'PhabricatorSearchBaseController' => 'applications/search/controller/PhabricatorSearchBaseController.php',
'PhabricatorSearchCommitIndexer' => 'applications/search/index/indexer/PhabricatorSearchCommitIndexer.php',
'PhabricatorSearchController' => 'applications/search/controller/PhabricatorSearchController.php',
'PhabricatorSearchDAO' => 'applications/search/storage/PhabricatorSearchDAO.php',
'PhabricatorSearchDifferentialIndexer' => 'applications/search/index/indexer/PhabricatorSearchDifferentialIndexer.php',
'PhabricatorSearchDocument' => 'applications/search/storage/document/PhabricatorSearchDocument.php',
'PhabricatorSearchDocumentField' => 'applications/search/storage/document/PhabricatorSearchDocumentField.php',
'PhabricatorSearchDocumentIndexer' => 'applications/search/index/indexer/PhabricatorSearchDocumentIndexer.php',
'PhabricatorSearchDocumentRelationship' => 'applications/search/storage/document/PhabricatorSearchDocumentRelationship.php',
'PhabricatorSearchEngine' => 'applications/search/engine/PhabricatorSearchEngine.php',
'PhabricatorSearchEngineElastic' => 'applications/search/engine/PhabricatorSearchEngineElastic.php',
'PhabricatorSearchEngineMySQL' => 'applications/search/engine/PhabricatorSearchEngineMySQL.php',
'PhabricatorSearchEngineSelector' => 'applications/search/selector/PhabricatorSearchEngineSelector.php',
'PhabricatorSearchField' => 'applications/search/constants/PhabricatorSearchField.php',
'PhabricatorSearchIndexController' => 'applications/search/controller/PhabricatorSearchIndexController.php',
'PhabricatorSearchManiphestIndexer' => 'applications/search/index/indexer/PhabricatorSearchManiphestIndexer.php',
'PhabricatorSearchPhrictionIndexer' => 'applications/search/index/indexer/PhabricatorSearchPhrictionIndexer.php',
'PhabricatorSearchQuery' => 'applications/search/storage/PhabricatorSearchQuery.php',
'PhabricatorSearchRelationship' => 'applications/search/constants/PhabricatorSearchRelationship.php',
'PhabricatorSearchResultView' => 'applications/search/view/PhabricatorSearchResultView.php',
'PhabricatorSearchScope' => 'applications/search/constants/PhabricatorSearchScope.php',
'PhabricatorSearchSelectController' => 'applications/search/controller/PhabricatorSearchSelectController.php',
'PhabricatorSearchUserIndexer' => 'applications/search/index/indexer/PhabricatorSearchUserIndexer.php',
'PhabricatorSetup' => 'infrastructure/PhabricatorSetup.php',
'PhabricatorSlowvoteChoice' => 'applications/slowvote/storage/PhabricatorSlowvoteChoice.php',
'PhabricatorSlowvoteComment' => 'applications/slowvote/storage/PhabricatorSlowvoteComment.php',
'PhabricatorSlowvoteController' => 'applications/slowvote/controller/PhabricatorSlowvoteController.php',
'PhabricatorSlowvoteCreateController' => 'applications/slowvote/controller/PhabricatorSlowvoteCreateController.php',
'PhabricatorSlowvoteDAO' => 'applications/slowvote/storage/PhabricatorSlowvoteDAO.php',
'PhabricatorSlowvoteListController' => 'applications/slowvote/controller/PhabricatorSlowvoteListController.php',
'PhabricatorSlowvoteOption' => 'applications/slowvote/storage/PhabricatorSlowvoteOption.php',
'PhabricatorSlowvotePoll' => 'applications/slowvote/storage/PhabricatorSlowvotePoll.php',
'PhabricatorSlowvotePollController' => 'applications/slowvote/controller/PhabricatorSlowvotePollController.php',
'PhabricatorSlug' => 'infrastructure/util/PhabricatorSlug.php',
'PhabricatorSlugTestCase' => 'infrastructure/util/__tests__/PhabricatorSlugTestCase.php',
'PhabricatorSortTableExample' => 'applications/uiexample/examples/PhabricatorSortTableExample.php',
'PhabricatorStandardPageView' => 'view/page/PhabricatorStandardPageView.php',
'PhabricatorStatusController' => 'applications/status/PhabricatorStatusController.php',
'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',
'PhabricatorStorageManagementDatabasesWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementDatabasesWorkflow.php',
'PhabricatorStorageManagementDestroyWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementDestroyWorkflow.php',
'PhabricatorStorageManagementDumpWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementDumpWorkflow.php',
'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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSymbolNameLinter' => 'infrastructure/lint/hook/PhabricatorSymbolNameLinter.php',
Minor, move all remarkup code to src/infrastructure/markup/
2012-07-02 19:44:37 +02:00
'PhabricatorSyntaxHighlighter' => 'infrastructure/markup/PhabricatorSyntaxHighlighter.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'PhabricatorTestCase' => 'infrastructure/testing/PhabricatorTestCase.php',
'PhabricatorTimelineCursor' => 'infrastructure/daemon/timeline/storage/PhabricatorTimelineCursor.php',
'PhabricatorTimelineDAO' => 'infrastructure/daemon/timeline/storage/PhabricatorTimelineDAO.php',
'PhabricatorTimelineEvent' => 'infrastructure/daemon/timeline/storage/PhabricatorTimelineEvent.php',
'PhabricatorTimelineEventData' => 'infrastructure/daemon/timeline/storage/PhabricatorTimelineEventData.php',
'PhabricatorTimelineIterator' => 'infrastructure/daemon/timeline/cursor/PhabricatorTimelineIterator.php',
'PhabricatorTimer' => 'applications/countdown/storage/PhabricatorTimer.php',
'PhabricatorTransactionView' => 'view/layout/PhabricatorTransactionView.php',
'PhabricatorTransformedFile' => 'applications/files/storage/PhabricatorTransformedFile.php',
Use pht() Summary: This is the first step in Phabricator internationalization. It adds a translation selector and calls it at startup. Installations can add custom selectors to override some texts. We can add official translations in future. Next step is to allow user to choose his translation which will override the global one. This is currently used only for English plurals. Test Plan: Displayed a diff with unit test error, verified that it says 'Detail' or 'Details' and not 'Detail(s)'. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D2753
2012-06-14 22:43:09 +02:00
'PhabricatorTranslation' => 'infrastructure/internationalization/PhabricatorTranslation.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'PhabricatorTypeaheadCommonDatasourceController' => 'applications/typeahead/controller/PhabricatorTypeaheadCommonDatasourceController.php',
'PhabricatorTypeaheadDatasourceController' => 'applications/typeahead/controller/PhabricatorTypeaheadDatasourceController.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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'PhabricatorUIExampleController' => 'applications/uiexample/controller/PhabricatorUIExampleController.php',
'PhabricatorUIExampleRenderController' => 'applications/uiexample/controller/PhabricatorUIExampleRenderController.php',
'PhabricatorUIListFilterExample' => 'applications/uiexample/examples/PhabricatorUIListFilterExample.php',
Add a basic notification UI element Summary: This is //extremely// basic but dead simple and should cover us for v1, I think. Let me know what features you need. Test Plan: Used UI example page. Reviewers: allenjohnashton, ddfisher, keebuhm Reviewed By: ddfisher CC: aran, ender Maniphest Tasks: T944 Differential Revision: https://secure.phabricator.com/D2732
2012-06-14 00:00:24 +02:00
'PhabricatorUINotificationExample' => 'applications/uiexample/examples/PhabricatorUINotificationExample.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUIPagerExample' => 'applications/uiexample/examples/PhabricatorUIPagerExample.php',
'PhabricatorUITooltipExample' => 'applications/uiexample/examples/PhabricatorUITooltipExample.php',
'PhabricatorUnitsTestCase' => 'view/__tests__/PhabricatorUnitsTestCase.php',
'PhabricatorUser' => 'applications/people/storage/PhabricatorUser.php',
'PhabricatorUserAccountSettingsPanelController' => 'applications/people/controller/settings/panels/PhabricatorUserAccountSettingsPanelController.php',
'PhabricatorUserConduitSettingsPanelController' => 'applications/people/controller/settings/panels/PhabricatorUserConduitSettingsPanelController.php',
'PhabricatorUserDAO' => 'applications/people/storage/PhabricatorUserDAO.php',
'PhabricatorUserEditor' => 'applications/people/PhabricatorUserEditor.php',
'PhabricatorUserEmail' => 'applications/people/storage/PhabricatorUserEmail.php',
'PhabricatorUserEmailPreferenceSettingsPanelController' => 'applications/people/controller/settings/panels/PhabricatorUserEmailPreferenceSettingsPanelController.php',
'PhabricatorUserEmailSettingsPanelController' => 'applications/people/controller/settings/panels/PhabricatorUserEmailSettingsPanelController.php',
Made it possible to login using LDAP Summary: Made it possible to link and unlink LDAP accounts with Phabricator accounts. Test Plan: I've tested this code locally and in production where I work. I've tried creating an account from scratch by logging in with LDAP and linking and unlinking an LDAP account with an existing account. I've tried to associate the same LDAP account with different Phabricator accounts and it failed as expected. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, auduny, svemir Maniphest Tasks: T742 Differential Revision: https://secure.phabricator.com/D2722
2012-06-13 17:52:05 +02:00
'PhabricatorUserLDAPInfo' => 'applications/people/storage/PhabricatorUserLDAPInfo.php',
'PhabricatorUserLDAPSettingsPanelController' => 'applications/people/controller/settings/panels/PhabricatorUserLDAPSettingsPanelController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'PhabricatorUserOAuthInfo' => 'applications/people/storage/PhabricatorUserOAuthInfo.php',
'PhabricatorUserOAuthSettingsPanelController' => 'applications/people/controller/settings/panels/PhabricatorUserOAuthSettingsPanelController.php',
'PhabricatorUserPasswordSettingsPanelController' => 'applications/people/controller/settings/panels/PhabricatorUserPasswordSettingsPanelController.php',
'PhabricatorUserPreferenceSettingsPanelController' => 'applications/people/controller/settings/panels/PhabricatorUserPreferenceSettingsPanelController.php',
'PhabricatorUserPreferences' => 'applications/people/storage/PhabricatorUserPreferences.php',
'PhabricatorUserProfile' => 'applications/people/storage/PhabricatorUserProfile.php',
'PhabricatorUserProfileSettingsPanelController' => 'applications/people/controller/settings/panels/PhabricatorUserProfileSettingsPanelController.php',
'PhabricatorUserSSHKey' => 'applications/people/storage/PhabricatorUserSSHKey.php',
'PhabricatorUserSSHKeysSettingsPanelController' => 'applications/people/controller/settings/panels/PhabricatorUserSSHKeysSettingsPanelController.php',
'PhabricatorUserSearchSettingsPanelController' => 'applications/people/controller/settings/panels/PhabricatorUserSearchSettingsPanelController.php',
'PhabricatorUserSettingsController' => 'applications/people/controller/PhabricatorUserSettingsController.php',
'PhabricatorUserSettingsPanelController' => 'applications/people/controller/settings/panels/PhabricatorUserSettingsPanelController.php',
'PhabricatorUserStatus' => 'applications/people/storage/PhabricatorUserStatus.php',
'PhabricatorUserTestCase' => 'applications/people/storage/__tests__/PhabricatorUserTestCase.php',
'PhabricatorWorker' => 'infrastructure/daemon/workers/PhabricatorWorker.php',
'PhabricatorWorkerDAO' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerDAO.php',
'PhabricatorWorkerTask' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerTask.php',
'PhabricatorWorkerTaskData' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerTaskData.php',
'PhabricatorWorkerTaskDetailController' => 'applications/daemon/controller/PhabricatorWorkerTaskDetailController.php',
'PhabricatorWorkerTaskUpdateController' => 'applications/daemon/controller/PhabricatorWorkerTaskUpdateController.php',
'PhabricatorXHPASTViewController' => 'applications/xhpastview/controller/PhabricatorXHPASTViewController.php',
'PhabricatorXHPASTViewDAO' => 'applications/xhpastview/storage/PhabricatorXHPASTViewDAO.php',
'PhabricatorXHPASTViewFrameController' => 'applications/xhpastview/controller/PhabricatorXHPASTViewFrameController.php',
'PhabricatorXHPASTViewFramesetController' => 'applications/xhpastview/controller/PhabricatorXHPASTViewFramesetController.php',
'PhabricatorXHPASTViewInputController' => 'applications/xhpastview/controller/PhabricatorXHPASTViewInputController.php',
'PhabricatorXHPASTViewPanelController' => 'applications/xhpastview/controller/PhabricatorXHPASTViewPanelController.php',
'PhabricatorXHPASTViewParseTree' => 'applications/xhpastview/storage/PhabricatorXHPASTViewParseTree.php',
'PhabricatorXHPASTViewRunController' => 'applications/xhpastview/controller/PhabricatorXHPASTViewRunController.php',
'PhabricatorXHPASTViewStreamController' => 'applications/xhpastview/controller/PhabricatorXHPASTViewStreamController.php',
'PhabricatorXHPASTViewTreeController' => 'applications/xhpastview/controller/PhabricatorXHPASTViewTreeController.php',
'PhabricatorXHProfController' => 'applications/xhprof/controller/PhabricatorXHProfController.php',
'PhabricatorXHProfProfileController' => 'applications/xhprof/controller/PhabricatorXHProfProfileController.php',
'PhabricatorXHProfProfileSymbolView' => 'applications/xhprof/view/PhabricatorXHProfProfileSymbolView.php',
'PhabricatorXHProfProfileTopLevelView' => 'applications/xhprof/view/PhabricatorXHProfProfileTopLevelView.php',
'PhabricatorXHProfProfileView' => 'applications/xhprof/view/PhabricatorXHProfProfileView.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
'PhameAllBlogListController' => 'applications/phame/controller/blog/list/PhameAllBlogListController.php',
'PhameAllPostListController' => 'applications/phame/controller/post/list/PhameAllPostListController.php',
'PhameBlog' => 'applications/phame/storage/PhameBlog.php',
'PhameBlogDeleteController' => 'applications/phame/controller/blog/PhameBlogDeleteController.php',
'PhameBlogDetailView' => 'applications/phame/view/PhameBlogDetailView.php',
'PhameBlogEditController' => 'applications/phame/controller/blog/PhameBlogEditController.php',
'PhameBlogListBaseController' => 'applications/phame/controller/blog/list/PhameBlogListBaseController.php',
'PhameBlogListView' => 'applications/phame/view/PhameBlogListView.php',
'PhameBlogQuery' => 'applications/phame/query/PhameBlogQuery.php',
'PhameBlogViewController' => 'applications/phame/controller/blog/PhameBlogViewController.php',
Phame - add an "Everyone but Me" view and make published posts truly accessible to the whole world. Summary: accessibility covers not only a given post but also the various "published" views. to keep the code relative clean, this diff also splits up the post list controller logic quite a bit. this also feels like good preparation for some other work around introducing "blogs" which are collections of published posts from bloggers with some fancy features around that. Test Plan: clicked around various parts of the Phame application as a logged in user, a logged in user with no personal posts, and without any user logged in at all. various views all seemed reasonable. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D2898
2012-07-06 00:43:14 +02:00
'PhameBloggerPostListController' => 'applications/phame/controller/post/list/PhameBloggerPostListController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'PhameDraftListController' => 'applications/phame/controller/post/list/PhameDraftListController.php',
'PhamePost' => 'applications/phame/storage/PhamePost.php',
'PhamePostDeleteController' => 'applications/phame/controller/post/PhamePostDeleteController.php',
'PhamePostDetailView' => 'applications/phame/view/PhamePostDetailView.php',
'PhamePostEditController' => 'applications/phame/controller/post/PhamePostEditController.php',
'PhamePostListBaseController' => 'applications/phame/controller/post/list/PhamePostListBaseController.php',
'PhamePostListView' => 'applications/phame/view/PhamePostListView.php',
'PhamePostPreviewController' => 'applications/phame/controller/post/PhamePostPreviewController.php',
'PhamePostQuery' => 'applications/phame/query/PhamePostQuery.php',
'PhamePostViewController' => 'applications/phame/controller/post/PhamePostViewController.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
'PhameUserBlogListController' => 'applications/phame/controller/blog/list/PhameUserBlogListController.php',
Phame - add an "Everyone but Me" view and make published posts truly accessible to the whole world. Summary: accessibility covers not only a given post but also the various "published" views. to keep the code relative clean, this diff also splits up the post list controller logic quite a bit. this also feels like good preparation for some other work around introducing "blogs" which are collections of published posts from bloggers with some fancy features around that. Test Plan: clicked around various parts of the Phame application as a logged in user, a logged in user with no personal posts, and without any user logged in at all. various views all seemed reasonable. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D2898
2012-07-06 00:43:14 +02:00
'PhameUserPostListController' => 'applications/phame/controller/post/list/PhameUserPostListController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'PhortuneStripeBaseController' => 'applications/phortune/stripe/controller/PhortuneStripeBaseController.php',
'PhortuneStripePaymentFormView' => 'applications/phortune/stripe/view/PhortuneStripePaymentFormView.php',
'PhortuneStripeTestPaymentFormController' => 'applications/phortune/stripe/controller/PhortuneStripeTestPaymentFormController.php',
'PhrictionActionConstants' => 'applications/phriction/constants/PhrictionActionConstants.php',
'PhrictionChangeType' => 'applications/phriction/constants/PhrictionChangeType.php',
'PhrictionConstants' => 'applications/phriction/constants/PhrictionConstants.php',
'PhrictionContent' => 'applications/phriction/storage/PhrictionContent.php',
'PhrictionController' => 'applications/phriction/controller/PhrictionController.php',
'PhrictionDAO' => 'applications/phriction/storage/PhrictionDAO.php',
'PhrictionDeleteController' => 'applications/phriction/controller/PhrictionDeleteController.php',
'PhrictionDiffController' => 'applications/phriction/controller/PhrictionDiffController.php',
'PhrictionDocument' => 'applications/phriction/storage/PhrictionDocument.php',
'PhrictionDocumentController' => 'applications/phriction/controller/PhrictionDocumentController.php',
'PhrictionDocumentEditor' => 'applications/phriction/editor/PhrictionDocumentEditor.php',
'PhrictionDocumentPreviewController' => 'applications/phriction/controller/PhrictionDocumentPreviewController.php',
'PhrictionDocumentStatus' => 'applications/phriction/constants/PhrictionDocumentStatus.php',
'PhrictionDocumentTestCase' => 'applications/phriction/storage/__tests__/PhrictionDocumentTestCase.php',
'PhrictionEditController' => 'applications/phriction/controller/PhrictionEditController.php',
'PhrictionHistoryController' => 'applications/phriction/controller/PhrictionHistoryController.php',
'PhrictionListController' => 'applications/phriction/controller/PhrictionListController.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',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
),
'function' =>
array(
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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_format' => 'view/viewutils.php',
'celerity_generate_unique_node_id' => 'infrastructure/celerity/api.php',
'celerity_get_resource_uri' => 'infrastructure/celerity/api.php',
'celerity_register_resource_map' => 'infrastructure/celerity/map.php',
'javelin_render_tag' => 'infrastructure/javelin/markup.php',
'phabricator_date' => 'view/viewutils.php',
'phabricator_datetime' => 'view/viewutils.php',
'phabricator_format_bytes' => 'view/viewutils.php',
'phabricator_format_local_time' => 'view/viewutils.php',
'phabricator_format_relative_time' => 'view/viewutils.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
'phabricator_format_relative_time_detailed' => 'view/viewutils.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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_units_generic' => 'view/viewutils.php',
'phabricator_on_relative_date' => 'view/viewutils.php',
'phabricator_parse_bytes' => 'view/viewutils.php',
'phabricator_relative_date' => 'view/viewutils.php',
'phabricator_render_form' => 'infrastructure/javelin/markup.php',
'phabricator_time' => 'view/viewutils.php',
'phid_get_type' => 'applications/phid/utils.php',
'phid_group_by_type' => 'applications/phid/utils.php',
'require_celerity_resource' => 'infrastructure/celerity/api.php',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
),
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
'xmap' =>
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
array(
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',
Send 403 for admin pages without being admin Summary: I've also moved the response generation for 404 from ##AphrontDefaultApplicationConfiguration## to ##buildResponseString()## Test Plan: Visit / Visit /mail/ Visit /x/ Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley, vrana Differential Revision: https://secure.phabricator.com/D1406
2012-01-15 10:07:56 +01:00
'Aphront403Response' => 'AphrontWebpageResponse',
'Aphront404Response' => 'AphrontWebpageResponse',
Javelin integration.
2011-01-25 20:57:47 +01:00
'AphrontAjaxResponse' => 'AphrontResponse',
Improve drag-and-drop uploader Summary: Make it discoverable, show uploading progress, show file thumbnails, allow you to remove files, make it a generic form component. Test Plan: Uploaded ducks Reviewed By: tomo Reviewers: aran, tomo, jungejason, tuomaspelkonen CC: anjali, aran, epriestley, tomo Differential Revision: 334
2011-05-23 01:11:41 +02:00
'AphrontAttachedFileView' => 'AphrontView',
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',
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
'AphrontCalendarMonthView' => 'AphrontView',
Tweak style on "Create Another Task" button Summary: Not totally sure I'm in love with this but I think it's somewhat non-terrible, despite the lack of lens flare. Also made "Cancel" take you back to the task if you got to "Create" from "Create Another Task". Test Plan: - Style: https://secure.phabricator.com/file/view/PHID-FILE-ad37d3c1f3b2c7a7a7d1/ - Hit "Cancel" from "Create Another", got sent back to task. - Hit "Cancel" from normal create, got sent back to list. - Tried to save an invalid task after making changes to CC/Projects, changes were preserved. Reviewed By: codeblock Reviewers: hunterbridges, jungejason, tuomaspelkonen, aran, codeblock CC: aran, epriestley, codeblock Differential Revision: 736
2011-07-27 19:46:22 +02:00
'AphrontContextBarView' => 'AphrontView',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'AphrontCrumbsView' => 'AphrontView',
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',
'AphrontDialogView' => 'AphrontView',
'AphrontErrorView' => 'AphrontView',
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',
Improve file preview in Maniphest Summary: Show large thumbnails of attached files in Maniphest. Test Plan: Looked at large thumbnails in Maniphest. Reviewed By: jungejason Reviewers: tomo, aran, jungejason, tuomaspelkonen CC: anjali, aran, epriestley, jungejason Differential Revision: 335
2011-05-23 02:06:42 +02:00
'AphrontFilePreviewView' => 'AphrontView',
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',
Various fixes, particularly on the revision update workflow.
2011-02-05 02:53:14 +01:00
'AphrontFormDividerControl' => 'AphrontFormControl',
Improve drag-and-drop uploader Summary: Make it discoverable, show uploading progress, show file thumbnails, allow you to remove files, make it a generic form component. Test Plan: Uploaded ducks Reviewed By: tomo Reviewers: aran, tomo, jungejason, tuomaspelkonen CC: anjali, aran, epriestley, tomo Differential Revision: 334
2011-05-23 01:11:41 +02:00
'AphrontFormDragAndDropUploadControl' => 'AphrontFormControl',
Phabricator file upload application.
2011-01-23 03:33:00 +01:00
'AphrontFormFileControl' => 'AphrontFormControl',
Robustify profile image controls ever so slightly Summary: show project profile image on pertinent edit page. also add a "Use Default Image" checkbox for both project and user profiles. Also added a function for projects to get the profile picture to prevent some copy + paste action. Test Plan: set my user profile and project profile image. clicked "Use Default Image" and got the default image back. Reviewers: epriestley, floatinglomas Reviewed By: floatinglomas CC: aran, Korvin Maniphest Tasks: T1307 Differential Revision: https://secure.phabricator.com/D2852
2012-06-26 17:14:15 +02:00
'AphrontFormImageControl' => 'AphrontFormControl',
Inset view controller for inset elements of forms. Summary: T937 suggests 'inset' could have its own view controller. It has the following methods: - setTitle for title - setRightbutton if you have to place something (preferably a button) on the right side of the form - setDescription if you want to describe what it does - setContent for the main content - addDivAttributes REALLY not sure about this one but it had to be included because of a single controller (see owners/controller/edit/PhabricatorOwnersEditController.php:238) - appendChild works as usual if your form is complex but you still want to remove ->appendChild('<div class..') ->appendChild('</div>'); It might be an overkill so maybe some could be dropped: - addDivAttributes() and just rewrite how PhabricatorOwnersEditController.php works - setContent() and use appendChild for the main content? Test Plan: - Looked at the controllers in phabricator - Changed the controller - Opened the page in another tab - If something didnd't look the same I fixed it. Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1926
2012-03-16 01:10:19 +01:00
'AphrontFormInsetView' => 'AphrontView',
Allow projects to be quickly added from the Maniphest task creation interface Summary: Provide a quick workflow for adding a new project. This ended up being sort of complicated because we don't currently put forms in dialogs. I separated the actual <form /> tag out of the display/layout of AphrontFormView to enable this (the dialog is itself a form). Limitations: if you create a new project and then remove it, it won't appear in the tokenizer until you reload the page. We need to add the ability for the datasource to drop its cache to enable this, which is super complicated. Test Plan: Used "Create new project" to add a new project when creating a task. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran CC: anjali, aran, epriestley Differential Revision: 422
2011-06-10 00:28:29 +02:00
'AphrontFormLayoutView' => 'AphrontView',
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',
AphrontListFilterView, for list filtering.
2011-04-04 00:50:06 +02:00
'AphrontFormToggleButtonsControl' => 'AphrontFormControl',
Typeaheads
2011-01-25 22:48:05 +01:00
'AphrontFormTokenizerControl' => 'AphrontFormControl',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontFormView' => 'AphrontView',
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',
Unify headsup action lists. Summary: Test Plan: Reviewers: CC:
2011-02-20 21:50:28 +01:00
'AphrontHeadsupActionListView' => 'AphrontView',
'AphrontHeadsupActionView' => 'AphrontView',
Unify Differential/Maniphest/Diffusion styles and allow commits to be flagged explicitly Summary: - Differential, Maniphest and Diffusion use slightly different styles for the object detail panels. - Instead, use the same styles and CSS. - Add object actions to Diffusion, including "Flag". Test Plan: Looked at revisions, tasks and commit. Flagged and unflagged commits. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T1041 Differential Revision: https://secure.phabricator.com/D2062
2012-03-30 23:12:10 +02:00
'AphrontHeadsupView' => 'AphrontView',
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',
Reduce size of "Unbreak Now" and "Needs Triage" panels when no action is required Summary: Make these things like 1/4th the size if they aren't actionable. Test Plan: Loaded home page with actionable, unactionable panels. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1613
2012-02-15 01:23:53 +01:00
'AphrontMiniPanelView' => 'AphrontView',
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',
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',
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',
AphrontPagerView and UIExamples.
2011-04-01 02:06:33 +02:00
'AphrontPagerView' => 'AphrontView',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontPanelView' => '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',
Minor, formalize changeset response class.
2012-03-13 05:39:05 +01:00
'AphrontProxyResponse' => 'AphrontResponse',
Authentication
2011-01-26 22:21:12 +01:00
'AphrontRedirectException' => 'AphrontException',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontRedirectResponse' => 'AphrontResponse',
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',
Make 404 page somewhat prettier.
2011-01-30 18:15:01 +01:00
'AphrontRequestFailureView' => 'AphrontView',
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',
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',
Conduit server-side basics.
2011-01-24 18:00:29 +01:00
'AphrontSideNavView' => 'AphrontView',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontTableView' => '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 tag support in Diffusion Summary: - When viewing a commit, show its tags. - For commits with many tags, show a list of all tags on the tag list interface. - Improve some handling of symbolic references. - When tags contain content, show it on the browse view reached by clicking the tag name. Test Plan: Looked at commits with and without tags, clicked "More tags...", clicked tag names. Reviewers: btrahan, vrana, davidreuss, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1130 Differential Revision: https://secure.phabricator.com/D2290
2012-04-24 03:36:25 +02:00
'AphrontUsageException' => 'AphrontException',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontWebpageResponse' => 'AphrontResponse',
Celerity, a Haste-style static resource management system.
2011-01-25 18:59:31 +01:00
'CelerityResourceController' => 'AphrontController',
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',
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',
Add an "arcanist.projectinfo" Conduit call Summary: We currently rely on "remote_hooks_enabled" in .arcconfig to determine whether commands like "arc amend" and "arc merge" should imply "arc mark-committed". However, this is a historical artifact that is now bad for a bunch of reasons: - The option name is confusing, it really means 'repository is tracked'. - The option is hard to discover and generally sucks. - We can empirically determine the right answer since we now know if a project is in a tracked repository. Add a call which arcanist can make on these workflows to figure out if it is interacting with a project in a tracked repository or not. Also added an "isTracked()" convenience method to reduce the number of magic strings all over the place. Test Plan: Ran "arcanist.projectinfo" for nonexistent, untracked and tracked projects. Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran Reviewed By: Makinde CC: aran, epriestley, Makinde Differential Revision: 945
2011-09-16 20:42:45 +02:00
'ConduitAPI_arcanist_Method' => 'ConduitAPIMethod',
'ConduitAPI_arcanist_projectinfo_Method' => 'ConduitAPI_arcanist_Method',
Provide an audit.query method for Conduit Summary: Conduit access for open audits. Test Plan: Used test console to run some queries. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1792
2012-03-07 00:12:27 +01:00
'ConduitAPI_audit_Method' => 'ConduitAPIMethod',
'ConduitAPI_audit_query_Method' => 'ConduitAPI_audit_Method',
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
'ConduitAPI_chatlog_Method' => 'ConduitAPIMethod',
'ConduitAPI_chatlog_query_Method' => 'ConduitAPI_chatlog_Method',
'ConduitAPI_chatlog_record_Method' => 'ConduitAPI_chatlog_Method',
Conduit: conduit.connect
2011-01-24 20:30:10 +01:00
'ConduitAPI_conduit_connect_Method' => 'ConduitAPIMethod',
"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
'ConduitAPI_conduit_getcertificate_Method' => 'ConduitAPIMethod',
conduit.ping Summary: Test Plan: Reviewers: CC:
2011-02-19 07:36:32 +01:00
'ConduitAPI_conduit_ping_Method' => 'ConduitAPIMethod',
Diffusion/phd/console improvements.
2011-03-15 21:38:14 +01:00
'ConduitAPI_daemon_launched_Method' => 'ConduitAPIMethod',
'ConduitAPI_daemon_log_Method' => 'ConduitAPIMethod',
Save daemon state to database Summary: To make it easier to monitor daemons, let's store their current state (running, died, exited, or unknown) to the db. The purpose of this is to provide more information on the daemon console about the status of daemons, especially when they are running on multiple machines. This is mostly backend work, with only a few frontend changes. (It is also dependent on a change to libphutil.) These changes will make dead or stuck daemons more obvious, and will allow more work on the frontend to hide daemons (and logs) that have exited cleanly, i.e. ones we don't care about any more. Test Plan: - run db migration, check in db that all daemons were marked as exited - start up a daemon, check in db that it is marked as running - open web interface, check that daemon is listed as running - after daemon has been running for a little bit, check in db that dateModified is being updated (indicating daemon is properly sending heartbeat) - kill -9 daemon (but don't run bin/phd yet), and check that db still shows it as running - edit daemon db entry to show it as being on a different host, and backdate dateModified field by 3 minutes, and check the web ui to show that the status is unknown. - change db entry to have proper host, check in web ui that daemon status is displayed as dead. Check db to see that the status was saved. - run bin/phd stop, and see that the formerly dead daemon is now exited. Reviewers: epriestley, vrana Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3126
2012-08-02 02:06:04 +02:00
'ConduitAPI_daemon_setstatus_Method' => 'ConduitAPIMethod',
Add a "differential.createrawdiff" Conduit method Summary: "differential.creatediff" requires a mostly-parsed diff, but there's no reason we can't make DifferentialDiffs out of raw diffs. This mainly serves to lower the adoption barrier if getting "arc" distributed is too much of a hassle. Test Plan: Made a diff out of a raw block of diff text. Reviewers: ffx, vrana, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2751
2012-06-20 21:35:04 +02:00
'ConduitAPI_differential_Method' => 'ConduitAPIMethod',
Use "closed", not "committed", in Differential Summary: "Committed" is SVN-specific language, and confusing in Git and Mercurial. Use neutral language instead. Test Plan: Inspection. Reviewers: btrahan, Makinde, vrana, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T909 Differential Revision: https://secure.phabricator.com/D2087
2012-04-24 02:40:57 +02:00
'ConduitAPI_differential_close_Method' => 'ConduitAPIMethod',
Add a "createcomment" method to Differential Summary: Added a new method differential.createcomment Task ID: #752014 Test Plan: I created a test diff and called this method via the conduit from a client PHP script to add comments. I confirmed that 1) the comment appeared on the revision, 2) URLs within the comment were turned into hyperlinks, and 3) Phabricator sent a notification email to the people watching the test diff. Reviewers: nh, jungejason, epriestley Reviewed By: nh CC: aran, nh Differential Revision: 1128
2011-11-18 18:16:40 +01:00
'ConduitAPI_differential_createcomment_Method' => 'ConduitAPIMethod',
Conduit: differential.creatediff
2011-01-24 20:01:53 +01:00
'ConduitAPI_differential_creatediff_Method' => 'ConduitAPIMethod',
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
'ConduitAPI_differential_createinline_Method' => 'ConduitAPI_differential_Method',
Add a "differential.createrawdiff" Conduit method Summary: "differential.creatediff" requires a mostly-parsed diff, but there's no reason we can't make DifferentialDiffs out of raw diffs. This mainly serves to lower the adoption barrier if getting "arc" distributed is too much of a hassle. Test Plan: Made a diff out of a raw block of diff text. Reviewers: ffx, vrana, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2751
2012-06-20 21:35:04 +02:00
'ConduitAPI_differential_createrawdiff_Method' => 'ConduitAPI_differential_Method',
differential.createrevision Summary: Conduit method. Test Plan: Meta Reviewers: CC: Differential Revision: 23
2011-02-06 22:49:23 +01:00
'ConduitAPI_differential_createrevision_Method' => 'ConduitAPIMethod',
differential.find Summary: Test Plan: meta Reviewers: CC:
2011-02-06 23:43:06 +01:00
'ConduitAPI_differential_find_Method' => 'ConduitAPIMethod',
Add support for postponed linters Summary: This adds: 1) A new "arc:lint-postponed" diff property which stores a list of lint names that are postponed and a finishpostponedlinters conduit method which removes linters from this list. Postponed linters are shown in the lint details. 2) A updatelintmessages conduit message, which adds additional lint messages to the "arc:lint" diff property. In combination, this provides very basic support for running asynchronous static analysis tools. When the diff is being created, a list of asynchronous static analysis runs can be added to the diff's postponed linters list. As these postponed linters finish up, then can report new lint messages back to the diff then mark themselves as complete. The client is currently responsible for filtering the lint messages by things like affected lines and files. Test Plan: Used conduit call API to add lint messages and remove postponed linters from a test diff. Reviewers: epriestley, vrana, nh, jungejason Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1332 Differential Revision: https://secure.phabricator.com/D2792
2012-06-15 02:09:24 +02:00
'ConduitAPI_differential_finishpostponedlinters_Method' => 'ConduitAPIMethod',
Added a conduit method for getting all the diffs for a revision. Summary: Loading all diffs for a differential revision is needed by at least perflab. Test Plan: Created a simple script that queried the conduit and made sure that it returned correct values. Reviewed By: jungejason Reviewers: jungejason CC: epriestley, jungejason Differential Revision: 155
2011-04-21 00:29:02 +02:00
'ConduitAPI_differential_getalldiffs_Method' => 'ConduitAPIMethod',
Conduit: differential.getcommitmessage Summary: Test Plan: Reviewers: CC:
2011-02-09 18:41:26 +01:00
'ConduitAPI_differential_getcommitmessage_Method' => 'ConduitAPIMethod',
differential.getcommitpaths Summary: Test Plan: Reviewers: CC:
2011-02-19 07:28:03 +01:00
'ConduitAPI_differential_getcommitpaths_Method' => 'ConduitAPIMethod',
Provide differential.getdiff, useful for 'arc patch'. Summary: Test Plan: ran 'arc patch' Reviewers: CC:
2011-02-19 07:15:28 +01:00
'ConduitAPI_differential_getdiff_Method' => 'ConduitAPIMethod',
add a getrevision conduit method Summary: Add a method to get the information about a revision, including its full list of diffs. We could add an option to just return the diff IDs if we wanted. For my use case, I need the full set of information for each diff, so fewer round trips is better. This is also how the old json.php page used to work. Test Plan: Tuomas tested it in his sandbox. Reviewed By: tuomaspelkonen Reviewers: jungejason, tuomaspelkonen, epriestley CC: tuomaspelkonen Differential Revision: 156
2011-04-21 01:38:16 +02:00
'ConduitAPI_differential_getrevision_Method' => 'ConduitAPIMethod',
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
'ConduitAPI_differential_getrevisioncomments_Method' => 'ConduitAPI_differential_Method',
Added a conduit method for querying revision feedback. Summary: Push tools needs information about differential revision comments. Added a method that returns the needed information. Test Plan: Tested that /intern/push/merges shows correct information. Reviewed By: jungejason Reviewers: jungejason CC: epriestley, jungejason Differential Revision: 152
2011-04-20 01:24:45 +02:00
'ConduitAPI_differential_getrevisionfeedback_Method' => 'ConduitAPIMethod',
differential.markcommitted Summary: Test Plan: Reviewers: CC:
2011-02-09 18:48:26 +01:00
'ConduitAPI_differential_markcommitted_Method' => 'ConduitAPIMethod',
differential.parsecommitmessage Test plan: meta
2011-02-06 22:42:00 +01:00
'ConduitAPI_differential_parsecommitmessage_Method' => 'ConduitAPIMethod',
Add differential.query conduit method Summary: Created a differential.query conduit method that is built on top of DifferentialRevisionQuery. I also added support for querying by author, ccs, and reviewers to DifferentialRevisionQuery, so feature parity can be brought up to match differential.find and its backing class DifferentialRevisionListData. Test Plan: Tried a few calls to the conduit call using the web interface, and got back reasonable looking data. Reviewers: epriestley, jungejason, btrahan Reviewed By: epriestley CC: aran, nh, epriestley Differential Revision: 1158
2011-12-02 01:57:06 +01:00
'ConduitAPI_differential_query_Method' => 'ConduitAPIMethod',
Conduit: differential.setdiffproperty
2011-01-24 21:07:34 +01:00
'ConduitAPI_differential_setdiffproperty_Method' => 'ConduitAPIMethod',
differential.updaterevision Summary: Test Plan: meta Reviewers: CC: Differential Revision: 24
2011-02-06 23:00:32 +01:00
'ConduitAPI_differential_updaterevision_Method' => 'ConduitAPIMethod',
Enable updating task->revision assoc Summary: add a conduit method to enable querying revisions' phid from their revision_IDs, and another one to update the task->revision assoc. Test Plan: for querying revision_phid method, tested empty, one, and two revisions in the query. For the one to update the task->revision assoc, I have another diff in facebook which verified it add and remove assoc correctly. Reviewers: tuomaspelkonen, epriestley CC: Differential Revision: 165
2011-04-22 03:47:04 +02:00
'ConduitAPI_differential_updatetaskrevisionassoc_Method' => 'ConduitAPIMethod',
Added a conduit call to update arc unit results for a postponed test. Summary: It was not possible before to update arc unit results for a postponed test. This change makes it possible. Also the number of postponed tests are shown in differential. Let me know if this looks too Facebook specific. Test Plan: Tested the conduit call manually from Conduit Console and updated test results for a diff that had 20 postponed tests. Reviewed By: jungejason Reviewers: epriestley, jungejason Commenters: epriestley CC: slawekbiel, aran, tuomaspelkonen, jungejason, epriestley Differential Revision: 416
2011-06-09 01:16:59 +02:00
'ConduitAPI_differential_updateunitresults_Method' => 'ConduitAPIMethod',
Expose symbol information over Conduit Summary: I want to add a command like "where is ArcanistUnitTestEngine" to phabot. I also want to add a symbol typeahead to Diffusion and generally finish up that feature since it's useful but only half-implemented. Consolidate the query logic and expose the data over Conduit. Test Plan: Used /symbol/ and Conduit to lookup symbols. Reviewers: btrahan, jungejason Reviewed By: jungejason CC: aran, jungejason Maniphest Tasks: T315 Differential Revision: https://secure.phabricator.com/D1260
2011-12-21 18:39:33 +01:00
'ConduitAPI_diffusion_findsymbols_Method' => 'ConduitAPIMethod',
First cut at diffusion.getcommits method
2011-04-14 01:39:08 +02:00
'ConduitAPI_diffusion_getcommits_Method' => 'ConduitAPIMethod',
diffusion.getrecentcommitsbypath Summary: Implement diffusion.getrecentcommitsbypath, a Conduit wrapper over DiffusionHistoryQuery which returns results suitable for consumption by diffusion.getcommits. Test Plan: Conduit console Reviewed By: epriestley Reviewers: epriestley CC: aran, epriestley Differential Revision: 315
2011-05-20 00:36:17 +02:00
'ConduitAPI_diffusion_getrecentcommitsbypath_Method' => 'ConduitAPIMethod',
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
'ConduitAPI_feed_publish_Method' => 'ConduitAPIMethod',
Add conduit feed.query method Summary: This is not totally done yet, and i'm submitting for feedback. Test Plan: Played with various settings in local conduit console. Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T790 Differential Revision: https://secure.phabricator.com/D1555
2012-02-03 01:44:05 +01:00
'ConduitAPI_feed_query_Method' => 'ConduitAPIMethod',
Add file.download to Conduit Summary: This is required to make "arc patch" and "arc export" support binary changes. Test Plan: Called from web console and "arc". Reviewed By: aran Reviewers: tuomaspelkonen, jungejason, aran CC: aran, epriestley Differential Revision: 326
2011-05-21 18:53:50 +02:00
'ConduitAPI_file_download_Method' => 'ConduitAPIMethod',
Add a 'file.info' Conduit method Summary: Need this for 'arc upload' and 'arc download'. Given a file PHID or ID, provides information about it. Test Plan: - Implemented 'arc upload' and 'arc download' based on 'file.info'. - Used Conduit API console to test method. Reviewed By: codeblock Reviewers: codeblock, jungejason, tuomaspelkonen, aran CC: aran, codeblock, epriestley Differential Revision: 741
2011-07-29 19:00:16 +02:00
'ConduitAPI_file_info_Method' => 'ConduitAPIMethod',
Conduit server-side basics.
2011-01-24 18:00:29 +01:00
'ConduitAPI_file_upload_Method' => 'ConduitAPIMethod',
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
'ConduitAPI_flag_Method' => 'ConduitAPIMethod',
Add a flag.delete Conduit method Summary: Fairly straightforward: allow deletion of flags from Conduit. Test Plan: Try arc call-conduit with different ids. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1556 Differential Revision: https://secure.phabricator.com/D3132
2012-08-02 21:25:01 +02:00
'ConduitAPI_flag_delete_Method' => 'ConduitAPI_flag_Method',
Improve the flag.* Conduit methods Summary: - Put the code to generate informational dicts about flags into the base class. - Update flag.delete to accept an object PHID in order to delete the flag on that object, since currently the model is that each object may have at most one flag, and each flag has exactly one object, although the former is not enforced. - Add flag.edit, which creates or updates a flag, optionally with the given color and note. Test Plan: Spend endless hours repeatedly running arc call-conduit and arc flag. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3141
2012-08-03 20:41:33 +02:00
'ConduitAPI_flag_edit_Method' => 'ConduitAPI_flag_Method',
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
'ConduitAPI_flag_query_Method' => 'ConduitAPI_flag_Method',
Bring macros to IRC Summary: Adds a macro handler that spams your channel with macros. Config is: - macro.size: scale macros to this size before rasterizing - macro.sleep: sleep this many seconds between lines (evade flood protection) Test Plan: derpderp Reviewers: kdeggelman, btrahan Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1838
2012-03-09 21:40:03 +01:00
'ConduitAPI_macro_Method' => 'ConduitAPIMethod',
'ConduitAPI_macro_query_Method' => 'ConduitAPI_macro_Method',
Provide a basic maniphest.createtask method via Conduit Summary: This could be a lot fancier but let's see what else we need. Also fixed some bugs with maniphest.info. Test Plan: Used the Conduit web console to create some tasks with different values. Reviewers: jungejason, tuomaspelkonen, aran Reviewed By: jungejason CC: aran, jungejason, epriestley Differential Revision: 824
2011-08-18 00:19:48 +02:00
'ConduitAPI_maniphest_Method' => 'ConduitAPIMethod',
'ConduitAPI_maniphest_createtask_Method' => 'ConduitAPI_maniphest_Method',
Add specific close status queries to maniphest.find (and rename it to maniphest.query) Summary: - Allow clients to query for specific closed statuses (invalid, resolved, wontfix, etc), not just "closed" tasks. - Rename this method to maniphest.query and deprecate maniphest.find as an alias to maniphest.query, for API consistency. Test Plan: Ran queries for all tasks, "wontfix" tasks, closed tasks. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2887
2012-06-29 18:17:19 +02:00
'ConduitAPI_maniphest_find_Method' => 'ConduitAPI_maniphest_query_Method',
Added conduit method to get maniphest transactions Summary: Added a Conduit API method to return all transactions for a given set of task_ids. This will be used to comments and other important information about the tasks. Test Plan: Use Conduit to execute ##maniphest.gettasktransactions## and visually verify that transaction information is returned. Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1361
2012-01-11 04:51:55 +01:00
'ConduitAPI_maniphest_gettasktransactions_Method' => 'ConduitAPI_maniphest_Method',
Provide a basic maniphest.createtask method via Conduit Summary: This could be a lot fancier but let's see what else we need. Also fixed some bugs with maniphest.info. Test Plan: Used the Conduit web console to create some tasks with different values. Reviewers: jungejason, tuomaspelkonen, aran Reviewed By: jungejason CC: aran, jungejason, epriestley Differential Revision: 824
2011-08-18 00:19:48 +02:00
'ConduitAPI_maniphest_info_Method' => 'ConduitAPI_maniphest_Method',
Add specific close status queries to maniphest.find (and rename it to maniphest.query) Summary: - Allow clients to query for specific closed statuses (invalid, resolved, wontfix, etc), not just "closed" tasks. - Rename this method to maniphest.query and deprecate maniphest.find as an alias to maniphest.query, for API consistency. Test Plan: Ran queries for all tasks, "wontfix" tasks, closed tasks. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2887
2012-06-29 18:17:19 +02:00
'ConduitAPI_maniphest_query_Method' => 'ConduitAPI_maniphest_Method',
Add a "maniphest.update" Conduit method Summary: - Add maniphest.update - Add support for auxiliary fields to maniphest.createtask Test Plan: - Created tasks with maniphest.createtask - Updated tasks with maniphest.update Reviewers: btrahan, jungejason, zeeg Reviewed By: btrahan CC: aran, btrahan Differential Revision: https://secure.phabricator.com/D1330
2012-01-06 04:02:50 +01:00
'ConduitAPI_maniphest_update_Method' => 'ConduitAPI_maniphest_Method',
Add owners.query method Summary: Allow callers to find all packages/paths owned by a given user/project. Test Plan: Used conduit api page with -- user owner: PHID-USER-6ce1c976b86e5f3c34f6 (tried both loadPackagesFromProjects true/false) proj owner: PHID-PROJ-r5wnmmaawqsn4tvjmqm4 repo/path: E, /tfb/trunk/www/flib/privacy. Checked both path.getowners and owners.query (all of these are defined internally at fb) Reviewers: epriestley, btrahan, nh Reviewed By: btrahan CC: aran, Koolvin Differential Revision: https://secure.phabricator.com/D2482
2012-05-22 19:19:58 +02:00
'ConduitAPI_owners_query_Method' => 'ConduitAPIMethod',
Provide a paste.create Conduit method Summary: - Allow the console to handle abstract classes correctly. - Move paste dictionary generation to an abstract base class. - Add paste.create. - Add 'objectName', 'parentPHID', and 'content' to Paste info dictionaries (you can use filePHID with file.download to get the content but I think just always sending it back is reasonable). Test Plan: - Use paste.create to create new pastes. - Used paste.info to get existing pastes. - Checked console UI to make sure "paste." didn't show up or anything silly/dumb like that. - Tried to call the method "paste" and got the right exception. Reviewed By: codeblock Reviewers: codeblock, jungejason, tuomaspelkonen, aran CC: aran, codeblock Differential Revision: 747
2011-07-30 03:31:14 +02:00
'ConduitAPI_paste_Method' => 'ConduitAPIMethod',
'ConduitAPI_paste_create_Method' => 'ConduitAPI_paste_Method',
'ConduitAPI_paste_info_Method' => 'ConduitAPI_paste_Method',
Adding conduit API method to find owner for the affected file Summary: Adding method that given a path will go up the folder hierarchy until it finds the owning package and return owners for that package. Task ID: #403724 Test Plan: Tried the new API call through console on various path combinations Reviewed By: epriestley Reviewers: epriestley, dpepper, tuomaspelkonen CC: epriestley, Leon Revert Plan: n/a Tags: bootcamp, Push Efficiency - begin *PUBLIC* platform impact section - Bugzilla: # - end platform impact - Differential Revision: 126
2011-04-12 06:51:36 +02:00
'ConduitAPI_path_getowners_Method' => 'ConduitAPIMethod',
Add user.info and phid.info Conduit methods Summary: Allow user and arbitrary object lookup by PHID. Test Plan: Executed user.whoami, user.info, user.find and phid.info via Conduit console. Reviewers: jungejason, tuomaspelkonen, aran, nh Reviewed By: nh CC: skrul, aran, nh, jungejason, epriestley Differential Revision: 870
2011-08-30 21:03:58 +02:00
'ConduitAPI_phid_Method' => 'ConduitAPIMethod',
'ConduitAPI_phid_info_Method' => 'ConduitAPI_phid_Method',
Improve the flag.* Conduit methods Summary: - Put the code to generate informational dicts about flags into the base class. - Update flag.delete to accept an object PHID in order to delete the flag on that object, since currently the model is that each object may have at most one flag, and each flag has exactly one object, although the former is not enforced. - Add flag.edit, which creates or updates a flag, optionally with the given color and note. Test Plan: Spend endless hours repeatedly running arc call-conduit and arc flag. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3141
2012-08-03 20:41:33 +02:00
'ConduitAPI_phid_lookup_Method' => 'ConduitAPI_phid_Method',
[conduit] create phid.query method Summary: Provide a phid.query method that returns the same information as phid.info, but allows querying for multiple phids at once. Test Plan: Called the method from the web conduit console. Reviewers: btrahan, epriestley, jungejason Reviewed By: epriestley CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1617
2012-02-15 03:26:27 +01:00
'ConduitAPI_phid_query_Method' => 'ConduitAPI_phid_Method',
Provide access to Phriction via Conduit Summary: Provide three Phriction methods for programmatic access to Phriction: - phriction.info: get information about a document - phriction.history: get change history for a document - phriction.edit: create or update a document I moved all the editing/creation logic into a new PhrictionDocumentEditor to share code between the Conduit and Web edit pathways. Test Plan: Got info and history via conduit. Edited and created new pages via conduit and web. Reviewers: hsb, jungejason, tuomaspelkonen, aran, hunterbridges Reviewed By: hunterbridges CC: skrul, aran, hunterbridges Differential Revision: 866
2011-08-26 21:50:28 +02:00
'ConduitAPI_phriction_Method' => 'ConduitAPIMethod',
'ConduitAPI_phriction_edit_Method' => 'ConduitAPI_phriction_Method',
'ConduitAPI_phriction_history_Method' => 'ConduitAPI_phriction_Method',
'ConduitAPI_phriction_info_Method' => 'ConduitAPI_phriction_Method',
Add project.query to Conduit Summary: Add a conduit method to query project information. Test Plan: Ran method from API test console. Reviewers: bill, btrahan, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T681 Differential Revision: https://secure.phabricator.com/D1444
2012-01-18 01:29:35 +01:00
'ConduitAPI_project_Method' => 'ConduitAPIMethod',
'ConduitAPI_project_query_Method' => 'ConduitAPI_project_Method',
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
'ConduitAPI_remarkup_process_Method' => 'ConduitAPIMethod',
Add "repository.create" and "repository.query" methods to Conduit Summary: Primarily for @csilvers who has 92 million repositories or something. This is a touch hacky, but movitated by pragmatism. Test Plan: - Ran "repository.create" to create repositories, "repository.query" to list them. - Tested most or maybe all of the error conditions, probably. Reviewers: btrahan, vrana, csilvers Reviewed By: csilvers CC: aran Differential Revision: https://secure.phabricator.com/D2396
2012-05-05 01:16:22 +02:00
'ConduitAPI_repository_Method' => 'ConduitAPIMethod',
'ConduitAPI_repository_create_Method' => 'ConduitAPI_repository_Method',
'ConduitAPI_repository_query_Method' => 'ConduitAPI_repository_Method',
Conduit method for slowvote.poll.info. Summary: Provides a slowvote.poll.info method. Test Plan: Web console - seemed to work fine. Reviewers: epriestley, phuzion CC: Differential Revision: 659
2011-07-13 04:18:20 +02:00
'ConduitAPI_slowvote_info_Method' => 'ConduitAPIMethod',
Add user.info and phid.info Conduit methods Summary: Allow user and arbitrary object lookup by PHID. Test Plan: Executed user.whoami, user.info, user.find and phid.info via Conduit console. Reviewers: jungejason, tuomaspelkonen, aran, nh Reviewed By: nh CC: skrul, aran, nh, jungejason, epriestley Differential Revision: 870
2011-08-30 21:03:58 +02:00
'ConduitAPI_user_Method' => 'ConduitAPIMethod',
Allowing setting user status Summary: I will use it for highlighting users which are not currently available. Maybe I will also use it in the nagging tool. I don't plan creating a UI for it as API is currently enough for us. Maybe I will visualize it at /calendar/ later. I plan creating `user.deletestatus` method when this one will be done. Test Plan: `storage upgrade` Call Conduit `user.addstatus`. Verify DB. Reviewers: epriestley Reviewed By: epriestley CC: aran, Koolvin Differential Revision: https://secure.phabricator.com/D2382
2012-05-04 00:47:34 +02:00
'ConduitAPI_user_addstatus_Method' => 'ConduitAPI_user_Method',
Add Conduit method to disable user Summary: There's no method for enabling users somewhat intentionally. Test Plan: Disable myself (oops, this is probably my last diff ever). Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D2497
2012-05-18 20:51:24 +02:00
'ConduitAPI_user_disable_Method' => 'ConduitAPI_user_Method',
Add user.enable conduit method Test Plan: enabled a disabled user Reviewers: vrana, epriestley Reviewed By: vrana CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D2800
2012-06-19 23:36:08 +02:00
'ConduitAPI_user_enable_Method' => 'ConduitAPI_user_Method',
Add user.info and phid.info Conduit methods Summary: Allow user and arbitrary object lookup by PHID. Test Plan: Executed user.whoami, user.info, user.find and phid.info via Conduit console. Reviewers: jungejason, tuomaspelkonen, aran, nh Reviewed By: nh CC: skrul, aran, nh, jungejason, epriestley Differential Revision: 870
2011-08-30 21:03:58 +02:00
'ConduitAPI_user_find_Method' => 'ConduitAPI_user_Method',
'ConduitAPI_user_info_Method' => 'ConduitAPI_user_Method',
Conduit user.query method Summary: also includes a PhabricatorPeopleQuery object Test Plan: queried for various combinations username, realname, id, phid, and email. verified correct results. Reviewers: epriestley Reviewed By: epriestley CC: zeeg, aran, Koolvin Maniphest Tasks: T1075 Differential Revision: https://secure.phabricator.com/D2416
2012-05-07 22:35:09 +02:00
'ConduitAPI_user_query_Method' => 'ConduitAPI_user_Method',
Simplify transaction handling and restore read/write locks Summary: - We used to have connection-level caching, so we needed getTransactionKey() to make sure there was one transaction state per real connection. We now cache in Lisk and each Connection object is guaranteed to represent a real, unique connection, so we can make this a non-static. - I kept the classes separate because it was a little easier, but maybe we should merge them? - Also track/implement read/write locking. - (The advantage of this over just writing LOCK IN SHARE MODE is that you can use, e.g., some Query class even if you don't have access to the queries it runs.) Test Plan: Can you come up with a way to write unit tests for this? It seems like testing that it works requires deadlocking MySQL if the test is running in one process. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2398
2012-05-05 20:29:09 +02:00
'ConduitAPI_user_removestatus_Method' => 'ConduitAPI_user_Method',
Add user.info and phid.info Conduit methods Summary: Allow user and arbitrary object lookup by PHID. Test Plan: Executed user.whoami, user.info, user.find and phid.info via Conduit console. Reviewers: jungejason, tuomaspelkonen, aran, nh Reviewed By: nh CC: skrul, aran, nh, jungejason, epriestley Differential Revision: 870
2011-08-30 21:03:58 +02:00
'ConduitAPI_user_whoami_Method' => 'ConduitAPI_user_Method',
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',
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 a "Config" plugin to DarkConsole. Summary: This plugin lets you see how the host is configured at runtime. Test Plan: Reviewers: CC:
2011-02-12 01:48:43 +01:00
'DarkConsoleConfigPlugin' => 'DarkConsolePlugin',
Flesh out some DarkConsole stuff.
2011-02-03 07:38:42 +01:00
'DarkConsoleController' => 'PhabricatorController',
Very rough cut of DarkConsole + XHProf
2011-02-02 22:48:52 +01:00
'DarkConsoleErrorLogPlugin' => 'DarkConsolePlugin',
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',
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
'DarkConsoleEventPluginAPI' => 'PhutilEventListener',
Very rough cut of DarkConsole + XHProf
2011-02-02 22:48:52 +01:00
'DarkConsoleRequestPlugin' => 'DarkConsolePlugin',
'DarkConsoleServicesPlugin' => 'DarkConsolePlugin',
'DarkConsoleXHProfPlugin' => 'DarkConsolePlugin',
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
'DefaultDatabaseConfigurationProvider' => 'DatabaseConfigurationProvider',
Improve behavior when user submits a no-op action in Differential Summary: See T730 and the slightly-less-pretty version of this in D1398. When a user takes an action in Differential that has no effect (for instance, accepting an already-accepted revision), prompt them: Action Has No Effect You can not accept this revision because it has already been accepted. Do you want to post the feedback anyway, as a normal comment? [Cancel] [Post as Comment] If they have no comment text, the dialog only says "Cancel". I think this is probably the best way to balance all the concerns here -- it might occasionally be a little annoying, but that should be rare, and it should never be confusing (the current workflow is extremely confusing). This also fixes the issue where you can add all sorts of CCs who are already part of the revision, either explicitly or via mentions. Test Plan: Posted some has-effect and has-no-effect comments, made different choices in the dialog, everything seems to work OK? Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran, vrana Maniphest Tasks: T730 Differential Revision: https://secure.phabricator.com/D1403
2012-01-14 20:39:22 +01:00
'DifferentialActionHasNoEffectException' => 'DifferentialException',
AddCommentView
2011-01-30 20:02:22 +01:00
'DifferentialAddCommentView' => 'AphrontView',
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',
Move Differential's simple fields to the extensible field schema Summary: Differential has a bunch of display-only fields, implement them all as field specifications instead of hard-coded fields. Also add some more documentation and fix redundant string constants in blame rev/revert plan fields. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 807
2011-08-14 20:29:56 +02:00
'DifferentialApplyPatchFieldSpecification' => 'DifferentialFieldSpecification',
Move Differential's read-only fields to the extensible field schema Summary: Move additional fields (which rely on loading handles) to the extensible field classes and out of hardcoding in the controller. Depends on D807. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 808
2011-08-14 21:33:54 +02:00
'DifferentialArcanistProjectFieldSpecification' => 'DifferentialFieldSpecification',
Add an "Auditors" field to commit messages which pushes audit requests when present Summary: Adds an optional "Auditors" field (like "Reviewers") to commit messages which gives installs a zero-config method for making audit requests. This field does not appear on templates unless set, and is mostly ignored (but validated and preserved) by Differential. It is then parsed by the daemons if present, and audit requests are pushed to valid users. Test Plan: Made an "Auditors" commit and verified it was retained with "arc amend --show". Pushed it and verified the audit was triggered. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904, T880 Differential Revision: https://secure.phabricator.com/D1793
2012-03-07 00:10:35 +01:00
'DifferentialAuditorsFieldSpecification' => 'DifferentialFieldSpecification',
Move Differential's read-only fields to the extensible field schema Summary: Move additional fields (which rely on loading handles) to the extensible field classes and out of hardcoding in the controller. Depends on D807. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 808
2011-08-14 21:33:54 +02:00
'DifferentialAuthorFieldSpecification' => 'DifferentialFieldSpecification',
Add basic auxiliary field storage for Differential Summary: Precursor to building this out to solve T343. This is similar to the Maniphest fields we landed recently, although I think they're dissimilar enough that it isn't worth going crazy trying to make them share code, at least for now. This doesn't really do anything yet, just adds a storage object and a couple of selector/field indirection classes. Test Plan: Ran SQL upgrade script, created an aux field. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason Differential Revision: 798
2011-08-10 20:29:08 +02:00
'DifferentialAuxiliaryField' => 'DifferentialDAO',
Provide builtin definitions for "Blame Revision" and "Revert Plan" fields Summary: This is just to ease transitions for any installs which use these fields (e.g., Facebook). I'll write some docs and a migration script once this stuff is a little more solid, too. Depends on D800. Technically these are "better" than the current fields since they show up other places than the edit screen (derp derp). Test Plan: Created a field selector which provides these; verified they work by typing stuff into them and saving the revision. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, epriestley, jungejason Differential Revision: 801
2011-08-11 00:36:18 +02:00
'DifferentialBlameRevisionFieldSpecification' => 'DifferentialFieldSpecification',
Separate field for branch in revision Summary: The main purpose of this change is to allow selecting the branch by triple-click. Plus it is not perfectly clear that the text in brackets means branch. Test Plan: Display revision. Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1585
2012-02-07 01:34:25 +01:00
'DifferentialBranchFieldSpecification' => 'DifferentialFieldSpecification',
DifferentialRevisionEditor
2011-01-26 02:17:19 +01:00
'DifferentialCCWelcomeMail' => 'DifferentialReviewRequestMail',
Move Differential's remaining field views to extensble field schema Summary: Move all the rest of the fields into the custom field schema, for revision views. I left a couple of stubs in here (willWriteRevision, didWriteRevision) since I'd planned to do edits here too, but this diff is sort of big-ish already. I'll do all the edit fields in the next revision. Depends on D808. Test Plan: Viewed, edited and conduit'ed some revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 809
2011-08-14 22:55:30 +02:00
'DifferentialCCsFieldSpecification' => 'DifferentialFieldSpecification',
Conduit: differential.creatediff
2011-01-24 20:01:53 +01:00
'DifferentialChangeset' => 'DifferentialDAO',
DifferentialDiffView
2011-01-24 22:18:41 +01:00
'DifferentialChangesetDetailView' => 'AphrontView',
Javelin integration.
2011-01-25 20:57:47 +01:00
'DifferentialChangesetListView' => 'AphrontView',
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' => 'ArcanistPhutilTestCase',
DifferentialChangesetView
2011-01-25 00:52:35 +01:00
'DifferentialChangesetViewController' => 'DifferentialController',
Basic Differential revision feedback view.
2011-01-30 19:37:36 +01:00
'DifferentialComment' => 'DifferentialDAO',
Write pathway for Differential Comments
2011-01-30 21:08:40 +01:00
'DifferentialCommentMail' => 'DifferentialMail',
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',
Move Differential's read-only fields to the extensible field schema Summary: Move additional fields (which rely on loading handles) to the extensible field classes and out of hardcoding in the controller. Depends on D807. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 808
2011-08-14 21:33:54 +02:00
'DifferentialCommitsFieldSpecification' => 'DifferentialFieldSpecification',
DifferentialDiffView
2011-01-24 22:18:41 +01:00
'DifferentialController' => 'PhabricatorController',
Conduit: differential.creatediff
2011-01-24 20:01:53 +01:00
'DifferentialDAO' => 'PhabricatorLiskDAO',
Drive differential revision list with custom fields Summary: Build the revision list table out of custom fields instead of hard-coding it, so installs can add all sorts of zany things to it. NOTE: You may need to implement sortFieldsForRevisionList() if you have a custom DifferentialFieldSelector, or some fields might show up out of order. This implementation will preserve the expected behavior: public function sortFieldsForRevisionList(array $fields) { $default = new DifferentialDefaultFieldSelector(); return $default->sortFieldsForRevisionList($fields); } Test Plan: - Loaded differential revision list, identical to old list. - Profiled page to verify the cost increase isn't significant (it's quite small). Reviewers: jungejason, btrahan Reviewed By: btrahan CC: aran, btrahan, davidreuss, epriestley Maniphest Tasks: T773, T729 Differential Revision: https://secure.phabricator.com/D1388
2012-02-20 14:38:21 +01:00
'DifferentialDateCreatedFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialDateModifiedFieldSpecification' => 'DifferentialFieldSpecification',
Add basic auxiliary field storage for Differential Summary: Precursor to building this out to solve T343. This is similar to the Maniphest fields we landed recently, although I think they're dissimilar enough that it isn't worth going crazy trying to make them share code, at least for now. This doesn't really do anything yet, just adds a storage object and a couple of selector/field indirection classes. Test Plan: Ran SQL upgrade script, created an aux field. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason Differential Revision: 798
2011-08-10 20:29:08 +02:00
'DifferentialDefaultFieldSelector' => 'DifferentialFieldSelector',
Move Differential's read-only fields to the extensible field schema Summary: Move additional fields (which rely on loading handles) to the extensible field classes and out of hardcoding in the controller. Depends on D807. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 808
2011-08-14 21:33:54 +02:00
'DifferentialDependenciesFieldSpecification' => 'DifferentialFieldSpecification',
Conduit: differential.creatediff
2011-01-24 20:01:53 +01:00
'DifferentialDiff' => 'DifferentialDAO',
DifferentialRevisionEditor
2011-01-26 02:17:19 +01:00
'DifferentialDiffContentMail' => 'DifferentialMail',
Differential lazyweb diff create workflow.
2011-02-05 21:20:18 +01:00
'DifferentialDiffCreateController' => 'DifferentialController',
Conduit: differential.setdiffproperty
2011-01-24 21:07:34 +01:00
'DifferentialDiffProperty' => 'DifferentialDAO',
DifferentialDiffView
2011-01-24 22:18:41 +01:00
'DifferentialDiffTableOfContentsView' => 'AphrontView',
'DifferentialDiffViewController' => 'DifferentialController',
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
'DifferentialException' => 'Exception',
Add reply handler for differential revision Summary: add email reply handler so that the user can reply to a differential email to act on the revision. It generates the reply-to email address, creates email body text with supported commands list, and handle the action request on the differential revision. Right now the reply-to handing is disabled in the config file. But a site using Phabricator can enable it and implement a class inheriting from DifferentialReplyHandler to enable customized email handing. Later we will need to add code to DifferentialMail.php to support sending separate email to each email recipient to achieve better security (see D226). The reply-to will be something like D<revision_id>+<user_id>+<hash>@domain.com. We will create separate task for it. Test Plan: tried comment on a revision from web UI and the email was sent out as before without any change. When a subclass of DifferentialReplyHandler is implemented and enabled, email's reply-to is set and email text is added. Reply to the email with valid command did create action to the revision. Reviewed By: epriestley Reviewers: tuomaspelkonen, epriestley, slawekbiel, dpepper CC: aran, epriestley, jungejason Differential Revision: 224
2011-05-01 04:40:05 +02:00
'DifferentialExceptionMail' => 'DifferentialMail',
Move Differential's simple fields to the extensible field schema Summary: Differential has a bunch of display-only fields, implement them all as field specifications instead of hard-coded fields. Also add some more documentation and fix redundant string constants in blame rev/revert plan fields. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 807
2011-08-14 20:29:56 +02:00
'DifferentialExportPatchFieldSpecification' => 'DifferentialFieldSpecification',
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
'DifferentialFieldDataNotAvailableException' => 'Exception',
'DifferentialFieldParseException' => 'Exception',
'DifferentialFieldSpecificationIncompleteException' => 'Exception',
'DifferentialFieldValidationException' => 'Exception',
Drive revision update from Conduit via custom fields Summary: When we create or update a revision, we use a parsed commit message dictionary to edit its fields. Drive consumption of the dictionary through custom fields instead of hardcoding. This requires adding some fields which don't really do anything right now to cover fields which appear only in the commit message. Test Plan: "arc diff"'d this revision against localhost, "arc diff"'d again to update. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason Differential Revision: 811
2011-08-15 03:52:09 +02:00
'DifferentialGitSVNIDFieldSpecification' => 'DifferentialFieldSpecification',
Move Differential's simple fields to the extensible field schema Summary: Differential has a bunch of display-only fields, implement them all as field specifications instead of hard-coded fields. Also add some more documentation and fix redundant string constants in blame rev/revert plan fields. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 807
2011-08-14 20:29:56 +02:00
'DifferentialHostFieldSpecification' => 'DifferentialFieldSpecification',
Conduit: differential.creatediff
2011-01-24 20:01:53 +01:00
'DifferentialHunk' => 'DifferentialDAO',
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' => 'ArcanistPhutilTestCase',
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
'DifferentialInlineComment' =>
array(
0 => 'DifferentialDAO',
1 => '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',
Use an inline dialog element for inline comments in Differential Summary: The current approach of using a modal overlay dialog to create/edit inline comments is pretty silly. Use an inline textarea instead. This element isn't perfect and we have some mild modalness issues, but I think it's better than the silly thing we've got going on right now. We can keep poking it as people break it. Test Plan: - Created comments; submitted and undid them in empty and nonempty states. Used undo for nonempty states + cancel. - Edited comments; saved and canceled them. Used undo for changed state. - Replied to comments; yada yada as above. - Deleted comments. - Did various modal trickery where I clicked "Reply" on something else with a dialog already up, this very mildly glitches but I think it's not a big issue. Reviewers: vrana, btrahan, Makinde, nh Reviewed By: vrana CC: aran, epriestley Maniphest Tasks: T431 Differential Revision: https://secure.phabricator.com/D1716
2012-02-29 23:28:48 +01:00
'DifferentialInlineCommentEditView' => 'AphrontView',
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',
InlineComments
2011-02-02 01:42:36 +01:00
'DifferentialInlineCommentView' => 'AphrontView',
Move Differential's simple fields to the extensible field schema Summary: Differential has a bunch of display-only fields, implement them all as field specifications instead of hard-coded fields. Also add some more documentation and fix redundant string constants in blame rev/revert plan fields. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 807
2011-08-14 20:29:56 +02:00
'DifferentialLinesFieldSpecification' => 'DifferentialFieldSpecification',
Move Differential's remaining field views to extensble field schema Summary: Move all the rest of the fields into the custom field schema, for revision views. I left a couple of stubs in here (willWriteRevision, didWriteRevision) since I'd planned to do edits here too, but this diff is sort of big-ish already. I'll do all the edit fields in the next revision. Depends on D808. Test Plan: Viewed, edited and conduit'ed some revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 809
2011-08-14 22:55:30 +02:00
'DifferentialLintFieldSpecification' => 'DifferentialFieldSpecification',
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',
Move Differential's read-only fields to the extensible field schema Summary: Move additional fields (which rely on loading handles) to the extensible field classes and out of hardcoding in the controller. Depends on D807. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 808
2011-08-14 21:33:54 +02:00
'DifferentialManiphestTasksFieldSpecification' => 'DifferentialFieldSpecification',
DifferentialRevisionEditor
2011-01-26 02:17:19 +01:00
'DifferentialNewDiffMail' => 'DifferentialReviewRequestMail',
Move Differential's simple fields to the extensible field schema Summary: Differential has a bunch of display-only fields, implement them all as field specifications instead of hard-coded fields. Also add some more documentation and fix redundant string constants in blame rev/revert plan fields. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 807
2011-08-14 20:29:56 +02:00
'DifferentialPathFieldSpecification' => 'DifferentialFieldSpecification',
Provide basic capabilities to make Differential column width flexible Summary: - Make wrap width settable in PHP. - Dynamically generate max-width based on configurable maximum width. - Constrain non-diff elements to standard width. - Provide a configuration setting. Test Plan: Set various things to 100 / 120, as far as I could tell everything seemed to render sensibly? This should have no effect on 80-col changes. Reviewed By: jdperlow Reviewers: jdperlow, tuomaspelkonen, jungejason, aran CC: aran, jdperlow Differential Revision: 413
2011-06-08 21:39:03 +02:00
'DifferentialPrimaryPaneView' => 'AphrontView',
Support email multiplexing for private Reply-To addresses Summary: Provide a base PhabricatorMailReplyHandler class which handles the plumbing for multiplexing email if necessary and supporting public and private reply handler addressses. DifferentialReplyHandler now extends it, and a new ManiphestReplyHandler also does. The general approach here is that we have three supported cases: - no reply handler, default config, same as what we're doing now - public reply handler, requires overriding classes but just sets "reply-to" to some address the install generates and still sends only one email - private reply handler, provides a default generation mechanism or you can override it and splits mail apart so we send one to each recipient Test Plan: Sent email from Maniphest and Differential with and without reply-handler-domains set. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran CC: aran, epriestley Differential Revision: 254
2011-05-10 01:31:26 +02:00
'DifferentialReplyHandler' => 'PhabricatorMailReplyHandler',
Further improve unit/lint rendering Summary: I think this improves things, let me know if you have feedback. Also addresses T840. Test Plan: See screenshots... Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran, zeeg Maniphest Tasks: T840 Differential Revision: https://secure.phabricator.com/D2357
2012-05-01 19:15:56 +02:00
'DifferentialResultsTableView' => 'AphrontView',
Provide builtin definitions for "Blame Revision" and "Revert Plan" fields Summary: This is just to ease transitions for any installs which use these fields (e.g., Facebook). I'll write some docs and a migration script once this stuff is a little more solid, too. Depends on D800. Technically these are "better" than the current fields since they show up other places than the edit screen (derp derp). Test Plan: Created a field selector which provides these; verified they work by typing stuff into them and saving the revision. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, epriestley, jungejason Differential Revision: 801
2011-08-11 00:36:18 +02:00
'DifferentialRevertPlanFieldSpecification' => 'DifferentialFieldSpecification',
DifferentialRevisionEditor
2011-01-26 02:17:19 +01:00
'DifferentialReviewRequestMail' => 'DifferentialMail',
Drive revision update from Conduit via custom fields Summary: When we create or update a revision, we use a parsed commit message dictionary to edit its fields. Drive consumption of the dictionary through custom fields instead of hardcoding. This requires adding some fields which don't really do anything right now to cover fields which appear only in the commit message. Test Plan: "arc diff"'d this revision against localhost, "arc diff"'d again to update. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason Differential Revision: 811
2011-08-15 03:52:09 +02:00
'DifferentialReviewedByFieldSpecification' => 'DifferentialFieldSpecification',
Compute reviewer stats Summary: The final goal is to display reviewers response time on homepage. This is a building block for it. The algorithm is quite strict - it doesn't count simple comment as response because reviewers would be able to cheat with comments like "I'm overwhelmed right now and will review next week". We are more liberate in Phabricator where reviewers response with comments without changing the status quite often but I'm not trying to improve response times in Phabricator so this is irrelevant. Reviewers in Facebook changes status more often (to clean their queue) so I follow this approach. There is currently no way to track reviewers silently added and removed in Edit Revision but it's not a big deal. The algorithm doesn't track commandeered revision, there's a TODO for it. Response times are put in two buckets: `$reviewed` and `$not_reviewed`. `$reviewed` contains reviewers who took action, `$not_reviewed` contains reviewers who didn't respond on time. I will probably compute average time from `$reviewed` and raise it for those `$not_reviewed` that are higher than this average. The idea is to not favor reviewers who were only lucky for being in a group with someone fast. Test Plan: Passed test. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3062
2012-07-25 02:58:33 +02:00
'DifferentialReviewerStatsTestCase' => 'PhabricatorTestCase',
Move Differential's remaining field views to extensble field schema Summary: Move all the rest of the fields into the custom field schema, for revision views. I left a couple of stubs in here (willWriteRevision, didWriteRevision) since I'd planned to do edits here too, but this diff is sort of big-ish already. I'll do all the edit fields in the next revision. Depends on D808. Test Plan: Viewed, edited and conduit'ed some revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 809
2011-08-14 22:55:30 +02:00
'DifferentialReviewersFieldSpecification' => 'DifferentialFieldSpecification',
Conduit: differential.creatediff
2011-01-24 20:01:53 +01:00
'DifferentialRevision' => 'DifferentialDAO',
Basic Differential revision feedback view.
2011-01-30 19:37:36 +01:00
'DifferentialRevisionCommentListView' => 'AphrontView',
'DifferentialRevisionCommentView' => 'AphrontView',
DifferentialRevisionView
2011-01-27 23:55:52 +01:00
'DifferentialRevisionDetailView' => 'AphrontView',
RevisionEdit
2011-01-25 22:26:09 +01:00
'DifferentialRevisionEditController' => 'DifferentialController',
Emit full URIs to identify Differential revisions Summary: - Previously, used IDs like "33" to match a commit to a Differential revision. This has a namespacing problem because we now have an arbitrarily large number of Phabricator installs in the world, and they may want to track commits from other installs. - In Differential, parse raw IDs or full URIs. Emit only full URIs. - In Repositories, parse only full URIs. - This might cause a few commits to not be picked up in rare circumstances. Users can fix them with "arc mark-committed". This should be exceedingly rare because of hash matching. - There are some caveats for reparsing older repositories, see comments inline. I don't think there's much broad impact here. Test Plan: - Created a new revision, got a full URI. - Updated revision, worked correctly. - Ran unit tests. - Monkeyed with "Differential Revision" field. - Reviewers: btrahan, jungejason Reviewers: btrahan, jungejason Reviewed By: jungejason CC: aran, epriestley, jungejason Maniphest Tasks: T54, T692 Differential Revision: 1250
2011-12-21 00:40:24 +01:00
'DifferentialRevisionIDFieldParserTestCase' => 'PhabricatorTestCase',
Drive revision update from Conduit via custom fields Summary: When we create or update a revision, we use a parsed commit message dictionary to edit its fields. Drive consumption of the dictionary through custom fields instead of hardcoding. This requires adding some fields which don't really do anything right now to cover fields which appear only in the commit message. Test Plan: "arc diff"'d this revision against localhost, "arc diff"'d again to update. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason Differential Revision: 811
2011-08-15 03:52:09 +02:00
'DifferentialRevisionIDFieldSpecification' => 'DifferentialFieldSpecification',
RevisionList
2011-01-26 00:19:06 +01: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',
Various statistics about revisions at /differential/stats/revisions/ Summary: Show some statistics, like number of revisions, number of revisions per week, lines per revision, etc. for phrivolous amusement. Test Plan: - Went to /differential/stats/revisions/ Numbers seem right - Clicked 'Accepted' Again - Changed to another user with long history Load time was not too long though delay noticeable - Clicked 'Requested changes to' User was preserved, looks good Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1643
2012-02-19 05:16:35 +01:00
'DifferentialRevisionStatsController' => 'DifferentialController',
'DifferentialRevisionStatsView' => 'AphrontView',
Move Differential's remaining field views to extensble field schema Summary: Move all the rest of the fields into the custom field schema, for revision views. I left a couple of stubs in here (willWriteRevision, didWriteRevision) since I'd planned to do edits here too, but this diff is sort of big-ish already. I'll do all the edit fields in the next revision. Depends on D808. Test Plan: Viewed, edited and conduit'ed some revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 809
2011-08-14 22:55:30 +02:00
'DifferentialRevisionStatusFieldSpecification' => 'DifferentialFieldSpecification',
DifferentialRevisionView
2011-01-27 23:55:52 +01:00
'DifferentialRevisionUpdateHistoryView' => 'AphrontView',
'DifferentialRevisionViewController' => 'DifferentialController',
Make subscribe/unsubscribe work properly on Revisions. Summary: Test Plan: Reviewers: CC:
2011-02-19 23:36:13 +01:00
'DifferentialSubscribeController' => 'DifferentialController',
Implement all field edit interfaces on the custom field schema Summary: Moves the revision edit controller to be completely schema-driven. Depends on D810. Test Plan: Edited revisions. Entered intentionally invalid values to trigger error conditions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 810
2011-08-14 23:28:08 +02:00
'DifferentialSummaryFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialTestPlanFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialTitleFieldSpecification' => 'DifferentialFieldSpecification',
Move Differential's remaining field views to extensble field schema Summary: Move all the rest of the fields into the custom field schema, for revision views. I left a couple of stubs in here (willWriteRevision, didWriteRevision) since I'd planned to do edits here too, but this diff is sort of big-ish already. I'll do all the edit fields in the next revision. Depends on D808. Test Plan: Viewed, edited and conduit'ed some revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 809
2011-08-14 22:55:30 +02:00
'DifferentialUnitFieldSpecification' => 'DifferentialFieldSpecification',
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',
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
'DiffusionBrowseFileController' => 'DiffusionController',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionBrowseTableView' => 'DiffusionView',
Browse / git improvements.
2011-03-14 06:03:30 +01:00
'DiffusionChangeController' => 'DiffusionController',
Show audit comments on the Diffusion commit view Summary: We already allow you to create comments, but we don't show them on the commit page. After style / view unification this is easy; show comments on the commit page. Test Plan: Made comments on a commit using the audit too, saw them show up in Diffusion. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1687
2012-02-24 23:14:39 +01:00
'DiffusionCommentListView' => 'AphrontView',
'DiffusionCommentView' => 'AphrontView',
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',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionCommitChangeTableView' => 'DiffusionView',
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',
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',
Show parent commits in Diffusion Summary: Show parent commit information to make it easier to understand merges. Test Plan: Looked at commits in SVN, hg, git. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T961 Differential Revision: https://secure.phabricator.com/D2021
2012-03-26 21:21:48 +02:00
'DiffusionCommitParentsQuery' => 'DiffusionQuery',
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',
Improve tag support in Diffusion Summary: - When viewing a commit, show its tags. - For commits with many tags, show a list of all tags on the tag list interface. - Improve some handling of symbolic references. - When tags contain content, show it on the browse view reached by clicking the tag name. Test Plan: Looked at commits with and without tags, clicked "More tags...", clicked tag names. Reviewers: btrahan, vrana, davidreuss, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1130 Differential Revision: https://secure.phabricator.com/D2290
2012-04-24 03:36:25 +02:00
'DiffusionCommitTagsQuery' => 'DiffusionQuery',
Show all branches a commit appears on Summary: We show the contextual branch (always the repository default branch) when viewing a commit. Instead, show all branches the commit appears on. Also pull some of the duplicated DiffusionXQuery stuff into a DiffusionQuery base class, I'll do a followup to reduce more duplication. Test Plan: Looked at a commit in Git. My HG and SVN setups are a little borked so I kind of faked tests in them -- I'm fixing them now. Reviewers: btrahan, jungejason, fratrik Reviewed By: btrahan CC: aran Maniphest Tasks: T768 Differential Revision: https://secure.phabricator.com/D1458
2012-01-19 20:49:51 +01:00
'DiffusionContainsQuery' => 'DiffusionQuery',
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',
Rough cut of Diffusion change view.
2011-03-31 02:36:16 +02:00
'DiffusionDiffController' => 'DiffusionController',
General Herald refactoring pass Summary: **Who can delete global rules?**: I discussed this with @jungejason. The current behavior is that the rule author or any administrator can delete a global rule, but this isn't consistent with who can edit a rule (anyone) and doesn't really make much sense (it's an artifact of the global/personal split). I proposed that anyone can delete a rule but we don't actually delete them, and log the deletion. However, when it came time to actually write the code for this I backed off a bit and continued actually deleting the rules -- I think this does a reasonable job of balancing accountability with complexity. So the new impelmentation is: - Personal rules can be deleted only by their owners. - Global rules can be deleted by any user. - All deletes are logged. - Logs are more detailed. - All logged actions can be viewed in aggregate. **Minor Cleanup** - Merged `HomeController` and `AllController`. - Moved most queries to Query classes. - Use AphrontFormSelectControl::renderSelectTag() where appropriate (this is a fairly recent addition). - Use an AphrontErrorView to render the dry run notice (this didn't exist when I ported). - Reenable some transaction code (this works again now). - Removed the ability for admins to change rule authors (this was a little buggy, messy, and doesn't make tons of sense after the personal/global rule split). - Rules which depend on other rules now display the right options (all global rules, all your personal rules for personal rules). - Fix a bug in AphrontTableView where the "no data" cell would be rendered too wide if some columns are not visible. - Allow selectFilter() in AphrontNavFilterView to be called without a 'default' argument. Test Plan: - Browsed, created, edited, deleted personal and gules. - Verified generated logs. - Did some dry runs. - Verified transcript list and transcript details. - Created/edited all/any rules; created/edited once/every time rules. - Filtered admin views by users. Reviewers: jungejason, btrahan Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D2040
2012-03-30 19:49:55 +02:00
'DiffusionDiffQuery' => 'DiffusionQuery',
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',
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',
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',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionGitBranchQuery' => 'DiffusionBranchQuery',
Make tracked git repositories use an implicit 'origin' remote Summary: See T624. I originally wrote this to require an explicit remote, but this creates an ugly "origin:" in all the URIs and makes T270 more difficult. Treat all branch names as implying 'origin/'. Test Plan: - Pulled and imported a fresh copy of libphutil without issues. - Browsed various git repositories. - Browsed Javelin's various branches. - Ran upgrade script, got a bunch of clean 'origin/master' -> 'master' conversions. - Tried to specify an explicit remote in a default branch name. - Unit tests. Reviewers: nh, jungejason, btrahan Reviewed By: btrahan CC: aran, btrahan Maniphest Tasks: T624 Differential Revision: https://secure.phabricator.com/D1269
2011-12-22 21:24:12 +01:00
'DiffusionGitBranchQueryTestCase' => 'PhabricatorTestCase',
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
'DiffusionGitBrowseQuery' => 'DiffusionBrowseQuery',
Show parent commits in Diffusion Summary: Show parent commit information to make it easier to understand merges. Test Plan: Looked at commits in SVN, hg, git. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T961 Differential Revision: https://secure.phabricator.com/D2021
2012-03-26 21:21:48 +02:00
'DiffusionGitCommitParentsQuery' => 'DiffusionCommitParentsQuery',
Improve tag support in Diffusion Summary: - When viewing a commit, show its tags. - For commits with many tags, show a list of all tags on the tag list interface. - Improve some handling of symbolic references. - When tags contain content, show it on the browse view reached by clicking the tag name. Test Plan: Looked at commits with and without tags, clicked "More tags...", clicked tag names. Reviewers: btrahan, vrana, davidreuss, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1130 Differential Revision: https://secure.phabricator.com/D2290
2012-04-24 03:36:25 +02:00
'DiffusionGitCommitTagsQuery' => 'DiffusionCommitTagsQuery',
Show all branches a commit appears on Summary: We show the contextual branch (always the repository default branch) when viewing a commit. Instead, show all branches the commit appears on. Also pull some of the duplicated DiffusionXQuery stuff into a DiffusionQuery base class, I'll do a followup to reduce more duplication. Test Plan: Looked at a commit in Git. My HG and SVN setups are a little borked so I kind of faked tests in them -- I'm fixing them now. Reviewers: btrahan, jungejason, fratrik Reviewed By: btrahan CC: aran Maniphest Tasks: T768 Differential Revision: https://secure.phabricator.com/D1458
2012-01-19 20:49:51 +01:00
'DiffusionGitContainsQuery' => 'DiffusionContainsQuery',
Basic DiffusionGitDiffQuery.
2011-03-31 03:17:36 +02:00
'DiffusionGitDiffQuery' => 'DiffusionDiffQuery',
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',
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
'DiffusionGitHistoryQuery' => 'DiffusionHistoryQuery',
Add more change metadata to SVN and git.
2011-03-31 08:27:06 +02:00
'DiffusionGitLastModifiedQuery' => 'DiffusionLastModifiedQuery',
Show merged changes in commit views for merges Summary: When a commit is a merge, show what it merged. Also fix some bugs: - Mercurial queries may contain ":", but mercurial rev ranges may also contain ":". A rev range with a branch that has a ":" in it is ambigiuous, e.g. branch "a:b" might appear in a rev range like "a:b:0", which can not be parsed. Use stable commit names instead. - Mercurial stable commit name implementation was broken, fix it. - Extend DiffusionHistoryQuery from DiffusionQuery to share code. - Fix a bug where Mercurial's main browse list would not show the most recent commit if it was a merge commit. Test Plan: Generated a bunch of mercurial/git merge commits and looked at them, they seemed to accurately represent the repository state. Reviewers: btrahan, Makinde Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T961 Differential Revision: https://secure.phabricator.com/D2005
2012-03-23 23:32:26 +01:00
'DiffusionGitMergedCommitsQuery' => 'DiffusionMergedCommitsQuery',
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',
Allow "blame previous revision" to track file moves and handle edge cases Summary: - Track + message through file moves. - Stop + message on file create. - Stop + message on first commit. Test Plan: - Tested blaming through a move, through a create, and through the first commit. - Verified this doesn't break anything in SVN / Mercurial. Reviewers: vrana, btrahan, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1091 Differential Revision: https://secure.phabricator.com/D2295
2012-04-24 03:16:38 +02:00
'DiffusionGitRenameHistoryQuery' => 'DiffusionRenameHistoryQuery',
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',
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
'DiffusionGitTagListQuery' => 'DiffusionTagListQuery',
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',
Show merged changes in commit views for merges Summary: When a commit is a merge, show what it merged. Also fix some bugs: - Mercurial queries may contain ":", but mercurial rev ranges may also contain ":". A rev range with a branch that has a ":" in it is ambigiuous, e.g. branch "a:b" might appear in a rev range like "a:b:0", which can not be parsed. Use stable commit names instead. - Mercurial stable commit name implementation was broken, fix it. - Extend DiffusionHistoryQuery from DiffusionQuery to share code. - Fix a bug where Mercurial's main browse list would not show the most recent commit if it was a merge commit. Test Plan: Generated a bunch of mercurial/git merge commits and looked at them, they seemed to accurately represent the repository state. Reviewers: btrahan, Makinde Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T961 Differential Revision: https://secure.phabricator.com/D2005
2012-03-23 23:32:26 +01:00
'DiffusionHistoryQuery' => 'DiffusionQuery',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionHistoryTableView' => 'DiffusionView',
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
'DiffusionHomeController' => 'DiffusionController',
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',
Add more change metadata to SVN and git.
2011-03-31 08:27:06 +02:00
'DiffusionLastModifiedController' => 'DiffusionController',
General Herald refactoring pass Summary: **Who can delete global rules?**: I discussed this with @jungejason. The current behavior is that the rule author or any administrator can delete a global rule, but this isn't consistent with who can edit a rule (anyone) and doesn't really make much sense (it's an artifact of the global/personal split). I proposed that anyone can delete a rule but we don't actually delete them, and log the deletion. However, when it came time to actually write the code for this I backed off a bit and continued actually deleting the rules -- I think this does a reasonable job of balancing accountability with complexity. So the new impelmentation is: - Personal rules can be deleted only by their owners. - Global rules can be deleted by any user. - All deletes are logged. - Logs are more detailed. - All logged actions can be viewed in aggregate. **Minor Cleanup** - Merged `HomeController` and `AllController`. - Moved most queries to Query classes. - Use AphrontFormSelectControl::renderSelectTag() where appropriate (this is a fairly recent addition). - Use an AphrontErrorView to render the dry run notice (this didn't exist when I ported). - Reenable some transaction code (this works again now). - Removed the ability for admins to change rule authors (this was a little buggy, messy, and doesn't make tons of sense after the personal/global rule split). - Rules which depend on other rules now display the right options (all global rules, all your personal rules for personal rules). - Fix a bug in AphrontTableView where the "no data" cell would be rendered too wide if some columns are not visible. - Allow selectFilter() in AphrontNavFilterView to be called without a 'default' argument. Test Plan: - Browsed, created, edited, deleted personal and gules. - Verified generated logs. - Did some dry runs. - Verified transcript list and transcript details. - Created/edited all/any rules; created/edited once/every time rules. - Filtered admin views by users. Reviewers: jungejason, btrahan Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D2040
2012-03-30 19:49:55 +02:00
'DiffusionLastModifiedQuery' => 'DiffusionQuery',
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
'DiffusionMercurialBranchQuery' => 'DiffusionBranchQuery',
'DiffusionMercurialBrowseQuery' => 'DiffusionBrowseQuery',
Show parent commits in Diffusion Summary: Show parent commit information to make it easier to understand merges. Test Plan: Looked at commits in SVN, hg, git. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T961 Differential Revision: https://secure.phabricator.com/D2021
2012-03-26 21:21:48 +02:00
'DiffusionMercurialCommitParentsQuery' => 'DiffusionCommitParentsQuery',
Improve tag support in Diffusion Summary: - When viewing a commit, show its tags. - For commits with many tags, show a list of all tags on the tag list interface. - Improve some handling of symbolic references. - When tags contain content, show it on the browse view reached by clicking the tag name. Test Plan: Looked at commits with and without tags, clicked "More tags...", clicked tag names. Reviewers: btrahan, vrana, davidreuss, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1130 Differential Revision: https://secure.phabricator.com/D2290
2012-04-24 03:36:25 +02:00
'DiffusionMercurialCommitTagsQuery' => 'DiffusionCommitTagsQuery',
Show all branches a commit appears on Summary: We show the contextual branch (always the repository default branch) when viewing a commit. Instead, show all branches the commit appears on. Also pull some of the duplicated DiffusionXQuery stuff into a DiffusionQuery base class, I'll do a followup to reduce more duplication. Test Plan: Looked at a commit in Git. My HG and SVN setups are a little borked so I kind of faked tests in them -- I'm fixing them now. Reviewers: btrahan, jungejason, fratrik Reviewed By: btrahan CC: aran Maniphest Tasks: T768 Differential Revision: https://secure.phabricator.com/D1458
2012-01-19 20:49:51 +01:00
'DiffusionMercurialContainsQuery' => 'DiffusionContainsQuery',
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
'DiffusionMercurialDiffQuery' => 'DiffusionDiffQuery',
'DiffusionMercurialFileContentQuery' => 'DiffusionFileContentQuery',
'DiffusionMercurialHistoryQuery' => 'DiffusionHistoryQuery',
'DiffusionMercurialLastModifiedQuery' => 'DiffusionLastModifiedQuery',
Show merged changes in commit views for merges Summary: When a commit is a merge, show what it merged. Also fix some bugs: - Mercurial queries may contain ":", but mercurial rev ranges may also contain ":". A rev range with a branch that has a ":" in it is ambigiuous, e.g. branch "a:b" might appear in a rev range like "a:b:0", which can not be parsed. Use stable commit names instead. - Mercurial stable commit name implementation was broken, fix it. - Extend DiffusionHistoryQuery from DiffusionQuery to share code. - Fix a bug where Mercurial's main browse list would not show the most recent commit if it was a merge commit. Test Plan: Generated a bunch of mercurial/git merge commits and looked at them, they seemed to accurately represent the repository state. Reviewers: btrahan, Makinde Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T961 Differential Revision: https://secure.phabricator.com/D2005
2012-03-23 23:32:26 +01:00
'DiffusionMercurialMergedCommitsQuery' => 'DiffusionMergedCommitsQuery',
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',
Allow "blame previous revision" to track file moves and handle edge cases Summary: - Track + message through file moves. - Stop + message on file create. - Stop + message on first commit. Test Plan: - Tested blaming through a move, through a create, and through the first commit. - Verified this doesn't break anything in SVN / Mercurial. Reviewers: vrana, btrahan, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1091 Differential Revision: https://secure.phabricator.com/D2295
2012-04-24 03:16:38 +02:00
'DiffusionMercurialRenameHistoryQuery' => 'DiffusionRenameHistoryQuery',
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',
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
'DiffusionMercurialTagListQuery' => 'DiffusionTagListQuery',
Show merged changes in commit views for merges Summary: When a commit is a merge, show what it merged. Also fix some bugs: - Mercurial queries may contain ":", but mercurial rev ranges may also contain ":". A rev range with a branch that has a ":" in it is ambigiuous, e.g. branch "a:b" might appear in a rev range like "a:b:0", which can not be parsed. Use stable commit names instead. - Mercurial stable commit name implementation was broken, fix it. - Extend DiffusionHistoryQuery from DiffusionQuery to share code. - Fix a bug where Mercurial's main browse list would not show the most recent commit if it was a merge commit. Test Plan: Generated a bunch of mercurial/git merge commits and looked at them, they seemed to accurately represent the repository state. Reviewers: btrahan, Makinde Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T961 Differential Revision: https://secure.phabricator.com/D2005
2012-03-23 23:32:26 +01:00
'DiffusionMergedCommitsQuery' => 'DiffusionQuery',
Some owners read workflows.
2011-04-04 04:20:47 +02:00
'DiffusionPathCompleteController' => 'DiffusionController',
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',
Some owners read workflows.
2011-04-04 04:20:47 +02:00
'DiffusionPathValidateController' => 'DiffusionController',
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',
Allow "blame previous revision" to track file moves and handle edge cases Summary: - Track + message through file moves. - Stop + message on file create. - Stop + message on first commit. Test Plan: - Tested blaming through a move, through a create, and through the first commit. - Verified this doesn't break anything in SVN / Mercurial. Reviewers: vrana, btrahan, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1091 Differential Revision: https://secure.phabricator.com/D2295
2012-04-24 03:16:38 +02:00
'DiffusionRenameHistoryQuery' => 'DiffusionQuery',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionRepositoryController' => 'DiffusionController',
Improve performance of repository discovery under Mercurial Summary: Prelminary, I want to test this a bit more when I'm better rested. Provide a "bulk" import mode for Mercurial so we can do initial discovery more quickly. Test Plan: Imported the Mercurial repository in 2m45s, blocked on MySQL I/O rather than Mercurial I/O. Reviewers: csilvers, btrahan Reviewed By: csilvers CC: aran Differential Revision: https://secure.phabricator.com/D2457
2012-05-12 03:29:14 +02:00
'DiffusionSetupException' => 'AphrontUsageException',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionSvnBrowseQuery' => 'DiffusionBrowseQuery',
Show parent commits in Diffusion Summary: Show parent commit information to make it easier to understand merges. Test Plan: Looked at commits in SVN, hg, git. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T961 Differential Revision: https://secure.phabricator.com/D2021
2012-03-26 21:21:48 +02:00
'DiffusionSvnCommitParentsQuery' => 'DiffusionCommitParentsQuery',
Improve tag support in Diffusion Summary: - When viewing a commit, show its tags. - For commits with many tags, show a list of all tags on the tag list interface. - Improve some handling of symbolic references. - When tags contain content, show it on the browse view reached by clicking the tag name. Test Plan: Looked at commits with and without tags, clicked "More tags...", clicked tag names. Reviewers: btrahan, vrana, davidreuss, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1130 Differential Revision: https://secure.phabricator.com/D2290
2012-04-24 03:36:25 +02:00
'DiffusionSvnCommitTagsQuery' => 'DiffusionCommitTagsQuery',
Minor, part 2/2, fix class casing.
2012-03-24 20:52:14 +01:00
'DiffusionSvnContainsQuery' => 'DiffusionContainsQuery',
Rough cut of Diffusion change view.
2011-03-31 02:36:16 +02:00
'DiffusionSvnDiffQuery' => 'DiffusionDiffQuery',
Browse / git improvements.
2011-03-14 06:03:30 +01:00
'DiffusionSvnFileContentQuery' => 'DiffusionFileContentQuery',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionSvnHistoryQuery' => 'DiffusionHistoryQuery',
Add more change metadata to SVN and git.
2011-03-31 08:27:06 +02:00
'DiffusionSvnLastModifiedQuery' => 'DiffusionLastModifiedQuery',
Show merged changes in commit views for merges Summary: When a commit is a merge, show what it merged. Also fix some bugs: - Mercurial queries may contain ":", but mercurial rev ranges may also contain ":". A rev range with a branch that has a ":" in it is ambigiuous, e.g. branch "a:b" might appear in a rev range like "a:b:0", which can not be parsed. Use stable commit names instead. - Mercurial stable commit name implementation was broken, fix it. - Extend DiffusionHistoryQuery from DiffusionQuery to share code. - Fix a bug where Mercurial's main browse list would not show the most recent commit if it was a merge commit. Test Plan: Generated a bunch of mercurial/git merge commits and looked at them, they seemed to accurately represent the repository state. Reviewers: btrahan, Makinde Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T961 Differential Revision: https://secure.phabricator.com/D2005
2012-03-23 23:32:26 +01:00
'DiffusionSvnMergedCommitsQuery' => 'DiffusionMergedCommitsQuery',
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',
Allow "blame previous revision" to track file moves and handle edge cases Summary: - Track + message through file moves. - Stop + message on file create. - Stop + message on first commit. Test Plan: - Tested blaming through a move, through a create, and through the first commit. - Verified this doesn't break anything in SVN / Mercurial. Reviewers: vrana, btrahan, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1091 Differential Revision: https://secure.phabricator.com/D2295
2012-04-24 03:16:38 +02:00
'DiffusionSvnRenameHistoryQuery' => 'DiffusionRenameHistoryQuery',
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 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
'DiffusionSvnTagListQuery' => 'DiffusionTagListQuery',
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',
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
'DiffusionTagListQuery' => 'DiffusionQuery',
'DiffusionTagListView' => 'DiffusionView',
Fix many encoding and architecture problems in Diffusion request and URI handling Summary: Diffusion request/uri handling is currently a big, hastily ported mess. In particular, it has: - Tons and tons of duplicated code. - Bugs with handling unusual branch and file names. - An excessively large (and yet insufficiently expressive) API on DiffusionRequest, including a nonsensical concrete base class. - Other tools were doing hacky things like passing ":" branch names. This diff attempts to fix these issues. - Make the base class abstract (it was concrete ONLY for "/diffusion/"). - Move all URI generation to DiffusionRequest. Make the core static. Add unit tests. - Delete the 300 copies of URI generation code throughout Diffusion. - Move all URI parsing to DiffusionRequest. Make the core static. Add unit tests. - Add an appropriate static initializer for other callers. - Convert all code calling `newFromAphrontRequestDictionary` outside of Diffusion to the new `newFromDictionary` API. - Refactor static initializers to be sensibly-sized. - Refactor derived DiffusionRequest classes to remove duplicated code. - Properly encode branch names (fixes branches with "/", see <https://github.com/facebook/phabricator/issues/100>). - Properly encode path names (fixes issues in D1742). - Properly escape delimiter characters ";" and "$" in path names so files like "$100" are not interpreted as "line 100". - Fix a couple warnings. - Fix a couple lint issues. - Fix a bug where we would not parse filenames with spaces in them correctly in the Git browse query. - Fix a bug where Git change queries would fail unnecessarily. - Provide or improve some documentation. This thing is pretty gigantic but also kind of hard to split up. If it's unreasonably difficult to review, let me know and I can take a stab at it though. This supplants D1742. Test Plan: - Used home, repository, branch, browse, change, history, diff (ajax), lastmodified (ajax) views of Diffusion. - Used Owners typeaheads and search. - Used diffusion.getrecentcommitsbypath method. - Pushed a change to an absurdly-named file on an absurdly-named branch, everything worked properly. {F9185} Reviewers: nh, vrana, btrahan Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1921
2012-03-20 03:52:14 +01:00
'DiffusionURITestCase' => 'ArcanistPhutilTestCase',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionView' => 'AphrontView',
Move resource allocation to task queue Summary: Run the actual resource allocation for Drydock out-of-process via the task queue. Test Plan: Ran "drydock_control.php", saw it insert a task and wait for task completion. Ran "phd debug taskmaster" and saw it run the task. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1470
2012-01-24 01:58:38 +01:00
'DrydockAllocatorWorker' => 'PhabricatorWorker',
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
'DrydockApacheWebrootBlueprint' => 'DrydockBlueprint',
'DrydockApacheWebrootInterface' => 'DrydockWebrootInterface',
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',
'DrydockController' => 'PhabricatorController',
'DrydockDAO' => 'PhabricatorLiskDAO',
'DrydockEC2HostBlueprint' => 'DrydockRemoteHostBlueprint',
'DrydockLease' => 'DrydockDAO',
'DrydockLeaseListController' => 'DrydockController',
'DrydockLeaseStatus' => 'DrydockConstants',
'DrydockLocalCommandInterface' => 'DrydockCommandInterface',
'DrydockLocalHostBlueprint' => 'DrydockBlueprint',
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
'DrydockLog' => 'DrydockDAO',
'DrydockLogController' => 'DrydockController',
'DrydockLogQuery' => 'PhabricatorOffsetPagedQuery',
'DrydockPhabricatorApplicationBlueprint' => 'DrydockBlueprint',
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
'DrydockRemoteHostBlueprint' => 'DrydockBlueprint',
'DrydockResource' => 'DrydockDAO',
'DrydockResourceAllocateController' => 'DrydockController',
'DrydockResourceListController' => 'DrydockController',
'DrydockResourceStatus' => 'DrydockConstants',
'DrydockSSHCommandInterface' => 'DrydockCommandInterface',
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',
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',
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',
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',
Herald skeleton.
2011-03-22 21:22:40 +01:00
'HeraldAction' => 'HeraldDAO',
'HeraldApplyTranscript' => 'HeraldDAO',
HeraldCommitAdapter and some related junk.
2011-04-04 08:23:36 +02:00
'HeraldCommitAdapter' => 'HeraldObjectAdapter',
Herald skeleton.
2011-03-22 21:22:40 +01:00
'HeraldCondition' => 'HeraldDAO',
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',
Herald CSS, plus edit/save/delete.
2011-03-24 19:07:36 +01:00
'HeraldDeleteController' => 'HeraldController',
Rough cut of herald transcripts and Differential adapter.
2011-03-25 05:32:26 +01:00
'HeraldDifferentialRevisionAdapter' => 'HeraldObjectAdapter',
Very rough cut at Herald test console.
2011-03-24 21:49:21 +01:00
'HeraldDryRunAdapter' => 'HeraldObjectAdapter',
General Herald refactoring pass Summary: **Who can delete global rules?**: I discussed this with @jungejason. The current behavior is that the rule author or any administrator can delete a global rule, but this isn't consistent with who can edit a rule (anyone) and doesn't really make much sense (it's an artifact of the global/personal split). I proposed that anyone can delete a rule but we don't actually delete them, and log the deletion. However, when it came time to actually write the code for this I backed off a bit and continued actually deleting the rules -- I think this does a reasonable job of balancing accountability with complexity. So the new impelmentation is: - Personal rules can be deleted only by their owners. - Global rules can be deleted by any user. - All deletes are logged. - Logs are more detailed. - All logged actions can be viewed in aggregate. **Minor Cleanup** - Merged `HomeController` and `AllController`. - Moved most queries to Query classes. - Use AphrontFormSelectControl::renderSelectTag() where appropriate (this is a fairly recent addition). - Use an AphrontErrorView to render the dry run notice (this didn't exist when I ported). - Reenable some transaction code (this works again now). - Removed the ability for admins to change rule authors (this was a little buggy, messy, and doesn't make tons of sense after the personal/global rule split). - Rules which depend on other rules now display the right options (all global rules, all your personal rules for personal rules). - Fix a bug in AphrontTableView where the "no data" cell would be rendered too wide if some columns are not visible. - Allow selectFilter() in AphrontNavFilterView to be called without a 'default' argument. Test Plan: - Browsed, created, edited, deleted personal and gules. - Verified generated logs. - Did some dry runs. - Verified transcript list and transcript details. - Created/edited all/any rules; created/edited once/every time rules. - Filtered admin views by users. Reviewers: jungejason, btrahan Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D2040
2012-03-30 19:49:55 +02:00
'HeraldEditLogQuery' => 'PhabricatorOffsetPagedQuery',
Rough cut of Herald home controller.
2011-03-22 21:49:46 +01:00
'HeraldHomeController' => 'HeraldController',
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',
'HeraldInvalidFieldException' => 'Exception',
Herald 'new rule type' interface.
2011-03-22 22:34:38 +01:00
'HeraldNewController' => 'HeraldController',
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',
Herald skeleton.
2011-03-22 21:22:40 +01:00
'HeraldRule' => 'HeraldDAO',
Horrendously rough cut of Herald rule editor.
2011-03-22 23:27:52 +01:00
'HeraldRuleController' => 'HeraldController',
Add basic edit history to herald rules Summary: Add a very basic edit history table to herald rules. This table is updated whenever saving a herald rule. The contents of the save are not examined, and the edit history contains no information about the rule itself *yet*. Edit history can be viewed by anyone through /herald/history/<rule id>/. Task ID: # Blame Rev: Test Plan: Made a test rule, saved some stuff. Revert Plan: Tags: Reviewers: epriestley, jungejason Reviewed By: epriestley CC: zizzy, aran, xela, epriestley Differential Revision: https://secure.phabricator.com/D1387
2012-01-30 20:51:23 +01:00
'HeraldRuleEdit' => 'HeraldDAO',
'HeraldRuleEditHistoryController' => 'HeraldController',
'HeraldRuleEditHistoryView' => 'AphrontView',
Enable admin to view and delete other users' herald rules Summary: enable admin to delete user's herald rules. This is useful for managing non-active users' rules. For example, ex-employees' rules. The code change includes: - Added a 'All' tab which is only accessible to admin. - Refactor out a HeraldRuleListView which is used by both the home controller and the all rule controller Test Plan: delete an ex-employee rule as an admin; disable myself as admin and verified that I don't have access to view other user's rules and I'am not be able to delete them; also verified that as a non-admin, I can still view, create and delete my own rules. Reviewers: epriestley, nh Reviewed By: epriestley CC: aran, epriestley, jungejason Differential Revision: 1064
2011-11-06 09:07:04 +01:00
'HeraldRuleListView' => 'AphrontView',
General Herald refactoring pass Summary: **Who can delete global rules?**: I discussed this with @jungejason. The current behavior is that the rule author or any administrator can delete a global rule, but this isn't consistent with who can edit a rule (anyone) and doesn't really make much sense (it's an artifact of the global/personal split). I proposed that anyone can delete a rule but we don't actually delete them, and log the deletion. However, when it came time to actually write the code for this I backed off a bit and continued actually deleting the rules -- I think this does a reasonable job of balancing accountability with complexity. So the new impelmentation is: - Personal rules can be deleted only by their owners. - Global rules can be deleted by any user. - All deletes are logged. - Logs are more detailed. - All logged actions can be viewed in aggregate. **Minor Cleanup** - Merged `HomeController` and `AllController`. - Moved most queries to Query classes. - Use AphrontFormSelectControl::renderSelectTag() where appropriate (this is a fairly recent addition). - Use an AphrontErrorView to render the dry run notice (this didn't exist when I ported). - Reenable some transaction code (this works again now). - Removed the ability for admins to change rule authors (this was a little buggy, messy, and doesn't make tons of sense after the personal/global rule split). - Rules which depend on other rules now display the right options (all global rules, all your personal rules for personal rules). - Fix a bug in AphrontTableView where the "no data" cell would be rendered too wide if some columns are not visible. - Allow selectFilter() in AphrontNavFilterView to be called without a 'default' argument. Test Plan: - Browsed, created, edited, deleted personal and gules. - Verified generated logs. - Did some dry runs. - Verified transcript list and transcript details. - Created/edited all/any rules; created/edited once/every time rules. - Filtered admin views by users. Reviewers: jungejason, btrahan Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D2040
2012-03-30 19:49:55 +02:00
'HeraldRuleQuery' => 'PhabricatorOffsetPagedQuery',
Very rough cut at Herald test console.
2011-03-24 21:49:21 +01:00
'HeraldTestConsoleController' => 'HeraldController',
Herald skeleton.
2011-03-22 21:22:40 +01:00
'HeraldTranscript' => 'HeraldDAO',
Rough cut of herald transcripts and Differential adapter.
2011-03-25 05:32:26 +01:00
'HeraldTranscriptController' => 'HeraldController',
'HeraldTranscriptListController' => 'HeraldController',
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
'JavelinReactorExample' => '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
'JavelinViewExample' => 'PhabricatorUIExample',
'JavelinViewExampleServerView' => 'AphrontView',
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',
Extend ManiphestAction from ManiphestConstants, not PhrictionConstants Summary: Bad copy/paste. Test Plan: arc liberate Reviewers: svemir, allenjohnashton Reviewed By: svemir CC: aran Differential Revision: https://secure.phabricator.com/D2738
2012-06-13 23:41:43 +02:00
'ManiphestAction' => 'ManiphestConstants',
Support for config-based custom fields in Maniphest Test Plan: Add fields to config based on specification on T335. View on Task Edit and Task Detail. Supported types are string, int and select Reviewed By: epriestley Reviewers: epriestley CC: aran, epriestley, hunterbridges Differential Revision: 753
2011-07-27 18:49:50 +02:00
'ManiphestAuxiliaryFieldDefaultSpecification' => 'ManiphestAuxiliaryFieldSpecification',
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
'ManiphestAuxiliaryFieldTypeException' => 'Exception',
'ManiphestAuxiliaryFieldValidationException' => 'Exception',
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',
Maniphest wireframes Summary: Test Plan: Reviewers: CC:
2011-02-08 19:53:59 +01:00
'ManiphestController' => 'PhabricatorController',
'ManiphestDAO' => 'PhabricatorLiskDAO',
Tweak Maniphest custom fields Summary: - Fix a bug where 'caption' didn't do anything. - Provide an abstract base implementation for extensions. - Add some documentation. - Expose aux fields via conduit. Test Plan: Added some fields like "Dinosaur", "Kilograms" and "derp" on my local install. Read documentation. Reviewed By: jungejason Reviewers: hunterbridges, jungejason, tuomaspelkonen, aran CC: aran, philc, jungejason Differential Revision: 785
2011-08-05 18:44:43 +02:00
'ManiphestDefaultTaskExtensions' => 'ManiphestTaskExtensions',
Insert Maniphest transactions when edges are edited Summary: - See D2741. - When EdgeEditor performs edits, emit events. - Listen for Maniphest edge events and save the changes as transactions. - Do all this in a reasonably generic way that won't take too much rewriting as we use edges more generally. Test Plan: Attached and detached commits from tasks, saw reasonable-looking transactions spring into existence. Reviewers: btrahan, davidreuss Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2906
2012-07-03 00:42:06 +02:00
'ManiphestEdgeEventListener' => 'PhutilEventListener',
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',
Support email multiplexing for private Reply-To addresses Summary: Provide a base PhabricatorMailReplyHandler class which handles the plumbing for multiplexing email if necessary and supporting public and private reply handler addressses. DifferentialReplyHandler now extends it, and a new ManiphestReplyHandler also does. The general approach here is that we have three supported cases: - no reply handler, default config, same as what we're doing now - public reply handler, requires overriding classes but just sets "reply-to" to some address the install generates and still sends only one email - private reply handler, provides a default generation mechanism or you can override it and splits mail apart so we send one to each recipient Test Plan: Sent email from Maniphest and Differential with and without reply-handler-domains set. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran CC: aran, epriestley Differential Revision: 254
2011-05-10 01:31:26 +02:00
'ManiphestReplyHandler' => 'PhabricatorMailReplyHandler',
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',
Allow Maniphest queries to be saved Summary: There have been a couple of requests for this since bookmarks are "out this year like woah" and "totally uncool dude". Allow users to save named custom queries and make them the /maniphest/ default if they so desire. A little messy. :/ Test Plan: Saved, edited, deleted custom queries. Made custom query default; made 'no default' default. Verified default behavior. Issued a modified search from a custom query. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley, 20after4 Maniphest Tasks: T923, T1034 Differential Revision: https://secure.phabricator.com/D1964
2012-04-10 18:46:04 +02:00
'ManiphestSavedQuery' => 'ManiphestDAO',
'ManiphestSavedQueryDeleteController' => 'ManiphestController',
'ManiphestSavedQueryEditController' => 'ManiphestController',
'ManiphestSavedQueryListController' => 'ManiphestController',
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',
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
'ManiphestTask' =>
array(
0 => 'ManiphestDAO',
1 => 'PhabricatorMarkupInterface',
),
Key Value Store for ManiphestTask Test Plan: Look at a task detail. Some dummy attributes are automatically added in ManiphestTaskDetailController. Reviewed By: epriestley Differential Revision: 730
2011-07-26 00:34:56 +02:00
'ManiphestTaskAuxiliaryStorage' => 'ManiphestDAO',
Show description changes in Maniphest Summary: When a task description is updated, there's currently no way to see the change. Build an "expanded summary" mode for transactions that shows description change details. Also include changes in the email. Test Plan: Changed task descriptions, clicked "show details", read email. Reviewed By: aran Reviewers: tuomaspelkonen, jungejason, aran CC: anjali, aran, epriestley Differential Revision: 320
2011-05-21 03:56:18 +02:00
'ManiphestTaskDescriptionChangeController' => 'ManiphestController',
Add a description preview to maniphest create / edit panel Summary: also fixes a small bug where the page title was always "Create Task". switch it to the header name which is much more descriptive / correct IMO. Test Plan: created a new task and watched the description preview update. edited an old task and saw the description preview populate with the correct existing data. edited an old task and edited the description and saw the description preview update Reviewers: epriestley CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1489
2012-01-25 20:23:00 +01:00
'ManiphestTaskDescriptionPreviewController' => 'ManiphestController',
Maniphest wireframes Summary: Test Plan: Reviewers: CC:
2011-02-08 19:53:59 +01:00
'ManiphestTaskDetailController' => 'ManiphestController',
Enable task editing in Maniphest. Summary: Test Plan: Reviewers: CC:
2011-02-20 23:15:53 +01:00
'ManiphestTaskEditController' => 'ManiphestController',
Maniphest wireframes Summary: Test Plan: Reviewers: CC:
2011-02-08 19:53:59 +01:00
'ManiphestTaskListController' => 'ManiphestController',
Slightly improve Maniphest documentation.
2011-07-04 22:04:22 +02:00
'ManiphestTaskListView' => 'ManiphestView',
'ManiphestTaskOwner' => 'ManiphestConstants',
'ManiphestTaskPriority' => 'ManiphestConstants',
Allow Maniphest tasks to be filtered by Project Summary: Major things taking place here: - A new table for storing <task, project> relationships. - Moved all task query logic into a dedicated class. - Added a "projects" filter to the UI. I was originally going to try to drive this off the main search index but the perf benefits of a custom schema make an overwhelming argument in favor of doing it this way. Test Plan: Filtered tasks by author and owner and zero, one, and more than one project. Exercised all the group/sort options. Ran the index script over my 100k task corpus. Edited task-project membership and verified the index updated. Reviewed By: cadamo Reviewers: gc3, jungejason, cadamo, tuomaspelkonen, aran CC: aran, cadamo, epriestley Differential Revision: 556
2011-06-30 01:16:33 +02:00
'ManiphestTaskProject' => 'ManiphestDAO',
Show projects on Maniphest tasks Summary: - Remove the "Priority" column, since this is indicated by the color swatch, to save space. - Reduce the "Updated" column from datetime to date only, since time isn't incredibly useful, to save space. - Show the first two projects a task is associated with, and "..." if there are more. - Show "None" (for "no owner") in a lighter color. Test Plan: Looked at tasks on homepage and in Maniphest. Reviewers: btrahan, 20after4 Reviewed By: btrahan CC: aran, edward Maniphest Tasks: T967 Differential Revision: https://secure.phabricator.com/D2065
2012-04-02 19:27:31 +02:00
'ManiphestTaskProjectsView' => 'ManiphestView',
Slightly improve Maniphest documentation.
2011-07-04 22:04:22 +02:00
'ManiphestTaskStatus' => 'ManiphestConstants',
Added subscriber view to Maniphest. Summary: People want to see all the tasks they have subscribed to in one view. A new table was added for this to make queries faster. Test Plan: Tested that the view was initially empty. After running the reindex_maniphest.php script, I saw the correct tasks there. Added myself as a subscriber to one task and made sure the view was updated. Removed myself as a subscriber from one task and made sure the view was updated again. Reviewed By: epriestley Reviewers: epriestley, jungejason, codeblock CC: aran, rm, epriestley Differential Revision: 603
2011-07-07 19:24:49 +02:00
'ManiphestTaskSubscriber' => 'ManiphestDAO',
Slightly improve Maniphest documentation.
2011-07-04 22:04:22 +02:00
'ManiphestTaskSummaryView' => 'ManiphestView',
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
'ManiphestTransaction' =>
array(
0 => 'ManiphestDAO',
1 => 'PhabricatorMarkupInterface',
),
Slightly improve Maniphest documentation.
2011-07-04 22:04:22 +02:00
'ManiphestTransactionDetailView' => 'ManiphestView',
'ManiphestTransactionListView' => 'ManiphestView',
Add comment previews to Maniphest Summary: Moves shared code from Differential and Maniphest comment previews into PhabricatorShapedRequest, and then implements Maniphest previews. This doesn't implement comment drafts, I'll follow up with that but it requires this and is completely separable. This also always shows the preview as "commented" rather than previewing the actual transaction. I'll follow up with that but I think it will require a little factoring and this is useful even without transaction details. I need to tweak the styling a bit too. Test Plan: Typed text in Maniphest and Differential. Toggled Differential action. Made comments. Reviewed By: rm Reviewers: rm, tuomaspelkonen, jungejason, aran CC: aran, rm Differential Revision: 258
2011-05-10 17:29:28 +02:00
'ManiphestTransactionPreviewController' => 'ManiphestController',
Maniphest wireframes Summary: Test Plan: Reviewers: CC:
2011-02-08 19:53:59 +01:00
'ManiphestTransactionSaveController' => 'ManiphestController',
Slightly improve Maniphest documentation.
2011-07-04 22:04:22 +02:00
'ManiphestTransactionType' => 'ManiphestConstants',
'ManiphestView' => 'AphrontView',
Add email preferences to receive fewer less-important notifications Summary: A few similar requests have come in across several tools and use cases that I think this does a reasonable job of resolving. We currently send one email for each update an object receives, but these aren't always appreciated: - Asana does post-commit review via Differential, so the "committed" mails are useless. - Quora wants to make project category edits to bugs without spamming people attached to them. - Some users in general are very sensitive to email volumes, and this gives us a good way to reduce the volumes without incurring the complexity of delayed-send-batching. The technical mechanism is basically: - Mail may optionally have "mail tags", which indicate content in the mail (e.g., "maniphest-priority, maniphest-cc, maniphest-comment" for a mail which contains a priority change, a CC change, and a comment). - If a mail has tags, remove any recipients who have opted out of all the tags. - Some tags can't be opted out of via the UI, so this ensures that important email is still delivered (e.g., cc + assign + comment is always delivered because you can't opt out of "assign" or "comment"). Test Plan: - Disabled all mail tags in the web UI. - Used test console to send myself mail with an opt-outable tag, it was immediately dropped. - Used test console to send myself mail with an opt-outable tag and a custom tag, it was delivered. - Made Differential updates affecting CCs with and without comments, got appropriate delivery. - Made Maniphest updates affecting project, priority and CCs with and without comments, got appropriate delivery. - Verified mail headers in all cases. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley, moskov Maniphest Tasks: T616, T855 Differential Revision: https://secure.phabricator.com/D1635
2012-02-18 07:57:07 +01:00
'MetaMTANotificationType' => 'MetaMTAConstants',
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',
'PackageCreateMail' => 'PackageMail',
'PackageDeleteMail' => 'PackageMail',
'PackageModifyMail' => 'PackageMail',
I guess this can support JS too.
2011-01-30 01:16:09 +01:00
'Phabricator404Controller' => 'PhabricatorController',
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
'PhabricatorApplicationApplications' => 'PhabricatorApplication',
'PhabricatorApplicationAudit' => 'PhabricatorApplication',
Drive menu icons from Applications Summary: This makes no changes, it just moves the menu icons to the applications instead of hard-coded on the page. I'm going to try to address some of the angst in T1593 next... Test Plan: Loaded logged-in / logged out pages. Clicked menu items. Looked at /applications/. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1593, T1569 Differential Revision: https://secure.phabricator.com/D3146
2012-08-05 23:12:43 +02:00
'PhabricatorApplicationAuth' => 'PhabricatorApplication',
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
'PhabricatorApplicationDifferential' => 'PhabricatorApplication',
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
'PhabricatorApplicationDiffusion' => '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
'PhabricatorApplicationFact' => 'PhabricatorApplication',
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
'PhabricatorApplicationFlags' => 'PhabricatorApplication',
'PhabricatorApplicationLaunchView' => 'AphrontView',
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
'PhabricatorApplicationManiphest' => 'PhabricatorApplication',
Drive menu icons from Applications Summary: This makes no changes, it just moves the menu icons to the applications instead of hard-coded on the page. I'm going to try to address some of the angst in T1593 next... Test Plan: Loaded logged-in / logged out pages. Clicked menu items. Looked at /applications/. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1593, T1569 Differential Revision: https://secure.phabricator.com/D3146
2012-08-05 23:12:43 +02:00
'PhabricatorApplicationPeople' => 'PhabricatorApplication',
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
'PhabricatorApplicationPhriction' => 'PhabricatorApplication',
Add a "Project" application Summary: Move routes into a formal application class. Test Plan: Checked /applications/, browsed various routes. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, floatinglomas Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3181
2012-08-07 20:54:49 +02:00
'PhabricatorApplicationProject' => 'PhabricatorApplication',
Drive menu icons from Applications Summary: This makes no changes, it just moves the menu icons to the applications instead of hard-coded on the page. I'm going to try to address some of the angst in T1593 next... Test Plan: Loaded logged-in / logged out pages. Clicked menu items. Looked at /applications/. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1593, T1569 Differential Revision: https://secure.phabricator.com/D3146
2012-08-05 23:12:43 +02:00
'PhabricatorApplicationSettings' => 'PhabricatorApplication',
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',
'PhabricatorApplicationsController' => 'PhabricatorController',
'PhabricatorApplicationsListController' => 'PhabricatorApplicationsController',
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',
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
'PhabricatorAuditComment' => 'PhabricatorAuditDAO',
Show commits in /audit/ Summary: The general idea here is to build a Differential-like dashboard which shows all the things you need to audit and all the things that other people have raised issues with, so you have a one-stop "what do I need to deal with?" interface. - Add problem commits to the "active" view of /audit/. - Add problem commits to homepage. - Add commit browsing interfaces to /audit/. - Add an "Audit" app button. Test Plan: Looked at homepage, commit filters. Audited commits, verified state changes reflected properly. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1712
2012-02-29 06:10:39 +01:00
'PhabricatorAuditCommitListView' => 'AphrontView',
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',
'PhabricatorAuditDAO' => 'PhabricatorLiskDAO',
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
'PhabricatorAuditInlineComment' =>
array(
0 => 'PhabricatorAuditDAO',
1 => 'PhabricatorInlineCommentInterface',
),
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
'PhabricatorAuditListController' => 'PhabricatorAuditController',
'PhabricatorAuditListView' => 'AphrontView',
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',
Enable email for audits Summary: When users submit an audit, send email to relevant parties informing them. Allow email to be replied to. Just basic support so far; no "!raise" stuff and no threading with the Herald commit notification. Test Plan: Made comments, got email. Replied to email, got comments. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1698
2012-02-27 21:57:57 +01:00
'PhabricatorAuditReplyHandler' => 'PhabricatorMailReplyHandler',
Authentication
2011-01-26 22:21:12 +01:00
'PhabricatorAuthController' => 'PhabricatorController',
Allow extending English translation Test Plan: Displayed home. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D2759
2012-06-15 04:01:57 +02:00
'PhabricatorBaseEnglishTranslation' => 'PhabricatorTranslation',
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',
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',
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
'PhabricatorCalendarBrowseController' => 'PhabricatorCalendarController',
'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',
'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',
Minor, formalize changeset response class.
2012-03-13 05:39:05 +01:00
'PhabricatorChangesetResponse' => 'AphrontProxyResponse',
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',
'PhabricatorChatLogController' => 'PhabricatorController',
'PhabricatorChatLogDAO' => 'PhabricatorLiskDAO',
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
'PhabricatorChatLogEvent' =>
array(
0 => 'PhabricatorChatLogDAO',
1 => 'PhabricatorPolicyInterface',
),
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
'PhabricatorChatLogEventType' => 'PhabricatorChatLogConstants',
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
'PhabricatorChatLogQuery' => 'PhabricatorCursorPagedPolicyQuery',
Conduit server-side basics.
2011-01-24 18:00:29 +01:00
'PhabricatorConduitAPIController' => 'PhabricatorConduitController',
"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',
Conduit server-side basics.
2011-01-24 18:00:29 +01:00
'PhabricatorConduitConnectionLog' => 'PhabricatorConduitDAO',
'PhabricatorConduitConsoleController' => 'PhabricatorConduitController',
'PhabricatorConduitController' => 'PhabricatorController',
'PhabricatorConduitDAO' => 'PhabricatorLiskDAO',
Create overview of Conduit methods Summary: Also couple of small changes: - Add method name to title. - 404 for /conduit/method/x/. - Remove utilities from side panel. - Remove side panel from log. Test Plan: /conduit/ /conduit/method/x/ /conduit/method/user.whoami/ /conduit/log/ Reviewers: btrahan, epriestley Reviewed By: epriestley CC: aran, Koolvin Differential Revision: https://secure.phabricator.com/D2326
2012-04-27 07:25:05 +02:00
'PhabricatorConduitListController' => 'PhabricatorConduitController',
Conduit server-side basics.
2011-01-24 18:00:29 +01:00
'PhabricatorConduitLogController' => 'PhabricatorConduitController',
'PhabricatorConduitMethodCallLog' => 'PhabricatorConduitDAO',
"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',
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',
More phabricator organizational stuff.
2011-01-23 02:48:55 +01:00
'PhabricatorController' => 'AphrontController',
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',
'PhabricatorCountdownDAO' => 'PhabricatorLiskDAO',
'PhabricatorCountdownDeleteController' => 'PhabricatorCountdownController',
'PhabricatorCountdownEditController' => 'PhabricatorCountdownController',
'PhabricatorCountdownListController' => 'PhabricatorCountdownController',
'PhabricatorCountdownViewController' => 'PhabricatorCountdownController',
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
'PhabricatorCursorPagedPolicyQuery' => 'PhabricatorPolicyQuery',
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 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
'PhabricatorDaemonCombinedLogController' => 'PhabricatorDaemonController',
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',
'PhabricatorDaemonController' => 'PhabricatorController',
Diffusion/phd/console improvements.
2011-03-15 21:38:14 +01:00
'PhabricatorDaemonDAO' => 'PhabricatorLiskDAO',
'PhabricatorDaemonLog' => 'PhabricatorDaemonDAO',
'PhabricatorDaemonLogEvent' => 'PhabricatorDaemonDAO',
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',
'PhabricatorDaemonLogListController' => 'PhabricatorDaemonController',
'PhabricatorDaemonLogListView' => 'AphrontView',
Diffusion/phd/console improvements.
2011-03-15 21:38:14 +01:00
'PhabricatorDaemonLogViewController' => 'PhabricatorDaemonController',
Increase parseriness of some parsery things. Summary: None of these are parsnips. Test Plan: Reviewers: CC:
2011-03-11 18:34:22 +01:00
'PhabricatorDaemonTimelineConsoleController' => 'PhabricatorDaemonController',
'PhabricatorDaemonTimelineEventController' => 'PhabricatorDaemonController',
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
'PhabricatorDefaultFileStorageEngineSelector' => 'PhabricatorFileStorageEngineSelector',
Provide an indirection layer between documents and the search engine Summary: In preparation for adding another search engine (see T355): - Rename "executor" to "engine". - Move all engine-specific operations into the engine. Specifically, this means that indexing moves out of the document store and into the engine (it was sort of silly where it was before). - Split choice of an engine into an overridable "selector" class, a base API, and a concrete MySQL implementation (just like storage engine selection). - Make all callers go through the indirection layer. The default selector just unconditionally selects the MySQL engine, but now (with D786) I can build an Elastic Search engine and you guys can build a multi-target engine if you want and I don't get there fast enough. Test Plan: - Created a new document (task). - Searched for and found it. - Viewed index reconstruction. Reviewed By: jungejason Reviewers: jungejason, amckinley, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 788
2011-08-08 00:14:23 +02:00
'PhabricatorDefaultSearchEngineSelector' => 'PhabricatorSearchEngineSelector',
More phabricator organizational stuff.
2011-01-23 02:48:55 +01:00
'PhabricatorDirectoryController' => 'PhabricatorController',
Further improve unit/lint rendering Summary: I think this improves things, let me know if you have feedback. Also addresses T840. Test Plan: See screenshots... Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran, zeeg Maniphest Tasks: T840 Differential Revision: https://secure.phabricator.com/D2357
2012-05-01 19:15:56 +02:00
'PhabricatorDirectoryMainController' => 'PhabricatorDirectoryController',
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',
Revision comment drafts.
2011-02-06 01:57:21 +01:00
'PhabricatorDraft' => 'PhabricatorDraftDAO',
'PhabricatorDraftDAO' => 'PhabricatorLiskDAO',
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',
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',
'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',
PhabricatorEnv 'infratructure' -> 'infrastructure' (rofl) Recaptcha Email Login / Forgot Password Password Reset
2011-01-31 20:55:26 +01:00
'PhabricatorEmailLoginController' => 'PhabricatorAuthController',
'PhabricatorEmailTokenController' => 'PhabricatorAuthController',
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
'PhabricatorEmailVerificationController' => 'PhabricatorPeopleController',
Allow extending English translation Test Plan: Displayed home. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D2759
2012-06-15 04:01:57 +02:00
'PhabricatorEnglishTranslation' => 'PhabricatorBaseEnglishTranslation',
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',
Make error views look less awful Summary: These elements look heavy and out of place right now. Test Plan: Looked at error views in uiexample page. Reviewers: btrahan, vrana, jungejason Reviewed By: jungejason CC: aran Differential Revision: https://secure.phabricator.com/D2144
2012-04-08 02:25:31 +02:00
'PhabricatorErrorExample' => 'PhabricatorUIExample',
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',
'PhabricatorEventType' => 'PhutilEventType',
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' => 'PhutilEventListener',
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',
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',
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',
'PhabricatorFactManagementWorkflow' => 'PhutilArgumentWorkflow',
'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',
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',
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',
Provide a public view of feed Summary: Depends on D628. Provides a config option so you can set up a public feed, which you can iframe. This needs some work but sort of works. Test Plan: Loaded the public feed as a logged-out user. Reviewed By: codeblock Reviewers: jungejason, tuomaspelkonen, aran, codeblock CC: aran, codeblock Differential Revision: 635
2011-07-10 03:03:59 +02:00
'PhabricatorFeedPublicStreamController' => 'PhabricatorFeedController',
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
'PhabricatorFeedQuery' => 'PhabricatorCursorPagedPolicyQuery',
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
'PhabricatorFeedStory' => 'PhabricatorPolicyInterface',
Support basic notification aggregation Summary: This is both only partially complete (supports Maniphest only) and somewhat overcomplicated (includes support for applying similar algorithms to Feed), but provides runtime aggregation of notifications. Test Plan: {F13502} Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2884
2012-07-01 20:08:59 +02:00
'PhabricatorFeedStoryAggregate' => 'PhabricatorFeedStory',
Integrate Audit into feed Summary: When a user posts an action in the audit tool, publish it to feed. Test Plan: Made some comments, saw them show up in feed. Reviewers: btrahan, jungejason Reviewed By: jungejason CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1695
2012-02-27 18:49:01 +01:00
'PhabricatorFeedStoryAudit' => 'PhabricatorFeedStory',
Publish feed stories about commits Summary: When stuff gets committed, publish feed stories about it. Test Plan: {F13061} Reviewers: jungejason, vrana, voldern Reviewed By: jungejason CC: aran Maniphest Tasks: T1322 Differential Revision: https://secure.phabricator.com/D2805
2012-06-20 15:03:44 +02:00
'PhabricatorFeedStoryCommit' => 'PhabricatorFeedStory',
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',
Publish Differential stories into feed Summary: Basic hookup for Differential -> Feed. Also introduces "one-line" stories for less-important stuff. Test Plan: Interacted with some revisions, got feed stories out of it. Reviewed By: jungejason Reviewers: jungejason, aran, tuomaspelkonen, codeblock CC: aran, jungejason Differential Revision: 632
2011-07-10 00:44:49 +02:00
'PhabricatorFeedStoryDifferential' => 'PhabricatorFeedStory',
Publish feed stories from Maniphest Summary: I didn't get around to this earlier; add Feed/Maniphest integration. This is partly motivated by wanting Projects to not be terrible. Pretty straightforward. Test Plan: - Created, updated, reassigned and closed a task. - Verified feed stories render reasonably. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, btrahan Maniphest Tasks: T681 Differential Revision: 1232
2011-12-17 22:27:11 +01:00
'PhabricatorFeedStoryManiphest' => 'PhabricatorFeedStory',
Support basic notification aggregation Summary: This is both only partially complete (supports Maniphest only) and somewhat overcomplicated (includes support for applying similar algorithms to Feed), but provides runtime aggregation of notifications. Test Plan: {F13502} Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2884
2012-07-01 20:08:59 +02:00
'PhabricatorFeedStoryManiphestAggregate' => 'PhabricatorFeedStoryAggregate',
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',
Publish Phriction edits to feed Summary: Basic integration between Phriction and feed. Test Plan: Created and edited some documents, they published to feed. Reviewed By: hsb Reviewers: hsb, codeblock, jungejason, tuomaspelkonen, aran CC: aran, hsb Differential Revision: 653
2011-07-12 16:23:04 +02:00
'PhabricatorFeedStoryPhriction' => 'PhabricatorFeedStory',
Add transaction-oriented editing to projects Summary: - Make some editing operations transaction-oriented, like Maniphest. (This seems to be a good model, particularly for extensibility.) I'll move the rest of the editing operations to transactions in future diffs. - Make transaction-oriented operations publish feed stories. Test Plan: - Created a new project. - Edited an existing project. - Created a new project via quick create flow from Maniphest. - Verified feed stories publish correctly. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T681 Differential Revision: https://secure.phabricator.com/D1477
2012-01-24 16:11:37 +01:00
'PhabricatorFeedStoryProject' => 'PhabricatorFeedStory',
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',
Improve feed stories with "style", and build basic status update stories. Summary: Straightfoward iteration on feed. Test Plan: https://secure.phabricator.com/file/view/PHID-FILE-d07077119dc834e76618/ Reviewed By: codeblock Reviewers: jungejason, aran, tuomaspelkonen, codeblock CC: aran, codeblock, epriestley Differential Revision: 631
2011-07-09 22:28:09 +02:00
'PhabricatorFeedStoryStatus' => 'PhabricatorFeedStory',
Publish Differential stories into feed Summary: Basic hookup for Differential -> Feed. Also introduces "one-line" stories for less-important stuff. Test Plan: Interacted with some revisions, got feed stories out of it. Reviewed By: jungejason Reviewers: jungejason, aran, tuomaspelkonen, codeblock CC: aran, jungejason Differential Revision: 632
2011-07-10 00:44:49 +02:00
'PhabricatorFeedStoryTypeConstants' => 'PhabricatorFeedConstants',
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
'PhabricatorFeedStoryUnknown' => 'PhabricatorFeedStory',
'PhabricatorFeedStoryView' => 'PhabricatorFeedView',
'PhabricatorFeedView' => 'AphrontView',
Phabricator file upload application.
2011-01-23 03:33:00 +01:00
'PhabricatorFile' => 'PhabricatorFileDAO',
'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',
Image macros for Phabricator! Summary: Added long waited image macro support for differential and others. Test Plan: Tried a couple of different macros and made sure they appear nicely in the comment preview. Made sure that the normal comments are shown correctly. Reviewed By: epriestley Reviewers: epriestley CC: jungejason, tuomaspelkonen, epriestley Differential Revision: 129
2011-04-14 00:15:48 +02:00
'PhabricatorFileImageMacro' => 'PhabricatorFileDAO',
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',
Phabricator file upload application.
2011-01-23 03:33:00 +01:00
'PhabricatorFileListController' => 'PhabricatorFileController',
Web editor/browser for image macros Summary: Restores the old "pokedex" feature and allows easy definition of new macros. Only good can come of this! Critical feature!! Test Plan: nyancat Reviewed By: tuomaspelkonen Reviewers: aran, bh, tomo, jungejason, tuomaspelkonen CC: aran, tuomaspelkonen Differential Revision: 220
2011-05-03 19:45:45 +02:00
'PhabricatorFileMacroDeleteController' => 'PhabricatorFileController',
'PhabricatorFileMacroEditController' => 'PhabricatorFileController',
'PhabricatorFileMacroListController' => 'PhabricatorFileController',
Restore image proxying to Remarkup Summary: Previously, Remarkup allowed you to paste in an image URI and get an inline image. However, it did this by hotlinking the image which isn't so hot in an open source product. Restore this feature, but use image proxying instead. The existing image macro code does most of the work. There is a mild security risk depending on the network setup so I've left this default-disabled and made a note about it. It should be safe to enable for Facebook. Test Plan: Pasted in image and non-image links, got reasonable behavior. Verified proxying appears to work. Verified that file:// shenanigans produce 400. Reviewed By: tuomaspelkonen Reviewers: aran, jungejason, tuomaspelkonen Commenters: cpiro CC: aran, cpiro, tuomaspelkonen Differential Revision: 214
2011-05-02 23:20:24 +02:00
'PhabricatorFileProxyController' => 'PhabricatorFileController',
'PhabricatorFileProxyImage' => 'PhabricatorFileDAO',
Add /F123 shortcut Summary: I wanted to point someone on a file uploaded to Phabricator and the normal link is just too long. I guess that this also improves security. Because pointing someone to the file directly reveals the secret key used in /data/ and it can be served without auth? We already use `{F123}` so there will be no conflicts in future because we wouldn't want to reuse it for something else. I promote the link on /file/ - it adds one redirect but I think it's worth it. I also considered making the link from the File ID column but there are already too many links (with some duplicity). Test Plan: /file/ /F123 (redirect) /F9999999999 (404) Reviewers: epriestley Reviewed By: epriestley CC: aran, Koolvin Differential Revision: https://secure.phabricator.com/D2380
2012-05-03 23:46:11 +02:00
'PhabricatorFileShortcutController' => 'PhabricatorFileController',
Files - kill tabs Summary: kill tabs for Files application. Technique is the "filter list" on the left hand side, with separation for "Files" versus "Image Macros". UI quirks include: - the page title does not change for the 3 files filters while it does change for each of the two image macro filters. - standalone "file" pages do not have the filter view - you can visit /file/upload/ standalone and it doesn't have the pretty filter list on it Please do give direction on these quirks if you like. :) This change also neuters the ?author= functionality for files. The code is written such that it can easily be brought back. Test Plan: clicked around on the filters, liked what I saw. uploaded files fancy-like and basic-like and it worked! made image macros and it worked! Reviewers: epriestley Reviewed By: epriestley CC: aran, btrahan, epriestley Maniphest Tasks: T631 Differential Revision: 1219
2011-12-15 07:37:23 +01:00
'PhabricatorFileSideNavView' => 'AphrontView',
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',
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',
Phabricator file upload application.
2011-01-23 03:33:00 +01:00
'PhabricatorFileUploadController' => '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',
Files - kill tabs Summary: kill tabs for Files application. Technique is the "filter list" on the left hand side, with separation for "Files" versus "Image Macros". UI quirks include: - the page title does not change for the 3 files filters while it does change for each of the two image macro filters. - standalone "file" pages do not have the filter view - you can visit /file/upload/ standalone and it doesn't have the pretty filter list on it Please do give direction on these quirks if you like. :) This change also neuters the ?author= functionality for files. The code is written such that it can easily be brought back. Test Plan: clicked around on the filters, liked what I saw. uploaded files fancy-like and basic-like and it worked! made image macros and it worked! Reviewers: epriestley Reviewed By: epriestley CC: aran, btrahan, epriestley Maniphest Tasks: T631 Differential Revision: 1219
2011-12-15 07:37:23 +01:00
'PhabricatorFileUploadView' => 'AphrontView',
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
'PhabricatorFlag' => 'PhabricatorFlagDAO',
'PhabricatorFlagColor' => 'PhabricatorFlagConstants',
'PhabricatorFlagController' => 'PhabricatorController',
'PhabricatorFlagDAO' => 'PhabricatorLiskDAO',
'PhabricatorFlagDeleteController' => 'PhabricatorFlagController',
'PhabricatorFlagEditController' => 'PhabricatorFlagController',
'PhabricatorFlagListController' => 'PhabricatorFlagController',
'PhabricatorFlagListView' => '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
'PhabricatorFormExample' => 'PhabricatorUIExample',
Add a garbage collector daemon Summary: Phabricator generates a bunch of data that we don't need to keep around forever, add a GC daemon to get rid of it with some basic configuration options. This needs a couple more diffs to get some of the details but I think this is a reasonable start. I also fixed a couple of UI things related to this, e.g. the daemon logs page going crazy when a daemon gets stuck in a loop and dumps tons of data to stdout. Test Plan: - Ran gc daemon in 'phd debug' mode and saw it delete stuff, then sleep once it had cleaned everything up. - Mucked around with TTLs and verified they work correctly. - Viewed gc'd transcripts in the web interface and made sure they displayed okay. - Viewed daemon logs before/after garbage collection. - Running some run-at / run-for tests now, I'll update if the daemon doesn't shut off in ~10-15 minutes. :P Reviewed By: tuomaspelkonen Reviewers: jungejason, tuomaspelkonen, aran CC: aran, tuomaspelkonen, epriestley Differential Revision: 583
2011-07-03 18:47:31 +02:00
'PhabricatorGarbageCollectorDaemon' => 'PhabricatorDaemon',
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',
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
'PhabricatorGoodForNothingWorker' => 'PhabricatorWorker',
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',
'PhabricatorHelpKeyboardShortcutController' => 'PhabricatorHelpController',
Very basic IRC Bot Summary: This is sort of a silly/fun project but I think there's some utility. For example, mroch added some handlers to an eggdrop or something similar to look for "D12345" and print out the title/link, which was actually pretty useful. We could also add logging here and subsume the more-or-less unowned Facebook tool that does the same thing, especially since we can get a bunch of good stuff it doesn't support (like search) more or less for free. This is also an easy way to provide some example code for writing Conduit system agents. This is a minimal implementation which creates a bot that connects to a hard-coded server and sits there indefinitely. Next steps: - Add conduit/sysagent support - Write differential/maniphest/diffusion handlers - Move configuration to the web interface (?) and integrate with phd - Write a logging handler? Test Plan: Ran bot with "exec_daemon.php", it connected to the hard-coded server and sat there indefinitely. Reviewed By: aran Reviewers: codeblock, mroch, tuomaspelkonen, aran, jungejason CC: aran, epriestley Differential Revision: 283
2011-05-15 18:29:48 +02:00
'PhabricatorIRCBot' => 'PhabricatorDaemon',
Add an example notification handler to the IRC bot Summary: Simple notificaiton handler that reads the difx event timeline and posts notifications to IRC. Test Plan: Ran it in #phabricator. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, btrahan Differential Revision: https://secure.phabricator.com/D1337
2012-01-06 20:31:00 +01:00
'PhabricatorIRCDifferentialNotificationHandler' => 'PhabricatorIRCHandler',
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
'PhabricatorIRCLogHandler' => 'PhabricatorIRCHandler',
Bring macros to IRC Summary: Adds a macro handler that spams your channel with macros. Config is: - macro.size: scale macros to this size before rasterizing - macro.sleep: sleep this many seconds between lines (evade flood protection) Test Plan: derpderp Reviewers: kdeggelman, btrahan Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1838
2012-03-09 21:40:03 +01:00
'PhabricatorIRCMacroHandler' => 'PhabricatorIRCHandler',
Add an "IRC Object Name" handler for D12345 Summary: I need to add some more conduit methods / info to make this at all useful but here's some basics. Test Plan: Hung out in #phabot-test Reviewed By: mroch Reviewers: mroch, codeblock, aran, jungejason, tuomaspelkonen CC: aran, mroch, epriestley Differential Revision: 300
2011-05-17 23:40:25 +02:00
'PhabricatorIRCObjectNameHandler' => 'PhabricatorIRCHandler',
Very basic IRC Bot Summary: This is sort of a silly/fun project but I think there's some utility. For example, mroch added some handlers to an eggdrop or something similar to look for "D12345" and print out the title/link, which was actually pretty useful. We could also add logging here and subsume the more-or-less unowned Facebook tool that does the same thing, especially since we can get a bunch of good stuff it doesn't support (like search) more or less for free. This is also an easy way to provide some example code for writing Conduit system agents. This is a minimal implementation which creates a bot that connects to a hard-coded server and sits there indefinitely. Next steps: - Add conduit/sysagent support - Write differential/maniphest/diffusion handlers - Move configuration to the web interface (?) and integrate with phd - Write a logging handler? Test Plan: Ran bot with "exec_daemon.php", it connected to the hard-coded server and sat there indefinitely. Reviewed By: aran Reviewers: codeblock, mroch, tuomaspelkonen, aran, jungejason CC: aran, epriestley Differential Revision: 283
2011-05-15 18:29:48 +02:00
'PhabricatorIRCProtocolHandler' => 'PhabricatorIRCHandler',
IRC Bot what's new directive Summary: Added "What's new?" to the ircbot ====Matches ```What is new? What's new? Whats new``` Test Plan: <`Korvin> what is new? <korvinbot-local> Derpen created D1: Herped the derp - http://phabricator.net/D1 It shows five. Reviewers: epriestley Reviewed By: epriestley CC: epriestley, aran Differential Revision: https://secure.phabricator.com/D1666
2012-02-24 03:01:25 +01:00
'PhabricatorIRCWhatsNewHandler' => 'PhabricatorIRCHandler',
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',
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',
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',
Made it possible to login using LDAP Summary: Made it possible to link and unlink LDAP accounts with Phabricator accounts. Test Plan: I've tested this code locally and in production where I work. I've tried creating an account from scratch by logging in with LDAP and linking and unlinking an LDAP account with an existing account. I've tried to associate the same LDAP account with different Phabricator accounts and it failed as expected. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, auduny, svemir Maniphest Tasks: T742 Differential Revision: https://secure.phabricator.com/D2722
2012-06-13 17:52:05 +02:00
'PhabricatorLDAPLoginController' => 'PhabricatorAuthController',
'PhabricatorLDAPRegistrationController' => 'PhabricatorAuthController',
Prevent the ability to scrape for valid usernames - return the same error message when either bind or the username search fails to find a user - config variables should use hypen and not underscore
2012-07-26 23:32:51 +02:00
'PhabricatorLDAPUnknownUserException' => 'Exception',
Made it possible to login using LDAP Summary: Made it possible to link and unlink LDAP accounts with Phabricator accounts. Test Plan: I've tested this code locally and in production where I work. I've tried creating an account from scratch by logging in with LDAP and linking and unlinking an LDAP account with an existing account. I've tried to associate the same LDAP account with different Phabricator accounts and it failed as expected. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, auduny, svemir Maniphest Tasks: T742 Differential Revision: https://secure.phabricator.com/D2722
2012-06-13 17:52:05 +02:00
'PhabricatorLDAPUnlinkController' => 'PhabricatorAuthController',
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
'PhabricatorLintEngine' => 'PhutilLintEngine',
More phabricator organizational stuff.
2011-01-23 02:48:55 +01:00
'PhabricatorLiskDAO' => 'LiskDAO',
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',
Authentication
2011-01-26 22:21:12 +01:00
'PhabricatorLoginController' => 'PhabricatorAuthController',
Validate logins, and simplify email password resets Summary: - There are some recent reports of login issues, see T755 and T754. I'm not really sure what's going on, but this is an attempt at getting some more information. - When we login a user by setting 'phusr' and 'phsid', send them to /login/validate/ to validate that the cookies actually got set. - Do email password resets in two steps: first, log the user in. Redirect them through validate, then give them the option to reset their password. - Don't CSRF logged-out users. It technically sort of works most of the time right now, but is silly. If we need logged-out CSRF we should generate it in some more reliable way. Test Plan: - Logged in with username/password. - Logged in with OAuth. - Logged in with email password reset. - Sent bad values to /login/validate/, got appropriate errors. - Reset password. - Verified next_uri still works. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, btrahan, j3kuntz Maniphest Tasks: T754, T755 Differential Revision: https://secure.phabricator.com/D1353
2012-01-10 23:42:07 +01:00
'PhabricatorLoginValidateController' => 'PhabricatorAuthController',
CSRF / Logout
2011-01-31 03:52:29 +01:00
'PhabricatorLogoutController' => 'PhabricatorAuthController',
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',
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',
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
'PhabricatorMainMenuGroupView' => 'AphrontView',
'PhabricatorMainMenuIconView' => 'AphrontView',
'PhabricatorMainMenuSearchView' => 'AphrontView',
'PhabricatorMainMenuView' => 'AphrontView',
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',
MetaMTA
2011-01-26 02:40:21 +01:00
'PhabricatorMetaMTAController' => 'PhabricatorController',
'PhabricatorMetaMTADAO' => 'PhabricatorLiskDAO',
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',
MetaMTA
2011-01-26 02:40:21 +01:00
'PhabricatorMetaMTAListController' => 'PhabricatorMetaMTAController',
'PhabricatorMetaMTAMail' => 'PhabricatorMetaMTADAO',
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',
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',
Mailing lists
2011-01-26 19:40:38 +01:00
'PhabricatorMetaMTAMailingList' => 'PhabricatorMetaMTADAO',
'PhabricatorMetaMTAMailingListEditController' => 'PhabricatorMetaMTAController',
'PhabricatorMetaMTAMailingListsController' => 'PhabricatorMetaMTAController',
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
'PhabricatorMetaMTAReceiveController' => 'PhabricatorMetaMTAController',
'PhabricatorMetaMTAReceivedListController' => 'PhabricatorMetaMTAController',
'PhabricatorMetaMTAReceivedMail' => 'PhabricatorMetaMTADAO',
MetaMTA
2011-01-26 02:40:21 +01:00
'PhabricatorMetaMTASendController' => 'PhabricatorMetaMTAController',
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',
MetaMetaView
2011-01-26 18:08:26 +01:00
'PhabricatorMetaMTAViewController' => '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',
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',
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',
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',
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',
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',
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
'PhabricatorNotificationQuery' => 'PhabricatorOffsetPagedQuery',
Add a server status page for notification server Summary: - Add a /notification/status/ page which shows server status. - Remove various test controllers and routes. - Make the "no notifications" message look better. - Move port/URI configuration to config file. Test Plan: Started server, hit /notification/status/, saw server status. Reviewers: allenjohnashton, ddfisher, keebuhm, jungejason Reviewed By: jungejason CC: aran Maniphest Tasks: T944 Differential Revision: https://secure.phabricator.com/D2756
2012-06-17 20:35:18 +02:00
'PhabricatorNotificationStatusController' => 'PhabricatorNotificationController',
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
'PhabricatorNotificationStoryView' => 'PhabricatorNotificationView',
'PhabricatorNotificationView' => 'AphrontView',
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
'PhabricatorOAuthClientAuthorization' => 'PhabricatorOAuthServerDAO',
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
'PhabricatorOAuthClientAuthorizationBaseController' => 'PhabricatorOAuthServerController',
'PhabricatorOAuthClientAuthorizationDeleteController' => 'PhabricatorOAuthClientAuthorizationBaseController',
'PhabricatorOAuthClientAuthorizationEditController' => 'PhabricatorOAuthClientAuthorizationBaseController',
'PhabricatorOAuthClientAuthorizationListController' => 'PhabricatorOAuthClientAuthorizationBaseController',
Add pagers to server clients and client authorizations in OAuth Server GUI Summary: ...also make the pager usage in ChatLog use the nice formatWhereClause functionality Test Plan: set $page_size = 2 and paged around the data a bit Reviewers: epriestley Reviewed By: epriestley CC: aran Maniphest Tasks: T905 Differential Revision: https://secure.phabricator.com/D2106
2012-04-05 02:51:16 +02:00
'PhabricatorOAuthClientAuthorizationQuery' => 'PhabricatorOffsetPagedQuery',
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
'PhabricatorOAuthClientBaseController' => 'PhabricatorOAuthServerController',
'PhabricatorOAuthClientDeleteController' => 'PhabricatorOAuthClientBaseController',
'PhabricatorOAuthClientEditController' => 'PhabricatorOAuthClientBaseController',
'PhabricatorOAuthClientListController' => 'PhabricatorOAuthClientBaseController',
'PhabricatorOAuthClientViewController' => 'PhabricatorOAuthClientBaseController',
Modularize oauth.
2011-02-28 04:47:22 +01:00
'PhabricatorOAuthDefaultRegistrationController' => 'PhabricatorOAuthRegistrationController',
Github OAuth Summary: Test Plan: Reviewers: CC:
2011-02-21 07:47:56 +01:00
'PhabricatorOAuthDiagnosticsController' => 'PhabricatorAuthController',
'PhabricatorOAuthFailureView' => 'AphrontView',
'PhabricatorOAuthLoginController' => 'PhabricatorAuthController',
OAuth -- add support for Disqus Summary: also fix some bugs where we weren't properly capturing the expiry value or scope of access tokens. This code isn't the cleanest as some providers don't confirm what scope you've been granted. In that case, assume the access token is of the minimum scope Phabricator requires. This seems more useful to me as only Phabricator at the moment really easily / consistently lets the user increase / decrease the granted scope so its basically always the correct assumption at the time we make it. Test Plan: linked and unlinked Phabricator, Github, Disqus and Facebook accounts from Phabricator instaneces Reviewers: epriestley Reviewed By: epriestley CC: zeeg, aran, Koolvin Maniphest Tasks: T1110 Differential Revision: https://secure.phabricator.com/D2431
2012-05-08 21:08:05 +02:00
'PhabricatorOAuthProviderDisqus' => 'PhabricatorOAuthProvider',
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
'PhabricatorOAuthProviderException' => 'Exception',
Github OAuth Summary: Test Plan: Reviewers: CC:
2011-02-21 07:47:56 +01:00
'PhabricatorOAuthProviderFacebook' => 'PhabricatorOAuthProvider',
Github is actually GitHub Test Plan: none Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1557
2012-02-03 02:25:31 +01:00
'PhabricatorOAuthProviderGitHub' => 'PhabricatorOAuthProvider',
Add Google as an OAuth2 provider (BETA) Summary: This is pretty straightforward, except: - We need to request read/write access to the address book to get the account ID (which we MUST have) and real name, email and account name (which we'd like to have). This is way more access than we should need, but there's apparently no "get_loggedin_user_basic_information" type of call in the Google API suite (or, at least, I couldn't find one). - We can't get the profile picture or profile URI since there's no Plus API access and Google users don't have meaningful public pages otherwise. - Google doesn't save the fact that you've authorized the app, so every time you want to login you need to reaffirm that you want to give us silly amounts of access. Phabricator sessions are pretty long-duration though so this shouldn't be a major issue. Test Plan: - Registered, logged out, and logged in with Google. - Registered, logged out, and logged in with Facebook / Github to make sure I didn't break anything. - Linked / unlinked Google accounts. Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran Reviewed By: aran CC: aran, epriestley, Makinde Differential Revision: 916
2011-09-09 01:37:22 +02:00
'PhabricatorOAuthProviderGoogle' => 'PhabricatorOAuthProvider',
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
'PhabricatorOAuthProviderPhabricator' => 'PhabricatorOAuthProvider',
Modularize oauth.
2011-02-28 04:47:22 +01:00
'PhabricatorOAuthRegistrationController' => 'PhabricatorAuthController',
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',
'PhabricatorOAuthServerAccessToken' => 'PhabricatorOAuthServerDAO',
'PhabricatorOAuthServerAuthController' => 'PhabricatorAuthController',
'PhabricatorOAuthServerAuthorizationCode' => 'PhabricatorOAuthServerDAO',
'PhabricatorOAuthServerClient' => 'PhabricatorOAuthServerDAO',
Add pagers to server clients and client authorizations in OAuth Server GUI Summary: ...also make the pager usage in ChatLog use the nice formatWhereClause functionality Test Plan: set $page_size = 2 and paged around the data a bit Reviewers: epriestley Reviewed By: epriestley CC: aran Maniphest Tasks: T905 Differential Revision: https://secure.phabricator.com/D2106
2012-04-05 02:51:16 +02:00
'PhabricatorOAuthServerClientQuery' => 'PhabricatorOffsetPagedQuery',
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',
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',
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',
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
'PhabricatorOAuthServerTestController' => '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
'PhabricatorOAuthServerTokenController' => 'PhabricatorAuthController',
OAuth linking/unlinking controls. Summary: Test Plan: Reviewers: CC:
2011-02-22 07:51:34 +01:00
'PhabricatorOAuthUnlinkController' => 'PhabricatorAuthController',
Add object status to Handles Summary: We use ObjectHandles as proxy objects which can refer to any other object in the system. Add the concept of the underlying object's "status" (e.g., open, closed or busy). This allows us to render completed tasks and revisions with strikethrough. In the future, if we implement OOO or something, we could render users with a "busy" status if they're on vacation, etc. Test Plan: Viewed a task with closed revisions and dependencies: https://secure.phabricator.com/file/view/PHID-FILE-6183e81286fa3288d33d/ Reviewed By: codeblock Reviewers: codeblock, hunterbridges, jungejason, tuomaspelkonen, aran CC: aran, codeblock Differential Revision: 772
2011-08-03 15:37:18 +02:00
'PhabricatorObjectHandleStatus' => 'PhabricatorObjectHandleConstants',
Make project membership edits use transactions and PHIDs and not be awful Summary: - Split project profile editing apart from project membership editing. - Make project membership editing simpler and easier to use. - Drop role / owner stuff from the UI. Test Plan: Added and removed project members. Edited project profile information. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3184
2012-08-07 20:57:38 +02:00
'PhabricatorObjectListView' => 'AphrontView',
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',
owners
2011-04-03 23:48:36 +02:00
'PhabricatorOwnersController' => 'PhabricatorController',
'PhabricatorOwnersDAO' => 'PhabricatorLiskDAO',
Some owners write workflows.
2011-04-04 07:03:27 +02:00
'PhabricatorOwnersDeleteController' => 'PhabricatorOwnersController',
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',
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
'PhabricatorOwnersPackage' =>
array(
0 => 'PhabricatorOwnersDAO',
1 => 'PhabricatorPolicyInterface',
),
'PhabricatorOwnersPackageQuery' => 'PhabricatorCursorPagedPolicyQuery',
owners
2011-04-03 23:48:36 +02:00
'PhabricatorOwnersPath' => 'PhabricatorOwnersDAO',
Introduce PHID generation.
2011-01-23 06:09:13 +01:00
'PhabricatorPHIDController' => 'PhabricatorController',
PhabricatorObjectHandles
2011-01-26 18:02:09 +01:00
'PhabricatorPHIDLookupController' => 'PhabricatorPHIDController',
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
'PhabricatorPaste' =>
array(
0 => 'PhabricatorPasteDAO',
1 => 'PhabricatorPolicyInterface',
),
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',
"Paste" application tweaks Summary: Tweaks to the paste app: - I realized that unlike all the other apps, it makes more sense for the default view of this one to be "create paste" instead of "list pastes" since when you access the application directly you are most often wanting to share something. Swap list out of the default slot and make edit the default. - Make the textarea bigger (usability). - Allow you to copy an existing paste. - Implement 'raw view'. - Tweak/adjust list view (usability, formatting). - Tweak page titles. Test Plan: Created, copied, and listed pastes. Viewed raw paste. Created an invalid paste. Tried to create a copy of a nonexistant paste. Reviewed By: codeblock Reviewers: codeblock, jungejason, aran, tuomaspelkonen CC: aran, epriestley, codeblock Differential Revision: 456
2011-06-14 04:12:30 +02:00
'PhabricatorPasteListController' => 'PhabricatorPasteController',
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
'PhabricatorPasteQuery' => 'PhabricatorCursorPagedPolicyQuery',
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',
Basic user/account tool.
2011-01-24 03:09:16 +01:00
'PhabricatorPeopleController' => 'PhabricatorController',
'PhabricatorPeopleEditController' => 'PhabricatorPeopleController',
Added ldap import controller
2012-07-04 04:10:38 +02:00
'PhabricatorPeopleLdapController' => 'PhabricatorPeopleController',
Basic user/account tool.
2011-01-24 03:09:16 +01:00
'PhabricatorPeopleListController' => 'PhabricatorPeopleController',
Provide an activity log for login and administrative actions Summary: This isn't complete, but I figured I'd ship it for review while it's still smallish. Provide an activity log for high-level system actions (logins, admin actions). This basically allows two things to happen: - The log itself is useful if there are shenanigans. - Password login can check it and start CAPTCHA'ing users after a few failed attempts. I'm going to change how the admin stuff works a little bit too, since right now you can make someone an agent, grab their certificate, revert them back to a normal user, and then act on their behalf over Conduit. This is a little silly, I'm going to move "agent" to the create workflow instead. I'll also add a confirm/email step to the administrative password reset flow. Test Plan: Took various administrative and non-administrative actions, they appeared in the logs. Filtered the logs in a bunch of different ways. Reviewers: jungejason, tuomaspelkonen, aran CC: Differential Revision: 302
2011-05-18 03:42:21 +02:00
'PhabricatorPeopleLogsController' => 'PhabricatorPeopleController',
Basic user/account tool.
2011-01-24 03:09:16 +01:00
'PhabricatorPeopleProfileController' => 'PhabricatorPeopleController',
Conduit user.query method Summary: also includes a PhabricatorPeopleQuery object Test Plan: queried for various combinations username, realname, id, phid, and email. verified correct results. Reviewers: epriestley Reviewed By: epriestley CC: zeeg, aran, Koolvin Maniphest Tasks: T1075 Differential Revision: https://secure.phabricator.com/D2416
2012-05-07 22:35:09 +02:00
'PhabricatorPeopleQuery' => 'PhabricatorOffsetPagedQuery',
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',
'PhabricatorPolicyCapability' => 'PhabricatorPolicyConstants',
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',
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
'PhabricatorPolicyQuery' => 'PhabricatorOffsetPagedQuery',
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',
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
'PhabricatorPolicyTestObject' => 'PhabricatorPolicyInterface',
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
'PhabricatorPolicyTestQuery' => 'PhabricatorPolicyQuery',
Rough cut of Project profile improvements Summary: - Old page was useless and dumb. - New page looks a little less bad, functions a little less poorly. - Still lots of work to be done. Test Plan: - Viewed a project. - Clicked all the links on the left nav. - Here is a screenshot: https://secure.phabricator.com/file/view/PHID-FILE-4buzquotb3fo4dhlicrw/ Reviewers: btrahan, jungejason Reviewed By: jungejason CC: aran, jungejason Maniphest Tasks: T681 Differential Revision: 1246
2011-12-17 05:01:38 +01:00
'PhabricatorProfileHeaderView' => 'AphrontView',
Rough cut of projects. Summary: Test Plan: Reviewers: CC:
2011-02-21 03:41:23 +01:00
'PhabricatorProject' => 'PhabricatorProjectDAO',
'PhabricatorProjectController' => 'PhabricatorController',
Allow affiliations to carry project ownership information; transform profile images correctly Summary: This is sort of doing two things at once: - Add an "isOwner" flag to Project Affiliation to lay the groundwork for T237. - Rename the "QuickCreate" workflow to "Create" and funnel all creation through it. - Reorganize the image transformation stuff and use it to correctly crop/resize uploaded images. Test Plan: Created and edited projects and affailiations. Uploaded project, user, and profile photos. Verified existing thumbnailing in Maniphest still works properly. Reviewed By: cadamo Reviewers: cadamo, aran, jungejason, tuomaspelkonen CC: aran, epriestley, cadamo Differential Revision: 529
2011-06-26 17:37:47 +02:00
'PhabricatorProjectCreateController' => 'PhabricatorProjectController',
Rough cut of projects. Summary: Test Plan: Reviewers: CC:
2011-02-21 03:41:23 +01:00
'PhabricatorProjectDAO' => 'PhabricatorLiskDAO',
'PhabricatorProjectListController' => 'PhabricatorProjectController',
Make project membership edits use transactions and PHIDs and not be awful Summary: - Split project profile editing apart from project membership editing. - Make project membership editing simpler and easier to use. - Drop role / owner stuff from the UI. Test Plan: Added and removed project members. Edited project profile information. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3184
2012-08-07 20:57:38 +02:00
'PhabricatorProjectMembersEditController' => 'PhabricatorProjectController',
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
'PhabricatorProjectNameCollisionException' => 'Exception',
Rough cut of projects. Summary: Test Plan: Reviewers: CC:
2011-02-21 03:41:23 +01:00
'PhabricatorProjectProfile' => 'PhabricatorProjectDAO',
'PhabricatorProjectProfileController' => 'PhabricatorProjectController',
Project list and profile view modifications Summary: Added some change on the project's list view, to show information about active tasks, population, etc. Also modified the "profile view", and added a class "PhabricatorProfileView" to render the profile, both on projects and users. Test Plan: play around the project directory :) Reviewers: epriestley ericfrenkiel CC: Differential Revision: 477
2011-06-18 10:13:56 +02:00
'PhabricatorProjectProfileEditController' => 'PhabricatorProjectController',
Add a "Project" application Summary: Move routes into a formal application class. Test Plan: Checked /applications/, browsed various routes. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, floatinglomas Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3181
2012-08-07 20:54:49 +02:00
'PhabricatorProjectQuery' => 'PhabricatorOffsetPagedQuery',
Add transaction-oriented editing to projects Summary: - Make some editing operations transaction-oriented, like Maniphest. (This seems to be a good model, particularly for extensibility.) I'll move the rest of the editing operations to transactions in future diffs. - Make transaction-oriented operations publish feed stories. Test Plan: - Created a new project. - Edited an existing project. - Created a new project via quick create flow from Maniphest. - Verified feed stories publish correctly. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T681 Differential Revision: https://secure.phabricator.com/D1477
2012-01-24 16:11:37 +01:00
'PhabricatorProjectTransaction' => 'PhabricatorProjectDAO',
'PhabricatorProjectTransactionType' => 'PhabricatorProjectConstants',
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',
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',
Add comment linking to Maniphest and Differential Summary: Allows you to link to comments with "D123#3" or "T123#3", then adds a pile of JS to try to make it not terrible. :/ The thing I'm trying to avoid here is when someone says "look at this! http://blog.com/#comment-239291" and you click and your browser jumps somewhere random and you have no idea which comment they meant. Since I really hate this, I've tried to avoid it by making sure the comment is always highlighted. Test Plan: Put T1#1 and D1#1 in remarkup and verified they linked properly. Clicked anchors on individual comments. Faked all comments hidden in Differential and verified they expanded on anchor or anchor change. Reviewed By: aran Reviewers: aran, tomo, mroch, jungejason, tuomaspelkonen CC: aran, epriestley Differential Revision: 383
2011-05-31 19:23:31 +02:00
'PhabricatorRemarkupRuleDifferential' => 'PhabricatorRemarkupRuleObjectName',
Provide a "reference-with-full-name" syntax for Remarkup Summary: Provide a {T123} syntax which pulls in the entire name of an object, not just a link to it. A major use for this is organizing projects using wiki pages. Since handle links show object status now, this lets you organize stuff in an ad-hoc way and get a reasonable overview of it. We can make handles richer in the future, too. The performance on this isn't perfect (it adds some potential single gets) but I think it's okay for now and I don't want to make remarkup engine even more complex until the preprocess/postprocess stuff has had a chance to settle and I'm more confident it works. In Differential and Maniphest we'll also incorrectly cache the object state/name, but that'll fix itself once I move the cache code to use preprocess/postprocess correctly. Test Plan: - See https://secure.phabricator.com/file/view/PHID-FILE-5f9ca32407bec20899b9/ for an example. - Generated and looked over the documentation. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran, hunterbridges CC: skrul, aran, jungejason, epriestley Differential Revision: 784
2011-08-05 17:50:26 +02:00
'PhabricatorRemarkupRuleDifferentialHandle' => 'PhabricatorRemarkupRuleObjectHandle',
Restore linking of Diffusion commits.
2011-04-11 12:02:19 +02:00
'PhabricatorRemarkupRuleDiffusion' => 'PhutilRemarkupRule',
Rough implementation of drag-and-drop file uploads Summary: This gets all the major pieces working. Allows you to drag-and-drop files in Differential and Phriction, and embed files in remarkup with {Fxxx} references. See also task. I'm explicitly not documenting this yet since it's still pretty rough. Test Plan: Dragged and dropped stuff into Differential and Phriction. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran, tomo Commenters: tomo CC: aran, tomo, jungejason Differential Revision: 674
2011-07-15 23:17:55 +02:00
'PhabricatorRemarkupRuleEmbedFile' => 'PhutilRemarkupRule',
Image macros for Phabricator! Summary: Added long waited image macro support for differential and others. Test Plan: Tried a couple of different macros and made sure they appear nicely in the comment preview. Made sure that the normal comments are shown correctly. Reviewed By: epriestley Reviewers: epriestley CC: jungejason, tuomaspelkonen, epriestley Differential Revision: 129
2011-04-14 00:15:48 +02:00
'PhabricatorRemarkupRuleImageMacro' => 'PhutilRemarkupRule',
Add comment linking to Maniphest and Differential Summary: Allows you to link to comments with "D123#3" or "T123#3", then adds a pile of JS to try to make it not terrible. :/ The thing I'm trying to avoid here is when someone says "look at this! http://blog.com/#comment-239291" and you click and your browser jumps somewhere random and you have no idea which comment they meant. Since I really hate this, I've tried to avoid it by making sure the comment is always highlighted. Test Plan: Put T1#1 and D1#1 in remarkup and verified they linked properly. Clicked anchors on individual comments. Faked all comments hidden in Differential and verified they expanded on anchor or anchor change. Reviewed By: aran Reviewers: aran, tomo, mroch, jungejason, tuomaspelkonen CC: aran, epriestley Differential Revision: 383
2011-05-31 19:23:31 +02:00
'PhabricatorRemarkupRuleManiphest' => 'PhabricatorRemarkupRuleObjectName',
Provide a "reference-with-full-name" syntax for Remarkup Summary: Provide a {T123} syntax which pulls in the entire name of an object, not just a link to it. A major use for this is organizing projects using wiki pages. Since handle links show object status now, this lets you organize stuff in an ad-hoc way and get a reasonable overview of it. We can make handles richer in the future, too. The performance on this isn't perfect (it adds some potential single gets) but I think it's okay for now and I don't want to make remarkup engine even more complex until the preprocess/postprocess stuff has had a chance to settle and I'm more confident it works. In Differential and Maniphest we'll also incorrectly cache the object state/name, but that'll fix itself once I move the cache code to use preprocess/postprocess correctly. Test Plan: - See https://secure.phabricator.com/file/view/PHID-FILE-5f9ca32407bec20899b9/ for an example. - Generated and looked over the documentation. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran, hunterbridges CC: skrul, aran, jungejason, epriestley Differential Revision: 784
2011-08-05 17:50:26 +02:00
'PhabricatorRemarkupRuleManiphestHandle' => 'PhabricatorRemarkupRuleObjectHandle',
Basic @mentions support Summary: Provides basic Remarkup support for @mentions. No application integration yet so these aren't terribly useful until that happens. Test Plan: https://secure.phabricator.com/file/view/PHID-FILE-83d68e7af6085ae928df/ Reviewers: tomo, mroch, jsp Commenters: tomo CC: aran, tomo, epriestley Differential Revision: 517
2011-06-24 19:59:57 +02:00
'PhabricatorRemarkupRuleMention' => 'PhutilRemarkupRule',
Provide a "reference-with-full-name" syntax for Remarkup Summary: Provide a {T123} syntax which pulls in the entire name of an object, not just a link to it. A major use for this is organizing projects using wiki pages. Since handle links show object status now, this lets you organize stuff in an ad-hoc way and get a reasonable overview of it. We can make handles richer in the future, too. The performance on this isn't perfect (it adds some potential single gets) but I think it's okay for now and I don't want to make remarkup engine even more complex until the preprocess/postprocess stuff has had a chance to settle and I'm more confident it works. In Differential and Maniphest we'll also incorrectly cache the object state/name, but that'll fix itself once I move the cache code to use preprocess/postprocess correctly. Test Plan: - See https://secure.phabricator.com/file/view/PHID-FILE-5f9ca32407bec20899b9/ for an example. - Generated and looked over the documentation. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran, hunterbridges CC: skrul, aran, jungejason, epriestley Differential Revision: 784
2011-08-05 17:50:26 +02:00
'PhabricatorRemarkupRuleObjectHandle' => 'PhutilRemarkupRule',
Add comment linking to Maniphest and Differential Summary: Allows you to link to comments with "D123#3" or "T123#3", then adds a pile of JS to try to make it not terrible. :/ The thing I'm trying to avoid here is when someone says "look at this! http://blog.com/#comment-239291" and you click and your browser jumps somewhere random and you have no idea which comment they meant. Since I really hate this, I've tried to avoid it by making sure the comment is always highlighted. Test Plan: Put T1#1 and D1#1 in remarkup and verified they linked properly. Clicked anchors on individual comments. Faked all comments hidden in Differential and verified they expanded on anchor or anchor change. Reviewed By: aran Reviewers: aran, tomo, mroch, jungejason, tuomaspelkonen CC: aran, epriestley Differential Revision: 383
2011-05-31 19:23:31 +02:00
'PhabricatorRemarkupRuleObjectName' => 'PhutilRemarkupRule',
Add P### link to paste Summary:Make a new directory, src/infrastructure/markup/remarkup/markuprule/paste/ Make a new class called PhabricatorRemarkupRulePaste in that directory. Add the rule to DifferentialMarkupEngineFactory. Test Plan: Created a task in maniphest. Put P1 and P2 in the content. Created P1 and P2 in Paste. Verified P1 and P2 were highlighted and linked correctly. Reviewers:epriestley, codeblock CC:jungejason Differential Revision: 539
2011-06-27 08:57:43 +02:00
'PhabricatorRemarkupRulePaste' => 'PhabricatorRemarkupRuleObjectName',
Basic remarkup integration for Phriction Summary: Document linking and some general layout improvements. I'd like to eventually do more meta-dataey things with links (like store them separately and check them for 404s) but this is a decent start. Test Plan: https://secure.phabricator.com/file/view/PHID-FILE-d756b94a06b69c273fce/ Reviewed By: jungejason Reviewers: hsb, codeblock, jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 650
2011-07-12 05:14:46 +02:00
'PhabricatorRemarkupRulePhriction' => 'PhutilRemarkupRule',
Restore image proxying to Remarkup Summary: Previously, Remarkup allowed you to paste in an image URI and get an inline image. However, it did this by hotlinking the image which isn't so hot in an open source product. Restore this feature, but use image proxying instead. The existing image macro code does most of the work. There is a mild security risk depending on the network setup so I've left this default-disabled and made a note about it. It should be safe to enable for Facebook. Test Plan: Pasted in image and non-image links, got reasonable behavior. Verified proxying appears to work. Verified that file:// shenanigans produce 400. Reviewed By: tuomaspelkonen Reviewers: aran, jungejason, tuomaspelkonen Commenters: cpiro CC: aran, cpiro, tuomaspelkonen Differential Revision: 214
2011-05-02 23:20:24 +02:00
'PhabricatorRemarkupRuleProxyImage' => 'PhutilRemarkupRule',
Embedded youtube videos. Summary: Markup support for embedding Youtube videos. Test Plan: https://www.youtube.com/watch?v=Vw4KVoEVcr0 was embedded Reviewed By: epriestley Reviewers: epriestley CC: aran, epriestley Differential Revision: 353
2011-05-27 21:50:02 +02:00
'PhabricatorRemarkupRuleYoutube' => 'PhutilRemarkupRule',
Rough cut of Repositories and GitHub post-receive hooks. Summary: Test Plan: Reviewers: CC:
2011-02-13 03:26:15 +01:00
'PhabricatorRepository' => 'PhabricatorRepositoryDAO',
Sync up UUIDs and create project configs.
2011-04-06 05:49:31 +02:00
'PhabricatorRepositoryArcanistProject' => 'PhabricatorRepositoryDAO',
'PhabricatorRepositoryArcanistProjectEditController' => 'PhabricatorRepositoryController',
Migrate "PhabricatorOwnersPackageCommitRelationship" to "PhabricatorRepositoryAuditRequest" Summary: - Move table to Repository, since we have no Owners joins in the application anymore but would like to do a Repository join. - Rename "packagePHID" to "auditorPHID", since this column may contain package, project, or user PHIDs. Test Plan: - Browsed Owners, Audit, and Differential interfaces to the Audit tool. - Made comments and state changes. - Ran "reparse.php --herald --owners" on several commits. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley, nh, vrana Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1787
2012-03-05 22:17:29 +01:00
'PhabricatorRepositoryAuditRequest' => 'PhabricatorRepositoryDAO',
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
'PhabricatorRepositoryCommit' => 'PhabricatorRepositoryDAO',
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',
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',
Rough cut of Repositories and GitHub post-receive hooks. Summary: Test Plan: Reviewers: CC:
2011-02-13 03:26:15 +01:00
'PhabricatorRepositoryController' => 'PhabricatorController',
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
'PhabricatorRepositoryCreateController' => 'PhabricatorRepositoryController',
Rough cut of Repositories and GitHub post-receive hooks. Summary: Test Plan: Reviewers: CC:
2011-02-13 03:26:15 +01:00
'PhabricatorRepositoryDAO' => 'PhabricatorLiskDAO',
Add basic detail-parser functionality.
2011-04-02 02:11:05 +02:00
'PhabricatorRepositoryDefaultCommitMessageDetailParser' => 'PhabricatorRepositoryCommitMessageDetailParser',
Fix repository deletion Summary: I never actually wrote this controller. Test Plan: Deleted a repository via web UI. Reviewed By: tuomaspelkonen Reviewers: tuomaspelkonen, jungejason, aran Commenters: aran CC: aran, tuomaspelkonen, epriestley Differential Revision: 231
2011-05-05 21:53:39 +02:00
'PhabricatorRepositoryDeleteController' => 'PhabricatorRepositoryController',
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
'PhabricatorRepositoryEditController' => 'PhabricatorRepositoryController',
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',
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
'PhabricatorRepositoryListController' => 'PhabricatorRepositoryController',
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',
'PhabricatorRepositoryManagementListWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
'PhabricatorRepositoryManagementPullWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
'PhabricatorRepositoryManagementWorkflow' => 'PhutilArgumentWorkflow',
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',
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',
Use one daemon to discover commits in all repositories, not one per repository Summary: See D2418. This merges the commit discovery daemon into the same single daemon, and applies all the same rules to it. There are relatively few implementation changes, but a few things did change: - I simplified/improved Mercurial importing, by finding full branch tip hashes with "--debug branches" and using "parents --template {node}" so we don't need to do separate "--debug id" calls. - Added a new "--not" flag to exclude repositories, since I switched to real arg parsing anyway. - I removed a web UI notification that you need to restart the daemons, this is no longer true. - I added a web UI notification that no pull daemon is running on the machine. NOTE: @makinde, this doesn't change anything from your perspective, but it something breaks this is the likely cause. This implicitly resolves T792, because discovery no longer runs before pulling. Test Plan: - Swapped databases to a fresh install. - Ran "pulllocal" in debug mode. Verified it correctly does nothing (fixed a minor issue with min() on empty array). - Added an SVN repository. Verified it cloned and discovered correctly. - Added a Mercurial repository. Verified it cloned and discovered correctly. - Added a Git repository. Verified it cloned and discovered correctly. - Ran with arguments to verify behaviors: "--not MTEST --not STEST", "P --no-discovery", "P". Reviewers: btrahan, csilvers, Makinde Reviewed By: btrahan CC: aran Maniphest Tasks: T792 Differential Revision: https://secure.phabricator.com/D2430
2012-05-08 21:53:41 +02:00
'PhabricatorRepositoryPullLocalDaemonTestCase' => 'PhabricatorTestCase',
Restore "Shortcuts" feature to Diffusion.
2011-03-31 09:33:44 +02:00
'PhabricatorRepositoryShortcut' => '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',
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 "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',
Add commits to the Phabricator search index Summary: create the indexer for commit Test Plan: run the reindex_one_commit.php against one existing commit and it is returned in search result on the webpage; run parse_one_commit against another commit; modified reindex_everything.php to let it only parse one commit after loading all commits. Reviewed By: epriestley Reviewers: epriestley, aran CC: aran, jungejason, epriestley, debow Differential Revision: 490
2011-06-20 06:02:48 +02:00
'PhabricatorSearchCommitIndexer' => 'PhabricatorSearchDocumentIndexer',
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
'PhabricatorSearchController' => 'PhabricatorSearchBaseController',
'PhabricatorSearchDAO' => 'PhabricatorLiskDAO',
'PhabricatorSearchDifferentialIndexer' => 'PhabricatorSearchDocumentIndexer',
'PhabricatorSearchDocument' => 'PhabricatorSearchDAO',
'PhabricatorSearchDocumentField' => 'PhabricatorSearchDAO',
'PhabricatorSearchDocumentRelationship' => 'PhabricatorSearchDAO',
[NO CLUE WHAT I'M DOING] Add an Elasticsearch engine Summary: I have no idea what I'm doing, but here's part of an elasticsearch engine. These things work: - Indexing stuff (??) - Searching for text/type? - Reconstructing things?? All the complicated stuff doesn't work. I'm having a hard time figuring out the best way to model things because elasticsearch's documentation is not exactly the most complete or illuminating. @amckinley, does this look sane-ish so far? Particularly, the /phabricator/<type>/<phid>/ URI scheme and how I've set up the relationships and fields in the documents? How should I model the relationship and field queries? I want, like, an "equal" query but it seems like I've got "text" or "term" to work with and neither are exact match? And "term" doesn't consider PHIDs to be terms since they have hyphens in them? I'll keep kind of slogging my way forward here but if you have valuable wisdom to share it would probably get me to a better end state much faster. The whole query construction phase is pretty much black magic to me. Test Plan: nyancat Reviewers: amckinley, vrana Reviewed By: vrana CC: jungejason, tuomaspelkonen, aran, 20after4, vrana Differential Revision: https://secure.phabricator.com/D790
2012-04-21 00:33:09 +02:00
'PhabricatorSearchEngineElastic' => 'PhabricatorSearchEngine',
Provide an indirection layer between documents and the search engine Summary: In preparation for adding another search engine (see T355): - Rename "executor" to "engine". - Move all engine-specific operations into the engine. Specifically, this means that indexing moves out of the document store and into the engine (it was sort of silly where it was before). - Split choice of an engine into an overridable "selector" class, a base API, and a concrete MySQL implementation (just like storage engine selection). - Make all callers go through the indirection layer. The default selector just unconditionally selects the MySQL engine, but now (with D786) I can build an Elastic Search engine and you guys can build a multi-target engine if you want and I don't get there fast enough. Test Plan: - Created a new document (task). - Searched for and found it. - Viewed index reconstruction. Reviewed By: jungejason Reviewers: jungejason, amckinley, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 788
2011-08-08 00:14:23 +02:00
'PhabricatorSearchEngineMySQL' => 'PhabricatorSearchEngine',
Index "owner" relationship in search correctly for Revisions Summary: The owners of a revision are only really the reviewers when the revision is in NEEDS_REVIEW. Also build a raw indexed document viewer so you can look at the index of a document from the web interface. Finally, reindex revisions when comments are added, not just when the revision itself is edited. Test Plan: Toggled abandon/reclaim on a revision and verified the relationships indexed properly. Reviewed By: jungejason Reviewers: aran, jungejason, tuomaspelkonen CC: aran, epriestley, jungejason Differential Revision: 470
2011-06-15 16:43:43 +02:00
'PhabricatorSearchIndexController' => '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
'PhabricatorSearchManiphestIndexer' => 'PhabricatorSearchDocumentIndexer',
Phriction handles and search Summary: Index Phriction documents in search, and allow PhabricatorObjectHandleData to load them. Test Plan: Searched for "pokemons", got my wiki page as a search result. Reviewed By: hsb Reviewers: hsb, codeblock, jungejason, tuomaspelkonen, aran CC: aran, hsb Differential Revision: 648
2011-07-12 02:29:08 +02:00
'PhabricatorSearchPhrictionIndexer' => 'PhabricatorSearchDocumentIndexer',
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
'PhabricatorSearchQuery' => 'PhabricatorSearchDAO',
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 "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',
Index users in search results. Summary: Add users to the search results. I need to follow this up with a patch to make the search results stop being terrible. I'll do that. Test Plan: Searched for users, ran "reindex_all_users.php" Reviewed By: jungejason Reviewers: tomo, jungejason, aran CC: aran, jungejason Differential Revision: 508
2011-06-23 22:31:20 +02:00
'PhabricatorSearchUserIndexer' => 'PhabricatorSearchDocumentIndexer',
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',
'PhabricatorSlowvoteComment' => 'PhabricatorSlowvoteDAO',
'PhabricatorSlowvoteController' => 'PhabricatorController',
'PhabricatorSlowvoteCreateController' => 'PhabricatorSlowvoteController',
'PhabricatorSlowvoteDAO' => 'PhabricatorLiskDAO',
'PhabricatorSlowvoteListController' => 'PhabricatorSlowvoteController',
'PhabricatorSlowvoteOption' => 'PhabricatorSlowvoteDAO',
'PhabricatorSlowvotePoll' => 'PhabricatorSlowvoteDAO',
'PhabricatorSlowvotePollController' => 'PhabricatorSlowvoteController',
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',
Add UI elements for sortable tables Summary: Allow AphrontTableView to render with sort indicators and links in its columns. Test Plan: Looked at UI example. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley, sandra Maniphest Tasks: T994 Differential Revision: https://secure.phabricator.com/D1946
2012-03-20 03:48:22 +01:00
'PhabricatorSortTableExample' => 'PhabricatorUIExample',
More phabricator organizational stuff.
2011-01-23 02:48:55 +01:00
'PhabricatorStandardPageView' => 'AphrontPageView',
Add /status/
2011-04-08 20:13:29 +02:00
'PhabricatorStatusController' => 'PhabricatorController',
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',
'PhabricatorStorageManagementStatusWorkflow' => 'PhabricatorStorageManagementWorkflow',
'PhabricatorStorageManagementUpgradeWorkflow' => 'PhabricatorStorageManagementWorkflow',
'PhabricatorStorageManagementWorkflow' => 'PhutilArgumentWorkflow',
Add a custom lint name hook to Phabricator Summary: Allow Conduit method so they stop raising lint warnings. See D874. Test Plan: Ran "arc lint" on conduit files and was no longer given frivolous warnings. Reviewers: nh, jungejason, tuomaspelkonen, aran Reviewed By: nh CC: aran, nh, epriestley Differential Revision: 875
2011-08-30 22:12:20 +02:00
'PhabricatorSymbolNameLinter' => 'ArcanistXHPASTLintNamingHook',
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',
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
'PhabricatorTestCase' => 'ArcanistPhutilTestCase',
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
'PhabricatorTimelineCursor' => 'PhabricatorTimelineDAO',
'PhabricatorTimelineDAO' => 'PhabricatorLiskDAO',
'PhabricatorTimelineEvent' => 'PhabricatorTimelineDAO',
'PhabricatorTimelineEventData' => 'PhabricatorTimelineDAO',
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
'PhabricatorTimelineIterator' => 'Iterator',
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
'PhabricatorTimer' => 'PhabricatorCountdownDAO',
Unify Maniphest + Differential comment styles Summary: I want to add comments to commits, and they should obviously share code with the nearly-identical comments in Maniphest and Differential. Unify code/style as much as possible. This program made possible by a generous grant from D1513. Test Plan: - Looked at a bunch of different Differential and Maniphest comments; they appeared to render identically to how they looked before. - Tested some edge cases like anchors and "show details" on description edits in Maniphest. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1686
2012-02-24 22:02:35 +01:00
'PhabricatorTransactionView' => 'AphrontView',
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 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',
Typeaheads
2011-01-25 22:48:05 +01:00
'PhabricatorTypeaheadCommonDatasourceController' => 'PhabricatorTypeaheadDatasourceController',
'PhabricatorTypeaheadDatasourceController' => 'PhabricatorController',
AphrontPagerView and UIExamples.
2011-04-01 02:06:33 +02:00
'PhabricatorUIExampleController' => 'PhabricatorController',
'PhabricatorUIExampleRenderController' => 'PhabricatorUIExampleController',
AphrontListFilterView, for list filtering.
2011-04-04 00:50:06 +02:00
'PhabricatorUIListFilterExample' => 'PhabricatorUIExample',
Add a basic notification UI element Summary: This is //extremely// basic but dead simple and should cover us for v1, I think. Let me know what features you need. Test Plan: Used UI example page. Reviewers: allenjohnashton, ddfisher, keebuhm Reviewed By: ddfisher CC: aran, ender Maniphest Tasks: T944 Differential Revision: https://secure.phabricator.com/D2732
2012-06-14 00:00:24 +02:00
'PhabricatorUINotificationExample' => 'PhabricatorUIExample',
AphrontPagerView and UIExamples.
2011-04-01 02:06:33 +02:00
'PhabricatorUIPagerExample' => 'PhabricatorUIExample',
Add a basic tooltip UI element Summary: There are a few things we can improve with tooltips. Test Plan: Moused over all the stuff on the test page. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T965 Differential Revision: https://secure.phabricator.com/D1870
2012-03-13 02:21:02 +01:00
'PhabricatorUITooltipExample' => 'PhabricatorUIExample',
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',
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
'PhabricatorUser' =>
array(
0 => 'PhabricatorUserDAO',
1 => 'PhutilPerson',
),
Refactor user settings Summary: I want to do two things here: - Add SSH Keys - Move "Preferences" into this panel But this controller was pretty gigantic and messy. Split it apart and use delegation instead. There are no functional changes. I changed some of the conduit certificate text to simplify it since no one should need to go through that workflow anymore, given the existence of "arc install-certificate". Test Plan: - Edited realname, including attempting to remove it. - Edited profile picture. - Edited timezone. - Edited email, including attempting to remove it. - Regenerated condiut certificate. - Linked and unlinked an OAuth account. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason Differential Revision: 688
2011-07-18 17:02:00 +02:00
'PhabricatorUserAccountSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
'PhabricatorUserConduitSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
Basic user/account tool.
2011-01-24 03:09:16 +01:00
'PhabricatorUserDAO' => 'PhabricatorLiskDAO',
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 optional "Re:" prefix to all threaded mail and allow disabling mail about your own actions Summary: - Mail.app on Lion has cumbersome threading rules, see T782. Add an option to stick "Re: " in front of all threaded mail so it behaves. This is horrible, but apparently the least-horrible option. - While I was in there, I added an option for T228. Test Plan: - Sent a bunch of threaded and unthreaded mail with varous "Re:" settings, seemed to get "Re:" in the right places. - Disabled email about my stuff, created a task with just me, got voided mail, added a CC, got mail to just the CC. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, mkjones Maniphest Tasks: T228, T782 Differential Revision: https://secure.phabricator.com/D1448
2012-01-18 05:32:28 +01:00
'PhabricatorUserEmailPreferenceSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
Refactor user settings Summary: I want to do two things here: - Add SSH Keys - Move "Preferences" into this panel But this controller was pretty gigantic and messy. Split it apart and use delegation instead. There are no functional changes. I changed some of the conduit certificate text to simplify it since no one should need to go through that workflow anymore, given the existence of "arc install-certificate". Test Plan: - Edited realname, including attempting to remove it. - Edited profile picture. - Edited timezone. - Edited email, including attempting to remove it. - Regenerated condiut certificate. - Linked and unlinked an OAuth account. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason Differential Revision: 688
2011-07-18 17:02:00 +02:00
'PhabricatorUserEmailSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
Made it possible to login using LDAP Summary: Made it possible to link and unlink LDAP accounts with Phabricator accounts. Test Plan: I've tested this code locally and in production where I work. I've tried creating an account from scratch by logging in with LDAP and linking and unlinking an LDAP account with an existing account. I've tried to associate the same LDAP account with different Phabricator accounts and it failed as expected. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, auduny, svemir Maniphest Tasks: T742 Differential Revision: https://secure.phabricator.com/D2722
2012-06-13 17:52:05 +02:00
'PhabricatorUserLDAPInfo' => 'PhabricatorUserDAO',
'PhabricatorUserLDAPSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
Provide an activity log for login and administrative actions Summary: This isn't complete, but I figured I'd ship it for review while it's still smallish. Provide an activity log for high-level system actions (logins, admin actions). This basically allows two things to happen: - The log itself is useful if there are shenanigans. - Password login can check it and start CAPTCHA'ing users after a few failed attempts. I'm going to change how the admin stuff works a little bit too, since right now you can make someone an agent, grab their certificate, revert them back to a normal user, and then act on their behalf over Conduit. This is a little silly, I'm going to move "agent" to the create workflow instead. I'll also add a confirm/email step to the administrative password reset flow. Test Plan: Took various administrative and non-administrative actions, they appeared in the logs. Filtered the logs in a bunch of different ways. Reviewers: jungejason, tuomaspelkonen, aran CC: Differential Revision: 302
2011-05-18 03:42:21 +02:00
'PhabricatorUserLog' => 'PhabricatorUserDAO',
Github OAuth Summary: Test Plan: Reviewers: CC:
2011-02-21 07:47:56 +01:00
'PhabricatorUserOAuthInfo' => 'PhabricatorUserDAO',
Refactor user settings Summary: I want to do two things here: - Add SSH Keys - Move "Preferences" into this panel But this controller was pretty gigantic and messy. Split it apart and use delegation instead. There are no functional changes. I changed some of the conduit certificate text to simplify it since no one should need to go through that workflow anymore, given the existence of "arc install-certificate". Test Plan: - Edited realname, including attempting to remove it. - Edited profile picture. - Edited timezone. - Edited email, including attempting to remove it. - Regenerated condiut certificate. - Linked and unlinked an OAuth account. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason Differential Revision: 688
2011-07-18 17:02:00 +02:00
'PhabricatorUserOAuthSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
Add change password settings panel Summary: In password-based auth environments, there is now a user settings panel to allow them to change their password. Test Plan: Click settings, choose password from the left: * enter current password, new password (twice), log out, and log in with new password * enter current password, non-matching passwords, and get error * enter invalid old password, and get error * use firebug to change csrf token and verify that it does not save with and invalid token Changed config to disable password auth, loaded settings panel and saw that password was no longer visible. Tried loading the panel anyway and got redirected. Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Differential Revision: 890
2011-09-04 10:53:58 +02:00
'PhabricatorUserPasswordSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
Move "Preferences" to "Settings" Summary: It makes more sense to just make this a settings panel rather than a standalone app, particularly since setting panels are relatively well separated now. Also default-disabled the SSH Keys interface since it won't currently be useful for most installs. Test Plan: Edited preferences. Reviewed By: jungejason Reviewers: tuomaspelkonen, jungejason, aran CC: aran, jungejason Differential Revision: 716
2011-07-24 20:02:08 +02:00
'PhabricatorUserPreferenceSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
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',
Unify profile and avatar images, move profile editing into settings Summary: See T266. Combine these interfaces into one and move it to settings. Test Plan: Edited my profile and account. Reviewers: codeblock, tcook, jungejason, tuomaspelkonen, aran CC: Differential Revision: 722
2011-07-25 00:03:59 +02:00
'PhabricatorUserProfileSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
Allow users to associate SSH Public Keys with their accounts Summary: With the sshd-vcs thing I hacked together, this will enable Phabricator to host repositories without requiring users to have SSH accounts. I also fixed "subporjects" and added an explicit ENGINE to it. Test Plan: Created, edited and deleted public keys. Attempted to add the same public key twice. Attempted to add invalid and unnamed public keys. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran, cadamo, codeblock CC: aran, epriestley Differential Revision: 711
2011-07-22 19:17:57 +02:00
'PhabricatorUserSSHKey' => 'PhabricatorUserDAO',
'PhabricatorUserSSHKeysSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
Added Search Box Preferences Summary: Resolves T989 - users can now disable the '/' keyboard shortcut which focuses the search box - users can now disable the jump nav functionality of the search box Test Plan: - verified that the '/' keyboard shortcut works with preference enabled or unset - verified that '/' no longer has any effect and disappears from keyboard shortcuts help overlay with preference disabled - verified that search boxes have jump nav capabilities with jump nav functionality preference unset or enabled - verified that search boxes do not jump with jump nav preference disabled - verified that the jump nav still works as a jump nav with jump nav preference disabled Reviewers: epriestley Reviewed By: epriestley CC: simpkins, aran, epriestley, vrana Maniphest Tasks: T989 Differential Revision: https://secure.phabricator.com/D1902
2012-03-15 04:47:17 +01:00
'PhabricatorUserSearchSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
Some acutal conduit authentication.
2011-02-06 07:36:21 +01:00
'PhabricatorUserSettingsController' => 'PhabricatorPeopleController',
Refactor user settings Summary: I want to do two things here: - Add SSH Keys - Move "Preferences" into this panel But this controller was pretty gigantic and messy. Split it apart and use delegation instead. There are no functional changes. I changed some of the conduit certificate text to simplify it since no one should need to go through that workflow anymore, given the existence of "arc install-certificate". Test Plan: - Edited realname, including attempting to remove it. - Edited profile picture. - Edited timezone. - Edited email, including attempting to remove it. - Regenerated condiut certificate. - Linked and unlinked an OAuth account. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason Differential Revision: 688
2011-07-18 17:02:00 +02:00
'PhabricatorUserSettingsPanelController' => 'PhabricatorPeopleController',
Allowing setting user status Summary: I will use it for highlighting users which are not currently available. Maybe I will also use it in the nagging tool. I don't plan creating a UI for it as API is currently enough for us. Maybe I will visualize it at /calendar/ later. I plan creating `user.deletestatus` method when this one will be done. Test Plan: `storage upgrade` Call Conduit `user.addstatus`. Verify DB. Reviewers: epriestley Reviewed By: epriestley CC: aran, Koolvin Differential Revision: https://secure.phabricator.com/D2382
2012-05-04 00:47:34 +02:00
'PhabricatorUserStatus' => 'PhabricatorUserDAO',
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',
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',
'PhabricatorWorkerTask' => 'PhabricatorWorkerDAO',
'PhabricatorWorkerTaskData' => 'PhabricatorWorkerDAO',
Improve daemon console.
2011-03-27 07:55:18 +02:00
'PhabricatorWorkerTaskDetailController' => 'PhabricatorDaemonController',
Add buttons to delete or free tasks from the queue Summary: See T709. I also ran into a case in Drydock where this is useful for testing/development. Test Plan: Freed lease of a task; deleted a task. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T709 Differential Revision: https://secure.phabricator.com/D1469
2012-01-24 01:36:32 +01:00
'PhabricatorWorkerTaskUpdateController' => 'PhabricatorDaemonController',
xhpastview
2011-04-07 04:17:05 +02:00
'PhabricatorXHPASTViewController' => 'PhabricatorController',
'PhabricatorXHPASTViewDAO' => 'PhabricatorLiskDAO',
'PhabricatorXHPASTViewFrameController' => 'PhabricatorXHPASTViewController',
'PhabricatorXHPASTViewFramesetController' => 'PhabricatorXHPASTViewController',
'PhabricatorXHPASTViewInputController' => 'PhabricatorXHPASTViewPanelController',
'PhabricatorXHPASTViewPanelController' => 'PhabricatorXHPASTViewController',
'PhabricatorXHPASTViewParseTree' => 'PhabricatorXHPASTViewDAO',
'PhabricatorXHPASTViewRunController' => 'PhabricatorXHPASTViewController',
'PhabricatorXHPASTViewStreamController' => 'PhabricatorXHPASTViewPanelController',
'PhabricatorXHPASTViewTreeController' => 'PhabricatorXHPASTViewPanelController',
Very rough cut of DarkConsole + XHProf
2011-02-02 22:48:52 +01:00
'PhabricatorXHProfController' => 'PhabricatorController',
'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',
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
'PhameAllBlogListController' => 'PhameBlogListBaseController',
'PhameAllPostListController' => 'PhamePostListBaseController',
'PhameBlog' => 'PhameDAO',
'PhameBlogDeleteController' => 'PhameController',
'PhameBlogDetailView' => 'AphrontView',
'PhameBlogEditController' => 'PhameController',
'PhameBlogListBaseController' => 'PhameController',
'PhameBlogListView' => 'AphrontView',
'PhameBlogQuery' => 'PhabricatorOffsetPagedQuery',
'PhameBlogViewController' => 'PhameController',
Phame - add an "Everyone but Me" view and make published posts truly accessible to the whole world. Summary: accessibility covers not only a given post but also the various "published" views. to keep the code relative clean, this diff also splits up the post list controller logic quite a bit. this also feels like good preparation for some other work around introducing "blogs" which are collections of published posts from bloggers with some fancy features around that. Test Plan: clicked around various parts of the Phame application as a logged in user, a logged in user with no personal posts, and without any user logged in at all. various views all seemed reasonable. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D2898
2012-07-06 00:43:14 +02:00
'PhameBloggerPostListController' => 'PhamePostListBaseController',
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',
'PhameDraftListController' => 'PhamePostListBaseController',
'PhamePost' => 'PhameDAO',
'PhamePostDeleteController' => 'PhameController',
'PhamePostDetailView' => 'AphrontView',
'PhamePostEditController' => 'PhameController',
'PhamePostListBaseController' => 'PhameController',
'PhamePostListView' => 'AphrontView',
'PhamePostPreviewController' => 'PhameController',
'PhamePostQuery' => 'PhabricatorOffsetPagedQuery',
'PhamePostViewController' => 'PhameController',
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
'PhameUserBlogListController' => 'PhameBlogListBaseController',
Phame - add an "Everyone but Me" view and make published posts truly accessible to the whole world. Summary: accessibility covers not only a given post but also the various "published" views. to keep the code relative clean, this diff also splits up the post list controller logic quite a bit. this also feels like good preparation for some other work around introducing "blogs" which are collections of published posts from bloggers with some fancy features around that. Test Plan: clicked around various parts of the Phame application as a logged in user, a logged in user with no personal posts, and without any user logged in at all. various views all seemed reasonable. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D2898
2012-07-06 00:43:14 +02:00
'PhameUserPostListController' => 'PhamePostListBaseController',
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',
'PhortuneStripeBaseController' => 'PhabricatorController',
'PhortuneStripePaymentFormView' => 'AphrontView',
'PhortuneStripeTestPaymentFormController' => 'PhortuneStripeBaseController',
Publish Phriction edits to feed Summary: Basic integration between Phriction and feed. Test Plan: Created and edited some documents, they published to feed. Reviewed By: hsb Reviewers: hsb, codeblock, jungejason, tuomaspelkonen, aran CC: aran, hsb Differential Revision: 653
2011-07-12 16:23:04 +02:00
'PhrictionActionConstants' => 'PhrictionConstants',
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',
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
'PhrictionContent' =>
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
array(
0 => 'PhrictionDAO',
1 => 'PhabricatorMarkupInterface',
),
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',
'PhrictionDAO' => 'PhabricatorLiskDAO',
'PhrictionDeleteController' => 'PhrictionController',
'PhrictionDiffController' => 'PhrictionController',
'PhrictionDocument' => 'PhrictionDAO',
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',
Add a document preview to Phriction Summary: Preview Phriction documents as they are edited, similar to how Differential/Maniphest work. Test Plan: Mashed my keyboard while editing a Phriction document. Reviewed By: hsb Reviewers: hsb, codeblock, jungejason, tuomaspelkonen, aran CC: aran, hsb Differential Revision: 684
2011-07-17 03:25:45 +02:00
'PhrictionDocumentPreviewController' => 'PhrictionController',
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',
Add hierarchical breadcrumbs to Phriction Summary: Show ancestor pages when viewing a page in Phriction. Test Plan: https://secure.phabricator.com/file/view/PHID-FILE-042368dbadaa8ab826ec/ Reviewed By: hsb Reviewers: hsb, codeblock, jungejason, tuomaspelkonen, aran Commenters: aran CC: aran, hsb, epriestley Differential Revision: 654
2011-07-12 17:08:03 +02:00
'PhrictionDocumentTestCase' => 'PhabricatorTestCase',
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',
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',
Basic Phriction list view Summary: Pretty much ripped from D636, but somewhat simplified. Lists all the documents in the system. Test Plan: Looked at both of the views, seems to work correctly. Reviewed By: hsb Reviewers: hsb, codeblock, jungejason, tuomaspelkonen, aran CC: aran, hsb, epriestley Differential Revision: 645
2011-07-12 00:42:12 +02:00
'PhrictionListController' => 'PhrictionController',
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',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
),
));
Copy permalink