2011-01-16 22:51:39 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
/**
|
2012-05-30 23:26:29 +02:00
|
|
|
* This file is automatically generated. Use 'arc liberate' to rebuild it.
|
2011-01-16 22:51:39 +01:00
|
|
|
* @generated
|
2012-05-30 23:26:29 +02:00
|
|
|
* @phutil-library-version 2
|
2011-01-16 22:51:39 +01:00
|
|
|
*/
|
|
|
|
|
|
|
|
phutil_register_library_map(array(
|
2012-05-30 23:26:29 +02:00
|
|
|
'__library_version__' => 2,
|
2011-01-16 22:51:39 +01:00
|
|
|
'class' =>
|
|
|
|
array(
|
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',
|
2012-06-01 21:46:28 +02:00
|
|
|
'AphrontApplicationConfiguration' => 'aphront/configuration/AphrontApplicationConfiguration.php',
|
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',
|
2012-06-01 21:46:28 +02:00
|
|
|
'AphrontDefaultApplicationConfiguration' => 'aphront/configuration/AphrontDefaultApplicationConfiguration.php',
|
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',
|
|
|
|
'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',
|
2012-06-26 17:14:15 +02:00
|
|
|
'AphrontFormImageControl' => 'view/form/control/AphrontFormImageControl.php',
|
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',
|
2012-11-29 08:57:13 +01:00
|
|
|
'AphrontHTMLResponse' => 'aphront/response/AphrontHTMLResponse.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-07-26 21:01:47 +02:00
|
|
|
'AphrontIsolatedDatabaseConnectionTestCase' => 'infrastructure/storage/__tests__/AphrontIsolatedDatabaseConnectionTestCase.php',
|
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',
|
2012-07-26 21:01:47 +02:00
|
|
|
'AphrontMySQLDatabaseConnectionTestCase' => 'infrastructure/storage/__tests__/AphrontMySQLDatabaseConnectionTestCase.php',
|
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',
|
|
|
|
'AphrontTableView' => 'view/control/AphrontTableView.php',
|
2013-01-16 19:50:41 +01:00
|
|
|
'AphrontTagView' => 'view/AphrontTagView.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2013-02-05 22:46:02 +01:00
|
|
|
'AuditPeopleMenuEventListener' => 'applications/audit/events/AuditPeopleMenuEventListener.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'CelerityAPI' => 'infrastructure/celerity/CelerityAPI.php',
|
2012-10-17 17:37:05 +02:00
|
|
|
'CelerityPhabricatorResourceController' => 'infrastructure/celerity/CelerityPhabricatorResourceController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-11-24 01:19:06 +01:00
|
|
|
'CeleritySpriteGenerator' => 'infrastructure/celerity/CeleritySpriteGenerator.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'CelerityStaticResourceResponse' => 'infrastructure/celerity/CelerityStaticResourceResponse.php',
|
|
|
|
'ConduitAPIMethod' => 'applications/conduit/method/ConduitAPIMethod.php',
|
|
|
|
'ConduitAPIRequest' => 'applications/conduit/protocol/ConduitAPIRequest.php',
|
|
|
|
'ConduitAPIResponse' => 'applications/conduit/protocol/ConduitAPIResponse.php',
|
2012-12-21 21:12:26 +01:00
|
|
|
'ConduitAPI_arcanist_Method' => 'applications/arcanist/conduit/ConduitAPI_arcanist_Method.php',
|
|
|
|
'ConduitAPI_arcanist_projectinfo_Method' => 'applications/arcanist/conduit/ConduitAPI_arcanist_projectinfo_Method.php',
|
|
|
|
'ConduitAPI_audit_Method' => 'applications/audit/conduit/ConduitAPI_audit_Method.php',
|
|
|
|
'ConduitAPI_audit_query_Method' => 'applications/audit/conduit/ConduitAPI_audit_query_Method.php',
|
|
|
|
'ConduitAPI_chatlog_Method' => 'applications/chatlog/conduit/ConduitAPI_chatlog_Method.php',
|
|
|
|
'ConduitAPI_chatlog_query_Method' => 'applications/chatlog/conduit/ConduitAPI_chatlog_query_Method.php',
|
|
|
|
'ConduitAPI_chatlog_record_Method' => 'applications/chatlog/conduit/ConduitAPI_chatlog_record_Method.php',
|
|
|
|
'ConduitAPI_conduit_connect_Method' => 'applications/conduit/method/ConduitAPI_conduit_connect_Method.php',
|
|
|
|
'ConduitAPI_conduit_getcertificate_Method' => 'applications/conduit/method/ConduitAPI_conduit_getcertificate_Method.php',
|
|
|
|
'ConduitAPI_conduit_ping_Method' => 'applications/conduit/method/ConduitAPI_conduit_ping_Method.php',
|
2013-01-20 01:37:06 +01:00
|
|
|
'ConduitAPI_conduit_query_Method' => 'applications/conduit/method/ConduitAPI_conduit_query_Method.php',
|
2012-12-21 21:12:26 +01:00
|
|
|
'ConduitAPI_daemon_launched_Method' => 'applications/daemon/conduit/ConduitAPI_daemon_launched_Method.php',
|
|
|
|
'ConduitAPI_daemon_log_Method' => 'applications/daemon/conduit/ConduitAPI_daemon_log_Method.php',
|
|
|
|
'ConduitAPI_daemon_setstatus_Method' => 'applications/daemon/conduit/ConduitAPI_daemon_setstatus_Method.php',
|
|
|
|
'ConduitAPI_differential_Method' => 'applications/differential/conduit/ConduitAPI_differential_Method.php',
|
|
|
|
'ConduitAPI_differential_close_Method' => 'applications/differential/conduit/ConduitAPI_differential_close_Method.php',
|
|
|
|
'ConduitAPI_differential_createcomment_Method' => 'applications/differential/conduit/ConduitAPI_differential_createcomment_Method.php',
|
|
|
|
'ConduitAPI_differential_creatediff_Method' => 'applications/differential/conduit/ConduitAPI_differential_creatediff_Method.php',
|
|
|
|
'ConduitAPI_differential_createinline_Method' => 'applications/differential/conduit/ConduitAPI_differential_createinline_Method.php',
|
|
|
|
'ConduitAPI_differential_createrawdiff_Method' => 'applications/differential/conduit/ConduitAPI_differential_createrawdiff_Method.php',
|
|
|
|
'ConduitAPI_differential_createrevision_Method' => 'applications/differential/conduit/ConduitAPI_differential_createrevision_Method.php',
|
|
|
|
'ConduitAPI_differential_find_Method' => 'applications/differential/conduit/ConduitAPI_differential_find_Method.php',
|
|
|
|
'ConduitAPI_differential_finishpostponedlinters_Method' => 'applications/differential/conduit/ConduitAPI_differential_finishpostponedlinters_Method.php',
|
|
|
|
'ConduitAPI_differential_getalldiffs_Method' => 'applications/differential/conduit/ConduitAPI_differential_getalldiffs_Method.php',
|
|
|
|
'ConduitAPI_differential_getcommitmessage_Method' => 'applications/differential/conduit/ConduitAPI_differential_getcommitmessage_Method.php',
|
|
|
|
'ConduitAPI_differential_getcommitpaths_Method' => 'applications/differential/conduit/ConduitAPI_differential_getcommitpaths_Method.php',
|
|
|
|
'ConduitAPI_differential_getdiff_Method' => 'applications/differential/conduit/ConduitAPI_differential_getdiff_Method.php',
|
|
|
|
'ConduitAPI_differential_getrevision_Method' => 'applications/differential/conduit/ConduitAPI_differential_getrevision_Method.php',
|
|
|
|
'ConduitAPI_differential_getrevisioncomments_Method' => 'applications/differential/conduit/ConduitAPI_differential_getrevisioncomments_Method.php',
|
|
|
|
'ConduitAPI_differential_getrevisionfeedback_Method' => 'applications/differential/conduit/ConduitAPI_differential_getrevisionfeedback_Method.php',
|
|
|
|
'ConduitAPI_differential_markcommitted_Method' => 'applications/differential/conduit/ConduitAPI_differential_markcommitted_Method.php',
|
|
|
|
'ConduitAPI_differential_parsecommitmessage_Method' => 'applications/differential/conduit/ConduitAPI_differential_parsecommitmessage_Method.php',
|
|
|
|
'ConduitAPI_differential_query_Method' => 'applications/differential/conduit/ConduitAPI_differential_query_Method.php',
|
|
|
|
'ConduitAPI_differential_setdiffproperty_Method' => 'applications/differential/conduit/ConduitAPI_differential_setdiffproperty_Method.php',
|
|
|
|
'ConduitAPI_differential_updaterevision_Method' => 'applications/differential/conduit/ConduitAPI_differential_updaterevision_Method.php',
|
|
|
|
'ConduitAPI_differential_updateunitresults_Method' => 'applications/differential/conduit/ConduitAPI_differential_updateunitresults_Method.php',
|
|
|
|
'ConduitAPI_diffusion_findsymbols_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_findsymbols_Method.php',
|
|
|
|
'ConduitAPI_diffusion_getcommits_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_getcommits_Method.php',
|
|
|
|
'ConduitAPI_diffusion_getlintmessages_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_getlintmessages_Method.php',
|
|
|
|
'ConduitAPI_diffusion_getrecentcommitsbypath_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_getrecentcommitsbypath_Method.php',
|
|
|
|
'ConduitAPI_feed_publish_Method' => 'applications/feed/conduit/ConduitAPI_feed_publish_Method.php',
|
|
|
|
'ConduitAPI_feed_query_Method' => 'applications/feed/conduit/ConduitAPI_feed_query_Method.php',
|
|
|
|
'ConduitAPI_file_download_Method' => 'applications/files/conduit/ConduitAPI_file_download_Method.php',
|
|
|
|
'ConduitAPI_file_info_Method' => 'applications/files/conduit/ConduitAPI_file_info_Method.php',
|
|
|
|
'ConduitAPI_file_upload_Method' => 'applications/files/conduit/ConduitAPI_file_upload_Method.php',
|
|
|
|
'ConduitAPI_flag_Method' => 'applications/flag/conduit/ConduitAPI_flag_Method.php',
|
|
|
|
'ConduitAPI_flag_delete_Method' => 'applications/flag/conduit/ConduitAPI_flag_delete_Method.php',
|
|
|
|
'ConduitAPI_flag_edit_Method' => 'applications/flag/conduit/ConduitAPI_flag_edit_Method.php',
|
|
|
|
'ConduitAPI_flag_query_Method' => 'applications/flag/conduit/ConduitAPI_flag_query_Method.php',
|
|
|
|
'ConduitAPI_macro_Method' => 'applications/macro/conduit/ConduitAPI_macro_Method.php',
|
|
|
|
'ConduitAPI_macro_query_Method' => 'applications/macro/conduit/ConduitAPI_macro_query_Method.php',
|
|
|
|
'ConduitAPI_maniphest_Method' => 'applications/maniphest/conduit/ConduitAPI_maniphest_Method.php',
|
|
|
|
'ConduitAPI_maniphest_createtask_Method' => 'applications/maniphest/conduit/ConduitAPI_maniphest_createtask_Method.php',
|
|
|
|
'ConduitAPI_maniphest_find_Method' => 'applications/maniphest/conduit/ConduitAPI_maniphest_find_Method.php',
|
|
|
|
'ConduitAPI_maniphest_gettasktransactions_Method' => 'applications/maniphest/conduit/ConduitAPI_maniphest_gettasktransactions_Method.php',
|
|
|
|
'ConduitAPI_maniphest_info_Method' => 'applications/maniphest/conduit/ConduitAPI_maniphest_info_Method.php',
|
|
|
|
'ConduitAPI_maniphest_query_Method' => 'applications/maniphest/conduit/ConduitAPI_maniphest_query_Method.php',
|
|
|
|
'ConduitAPI_maniphest_update_Method' => 'applications/maniphest/conduit/ConduitAPI_maniphest_update_Method.php',
|
|
|
|
'ConduitAPI_owners_query_Method' => 'applications/owners/conduit/ConduitAPI_owners_query_Method.php',
|
2012-08-24 22:20:20 +02:00
|
|
|
'ConduitAPI_paste_Method' => 'applications/paste/conduit/ConduitAPI_paste_Method.php',
|
|
|
|
'ConduitAPI_paste_create_Method' => 'applications/paste/conduit/ConduitAPI_paste_create_Method.php',
|
|
|
|
'ConduitAPI_paste_info_Method' => 'applications/paste/conduit/ConduitAPI_paste_info_Method.php',
|
|
|
|
'ConduitAPI_paste_query_Method' => 'applications/paste/conduit/ConduitAPI_paste_query_Method.php',
|
2012-12-21 21:12:26 +01:00
|
|
|
'ConduitAPI_phid_Method' => 'applications/phid/conduit/ConduitAPI_phid_Method.php',
|
|
|
|
'ConduitAPI_phid_info_Method' => 'applications/phid/conduit/ConduitAPI_phid_info_Method.php',
|
|
|
|
'ConduitAPI_phid_lookup_Method' => 'applications/phid/conduit/ConduitAPI_phid_lookup_Method.php',
|
|
|
|
'ConduitAPI_phid_query_Method' => 'applications/phid/conduit/ConduitAPI_phid_query_Method.php',
|
|
|
|
'ConduitAPI_phpast_getast_Method' => 'applications/phpast/conduit/ConduitAPI_phpast_getast_Method.php',
|
|
|
|
'ConduitAPI_phpast_version_Method' => 'applications/phpast/conduit/ConduitAPI_phpast_version_Method.php',
|
|
|
|
'ConduitAPI_phriction_Method' => 'applications/phriction/conduit/ConduitAPI_phriction_Method.php',
|
|
|
|
'ConduitAPI_phriction_edit_Method' => 'applications/phriction/conduit/ConduitAPI_phriction_edit_Method.php',
|
|
|
|
'ConduitAPI_phriction_history_Method' => 'applications/phriction/conduit/ConduitAPI_phriction_history_Method.php',
|
|
|
|
'ConduitAPI_phriction_info_Method' => 'applications/phriction/conduit/ConduitAPI_phriction_info_Method.php',
|
|
|
|
'ConduitAPI_project_Method' => 'applications/project/conduit/ConduitAPI_project_Method.php',
|
|
|
|
'ConduitAPI_project_query_Method' => 'applications/project/conduit/ConduitAPI_project_query_Method.php',
|
|
|
|
'ConduitAPI_remarkup_process_Method' => 'applications/remarkup/conduit/ConduitAPI_remarkup_process_Method.php',
|
|
|
|
'ConduitAPI_repository_Method' => 'applications/repository/conduit/ConduitAPI_repository_Method.php',
|
|
|
|
'ConduitAPI_repository_create_Method' => 'applications/repository/conduit/ConduitAPI_repository_create_Method.php',
|
|
|
|
'ConduitAPI_repository_query_Method' => 'applications/repository/conduit/ConduitAPI_repository_query_Method.php',
|
|
|
|
'ConduitAPI_slowvote_info_Method' => 'applications/slowvote/conduit/ConduitAPI_slowvote_info_Method.php',
|
|
|
|
'ConduitAPI_user_Method' => 'applications/people/conduit/ConduitAPI_user_Method.php',
|
|
|
|
'ConduitAPI_user_addstatus_Method' => 'applications/people/conduit/ConduitAPI_user_addstatus_Method.php',
|
|
|
|
'ConduitAPI_user_disable_Method' => 'applications/people/conduit/ConduitAPI_user_disable_Method.php',
|
|
|
|
'ConduitAPI_user_enable_Method' => 'applications/people/conduit/ConduitAPI_user_enable_Method.php',
|
|
|
|
'ConduitAPI_user_find_Method' => 'applications/people/conduit/ConduitAPI_user_find_Method.php',
|
|
|
|
'ConduitAPI_user_info_Method' => 'applications/people/conduit/ConduitAPI_user_info_Method.php',
|
|
|
|
'ConduitAPI_user_query_Method' => 'applications/people/conduit/ConduitAPI_user_query_Method.php',
|
|
|
|
'ConduitAPI_user_removestatus_Method' => 'applications/people/conduit/ConduitAPI_user_removestatus_Method.php',
|
|
|
|
'ConduitAPI_user_whoami_Method' => 'applications/people/conduit/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',
|
2012-06-01 21:10:26 +02:00
|
|
|
'ConduitException' => 'applications/conduit/protocol/ConduitException.php',
|
Implement SSHD glue and Conduit SSH endpoint
Summary:
- Build "sshd-auth" (for authentication) and "sshd-exec" (for command execution) binaries. These are callable by "sshd-vcs", located [[https://github.com/epriestley/sshd-vcs | in my account on GitHub]]. They are based on precursors [[https://github.com/epriestley/sshd-vcs-glue | here on GitHub]] which I deployed for TenXer about a year ago, so I have some confidence they at least basically work.
- The problem this solves is that normally every user would need an account on a machine to connect to it, and/or their public keys would all need to be listed in `~/.authorized_keys`. This is a big pain in most installs. Software like Gitosis/Gitolite solve this problem by giving you an easy way to add public keys to `~/.authorized_keys`, but this is pretty gross.
- Roughly, instead of looking in `~/.authorized_keys` when a user connects, the patched sshd instead runs `echo <public key> | sshd-auth`. The `sshd-auth` script looks up the public key and authorizes the matching user, if they exist. It also forces sshd to run `sshd-exec` instead of a normal shell.
- `sshd-exec` receives the authenticated user and any command which was passed to ssh (like `git receive-pack`) and can route them appropriately.
- Overall, this permits a single account to be set up on a server which all Phabricator users can connect to without any extra work, and which can safely execute commands and apply appropriate permissions, and disable users when they are disabled in Phabricator and all that stuff.
- Build out "sshd-exec" to do more thorough checks and setup, and delegate command execution to Workflows (they now exist, and did not when I originally built this stuff).
- Convert @btrahan's conduit API script into a workflow and slightly simplify it (ConduitCall did not exist at the time it was written).
The next steps here on the Repository side are to implement Workflows for Git, SVN and HG wire protocols. These will mostly just proxy the protocols, but also need to enforce permissions. So the approach will basically be:
- Implement workflows for stuff like `git receive-pack`.
- These workflows will implement enough of the underlying protocol to determine what resource the user is trying to access, and whether they want to read or write it.
- They'll then do a permissons check, and kick the user out if they don't have permission to do whatever they are trying to do.
- If the user does have permission, we just proxy the rest of the transaction.
Next steps on the Conduit side are more simple:
- Make ConduitClient understand "ssh://" URLs.
Test Plan: Ran `sshd-exec --phabricator-ssh-user epriestley conduit differential.query`, etc. This will get a more comprehensive test once I set up sshd-vcs.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603, T550
Differential Revision: https://secure.phabricator.com/D4229
2012-12-19 20:08:07 +01:00
|
|
|
'ConduitSSHWorkflow' => 'applications/conduit/ssh/ConduitSSHWorkflow.php',
|
2013-01-26 01:03:54 +01:00
|
|
|
'ConpherenceConfigOptions' => 'applications/conpherence/config/ConpherenceConfigOptions.php',
|
2013-01-25 02:23:05 +01:00
|
|
|
'ConpherenceConstants' => 'applications/conpherence/constants/ConpherenceConstants.php',
|
|
|
|
'ConpherenceController' => 'applications/conpherence/controller/ConpherenceController.php',
|
|
|
|
'ConpherenceDAO' => 'applications/conpherence/storage/ConpherenceDAO.php',
|
|
|
|
'ConpherenceEditor' => 'applications/conpherence/editor/ConpherenceEditor.php',
|
|
|
|
'ConpherenceListController' => 'applications/conpherence/controller/ConpherenceListController.php',
|
|
|
|
'ConpherenceMenuItemView' => 'applications/conpherence/view/ConpherenceMenuItemView.php',
|
|
|
|
'ConpherenceNewController' => 'applications/conpherence/controller/ConpherenceNewController.php',
|
|
|
|
'ConpherenceParticipant' => 'applications/conpherence/storage/ConpherenceParticipant.php',
|
|
|
|
'ConpherenceParticipantQuery' => 'applications/conpherence/query/ConpherenceParticipantQuery.php',
|
|
|
|
'ConpherenceParticipationStatus' => 'applications/conpherence/constants/ConpherenceParticipationStatus.php',
|
2013-02-05 22:46:02 +01:00
|
|
|
'ConpherencePeopleMenuEventListener' => 'applications/conpherence/events/ConpherencePeopleMenuEventListener.php',
|
2013-01-26 01:03:54 +01:00
|
|
|
'ConpherenceReplyHandler' => 'applications/conpherence/mail/ConpherenceReplyHandler.php',
|
2013-01-25 02:23:05 +01:00
|
|
|
'ConpherenceThread' => 'applications/conpherence/storage/ConpherenceThread.php',
|
|
|
|
'ConpherenceThreadQuery' => 'applications/conpherence/query/ConpherenceThreadQuery.php',
|
|
|
|
'ConpherenceTransaction' => 'applications/conpherence/storage/ConpherenceTransaction.php',
|
|
|
|
'ConpherenceTransactionComment' => 'applications/conpherence/storage/ConpherenceTransactionComment.php',
|
|
|
|
'ConpherenceTransactionQuery' => 'applications/conpherence/query/ConpherenceTransactionQuery.php',
|
|
|
|
'ConpherenceTransactionType' => 'applications/conpherence/constants/ConpherenceTransactionType.php',
|
|
|
|
'ConpherenceTransactionView' => 'applications/conpherence/view/ConpherenceTransactionView.php',
|
|
|
|
'ConpherenceUpdateController' => 'applications/conpherence/controller/ConpherenceUpdateController.php',
|
|
|
|
'ConpherenceViewController' => 'applications/conpherence/controller/ConpherenceViewController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-07-02 19:49:00 +02:00
|
|
|
'DatabaseConfigurationProvider' => 'infrastructure/storage/configuration/DatabaseConfigurationProvider.php',
|
|
|
|
'DefaultDatabaseConfigurationProvider' => 'infrastructure/storage/configuration/DefaultDatabaseConfigurationProvider.php',
|
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',
|
upgrade diffusion to use modern header UI and fix a few quirks
Summary:
upgrades are CrumbsView, HeaderView, PropertyListView, and ActionListView. I had to modify CrumbsView stuff a bit to handle the "advanced" diffusion crumbs.
Quirks fixed include making file tree view show up in diffusion, the page not have extra space when the file tree is hidden, links no longer breaking once you visit files (since without the change the files always got "/" appended and thus 404'd), and a differential quirk where it read "next step:" and that colon is a no no,
Test Plan: played around in diffusion and differential
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin, chad
Maniphest Tasks: T2048, T2178
Differential Revision: https://secure.phabricator.com/D4169
2012-12-13 02:50:42 +01:00
|
|
|
'DifferentialChangesetFileTreeSideNavBuilder' => 'applications/differential/view/DifferentialChangesetFileTreeSideNavBuilder.php',
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
|
|
|
'DifferentialChangesetHTMLRenderer' => 'applications/differential/render/DifferentialChangesetHTMLRenderer.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'DifferentialChangesetListView' => 'applications/differential/view/DifferentialChangesetListView.php',
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
|
|
|
'DifferentialChangesetOneUpRenderer' => 'applications/differential/render/DifferentialChangesetOneUpRenderer.php',
|
|
|
|
'DifferentialChangesetOneUpTestRenderer' => 'applications/differential/render/DifferentialChangesetOneUpTestRenderer.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'DifferentialChangesetParser' => 'applications/differential/parser/DifferentialChangesetParser.php',
|
2012-06-15 09:53:26 +02:00
|
|
|
'DifferentialChangesetParserTestCase' => 'applications/differential/parser/__tests__/DifferentialChangesetParserTestCase.php',
|
2012-12-08 01:19:57 +01:00
|
|
|
'DifferentialChangesetRenderer' => 'applications/differential/render/DifferentialChangesetRenderer.php',
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
|
|
|
'DifferentialChangesetTestRenderer' => 'applications/differential/render/DifferentialChangesetTestRenderer.php',
|
2012-12-08 01:19:57 +01:00
|
|
|
'DifferentialChangesetTwoUpRenderer' => 'applications/differential/render/DifferentialChangesetTwoUpRenderer.php',
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
|
|
|
'DifferentialChangesetTwoUpTestRenderer' => 'applications/differential/render/DifferentialChangesetTwoUpTestRenderer.php',
|
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',
|
2012-12-12 01:34:08 +01:00
|
|
|
'DifferentialConflictsFieldSpecification' => 'applications/differential/field/specification/DifferentialConflictsFieldSpecification.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-08-29 00:24:01 +02:00
|
|
|
'DifferentialDependsOnFieldSpecification' => 'applications/differential/field/specification/DifferentialDependsOnFieldSpecification.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-11-21 21:30:38 +01:00
|
|
|
'DifferentialDiffTestCase' => 'applications/differential/storage/__tests__/DifferentialDiffTestCase.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-09-11 19:37:30 +02:00
|
|
|
'DifferentialFreeformFieldSpecification' => 'applications/differential/field/specification/DifferentialFreeformFieldSpecification.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'DifferentialGitSVNIDFieldSpecification' => 'applications/differential/field/specification/DifferentialGitSVNIDFieldSpecification.php',
|
|
|
|
'DifferentialHostFieldSpecification' => 'applications/differential/field/specification/DifferentialHostFieldSpecification.php',
|
|
|
|
'DifferentialHunk' => 'applications/differential/storage/DifferentialHunk.php',
|
2013-01-09 22:11:17 +01:00
|
|
|
'DifferentialHunkParser' => 'applications/differential/parser/DifferentialHunkParser.php',
|
|
|
|
'DifferentialHunkParserTestCase' => 'applications/differential/parser/__tests__/DifferentialHunkParserTestCase.php',
|
2012-06-27 19:44:29 +02:00
|
|
|
'DifferentialHunkTestCase' => 'applications/differential/storage/__tests__/DifferentialHunkTestCase.php',
|
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',
|
2012-06-06 19:52:17 +02:00
|
|
|
'DifferentialMailPhase' => 'applications/differential/constants/DifferentialMailPhase.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'DifferentialManiphestTasksFieldSpecification' => 'applications/differential/field/specification/DifferentialManiphestTasksFieldSpecification.php',
|
|
|
|
'DifferentialNewDiffMail' => 'applications/differential/mail/DifferentialNewDiffMail.php',
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
|
|
|
'DifferentialParseRenderTestCase' => 'applications/differential/__tests__/DifferentialParseRenderTestCase.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'DifferentialPathFieldSpecification' => 'applications/differential/field/specification/DifferentialPathFieldSpecification.php',
|
2013-02-05 22:46:02 +01:00
|
|
|
'DifferentialPeopleMenuEventListener' => 'applications/differential/events/DifferentialPeopleMenuEventListener.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-07-25 02:58:33 +02:00
|
|
|
'DifferentialReviewerStats' => 'applications/differential/stats/DifferentialReviewerStats.php',
|
|
|
|
'DifferentialReviewerStatsTestCase' => 'applications/differential/stats/__tests__/DifferentialReviewerStatsTestCase.php',
|
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',
|
2012-12-11 23:59:27 +01:00
|
|
|
'DifferentialRevisionStatus' => 'applications/differential/constants/DifferentialRevisionStatus.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'DifferentialRevisionStatusFieldSpecification' => 'applications/differential/field/specification/DifferentialRevisionStatusFieldSpecification.php',
|
|
|
|
'DifferentialRevisionUpdateHistoryView' => 'applications/differential/view/DifferentialRevisionUpdateHistoryView.php',
|
|
|
|
'DifferentialRevisionViewController' => 'applications/differential/controller/DifferentialRevisionViewController.php',
|
Improve Search architecture
Summary:
The search indexing API has several problems right now:
- Always runs in-process.
- It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it.
- Being able to use the task queue will also make rebuilding indexes faster.
- Instead, make the API phid-oriented.
- No uniform indexing API.
- Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird.
- Instead, provide a uniform API.
- No uniform CLI.
- We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers.
- Instead, let indexers expose documents for indexing.
- Not application-oriented.
- All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world.
- Instead, move indexers to applications and load them with SymbolLoader.
Test Plan:
- `bin/search index`
- Indexed one revision, one task.
- Indexed `--type TASK`, `--type DREV`, etc., for all types.
- Indexed `--all`.
- Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it.
- Creating users is a pain; searched for a user after indexing.
- Creating commits is a pain; searched for a commit after indexing.
- Mocks aren't currently loadable in the result view, so their indexing is moot.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: 20after4, aran
Maniphest Tasks: T1991, T2104
Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
|
|
|
'DifferentialSearchIndexer' => 'applications/differential/search/DifferentialSearchIndexer.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-08-01 01:27:48 +02:00
|
|
|
'DiffusionCommitBranchesController' => 'applications/diffusion/controller/DiffusionCommitBranchesController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'DiffusionCommitChangeTableView' => 'applications/diffusion/view/DiffusionCommitChangeTableView.php',
|
|
|
|
'DiffusionCommitController' => 'applications/diffusion/controller/DiffusionCommitController.php',
|
2012-08-08 19:03:41 +02:00
|
|
|
'DiffusionCommitEditController' => 'applications/diffusion/controller/DiffusionCommitEditController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'DiffusionCommitParentsQuery' => 'applications/diffusion/query/parents/DiffusionCommitParentsQuery.php',
|
2012-08-01 01:27:48 +02:00
|
|
|
'DiffusionCommitTagsController' => 'applications/diffusion/controller/DiffusionCommitTagsController.php',
|
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',
|
2012-08-09 18:27:45 +02:00
|
|
|
'DiffusionExistsQuery' => 'applications/diffusion/query/exists/DiffusionExistsQuery.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-08-09 18:27:45 +02:00
|
|
|
'DiffusionGitExistsQuery' => 'applications/diffusion/query/exists/DiffusionGitExistsQuery.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
|
|
|
'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',
|
2012-07-23 20:01:28 +02:00
|
|
|
'DiffusionInlineCommentPreviewController' => 'applications/diffusion/controller/DiffusionInlineCommentPreviewController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'DiffusionLastModifiedController' => 'applications/diffusion/controller/DiffusionLastModifiedController.php',
|
|
|
|
'DiffusionLastModifiedQuery' => 'applications/diffusion/query/lastmodified/DiffusionLastModifiedQuery.php',
|
2012-11-08 20:11:44 +01:00
|
|
|
'DiffusionLintController' => 'applications/diffusion/controller/DiffusionLintController.php',
|
2012-11-09 01:13:21 +01:00
|
|
|
'DiffusionLintDetailsController' => 'applications/diffusion/controller/DiffusionLintDetailsController.php',
|
2012-11-09 03:37:15 +01:00
|
|
|
'DiffusionLintSaveRunner' => 'applications/diffusion/DiffusionLintSaveRunner.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-08-09 18:27:45 +02:00
|
|
|
'DiffusionMercurialExistsQuery' => 'applications/diffusion/query/exists/DiffusionMercurialExistsQuery.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
|
|
|
'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',
|
2013-02-05 22:46:02 +01:00
|
|
|
'DiffusionPeopleMenuEventListener' => 'applications/diffusion/events/DiffusionPeopleMenuEventListener.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'DiffusionQuery' => 'applications/diffusion/query/DiffusionQuery.php',
|
|
|
|
'DiffusionRawDiffQuery' => 'applications/diffusion/query/rawdiff/DiffusionRawDiffQuery.php',
|
2012-09-28 23:36:47 +02:00
|
|
|
'DiffusionRenameHistoryQuery' => 'applications/diffusion/query/DiffusionRenameHistoryQuery.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-08-09 18:27:45 +02:00
|
|
|
'DiffusionSvnExistsQuery' => 'applications/diffusion/query/exists/DiffusionSvnExistsQuery.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
|
|
|
'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',
|
Port Diviner Core to Phabricator
Summary:
This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix:
**Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes.
**Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms.
**Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom.
**URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature.
**Search** Once we have a database generation target, we can index the documentation.
**Design** Chad has some nice mocks.
Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T988
Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
|
|
|
'DivinerArticleAtomizer' => 'applications/diviner/atomizer/DivinerArticleAtomizer.php',
|
|
|
|
'DivinerAtom' => 'applications/diviner/atom/DivinerAtom.php',
|
|
|
|
'DivinerAtomCache' => 'applications/diviner/cache/DivinerAtomCache.php',
|
|
|
|
'DivinerAtomRef' => 'applications/diviner/atom/DivinerAtomRef.php',
|
|
|
|
'DivinerAtomizeWorkflow' => 'applications/diviner/workflow/DivinerAtomizeWorkflow.php',
|
|
|
|
'DivinerAtomizer' => 'applications/diviner/atomizer/DivinerAtomizer.php',
|
|
|
|
'DivinerFileAtomizer' => 'applications/diviner/atomizer/DivinerFileAtomizer.php',
|
|
|
|
'DivinerGenerateWorkflow' => 'applications/diviner/workflow/DivinerGenerateWorkflow.php',
|
2012-10-01 21:56:51 +02:00
|
|
|
'DivinerListController' => 'applications/diviner/controller/DivinerListController.php',
|
Port Diviner Core to Phabricator
Summary:
This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix:
**Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes.
**Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms.
**Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom.
**URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature.
**Search** Once we have a database generation target, we can index the documentation.
**Design** Chad has some nice mocks.
Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T988
Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
|
|
|
'DivinerWorkflow' => 'applications/diviner/workflow/DivinerWorkflow.php',
|
2012-11-02 00:53:17 +01:00
|
|
|
'DrydockAllocatorWorker' => 'applications/drydock/worker/DrydockAllocatorWorker.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'DrydockApacheWebrootInterface' => 'applications/drydock/interface/webroot/DrydockApacheWebrootInterface.php',
|
|
|
|
'DrydockBlueprint' => 'applications/drydock/blueprint/DrydockBlueprint.php',
|
2012-12-13 03:42:12 +01:00
|
|
|
'DrydockBlueprintScopeGuard' => 'applications/drydock/util/DrydockBlueprintScopeGuard.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
|
|
|
'DrydockInterface' => 'applications/drydock/interface/DrydockInterface.php',
|
|
|
|
'DrydockLease' => 'applications/drydock/storage/DrydockLease.php',
|
|
|
|
'DrydockLeaseListController' => 'applications/drydock/controller/DrydockLeaseListController.php',
|
2012-12-17 22:53:32 +01:00
|
|
|
'DrydockLeaseQuery' => 'applications/drydock/query/DrydockLeaseQuery.php',
|
2012-12-15 00:42:58 +01:00
|
|
|
'DrydockLeaseReleaseController' => 'applications/drydock/controller/DrydockLeaseReleaseController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'DrydockLeaseStatus' => 'applications/drydock/constants/DrydockLeaseStatus.php',
|
2012-11-07 00:28:33 +01:00
|
|
|
'DrydockLeaseViewController' => 'applications/drydock/controller/DrydockLeaseViewController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-11-27 21:48:03 +01:00
|
|
|
'DrydockManagementCloseWorkflow' => 'applications/drydock/management/DrydockManagementCloseWorkflow.php',
|
2012-11-01 23:30:14 +01:00
|
|
|
'DrydockManagementLeaseWorkflow' => 'applications/drydock/management/DrydockManagementLeaseWorkflow.php',
|
2012-12-15 00:42:58 +01:00
|
|
|
'DrydockManagementReleaseWorkflow' => 'applications/drydock/management/DrydockManagementReleaseWorkflow.php',
|
2012-11-01 23:30:14 +01:00
|
|
|
'DrydockManagementWaitForLeaseWorkflow' => 'applications/drydock/management/DrydockManagementWaitForLeaseWorkflow.php',
|
|
|
|
'DrydockManagementWorkflow' => 'applications/drydock/management/DrydockManagementWorkflow.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'DrydockResource' => 'applications/drydock/storage/DrydockResource.php',
|
2012-11-27 21:48:03 +01:00
|
|
|
'DrydockResourceCloseController' => 'applications/drydock/controller/DrydockResourceCloseController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'DrydockResourceListController' => 'applications/drydock/controller/DrydockResourceListController.php',
|
2012-12-17 23:47:21 +01:00
|
|
|
'DrydockResourceQuery' => 'applications/drydock/query/DrydockResourceQuery.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'DrydockResourceStatus' => 'applications/drydock/constants/DrydockResourceStatus.php',
|
2012-11-20 22:25:22 +01:00
|
|
|
'DrydockResourceViewController' => 'applications/drydock/controller/DrydockResourceViewController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'DrydockSSHCommandInterface' => 'applications/drydock/interface/command/DrydockSSHCommandInterface.php',
|
|
|
|
'DrydockWebrootInterface' => 'applications/drydock/interface/webroot/DrydockWebrootInterface.php',
|
2012-11-27 21:48:14 +01:00
|
|
|
'DrydockWorkingCopyBlueprint' => 'applications/drydock/blueprint/DrydockWorkingCopyBlueprint.php',
|
2012-11-02 21:34:18 +01:00
|
|
|
'FeedPublisherWorker' => 'applications/feed/worker/FeedPublisherWorker.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'HarbormasterDAO' => 'applications/harbormaster/storage/HarbormasterDAO.php',
|
2012-07-09 19:39:14 +02:00
|
|
|
'HarbormasterObject' => 'applications/harbormaster/storage/HarbormasterObject.php',
|
2012-12-17 22:43:26 +01:00
|
|
|
'HarbormasterRunnerWorker' => 'applications/harbormaster/worker/HarbormasterRunnerWorker.php',
|
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',
|
2012-07-31 01:08:10 +02:00
|
|
|
'JavelinUIExample' => 'applications/uiexample/examples/JavelinUIExample.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'JavelinViewExample' => 'applications/uiexample/examples/JavelinViewExample.php',
|
|
|
|
'JavelinViewExampleServerView' => 'applications/uiexample/examples/JavelinViewExampleServerView.php',
|
Implement a more compact, general database-backed key-value cache
Summary:
See discussion in D4204. Facebook currently has a 314MB remarkup cache with a 55MB index, which is slow to access. Under the theory that this is an index size/quality problem (the current index is on a potentially-384-byte field, with many keys sharing prefixes), provide a more general index with fancy new features:
- It implements PhutilKeyValueCache, so it can be a component in cache stacks and supports TTL.
- It has a 12-byte hash-based key.
- It automatically compresses large blocks of data (most of what we store is highly-compressible HTML).
Test Plan:
- Basics:
- Loaded /paste/, saw caches generate and save.
- Reloaded /paste/, saw the page hit cache.
- GC:
- Ran GC daemon, saw nothing.
- Set maximum lifetime to 1 second, ran GC daemon, saw it collect the entire cache.
- Deflate:
- Selected row formats from the database, saw a mixture of 'raw' and 'deflate' storage.
- Used profiler to verify that 'deflate' is fast (12 calls @ 220us on my paste list).
- Ran unit tests
Reviewers: vrana, btrahan
Reviewed By: vrana
CC: aran
Differential Revision: https://secure.phabricator.com/D4259
2012-12-21 23:17:56 +01:00
|
|
|
'LiskChunkTestCase' => 'infrastructure/storage/lisk/__tests__/LiskChunkTestCase.php',
|
2012-07-02 19:49:00 +02:00
|
|
|
'LiskDAO' => 'infrastructure/storage/lisk/LiskDAO.php',
|
|
|
|
'LiskDAOSet' => 'infrastructure/storage/lisk/LiskDAOSet.php',
|
2012-10-24 21:47:53 +02:00
|
|
|
'LiskDAOTestCase' => 'infrastructure/storage/lisk/__tests__/LiskDAOTestCase.php',
|
2012-07-02 19:49:00 +02:00
|
|
|
'LiskEphemeralObjectException' => 'infrastructure/storage/lisk/LiskEphemeralObjectException.php',
|
|
|
|
'LiskFixtureTestCase' => 'infrastructure/storage/lisk/__tests__/LiskFixtureTestCase.php',
|
|
|
|
'LiskIsolationTestCase' => 'infrastructure/storage/lisk/__tests__/LiskIsolationTestCase.php',
|
|
|
|
'LiskIsolationTestDAO' => 'infrastructure/storage/lisk/__tests__/LiskIsolationTestDAO.php',
|
|
|
|
'LiskIsolationTestDAOException' => 'infrastructure/storage/lisk/__tests__/LiskIsolationTestDAOException.php',
|
2012-07-19 05:01:23 +02:00
|
|
|
'LiskMigrationIterator' => 'infrastructure/storage/lisk/LiskMigrationIterator.php',
|
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',
|
2012-07-03 00:42:06 +02:00
|
|
|
'ManiphestEdgeEventListener' => 'applications/maniphest/event/ManiphestEdgeEventListener.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'ManiphestExportController' => 'applications/maniphest/controller/ManiphestExportController.php',
|
2013-02-05 22:46:02 +01:00
|
|
|
'ManiphestPeopleMenuEventListener' => 'applications/maniphest/event/ManiphestPeopleMenuEventListener.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
Improve Search architecture
Summary:
The search indexing API has several problems right now:
- Always runs in-process.
- It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it.
- Being able to use the task queue will also make rebuilding indexes faster.
- Instead, make the API phid-oriented.
- No uniform indexing API.
- Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird.
- Instead, provide a uniform API.
- No uniform CLI.
- We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers.
- Instead, let indexers expose documents for indexing.
- Not application-oriented.
- All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world.
- Instead, move indexers to applications and load them with SymbolLoader.
Test Plan:
- `bin/search index`
- Indexed one revision, one task.
- Indexed `--type TASK`, `--type DREV`, etc., for all types.
- Indexed `--all`.
- Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it.
- Creating users is a pain; searched for a user after indexing.
- Creating commits is a pain; searched for a commit after indexing.
- Mocks aren't currently loadable in the result view, so their indexing is moot.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: 20after4, aran
Maniphest Tasks: T1991, T2104
Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
|
|
|
'ManiphestSearchIndexer' => 'applications/maniphest/search/ManiphestSearchIndexer.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2013-01-19 19:20:22 +01:00
|
|
|
'ObjectHandleLoader' => 'applications/phid/handle/ObjectHandleLoader.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2013-01-01 23:09:29 +01:00
|
|
|
'PhabricatorAWSConfigOptions' => 'applications/config/option/PhabricatorAWSConfigOptions.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorAccessLog' => 'infrastructure/PhabricatorAccessLog.php',
|
2013-01-01 23:09:17 +01:00
|
|
|
'PhabricatorAccessLogConfigOptions' => 'applications/config/option/PhabricatorAccessLogConfigOptions.php',
|
2012-10-03 19:21:39 +02:00
|
|
|
'PhabricatorActionListExample' => 'applications/uiexample/examples/PhabricatorActionListExample.php',
|
2012-08-15 19:45:06 +02:00
|
|
|
'PhabricatorActionListView' => 'view/layout/PhabricatorActionListView.php',
|
|
|
|
'PhabricatorActionView' => 'view/layout/PhabricatorActionView.php',
|
2013-01-25 01:11:30 +01:00
|
|
|
'PhabricatorAllCapsTranslation' => 'infrastructure/internationalization/PhabricatorAllCapsTranslation.php',
|
2012-08-22 00:01:20 +02:00
|
|
|
'PhabricatorAnchorView' => 'view/layout/PhabricatorAnchorView.php',
|
2012-07-30 19:43:49 +02:00
|
|
|
'PhabricatorApplication' => 'applications/base/PhabricatorApplication.php',
|
2012-08-02 23:07:21 +02:00
|
|
|
'PhabricatorApplicationApplications' => 'applications/meta/application/PhabricatorApplicationApplications.php',
|
|
|
|
'PhabricatorApplicationAudit' => 'applications/audit/application/PhabricatorApplicationAudit.php',
|
2012-08-05 23:12:43 +02:00
|
|
|
'PhabricatorApplicationAuth' => 'applications/auth/application/PhabricatorApplicationAuth.php',
|
2012-10-24 22:22:24 +02:00
|
|
|
'PhabricatorApplicationCalendar' => 'applications/calendar/application/PhabricatorApplicationCalendar.php',
|
2012-10-01 21:56:10 +02:00
|
|
|
'PhabricatorApplicationConduit' => 'applications/conduit/application/PhabricatorApplicationConduit.php',
|
2012-12-28 00:20:09 +01:00
|
|
|
'PhabricatorApplicationConfig' => 'applications/config/application/PhabricatorApplicationConfig.php',
|
2012-12-31 00:36:06 +01:00
|
|
|
'PhabricatorApplicationConfigOptions' => 'applications/config/option/PhabricatorApplicationConfigOptions.php',
|
2013-01-25 02:23:05 +01:00
|
|
|
'PhabricatorApplicationConpherence' => 'applications/conpherence/application/PhabricatorApplicationConpherence.php',
|
2012-10-01 21:56:02 +02:00
|
|
|
'PhabricatorApplicationCountdown' => 'applications/countdown/application/PhabricatorApplicationCountdown.php',
|
2012-08-14 00:27:45 +02:00
|
|
|
'PhabricatorApplicationDaemons' => 'applications/daemon/application/PhabricatorApplicationDaemons.php',
|
2013-01-24 21:13:31 +01:00
|
|
|
'PhabricatorApplicationDetailViewController' => 'applications/meta/controller/PhabricatorApplicationDetailViewController.php',
|
2012-07-30 19:43:49 +02:00
|
|
|
'PhabricatorApplicationDifferential' => 'applications/differential/application/PhabricatorApplicationDifferential.php',
|
2012-08-02 23:07:21 +02:00
|
|
|
'PhabricatorApplicationDiffusion' => 'applications/diffusion/application/PhabricatorApplicationDiffusion.php',
|
2012-08-14 00:28:41 +02:00
|
|
|
'PhabricatorApplicationDiviner' => 'applications/diviner/application/PhabricatorApplicationDiviner.php',
|
2012-10-31 17:57:57 +01:00
|
|
|
'PhabricatorApplicationDrydock' => 'applications/drydock/application/PhabricatorApplicationDrydock.php',
|
2012-07-30 19:44:08 +02:00
|
|
|
'PhabricatorApplicationFact' => 'applications/fact/application/PhabricatorApplicationFact.php',
|
2013-01-11 01:06:29 +01:00
|
|
|
'PhabricatorApplicationFeed' => 'applications/feed/application/PhabricatorApplicationFeed.php',
|
2012-10-01 23:05:12 +02:00
|
|
|
'PhabricatorApplicationFiles' => 'applications/files/application/PhabricatorApplicationFiles.php',
|
2012-08-02 23:07:21 +02:00
|
|
|
'PhabricatorApplicationFlags' => 'applications/flag/application/PhabricatorApplicationFlags.php',
|
2012-10-01 21:56:10 +02:00
|
|
|
'PhabricatorApplicationHerald' => 'applications/herald/application/PhabricatorApplicationHerald.php',
|
2012-08-02 23:07:21 +02:00
|
|
|
'PhabricatorApplicationLaunchView' => 'applications/meta/view/PhabricatorApplicationLaunchView.php',
|
2012-10-01 23:04:03 +02:00
|
|
|
'PhabricatorApplicationMacro' => 'applications/macro/application/PhabricatorApplicationMacro.php',
|
2012-08-13 04:19:46 +02:00
|
|
|
'PhabricatorApplicationMailingLists' => 'applications/mailinglists/application/PhabricatorApplicationMailingLists.php',
|
2012-07-30 19:43:49 +02:00
|
|
|
'PhabricatorApplicationManiphest' => 'applications/maniphest/application/PhabricatorApplicationManiphest.php',
|
2012-08-13 21:37:06 +02:00
|
|
|
'PhabricatorApplicationMetaMTA' => 'applications/metamta/application/PhabricatorApplicationMetaMTA.php',
|
2012-10-01 21:56:33 +02:00
|
|
|
'PhabricatorApplicationOwners' => 'applications/owners/application/PhabricatorApplicationOwners.php',
|
|
|
|
'PhabricatorApplicationPHID' => 'applications/phid/application/PhabricatorApplicationPHID.php',
|
2012-12-21 21:12:26 +01:00
|
|
|
'PhabricatorApplicationPHPAST' => 'applications/phpast/application/PhabricatorApplicationPHPAST.php',
|
2012-08-15 19:45:06 +02:00
|
|
|
'PhabricatorApplicationPaste' => 'applications/paste/application/PhabricatorApplicationPaste.php',
|
2012-08-05 23:12:43 +02:00
|
|
|
'PhabricatorApplicationPeople' => 'applications/people/application/PhabricatorApplicationPeople.php',
|
2012-10-02 00:37:02 +02:00
|
|
|
'PhabricatorApplicationPhame' => 'applications/phame/application/PhabricatorApplicationPhame.php',
|
Add very basic scaffolding for Pholio
Summary:
I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc.
Basic hierarchy is:
- **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas".
- **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed.
- **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits.
- **PixelComment**: Equivalent of an inline comment.
Test Plan: Created a fake object and viewed it.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: aran, davidreuss
Maniphest Tasks: T2097
Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
|
|
|
'PhabricatorApplicationPholio' => 'applications/pholio/application/PhabricatorApplicationPholio.php',
|
2012-08-02 23:07:21 +02:00
|
|
|
'PhabricatorApplicationPhriction' => 'applications/phriction/application/PhabricatorApplicationPhriction.php',
|
2012-08-10 19:44:04 +02:00
|
|
|
'PhabricatorApplicationPonder' => 'applications/ponder/application/PhabricatorApplicationPonder.php',
|
2012-08-07 20:54:49 +02:00
|
|
|
'PhabricatorApplicationProject' => 'applications/project/application/PhabricatorApplicationProject.php',
|
2012-10-01 21:56:33 +02:00
|
|
|
'PhabricatorApplicationRepositories' => 'applications/repository/application/PhabricatorApplicationRepositories.php',
|
2012-08-13 21:37:18 +02:00
|
|
|
'PhabricatorApplicationSettings' => 'applications/settings/application/PhabricatorApplicationSettings.php',
|
2012-10-01 21:56:02 +02:00
|
|
|
'PhabricatorApplicationSlowvote' => 'applications/slowvote/application/PhabricatorApplicationSlowvote.php',
|
2012-08-02 23:07:21 +02:00
|
|
|
'PhabricatorApplicationStatusView' => 'applications/meta/view/PhabricatorApplicationStatusView.php',
|
2012-10-05 22:18:05 +02:00
|
|
|
'PhabricatorApplicationSubscriptions' => 'applications/subscriptions/application/PhabricatorApplicationSubscriptions.php',
|
2012-12-11 22:59:20 +01:00
|
|
|
'PhabricatorApplicationTransaction' => 'applications/transactions/storage/PhabricatorApplicationTransaction.php',
|
|
|
|
'PhabricatorApplicationTransactionComment' => 'applications/transactions/storage/PhabricatorApplicationTransactionComment.php',
|
2012-12-11 23:01:51 +01:00
|
|
|
'PhabricatorApplicationTransactionCommentEditController' => 'applications/transactions/controller/PhabricatorApplicationTransactionCommentEditController.php',
|
2012-12-11 22:59:20 +01:00
|
|
|
'PhabricatorApplicationTransactionCommentEditor' => 'applications/transactions/editor/PhabricatorApplicationTransactionCommentEditor.php',
|
2012-12-11 23:01:51 +01:00
|
|
|
'PhabricatorApplicationTransactionCommentHistoryController' => 'applications/transactions/controller/PhabricatorApplicationTransactionCommentHistoryController.php',
|
2012-12-11 22:59:20 +01:00
|
|
|
'PhabricatorApplicationTransactionCommentQuery' => 'applications/transactions/query/PhabricatorApplicationTransactionCommentQuery.php',
|
2012-12-21 14:51:33 +01:00
|
|
|
'PhabricatorApplicationTransactionCommentView' => 'applications/transactions/view/PhabricatorApplicationTransactionCommentView.php',
|
2012-12-11 23:01:51 +01:00
|
|
|
'PhabricatorApplicationTransactionController' => 'applications/transactions/controller/PhabricatorApplicationTransactionController.php',
|
2012-12-11 22:59:20 +01:00
|
|
|
'PhabricatorApplicationTransactionEditor' => 'applications/transactions/editor/PhabricatorApplicationTransactionEditor.php',
|
2012-12-11 23:00:21 +01:00
|
|
|
'PhabricatorApplicationTransactionFeedStory' => 'applications/transactions/feed/PhabricatorApplicationTransactionFeedStory.php',
|
Add ApplicationTransaction handling for transactions with no effect
Summary:
When a user submits an action with no effect (like an empty comment, an "abandon" on an already-accepted revision, or a "close, resolved" on a closed task) we want to alert them that their action isn't effective. These warnings fall into two general buckets:
- User is submitting two or more actions, and some aren't effective but some are. Prompt them to apply the effective actions only.
- A special case of this is where the only effective action is a comment. We provide tailored text ("Post Comment") in this case.
- User is submitting one action, which isn't effective. Tell them they're out of luck.
- A special case of this is an empty comment. We provide tailored text in this case.
By default, the transaction editor throws when transactions have no effect. The caller can then deal with this, or use `PhabricatorApplicationTransactionNoEffectResponse` to provide a standard dialog that gives the user information as above. For cases where we expect transactions to have no effect (notably, "edit" forms) we just continue on no-effect unconditionally.
Also fix an issue where new, combined or filtered transactions would not be represented properly in the Ajax response (i.e., return final transactions from `applyTransactions()`), and translate some strings.
Test Plan:
- Submitted empty and nonempy comments in Macro and Pholio.
- Submitted comments with new and existing "@mentions".
- Submitted edits in both applications.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T912, T2104
Differential Revision: https://secure.phabricator.com/D4160
2012-12-12 02:27:40 +01:00
|
|
|
'PhabricatorApplicationTransactionNoEffectException' => 'applications/transactions/exception/PhabricatorApplicationTransactionNoEffectException.php',
|
|
|
|
'PhabricatorApplicationTransactionNoEffectResponse' => 'applications/transactions/response/PhabricatorApplicationTransactionNoEffectResponse.php',
|
2012-12-11 22:59:20 +01:00
|
|
|
'PhabricatorApplicationTransactionQuery' => 'applications/transactions/query/PhabricatorApplicationTransactionQuery.php',
|
2012-12-11 23:02:29 +01:00
|
|
|
'PhabricatorApplicationTransactionResponse' => 'applications/transactions/response/PhabricatorApplicationTransactionResponse.php',
|
Modernize Macro application
Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro.
Test Plan:
{F26839}
{F26840}
{F26841}
{F26842}
{F26843}
{F26844}
{F26845}
Reviewers: vrana, btrahan, chad
Reviewed By: vrana
CC: aran
Maniphest Tasks: T2157, T175, T2104
Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
|
|
|
'PhabricatorApplicationTransactionView' => 'applications/transactions/view/PhabricatorApplicationTransactionView.php',
|
2012-12-11 22:59:20 +01:00
|
|
|
'PhabricatorApplicationTransactions' => 'applications/transactions/application/PhabricatorApplicationTransactions.php',
|
2012-09-11 18:56:40 +02:00
|
|
|
'PhabricatorApplicationUIExamples' => 'applications/uiexample/application/PhabricatorApplicationUIExamples.php',
|
2013-01-29 18:14:03 +01:00
|
|
|
'PhabricatorApplicationUninstallController' => 'applications/meta/controller/PhabricatorApplicationUninstallController.php',
|
2013-01-19 22:46:48 +01:00
|
|
|
'PhabricatorApplicationsController' => 'applications/meta/controller/PhabricatorApplicationsController.php',
|
|
|
|
'PhabricatorApplicationsListController' => 'applications/meta/controller/PhabricatorApplicationsListController.php',
|
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',
|
2013-01-07 21:48:39 +01:00
|
|
|
'PhabricatorAuthenticationConfigOptions' => 'applications/config/option/PhabricatorAuthenticationConfigOptions.php',
|
2012-10-16 19:33:47 +02:00
|
|
|
'PhabricatorBarePageExample' => 'applications/uiexample/examples/PhabricatorBarePageExample.php',
|
|
|
|
'PhabricatorBarePageView' => 'view/page/PhabricatorBarePageView.php',
|
2012-06-15 04:01:57 +02:00
|
|
|
'PhabricatorBaseEnglishTranslation' => 'infrastructure/internationalization/PhabricatorBaseEnglishTranslation.php',
|
2012-07-02 19:49:00 +02:00
|
|
|
'PhabricatorBuiltinPatchList' => 'infrastructure/storage/patch/PhabricatorBuiltinPatchList.php',
|
2012-11-08 17:22:08 +01:00
|
|
|
'PhabricatorButtonsExample' => 'applications/uiexample/examples/PhabricatorButtonsExample.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',
|
2012-12-25 15:09:51 +01:00
|
|
|
'PhabricatorCaches' => 'applications/cache/PhabricatorCaches.php',
|
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',
|
2012-10-24 22:22:24 +02:00
|
|
|
'PhabricatorCalendarDeleteStatusController' => 'applications/calendar/controller/PhabricatorCalendarDeleteStatusController.php',
|
|
|
|
'PhabricatorCalendarEditStatusController' => 'applications/calendar/controller/PhabricatorCalendarEditStatusController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorCalendarHoliday' => 'applications/calendar/storage/PhabricatorCalendarHoliday.php',
|
|
|
|
'PhabricatorCalendarHolidayTestCase' => 'applications/calendar/storage/__tests__/PhabricatorCalendarHolidayTestCase.php',
|
2012-10-24 22:22:24 +02:00
|
|
|
'PhabricatorCalendarViewStatusController' => 'applications/calendar/controller/PhabricatorCalendarViewStatusController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2013-01-16 20:10:41 +01:00
|
|
|
'PhabricatorConfigAllController' => 'applications/config/controller/PhabricatorConfigAllController.php',
|
2012-12-28 00:20:09 +01:00
|
|
|
'PhabricatorConfigController' => 'applications/config/controller/PhabricatorConfigController.php',
|
Add database configuration source to the source stack
Summary:
Read configuration from the new database source.
This adds an extra MySQL connect + query to every page. They're very cheap so I think we can suffer them for now, but I'd like to put cache in front of this at some point. The difficulties are:
- If we use APC, multi-frontend installs (Facebook) can't dirty it (major problem), and the CLI can't dirty it (fine for now, maybe a major problem later).
- If we use Memcache, we need to add config stuff.
- We could use APC in all non-Facebook installs if we can make it dirtyable from the CLI, but I don't see a reasonable way to do that.
- We don't have any other caches which are faster than the database.
So I'll probably implement Memcache support at some point, although this is a lame excuse for it.
Test Plan: Added some config values via web UI, saw them active on the install.
Reviewers: btrahan, codeblock, vrana
Reviewed By: codeblock
CC: aran
Maniphest Tasks: T2221
Differential Revision: https://secure.phabricator.com/D4296
2013-01-18 00:10:21 +01:00
|
|
|
'PhabricatorConfigDatabaseSource' => 'infrastructure/env/PhabricatorConfigDatabaseSource.php',
|
2013-01-01 23:10:33 +01:00
|
|
|
'PhabricatorConfigDefaultSource' => 'infrastructure/env/PhabricatorConfigDefaultSource.php',
|
2012-12-25 15:44:29 +01:00
|
|
|
'PhabricatorConfigDictionarySource' => 'infrastructure/env/PhabricatorConfigDictionarySource.php',
|
2012-12-28 00:20:09 +01:00
|
|
|
'PhabricatorConfigEditController' => 'applications/config/controller/PhabricatorConfigEditController.php',
|
2013-01-02 03:14:41 +01:00
|
|
|
'PhabricatorConfigEditor' => 'applications/config/editor/PhabricatorConfigEditor.php',
|
2012-12-28 00:20:09 +01:00
|
|
|
'PhabricatorConfigEntry' => 'applications/config/storage/PhabricatorConfigEntry.php',
|
|
|
|
'PhabricatorConfigEntryDAO' => 'applications/config/storage/PhabricatorConfigEntryDAO.php',
|
2012-12-25 15:44:29 +01:00
|
|
|
'PhabricatorConfigFileSource' => 'infrastructure/env/PhabricatorConfigFileSource.php',
|
2012-12-31 00:36:06 +01:00
|
|
|
'PhabricatorConfigGroupController' => 'applications/config/controller/PhabricatorConfigGroupController.php',
|
2012-12-30 15:37:49 +01:00
|
|
|
'PhabricatorConfigIssueListController' => 'applications/config/controller/PhabricatorConfigIssueListController.php',
|
|
|
|
'PhabricatorConfigIssueViewController' => 'applications/config/controller/PhabricatorConfigIssueViewController.php',
|
2013-01-12 00:28:33 +01:00
|
|
|
'PhabricatorConfigJSON' => 'applications/config/json/PhabricatorConfigJSON.php',
|
2012-12-28 00:20:09 +01:00
|
|
|
'PhabricatorConfigListController' => 'applications/config/controller/PhabricatorConfigListController.php',
|
Add a local configuration source and a non-environmental ENV config source
Summary:
See discussion in T2221. Before we can move configuration to the database, we have a bootstrapping problem: we need database credentials to live //somewhere// if we can't guess them (and we can only really guess localhost / root / no password).
Some options for this are:
- Have them live in ENV variables.
- These are often somewhat unfamiliar to users.
- Scripts would become a huge pain -- you'd have to dump a bunch of stuff into ENV.
- Some environments have limited ability to set ENV vars.
- SSH is also a pain.
- Have them live in a normal config file.
- This probably isn't really too awful, but:
- Since we deploy/upgrade with git, we can't currently let them edit a file which already exists, or their working copy will become dirty.
- So they have to copy or create a file, then edit it.
- The biggest issue I have with this is that it will be difficult to give specific, easily-followed directions from Setup. The instructions need to be like "Copy template.conf.php to real.conf.php, then edit these keys: x, y, z". This isn't as easy to follow as "run script Y".
- Have them live in an abnormal config file with script access (this diff).
- I think this is a little better than a normal config file, because we can tell users 'run phabricator/bin/config set mysql.user phabricator' and such, which is easier to follow than editing a config file.
I think this is only a marginal improvement over a normal config file and am open to arguments against this approach, but I think it will be a little easier for users to deal with than a normal config file. In most cases they should only need to store three values in this file -- db user/host/pass -- since once we have those we can bootstrap everything else. Normal config files also aren't going away for more advanced users, we're just offering a simple alternative for most users.
This also adds an ENVIRONMENT file as an alternative to PHABRICATOR_ENV. This is just a simple way to specify the environment if you don't have convenient access to env vars.
Test Plan: Ran `config set x y`, verified writes. Wrote to ENVIRONMENT, ran `PHABRICATOR_ENV= ./bin/repository`.
Reviewers: btrahan, vrana, codeblock
Reviewed By: codeblock
CC: aran
Maniphest Tasks: T2221
Differential Revision: https://secure.phabricator.com/D4294
2012-12-30 15:16:15 +01:00
|
|
|
'PhabricatorConfigLocalSource' => 'infrastructure/env/PhabricatorConfigLocalSource.php',
|
2013-01-22 00:27:42 +01:00
|
|
|
'PhabricatorConfigManagementDeleteWorkflow' => 'applications/config/management/PhabricatorConfigManagementDeleteWorkflow.php',
|
|
|
|
'PhabricatorConfigManagementGetWorkflow' => 'applications/config/management/PhabricatorConfigManagementGetWorkflow.php',
|
|
|
|
'PhabricatorConfigManagementListWorkflow' => 'applications/config/management/PhabricatorConfigManagementListWorkflow.php',
|
|
|
|
'PhabricatorConfigManagementSetWorkflow' => 'applications/config/management/PhabricatorConfigManagementSetWorkflow.php',
|
|
|
|
'PhabricatorConfigManagementWorkflow' => 'applications/config/management/PhabricatorConfigManagementWorkflow.php',
|
2012-12-31 00:36:06 +01:00
|
|
|
'PhabricatorConfigOption' => 'applications/config/option/PhabricatorConfigOption.php',
|
2012-12-25 15:44:29 +01:00
|
|
|
'PhabricatorConfigProxySource' => 'infrastructure/env/PhabricatorConfigProxySource.php',
|
2013-01-23 00:16:26 +01:00
|
|
|
'PhabricatorConfigResponse' => 'applications/config/response/PhabricatorConfigResponse.php',
|
2012-12-25 15:44:29 +01:00
|
|
|
'PhabricatorConfigSource' => 'infrastructure/env/PhabricatorConfigSource.php',
|
|
|
|
'PhabricatorConfigStackSource' => 'infrastructure/env/PhabricatorConfigStackSource.php',
|
2013-01-02 03:14:41 +01:00
|
|
|
'PhabricatorConfigTransaction' => 'applications/config/storage/PhabricatorConfigTransaction.php',
|
|
|
|
'PhabricatorConfigTransactionQuery' => 'applications/config/query/PhabricatorConfigTransactionQuery.php',
|
2013-01-02 03:15:03 +01:00
|
|
|
'PhabricatorConfigValidationException' => 'applications/config/exception/PhabricatorConfigValidationException.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorContentSource' => 'applications/metamta/contentsource/PhabricatorContentSource.php',
|
|
|
|
'PhabricatorContentSourceView' => 'applications/metamta/contentsource/PhabricatorContentSourceView.php',
|
|
|
|
'PhabricatorController' => 'applications/base/controller/PhabricatorController.php',
|
2013-01-02 03:22:48 +01:00
|
|
|
'PhabricatorCoreConfigOptions' => 'applications/config/option/PhabricatorCoreConfigOptions.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-12-07 22:35:17 +01:00
|
|
|
'PhabricatorCrumbView' => 'view/layout/PhabricatorCrumbView.php',
|
|
|
|
'PhabricatorCrumbsView' => 'view/layout/PhabricatorCrumbsView.php',
|
2012-09-13 19:15:08 +02:00
|
|
|
'PhabricatorCursorPagedPolicyAwareQuery' => 'infrastructure/query/policy/PhabricatorCursorPagedPolicyAwareQuery.php',
|
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',
|
|
|
|
'PhabricatorDefaultFileStorageEngineSelector' => 'applications/files/engineselector/PhabricatorDefaultFileStorageEngineSelector.php',
|
|
|
|
'PhabricatorDefaultSearchEngineSelector' => 'applications/search/selector/PhabricatorDefaultSearchEngineSelector.php',
|
2013-01-01 23:09:17 +01:00
|
|
|
'PhabricatorDeveloperConfigOptions' => 'applications/config/option/PhabricatorDeveloperConfigOptions.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorDifferenceEngine' => 'infrastructure/diff/PhabricatorDifferenceEngine.php',
|
2012-12-31 00:36:06 +01:00
|
|
|
'PhabricatorDifferentialConfigOptions' => 'applications/differential/config/PhabricatorDifferentialConfigOptions.php',
|
2013-01-16 18:08:13 +01:00
|
|
|
'PhabricatorDiffusionConfigOptions' => 'applications/diffusion/config/PhabricatorDiffusionConfigOptions.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorDirectoryController' => 'applications/directory/controller/PhabricatorDirectoryController.php',
|
|
|
|
'PhabricatorDirectoryMainController' => 'applications/directory/controller/PhabricatorDirectoryMainController.php',
|
|
|
|
'PhabricatorDisabledUserController' => 'applications/auth/controller/PhabricatorDisabledUserController.php',
|
2013-01-01 23:09:29 +01:00
|
|
|
'PhabricatorDisqusConfigOptions' => 'applications/config/option/PhabricatorDisqusConfigOptions.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
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',
|
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',
|
2012-10-10 19:18:23 +02:00
|
|
|
'PhabricatorEditor' => 'infrastructure/PhabricatorEditor.php',
|
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',
|
2012-06-14 22:43:09 +02:00
|
|
|
'PhabricatorEnglishTranslation' => 'infrastructure/internationalization/PhabricatorEnglishTranslation.php',
|
2012-12-25 15:44:29 +01:00
|
|
|
'PhabricatorEnv' => 'infrastructure/env/PhabricatorEnv.php',
|
|
|
|
'PhabricatorEnvTestCase' => 'infrastructure/env/__tests__/PhabricatorEnvTestCase.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorErrorExample' => 'applications/uiexample/examples/PhabricatorErrorExample.php',
|
|
|
|
'PhabricatorEvent' => 'infrastructure/events/PhabricatorEvent.php',
|
|
|
|
'PhabricatorEventEngine' => 'infrastructure/events/PhabricatorEventEngine.php',
|
|
|
|
'PhabricatorEventType' => 'infrastructure/events/constant/PhabricatorEventType.php',
|
2012-07-04 01:46:27 +02:00
|
|
|
'PhabricatorExampleEventListener' => 'infrastructure/events/PhabricatorExampleEventListener.php',
|
2013-01-03 00:52:30 +01:00
|
|
|
'PhabricatorExtendingPhabricatorConfigOptions' => 'applications/config/option/PhabricatorExtendingPhabricatorConfigOptions.php',
|
2013-01-01 23:09:29 +01:00
|
|
|
'PhabricatorFacebookConfigOptions' => 'applications/config/option/PhabricatorFacebookConfigOptions.php',
|
2012-07-27 22:46:01 +02:00
|
|
|
'PhabricatorFactAggregate' => 'applications/fact/storage/PhabricatorFactAggregate.php',
|
2012-07-30 19:44:08 +02:00
|
|
|
'PhabricatorFactChartController' => 'applications/fact/controller/PhabricatorFactChartController.php',
|
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',
|
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',
|
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',
|
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',
|
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',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorFeedBuilder' => 'applications/feed/builder/PhabricatorFeedBuilder.php',
|
2013-01-15 02:49:32 +01:00
|
|
|
'PhabricatorFeedConfigOptions' => 'applications/feed/config/PhabricatorFeedConfigOptions.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorFeedConstants' => 'applications/feed/constants/PhabricatorFeedConstants.php',
|
|
|
|
'PhabricatorFeedController' => 'applications/feed/controller/PhabricatorFeedController.php',
|
|
|
|
'PhabricatorFeedDAO' => 'applications/feed/storage/PhabricatorFeedDAO.php',
|
2013-01-11 01:06:29 +01:00
|
|
|
'PhabricatorFeedMainController' => 'applications/feed/controller/PhabricatorFeedMainController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorFeedPublicStreamController' => 'applications/feed/controller/PhabricatorFeedPublicStreamController.php',
|
|
|
|
'PhabricatorFeedQuery' => 'applications/feed/PhabricatorFeedQuery.php',
|
|
|
|
'PhabricatorFeedStory' => 'applications/feed/story/PhabricatorFeedStory.php',
|
2012-07-01 20:08:59 +02:00
|
|
|
'PhabricatorFeedStoryAggregate' => 'applications/feed/story/PhabricatorFeedStoryAggregate.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorFeedStoryAudit' => 'applications/feed/story/PhabricatorFeedStoryAudit.php',
|
2012-06-20 15:03:44 +02:00
|
|
|
'PhabricatorFeedStoryCommit' => 'applications/feed/story/PhabricatorFeedStoryCommit.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorFeedStoryData' => 'applications/feed/storage/PhabricatorFeedStoryData.php',
|
|
|
|
'PhabricatorFeedStoryDifferential' => 'applications/feed/story/PhabricatorFeedStoryDifferential.php',
|
2012-08-22 17:19:38 +02:00
|
|
|
'PhabricatorFeedStoryDifferentialAggregate' => 'applications/feed/story/PhabricatorFeedStoryDifferentialAggregate.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorFeedStoryManiphest' => 'applications/feed/story/PhabricatorFeedStoryManiphest.php',
|
2012-07-01 20:08:59 +02:00
|
|
|
'PhabricatorFeedStoryManiphestAggregate' => 'applications/feed/story/PhabricatorFeedStoryManiphestAggregate.php',
|
2012-06-08 15:31:30 +02:00
|
|
|
'PhabricatorFeedStoryNotification' => 'applications/notification/storage/PhabricatorFeedStoryNotification.php',
|
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',
|
|
|
|
'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',
|
2012-10-01 23:04:03 +02:00
|
|
|
'PhabricatorFileImageMacro' => 'applications/macro/storage/PhabricatorFileImageMacro.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorFileInfoController' => 'applications/files/controller/PhabricatorFileInfoController.php',
|
2012-10-23 04:06:56 +02:00
|
|
|
'PhabricatorFileLinkListView' => 'view/layout/PhabricatorFileLinkListView.php',
|
|
|
|
'PhabricatorFileLinkView' => 'view/layout/PhabricatorFileLinkView.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorFileListController' => 'applications/files/controller/PhabricatorFileListController.php',
|
2012-10-31 17:57:46 +01:00
|
|
|
'PhabricatorFileQuery' => 'applications/files/query/PhabricatorFileQuery.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorFileShortcutController' => 'applications/files/controller/PhabricatorFileShortcutController.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',
|
2013-01-14 02:01:00 +01:00
|
|
|
'PhabricatorFilesConfigOptions' => 'applications/files/config/PhabricatorFilesConfigOptions.php',
|
2012-10-25 20:36:38 +02:00
|
|
|
'PhabricatorFilesManagementEnginesWorkflow' => 'applications/files/management/PhabricatorFilesManagementEnginesWorkflow.php',
|
2013-01-07 18:43:35 +01:00
|
|
|
'PhabricatorFilesManagementMetadataWorkflow' => 'applications/files/management/PhabricatorFilesManagementMetadataWorkflow.php',
|
2012-10-25 20:36:38 +02:00
|
|
|
'PhabricatorFilesManagementMigrateWorkflow' => 'applications/files/management/PhabricatorFilesManagementMigrateWorkflow.php',
|
|
|
|
'PhabricatorFilesManagementWorkflow' => 'applications/files/management/PhabricatorFilesManagementWorkflow.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-08-24 22:19:47 +02:00
|
|
|
'PhabricatorFlagsUIEventListener' => 'applications/flag/events/PhabricatorFlagsUIEventListener.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorFormExample' => 'applications/uiexample/examples/PhabricatorFormExample.php',
|
2013-01-02 23:03:08 +01:00
|
|
|
'PhabricatorGarbageCollectorConfigOptions' => 'applications/config/option/PhabricatorGarbageCollectorConfigOptions.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorGarbageCollectorDaemon' => 'infrastructure/daemon/PhabricatorGarbageCollectorDaemon.php',
|
2012-06-26 00:21:48 +02:00
|
|
|
'PhabricatorGitGraphStream' => 'applications/repository/daemon/PhabricatorGitGraphStream.php',
|
2013-01-01 23:09:29 +01:00
|
|
|
'PhabricatorGitHubConfigOptions' => 'applications/config/option/PhabricatorGitHubConfigOptions.php',
|
2012-06-27 22:59:12 +02:00
|
|
|
'PhabricatorGlobalLock' => 'infrastructure/util/PhabricatorGlobalLock.php',
|
Modernize file uploads
Summary:
Modernizes file uploads. In particular:
- Adds a mobile menu, with an "Upload File" item.
- Adds crumbs to the list view, detail view and upload view.
- Adds "Upload File" action to crumbs.
- Moves upload file to a separate page.
- Removes the combined upload file + recent files page.
- Makes upload file use a normal file control by default (works on mobile).
- Home page, file list and file upload page are now global drop targets which accept files dropped anywhere on them. Dragging a file into the window shows a mask and an instructional message.
- User education on this is a little weak but I think that's a big can of worms?
- Fixes a bug where dropping multiple files into a Remarkup text area produced bad results (resolves T2190).
T879 is related, although it's specifically about Maniphest. I've declined to make global drop targets yet there because there are multiple drop targets on the page with different meanings. That UI needs updating in general.
@chad, do we have an "upload" icon (counterpart to "download")?
Test Plan: Uploaded files in Maniphest, Differential, Files, and from Home. Dragged and dropped multiple files into Differential. Used crumbs, mobile.
Reviewers: chad, btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2190
Differential Revision: https://secure.phabricator.com/D4200
2012-12-17 01:34:01 +01:00
|
|
|
'PhabricatorGlobalUploadTargetView' => 'applications/files/view/PhabricatorGlobalUploadTargetView.php',
|
2013-01-01 23:09:29 +01:00
|
|
|
'PhabricatorGoogleConfigOptions' => 'applications/config/option/PhabricatorGoogleConfigOptions.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorHandleObjectSelectorDataView' => 'applications/phid/handle/view/PhabricatorHandleObjectSelectorDataView.php',
|
|
|
|
'PhabricatorHash' => 'infrastructure/util/PhabricatorHash.php',
|
2012-12-21 14:43:33 +01:00
|
|
|
'PhabricatorHashTestCase' => 'infrastructure/util/__tests__/PhabricatorHashTestCase.php',
|
2012-08-15 19:45:06 +02:00
|
|
|
'PhabricatorHeaderView' => 'view/layout/PhabricatorHeaderView.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2013-01-19 14:45:04 +01:00
|
|
|
'PhabricatorIRCFeedNotificationHandler' => 'infrastructure/daemon/irc/handler/PhabricatorIRCFeedNotificationHandler.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2013-01-15 22:17:34 +01:00
|
|
|
'PhabricatorIRCSymbolHandler' => 'infrastructure/daemon/irc/handler/PhabricatorIRCSymbolHandler.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorIRCWhatsNewHandler' => 'infrastructure/daemon/irc/handler/PhabricatorIRCWhatsNewHandler.php',
|
|
|
|
'PhabricatorImageTransformer' => 'applications/files/PhabricatorImageTransformer.php',
|
2012-05-30 23:26:29 +02:00
|
|
|
'PhabricatorInfrastructureTestCase' => 'infrastructure/__tests__/PhabricatorInfrastructureTestCase.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorInlineCommentController' => 'infrastructure/diff/PhabricatorInlineCommentController.php',
|
|
|
|
'PhabricatorInlineCommentInterface' => 'infrastructure/diff/interface/PhabricatorInlineCommentInterface.php',
|
2012-07-23 20:01:28 +02:00
|
|
|
'PhabricatorInlineCommentPreviewController' => 'infrastructure/diff/PhabricatorInlineCommentPreviewController.php',
|
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',
|
Implement a more compact, general database-backed key-value cache
Summary:
See discussion in D4204. Facebook currently has a 314MB remarkup cache with a 55MB index, which is slow to access. Under the theory that this is an index size/quality problem (the current index is on a potentially-384-byte field, with many keys sharing prefixes), provide a more general index with fancy new features:
- It implements PhutilKeyValueCache, so it can be a component in cache stacks and supports TTL.
- It has a 12-byte hash-based key.
- It automatically compresses large blocks of data (most of what we store is highly-compressible HTML).
Test Plan:
- Basics:
- Loaded /paste/, saw caches generate and save.
- Reloaded /paste/, saw the page hit cache.
- GC:
- Ran GC daemon, saw nothing.
- Set maximum lifetime to 1 second, ran GC daemon, saw it collect the entire cache.
- Deflate:
- Selected row formats from the database, saw a mixture of 'raw' and 'deflate' storage.
- Used profiler to verify that 'deflate' is fast (12 calls @ 220us on my paste list).
- Ran unit tests
Reviewers: vrana, btrahan
Reviewed By: vrana
CC: aran
Differential Revision: https://secure.phabricator.com/D4259
2012-12-21 23:17:56 +01:00
|
|
|
'PhabricatorKeyValueDatabaseCache' => 'applications/cache/PhabricatorKeyValueDatabaseCache.php',
|
2013-01-02 23:04:05 +01:00
|
|
|
'PhabricatorLDAPConfigOptions' => 'applications/config/option/PhabricatorLDAPConfigOptions.php',
|
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',
|
2012-07-26 23:32:51 +02:00
|
|
|
'PhabricatorLDAPUnknownUserException' => 'applications/auth/ldap/PhabricatorLDAPUnknownUserException.php',
|
2012-06-13 17:52:05 +02:00
|
|
|
'PhabricatorLDAPUnlinkController' => 'applications/auth/controller/PhabricatorLDAPUnlinkController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorLintEngine' => 'infrastructure/lint/PhabricatorLintEngine.php',
|
2012-07-02 19:49:00 +02:00
|
|
|
'PhabricatorLiskDAO' => 'infrastructure/storage/lisk/PhabricatorLiskDAO.php',
|
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',
|
Modernize Macro application
Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro.
Test Plan:
{F26839}
{F26840}
{F26841}
{F26842}
{F26843}
{F26844}
{F26845}
Reviewers: vrana, btrahan, chad
Reviewed By: vrana
CC: aran
Maniphest Tasks: T2157, T175, T2104
Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
|
|
|
'PhabricatorMacroCommentController' => 'applications/macro/controller/PhabricatorMacroCommentController.php',
|
2013-01-16 19:52:30 +01:00
|
|
|
'PhabricatorMacroConfigOptions' => 'applications/macro/config/PhabricatorMacroConfigOptions.php',
|
2012-10-01 23:04:03 +02:00
|
|
|
'PhabricatorMacroController' => 'applications/macro/controller/PhabricatorMacroController.php',
|
Modernize Macro application
Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro.
Test Plan:
{F26839}
{F26840}
{F26841}
{F26842}
{F26843}
{F26844}
{F26845}
Reviewers: vrana, btrahan, chad
Reviewed By: vrana
CC: aran
Maniphest Tasks: T2157, T175, T2104
Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
|
|
|
'PhabricatorMacroDisableController' => 'applications/macro/controller/PhabricatorMacroDisableController.php',
|
2012-10-01 23:04:03 +02:00
|
|
|
'PhabricatorMacroEditController' => 'applications/macro/controller/PhabricatorMacroEditController.php',
|
Modernize Macro application
Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro.
Test Plan:
{F26839}
{F26840}
{F26841}
{F26842}
{F26843}
{F26844}
{F26845}
Reviewers: vrana, btrahan, chad
Reviewed By: vrana
CC: aran
Maniphest Tasks: T2157, T175, T2104
Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
|
|
|
'PhabricatorMacroEditor' => 'applications/macro/editor/PhabricatorMacroEditor.php',
|
2012-10-01 23:04:03 +02:00
|
|
|
'PhabricatorMacroListController' => 'applications/macro/controller/PhabricatorMacroListController.php',
|
2013-01-20 03:43:35 +01:00
|
|
|
'PhabricatorMacroMemeController' => 'applications/macro/controller/PhabricatorMacroMemeController.php',
|
2013-01-22 03:46:04 +01:00
|
|
|
'PhabricatorMacroMemeDialogController' => 'applications/macro/controller/PhabricatorMacroMemeDialogController.php',
|
Modernize Macro application
Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro.
Test Plan:
{F26839}
{F26840}
{F26841}
{F26842}
{F26843}
{F26844}
{F26845}
Reviewers: vrana, btrahan, chad
Reviewed By: vrana
CC: aran
Maniphest Tasks: T2157, T175, T2104
Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
|
|
|
'PhabricatorMacroReplyHandler' => 'applications/macro/mail/PhabricatorMacroReplyHandler.php',
|
|
|
|
'PhabricatorMacroTransaction' => 'applications/macro/storage/PhabricatorMacroTransaction.php',
|
|
|
|
'PhabricatorMacroTransactionComment' => 'applications/macro/storage/PhabricatorMacroTransactionComment.php',
|
|
|
|
'PhabricatorMacroTransactionQuery' => 'applications/macro/query/PhabricatorMacroTransactionQuery.php',
|
|
|
|
'PhabricatorMacroTransactionType' => 'applications/macro/constants/PhabricatorMacroTransactionType.php',
|
|
|
|
'PhabricatorMacroViewController' => 'applications/macro/controller/PhabricatorMacroViewController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorMailImplementationAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationAdapter.php',
|
|
|
|
'PhabricatorMailImplementationAmazonSESAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationAmazonSESAdapter.php',
|
2012-12-09 11:36:40 +01:00
|
|
|
'PhabricatorMailImplementationPHPMailerAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationPHPMailerAdapter.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorMailImplementationPHPMailerLiteAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationPHPMailerLiteAdapter.php',
|
|
|
|
'PhabricatorMailImplementationSendGridAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationSendGridAdapter.php',
|
|
|
|
'PhabricatorMailImplementationTestAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationTestAdapter.php',
|
|
|
|
'PhabricatorMailReplyHandler' => 'applications/metamta/replyhandler/PhabricatorMailReplyHandler.php',
|
2013-01-24 01:36:21 +01:00
|
|
|
'PhabricatorMailingListsController' => 'applications/mailinglists/controller/PhabricatorMailingListsController.php',
|
2012-08-13 04:19:46 +02:00
|
|
|
'PhabricatorMailingListsEditController' => 'applications/mailinglists/controller/PhabricatorMailingListsEditController.php',
|
|
|
|
'PhabricatorMailingListsListController' => 'applications/mailinglists/controller/PhabricatorMailingListsListController.php',
|
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',
|
2013-01-11 19:24:35 +01:00
|
|
|
'PhabricatorManiphestConfigOptions' => 'applications/maniphest/config/PhabricatorManiphestConfigOptions.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',
|
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',
|
2012-12-07 22:31:13 +01:00
|
|
|
'PhabricatorMenuItemView' => 'view/layout/PhabricatorMenuItemView.php',
|
2012-12-07 22:32:14 +01:00
|
|
|
'PhabricatorMenuView' => 'view/layout/PhabricatorMenuView.php',
|
2013-02-03 19:02:35 +01:00
|
|
|
'PhabricatorMenuViewTestCase' => 'view/layout/__tests__/PhabricatorMenuViewTestCase.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorMercurialGraphStream' => 'applications/repository/daemon/PhabricatorMercurialGraphStream.php',
|
|
|
|
'PhabricatorMetaMTAAttachment' => 'applications/metamta/storage/PhabricatorMetaMTAAttachment.php',
|
2013-01-17 00:06:39 +01:00
|
|
|
'PhabricatorMetaMTAConfigOptions' => 'applications/config/option/PhabricatorMetaMTAConfigOptions.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-07-17 04:01:43 +02:00
|
|
|
'PhabricatorMetaMTAMailBody' => 'applications/metamta/view/PhabricatorMetaMTAMailBody.php',
|
|
|
|
'PhabricatorMetaMTAMailBodyTestCase' => 'applications/metamta/view/__tests__/PhabricatorMetaMTAMailBodyTestCase.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorMetaMTAMailTestCase' => 'applications/metamta/storage/__tests__/PhabricatorMetaMTAMailTestCase.php',
|
2012-08-13 04:19:46 +02:00
|
|
|
'PhabricatorMetaMTAMailingList' => 'applications/mailinglists/storage/PhabricatorMetaMTAMailingList.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2013-01-03 15:01:14 +01:00
|
|
|
'PhabricatorMySQLConfigOptions' => 'applications/config/option/PhabricatorMySQLConfigOptions.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorMySQLFileStorageEngine' => 'applications/files/engine/PhabricatorMySQLFileStorageEngine.php',
|
2012-06-08 22:00:07 +02:00
|
|
|
'PhabricatorNotificationBuilder' => 'applications/notification/builder/PhabricatorNotificationBuilder.php',
|
2012-06-20 22:51:19 +02:00
|
|
|
'PhabricatorNotificationClearController' => 'applications/notification/controller/PhabricatorNotificationClearController.php',
|
2013-01-03 18:29:19 +01:00
|
|
|
'PhabricatorNotificationConfigOptions' => 'applications/config/option/PhabricatorNotificationConfigOptions.php',
|
2012-06-08 22:00:07 +02:00
|
|
|
'PhabricatorNotificationController' => 'applications/notification/controller/PhabricatorNotificationController.php',
|
2012-06-12 02:49:32 +02:00
|
|
|
'PhabricatorNotificationIndividualController' => 'applications/notification/controller/PhabricatorNotificationIndividualController.php',
|
2012-06-18 23:07:38 +02:00
|
|
|
'PhabricatorNotificationListController' => 'applications/notification/controller/PhabricatorNotificationListController.php',
|
2012-06-11 18:37:06 +02:00
|
|
|
'PhabricatorNotificationPanelController' => 'applications/notification/controller/PhabricatorNotificationPanelController.php',
|
2012-06-08 15:31:30 +02:00
|
|
|
'PhabricatorNotificationQuery' => 'applications/notification/PhabricatorNotificationQuery.php',
|
2012-06-17 20:35:18 +02:00
|
|
|
'PhabricatorNotificationStatusController' => 'applications/notification/controller/PhabricatorNotificationStatusController.php',
|
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',
|
2012-08-15 19:45:06 +02:00
|
|
|
'PhabricatorObjectItemListView' => 'view/layout/PhabricatorObjectItemListView.php',
|
|
|
|
'PhabricatorObjectItemView' => 'view/layout/PhabricatorObjectItemView.php',
|
2012-08-07 20:57:38 +02:00
|
|
|
'PhabricatorObjectListView' => 'view/control/PhabricatorObjectListView.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorObjectSelectorDialog' => 'view/control/PhabricatorObjectSelectorDialog.php',
|
|
|
|
'PhabricatorOffsetPagedQuery' => 'infrastructure/query/PhabricatorOffsetPagedQuery.php',
|
|
|
|
'PhabricatorOwnerPathQuery' => 'applications/owners/query/PhabricatorOwnerPathQuery.php',
|
2013-01-16 19:52:30 +01:00
|
|
|
'PhabricatorOwnersConfigOptions' => 'applications/owners/config/PhabricatorOwnersConfigOptions.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-11-19 21:53:41 +01:00
|
|
|
'PhabricatorOwnersPackagePathValidator' => 'applications/repository/worker/commitchangeparser/PhabricatorOwnersPackagePathValidator.php',
|
2012-08-08 21:25:11 +02:00
|
|
|
'PhabricatorOwnersPackageQuery' => 'applications/owners/query/PhabricatorOwnersPackageQuery.php',
|
2012-12-07 02:23:56 +01:00
|
|
|
'PhabricatorOwnersPackageTestCase' => 'applications/owners/storage/__tests__/PhabricatorOwnersPackageTestCase.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorOwnersPath' => 'applications/owners/storage/PhabricatorOwnersPath.php',
|
2013-01-09 15:05:34 +01:00
|
|
|
'PhabricatorPHDConfigOptions' => 'applications/config/option/PhabricatorPHDConfigOptions.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorPHID' => 'applications/phid/storage/PhabricatorPHID.php',
|
2013-01-19 19:20:22 +01:00
|
|
|
'PhabricatorPHIDConfigOptions' => 'applications/phid/config/PhabricatorPHIDConfigOptions.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorPHIDConstants' => 'applications/phid/PhabricatorPHIDConstants.php',
|
|
|
|
'PhabricatorPHIDController' => 'applications/phid/controller/PhabricatorPHIDController.php',
|
|
|
|
'PhabricatorPHIDLookupController' => 'applications/phid/controller/PhabricatorPHIDLookupController.php',
|
2013-01-15 21:03:44 +01:00
|
|
|
'PhabricatorPHPMailerConfigOptions' => 'applications/config/option/PhabricatorPHPMailerConfigOptions.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorPaste' => 'applications/paste/storage/PhabricatorPaste.php',
|
|
|
|
'PhabricatorPasteController' => 'applications/paste/controller/PhabricatorPasteController.php',
|
|
|
|
'PhabricatorPasteDAO' => 'applications/paste/storage/PhabricatorPasteDAO.php',
|
2012-08-24 22:19:14 +02:00
|
|
|
'PhabricatorPasteEditController' => 'applications/paste/controller/PhabricatorPasteEditController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-07-04 04:10:38 +02:00
|
|
|
'PhabricatorPeopleLdapController' => 'applications/people/controller/PhabricatorPeopleLdapController.php',
|
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',
|
2013-01-16 19:00:51 +01:00
|
|
|
'PhabricatorPhabricatorOAuthConfigOptions' => 'applications/config/option/PhabricatorPhabricatorOAuthConfigOptions.php',
|
2013-01-16 00:36:49 +01:00
|
|
|
'PhabricatorPhameConfigOptions' => 'applications/phame/config/PhabricatorPhameConfigOptions.php',
|
2013-01-16 19:52:30 +01:00
|
|
|
'PhabricatorPholioConfigOptions' => 'applications/pholio/config/PhabricatorPholioConfigOptions.php',
|
2013-01-15 15:31:53 +01:00
|
|
|
'PhabricatorPhrictionConfigOptions' => 'applications/phriction/config/PhabricatorPhrictionConfigOptions.php',
|
2012-10-01 23:06:00 +02:00
|
|
|
'PhabricatorPinboardItemView' => 'view/layout/PhabricatorPinboardItemView.php',
|
|
|
|
'PhabricatorPinboardView' => 'view/layout/PhabricatorPinboardView.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorPolicies' => 'applications/policy/constants/PhabricatorPolicies.php',
|
2012-09-13 19:15:08 +02:00
|
|
|
'PhabricatorPolicy' => 'applications/policy/filter/PhabricatorPolicy.php',
|
|
|
|
'PhabricatorPolicyAwareQuery' => 'infrastructure/query/policy/PhabricatorPolicyAwareQuery.php',
|
|
|
|
'PhabricatorPolicyAwareTestQuery' => 'applications/policy/__tests__/PhabricatorPolicyAwareTestQuery.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorPolicyCapability' => 'applications/policy/constants/PhabricatorPolicyCapability.php',
|
2013-01-07 21:47:26 +01:00
|
|
|
'PhabricatorPolicyConfigOptions' => 'applications/config/option/PhabricatorPolicyConfigOptions.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorPolicyConstants' => 'applications/policy/constants/PhabricatorPolicyConstants.php',
|
|
|
|
'PhabricatorPolicyException' => 'applications/policy/exception/PhabricatorPolicyException.php',
|
|
|
|
'PhabricatorPolicyFilter' => 'applications/policy/filter/PhabricatorPolicyFilter.php',
|
|
|
|
'PhabricatorPolicyInterface' => 'applications/policy/interface/PhabricatorPolicyInterface.php',
|
2012-09-13 19:15:08 +02:00
|
|
|
'PhabricatorPolicyQuery' => 'applications/policy/query/PhabricatorPolicyQuery.php',
|
2012-06-01 21:39:29 +02:00
|
|
|
'PhabricatorPolicyTestCase' => 'applications/policy/__tests__/PhabricatorPolicyTestCase.php',
|
|
|
|
'PhabricatorPolicyTestObject' => 'applications/policy/__tests__/PhabricatorPolicyTestObject.php',
|
2012-09-13 19:15:08 +02:00
|
|
|
'PhabricatorPolicyType' => 'applications/policy/constants/PhabricatorPolicyType.php',
|
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',
|
2012-08-11 16:05:20 +02:00
|
|
|
'PhabricatorProjectEditorTestCase' => 'applications/project/editor/__tests__/PhabricatorProjectEditorTestCase.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorProjectListController' => 'applications/project/controller/PhabricatorProjectListController.php',
|
2012-08-07 20:57:38 +02:00
|
|
|
'PhabricatorProjectMembersEditController' => 'applications/project/controller/PhabricatorProjectMembersEditController.php',
|
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',
|
2012-10-15 23:50:53 +02:00
|
|
|
'PhabricatorPropertyListExample' => 'applications/uiexample/examples/PhabricatorPropertyListExample.php',
|
2012-08-15 19:45:06 +02:00
|
|
|
'PhabricatorPropertyListView' => 'view/layout/PhabricatorPropertyListView.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorQuery' => 'infrastructure/query/PhabricatorQuery.php',
|
2013-01-03 18:17:38 +01:00
|
|
|
'PhabricatorRecaptchaConfigOptions' => 'applications/config/option/PhabricatorRecaptchaConfigOptions.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorRedirectController' => 'applications/base/controller/PhabricatorRedirectController.php',
|
|
|
|
'PhabricatorRefreshCSRFController' => 'applications/auth/controller/PhabricatorRefreshCSRFController.php',
|
2012-09-19 21:27:28 +02:00
|
|
|
'PhabricatorRemarkupControl' => 'view/form/control/PhabricatorRemarkupControl.php',
|
2012-08-15 04:19:23 +02:00
|
|
|
'PhabricatorRemarkupRuleCountdown' => 'infrastructure/markup/rule/PhabricatorRemarkupRuleCountdown.php',
|
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',
|
2013-01-24 18:57:58 +01:00
|
|
|
'PhabricatorRemarkupRuleMeme' => 'infrastructure/markup/rule/PhabricatorRemarkupRuleMeme.php',
|
2012-07-02 19:44:37 +02:00
|
|
|
'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',
|
|
|
|
'PhabricatorRemarkupRuleYoutube' => 'infrastructure/markup/rule/PhabricatorRemarkupRuleYoutube.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorRepository' => 'applications/repository/storage/PhabricatorRepository.php',
|
|
|
|
'PhabricatorRepositoryArcanistProject' => 'applications/repository/storage/PhabricatorRepositoryArcanistProject.php',
|
2012-10-04 22:25:58 +02:00
|
|
|
'PhabricatorRepositoryArcanistProjectDeleteController' => 'applications/repository/controller/PhabricatorRepositoryArcanistProjectDeleteController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorRepositoryArcanistProjectEditController' => 'applications/repository/controller/PhabricatorRepositoryArcanistProjectEditController.php',
|
|
|
|
'PhabricatorRepositoryAuditRequest' => 'applications/repository/storage/PhabricatorRepositoryAuditRequest.php',
|
2012-11-06 08:09:36 +01:00
|
|
|
'PhabricatorRepositoryBranch' => 'applications/repository/storage/PhabricatorRepositoryBranch.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorRepositoryCommit' => 'applications/repository/storage/PhabricatorRepositoryCommit.php',
|
|
|
|
'PhabricatorRepositoryCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/PhabricatorRepositoryCommitChangeParserWorker.php',
|
|
|
|
'PhabricatorRepositoryCommitData' => 'applications/repository/storage/PhabricatorRepositoryCommitData.php',
|
|
|
|
'PhabricatorRepositoryCommitHeraldWorker' => 'applications/repository/worker/PhabricatorRepositoryCommitHeraldWorker.php',
|
|
|
|
'PhabricatorRepositoryCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/PhabricatorRepositoryCommitMessageParserWorker.php',
|
|
|
|
'PhabricatorRepositoryCommitOwnersWorker' => 'applications/repository/worker/PhabricatorRepositoryCommitOwnersWorker.php',
|
|
|
|
'PhabricatorRepositoryCommitParserWorker' => 'applications/repository/worker/PhabricatorRepositoryCommitParserWorker.php',
|
Improve Search architecture
Summary:
The search indexing API has several problems right now:
- Always runs in-process.
- It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it.
- Being able to use the task queue will also make rebuilding indexes faster.
- Instead, make the API phid-oriented.
- No uniform indexing API.
- Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird.
- Instead, provide a uniform API.
- No uniform CLI.
- We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers.
- Instead, let indexers expose documents for indexing.
- Not application-oriented.
- All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world.
- Instead, move indexers to applications and load them with SymbolLoader.
Test Plan:
- `bin/search index`
- Indexed one revision, one task.
- Indexed `--type TASK`, `--type DREV`, etc., for all types.
- Indexed `--all`.
- Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it.
- Creating users is a pain; searched for a user after indexing.
- Creating commits is a pain; searched for a commit after indexing.
- Mocks aren't currently loadable in the result view, so their indexing is moot.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: 20after4, aran
Maniphest Tasks: T1991, T2104
Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
|
|
|
'PhabricatorRepositoryCommitSearchIndexer' => 'applications/repository/search/PhabricatorRepositoryCommitSearchIndexer.php',
|
2013-01-16 18:35:47 +01:00
|
|
|
'PhabricatorRepositoryConfigOptions' => 'applications/repository/PhabricatorRepositoryConfigOptions.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorRepositoryController' => 'applications/repository/controller/PhabricatorRepositoryController.php',
|
|
|
|
'PhabricatorRepositoryCreateController' => 'applications/repository/controller/PhabricatorRepositoryCreateController.php',
|
|
|
|
'PhabricatorRepositoryDAO' => 'applications/repository/storage/PhabricatorRepositoryDAO.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',
|
2012-10-26 01:23:41 +02:00
|
|
|
'PhabricatorRepositoryManagementDeleteWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementDeleteWorkflow.php',
|
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',
|
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',
|
2012-12-19 20:07:06 +01:00
|
|
|
'PhabricatorRepositoryQuery' => 'applications/repository/query/PhabricatorRepositoryQuery.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-07-02 19:49:00 +02:00
|
|
|
'PhabricatorSQLPatchList' => 'infrastructure/storage/patch/PhabricatorSQLPatchList.php',
|
Implement SSHD glue and Conduit SSH endpoint
Summary:
- Build "sshd-auth" (for authentication) and "sshd-exec" (for command execution) binaries. These are callable by "sshd-vcs", located [[https://github.com/epriestley/sshd-vcs | in my account on GitHub]]. They are based on precursors [[https://github.com/epriestley/sshd-vcs-glue | here on GitHub]] which I deployed for TenXer about a year ago, so I have some confidence they at least basically work.
- The problem this solves is that normally every user would need an account on a machine to connect to it, and/or their public keys would all need to be listed in `~/.authorized_keys`. This is a big pain in most installs. Software like Gitosis/Gitolite solve this problem by giving you an easy way to add public keys to `~/.authorized_keys`, but this is pretty gross.
- Roughly, instead of looking in `~/.authorized_keys` when a user connects, the patched sshd instead runs `echo <public key> | sshd-auth`. The `sshd-auth` script looks up the public key and authorizes the matching user, if they exist. It also forces sshd to run `sshd-exec` instead of a normal shell.
- `sshd-exec` receives the authenticated user and any command which was passed to ssh (like `git receive-pack`) and can route them appropriately.
- Overall, this permits a single account to be set up on a server which all Phabricator users can connect to without any extra work, and which can safely execute commands and apply appropriate permissions, and disable users when they are disabled in Phabricator and all that stuff.
- Build out "sshd-exec" to do more thorough checks and setup, and delegate command execution to Workflows (they now exist, and did not when I originally built this stuff).
- Convert @btrahan's conduit API script into a workflow and slightly simplify it (ConduitCall did not exist at the time it was written).
The next steps here on the Repository side are to implement Workflows for Git, SVN and HG wire protocols. These will mostly just proxy the protocols, but also need to enforce permissions. So the approach will basically be:
- Implement workflows for stuff like `git receive-pack`.
- These workflows will implement enough of the underlying protocol to determine what resource the user is trying to access, and whether they want to read or write it.
- They'll then do a permissons check, and kick the user out if they don't have permission to do whatever they are trying to do.
- If the user does have permission, we just proxy the rest of the transaction.
Next steps on the Conduit side are more simple:
- Make ConduitClient understand "ssh://" URLs.
Test Plan: Ran `sshd-exec --phabricator-ssh-user epriestley conduit differential.query`, etc. This will get a more comprehensive test once I set up sshd-vcs.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603, T550
Differential Revision: https://secure.phabricator.com/D4229
2012-12-19 20:08:07 +01:00
|
|
|
'PhabricatorSSHWorkflow' => 'infrastructure/ssh/PhabricatorSSHWorkflow.php',
|
2012-12-25 15:44:29 +01:00
|
|
|
'PhabricatorScopedEnv' => 'infrastructure/env/PhabricatorScopedEnv.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorSearchAbstractDocument' => 'applications/search/index/PhabricatorSearchAbstractDocument.php',
|
|
|
|
'PhabricatorSearchAttachController' => 'applications/search/controller/PhabricatorSearchAttachController.php',
|
|
|
|
'PhabricatorSearchBaseController' => 'applications/search/controller/PhabricatorSearchBaseController.php',
|
2013-01-12 00:28:16 +01:00
|
|
|
'PhabricatorSearchConfigOptions' => 'applications/search/config/PhabricatorSearchConfigOptions.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorSearchController' => 'applications/search/controller/PhabricatorSearchController.php',
|
|
|
|
'PhabricatorSearchDAO' => 'applications/search/storage/PhabricatorSearchDAO.php',
|
|
|
|
'PhabricatorSearchDocument' => 'applications/search/storage/document/PhabricatorSearchDocument.php',
|
|
|
|
'PhabricatorSearchDocumentField' => 'applications/search/storage/document/PhabricatorSearchDocumentField.php',
|
Improve Search architecture
Summary:
The search indexing API has several problems right now:
- Always runs in-process.
- It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it.
- Being able to use the task queue will also make rebuilding indexes faster.
- Instead, make the API phid-oriented.
- No uniform indexing API.
- Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird.
- Instead, provide a uniform API.
- No uniform CLI.
- We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers.
- Instead, let indexers expose documents for indexing.
- Not application-oriented.
- All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world.
- Instead, move indexers to applications and load them with SymbolLoader.
Test Plan:
- `bin/search index`
- Indexed one revision, one task.
- Indexed `--type TASK`, `--type DREV`, etc., for all types.
- Indexed `--all`.
- Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it.
- Creating users is a pain; searched for a user after indexing.
- Creating commits is a pain; searched for a commit after indexing.
- Mocks aren't currently loadable in the result view, so their indexing is moot.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: 20after4, aran
Maniphest Tasks: T1991, T2104
Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
|
|
|
'PhabricatorSearchDocumentIndexer' => 'applications/search/index/PhabricatorSearchDocumentIndexer.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
Improve Search architecture
Summary:
The search indexing API has several problems right now:
- Always runs in-process.
- It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it.
- Being able to use the task queue will also make rebuilding indexes faster.
- Instead, make the API phid-oriented.
- No uniform indexing API.
- Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird.
- Instead, provide a uniform API.
- No uniform CLI.
- We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers.
- Instead, let indexers expose documents for indexing.
- Not application-oriented.
- All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world.
- Instead, move indexers to applications and load them with SymbolLoader.
Test Plan:
- `bin/search index`
- Indexed one revision, one task.
- Indexed `--type TASK`, `--type DREV`, etc., for all types.
- Indexed `--all`.
- Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it.
- Creating users is a pain; searched for a user after indexing.
- Creating commits is a pain; searched for a commit after indexing.
- Mocks aren't currently loadable in the result view, so their indexing is moot.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: 20after4, aran
Maniphest Tasks: T1991, T2104
Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
|
|
|
'PhabricatorSearchIndexer' => 'applications/search/index/PhabricatorSearchIndexer.php',
|
|
|
|
'PhabricatorSearchManagementIndexWorkflow' => 'applications/search/management/PhabricatorSearchManagementIndexWorkflow.php',
|
|
|
|
'PhabricatorSearchManagementWorkflow' => 'applications/search/management/PhabricatorSearchManagementWorkflow.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2013-01-03 14:45:23 +01:00
|
|
|
'PhabricatorSecurityConfigOptions' => 'applications/config/option/PhabricatorSecurityConfigOptions.php',
|
2013-01-15 21:04:05 +01:00
|
|
|
'PhabricatorSendGridConfigOptions' => 'applications/config/option/PhabricatorSendGridConfigOptions.php',
|
2012-08-13 21:37:18 +02:00
|
|
|
'PhabricatorSettingsAdjustController' => 'applications/settings/controller/PhabricatorSettingsAdjustController.php',
|
|
|
|
'PhabricatorSettingsMainController' => 'applications/settings/controller/PhabricatorSettingsMainController.php',
|
2012-08-13 21:37:26 +02:00
|
|
|
'PhabricatorSettingsPanel' => 'applications/settings/panel/PhabricatorSettingsPanel.php',
|
|
|
|
'PhabricatorSettingsPanelAccount' => 'applications/settings/panel/PhabricatorSettingsPanelAccount.php',
|
|
|
|
'PhabricatorSettingsPanelConduit' => 'applications/settings/panel/PhabricatorSettingsPanelConduit.php',
|
2013-02-05 02:00:27 +01:00
|
|
|
'PhabricatorSettingsPanelDiffPreferences' => 'applications/settings/panel/PhabricatorSettingsPanelDiffPreferences.php',
|
2012-08-13 21:37:26 +02:00
|
|
|
'PhabricatorSettingsPanelDisplayPreferences' => 'applications/settings/panel/PhabricatorSettingsPanelDisplayPreferences.php',
|
|
|
|
'PhabricatorSettingsPanelEmailAddresses' => 'applications/settings/panel/PhabricatorSettingsPanelEmailAddresses.php',
|
|
|
|
'PhabricatorSettingsPanelEmailPreferences' => 'applications/settings/panel/PhabricatorSettingsPanelEmailPreferences.php',
|
2013-01-16 18:00:11 +01:00
|
|
|
'PhabricatorSettingsPanelHomePreferences' => 'applications/settings/panel/PhabricatorSettingsPanelHomePreferences.php',
|
2012-08-13 21:37:26 +02:00
|
|
|
'PhabricatorSettingsPanelLDAP' => 'applications/settings/panel/PhabricatorSettingsPanelLDAP.php',
|
|
|
|
'PhabricatorSettingsPanelOAuth' => 'applications/settings/panel/PhabricatorSettingsPanelOAuth.php',
|
|
|
|
'PhabricatorSettingsPanelPassword' => 'applications/settings/panel/PhabricatorSettingsPanelPassword.php',
|
|
|
|
'PhabricatorSettingsPanelProfile' => 'applications/settings/panel/PhabricatorSettingsPanelProfile.php',
|
|
|
|
'PhabricatorSettingsPanelSSHKeys' => 'applications/settings/panel/PhabricatorSettingsPanelSSHKeys.php',
|
|
|
|
'PhabricatorSettingsPanelSearchPreferences' => 'applications/settings/panel/PhabricatorSettingsPanelSearchPreferences.php',
|
2012-12-30 15:37:49 +01:00
|
|
|
'PhabricatorSetupCheck' => 'applications/config/check/PhabricatorSetupCheck.php',
|
|
|
|
'PhabricatorSetupCheckAPC' => 'applications/config/check/PhabricatorSetupCheckAPC.php',
|
2013-01-22 22:57:02 +01:00
|
|
|
'PhabricatorSetupCheckBaseURI' => 'applications/config/check/PhabricatorSetupCheckBaseURI.php',
|
2013-01-23 01:16:24 +01:00
|
|
|
'PhabricatorSetupCheckDatabase' => 'applications/config/check/PhabricatorSetupCheckDatabase.php',
|
2013-01-23 00:16:26 +01:00
|
|
|
'PhabricatorSetupCheckExtensions' => 'applications/config/check/PhabricatorSetupCheckExtensions.php',
|
2013-01-01 23:09:17 +01:00
|
|
|
'PhabricatorSetupCheckExtraConfig' => 'applications/config/check/PhabricatorSetupCheckExtraConfig.php',
|
2013-01-19 17:42:15 +01:00
|
|
|
'PhabricatorSetupCheckFacebook' => 'applications/config/check/PhabricatorSetupCheckFacebook.php',
|
2013-01-19 17:41:45 +01:00
|
|
|
'PhabricatorSetupCheckGD' => 'applications/config/check/PhabricatorSetupCheckGD.php',
|
2013-01-02 03:15:03 +01:00
|
|
|
'PhabricatorSetupCheckInvalidConfig' => 'applications/config/check/PhabricatorSetupCheckInvalidConfig.php',
|
2013-01-18 22:28:30 +01:00
|
|
|
'PhabricatorSetupCheckMail' => 'applications/config/check/PhabricatorSetupCheckMail.php',
|
2013-01-19 17:41:45 +01:00
|
|
|
'PhabricatorSetupCheckMySQL' => 'applications/config/check/PhabricatorSetupCheckMySQL.php',
|
2013-01-23 01:15:54 +01:00
|
|
|
'PhabricatorSetupCheckPHPConfig' => 'applications/config/check/PhabricatorSetupCheckPHPConfig.php',
|
2013-01-22 23:45:19 +01:00
|
|
|
'PhabricatorSetupCheckPath' => 'applications/config/check/PhabricatorSetupCheckPath.php',
|
2013-01-19 17:39:27 +01:00
|
|
|
'PhabricatorSetupCheckStorage' => 'applications/config/check/PhabricatorSetupCheckStorage.php',
|
2012-12-31 02:04:38 +01:00
|
|
|
'PhabricatorSetupCheckTimezone' => 'applications/config/check/PhabricatorSetupCheckTimezone.php',
|
2012-12-30 15:37:49 +01:00
|
|
|
'PhabricatorSetupIssue' => 'applications/config/issue/PhabricatorSetupIssue.php',
|
|
|
|
'PhabricatorSetupIssueView' => 'applications/config/view/PhabricatorSetupIssueView.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-08-15 19:45:06 +02:00
|
|
|
'PhabricatorSourceCodeView' => 'view/layout/PhabricatorSourceCodeView.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorStandardPageView' => 'view/page/PhabricatorStandardPageView.php',
|
|
|
|
'PhabricatorStatusController' => 'applications/status/PhabricatorStatusController.php',
|
|
|
|
'PhabricatorStorageFixtureScopeGuard' => 'infrastructure/testing/fixture/PhabricatorStorageFixtureScopeGuard.php',
|
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',
|
2012-10-05 22:18:05 +02:00
|
|
|
'PhabricatorSubscribableInterface' => 'applications/subscriptions/interface/PhabricatorSubscribableInterface.php',
|
|
|
|
'PhabricatorSubscribersQuery' => 'applications/subscriptions/query/PhabricatorSubscribersQuery.php',
|
|
|
|
'PhabricatorSubscriptionsEditController' => 'applications/subscriptions/controller/PhabricatorSubscriptionsEditController.php',
|
|
|
|
'PhabricatorSubscriptionsEditor' => 'applications/subscriptions/editor/PhabricatorSubscriptionsEditor.php',
|
|
|
|
'PhabricatorSubscriptionsUIEventListener' => 'applications/subscriptions/events/PhabricatorSubscriptionsUIEventListener.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorSymbolNameLinter' => 'infrastructure/lint/hook/PhabricatorSymbolNameLinter.php',
|
2012-07-02 19:44:37 +02:00
|
|
|
'PhabricatorSyntaxHighlighter' => 'infrastructure/markup/PhabricatorSyntaxHighlighter.php',
|
2013-01-10 18:56:36 +01:00
|
|
|
'PhabricatorSyntaxHighlightingConfigOptions' => 'applications/config/option/PhabricatorSyntaxHighlightingConfigOptions.php',
|
2012-11-24 15:47:06 +01:00
|
|
|
'PhabricatorTagExample' => 'applications/uiexample/examples/PhabricatorTagExample.php',
|
|
|
|
'PhabricatorTagView' => 'view/layout/PhabricatorTagView.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorTaskmasterDaemon' => 'infrastructure/daemon/workers/PhabricatorTaskmasterDaemon.php',
|
|
|
|
'PhabricatorTestCase' => 'infrastructure/testing/PhabricatorTestCase.php',
|
2012-11-01 19:30:23 +01:00
|
|
|
'PhabricatorTestWorker' => 'infrastructure/daemon/workers/__tests__/PhabricatorTestWorker.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-11-22 02:24:56 +01:00
|
|
|
'PhabricatorTimelineEventView' => 'view/layout/PhabricatorTimelineEventView.php',
|
|
|
|
'PhabricatorTimelineExample' => 'applications/uiexample/examples/PhabricatorTimelineExample.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorTimelineIterator' => 'infrastructure/daemon/timeline/cursor/PhabricatorTimelineIterator.php',
|
2012-11-22 02:24:56 +01:00
|
|
|
'PhabricatorTimelineView' => 'view/layout/PhabricatorTimelineView.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorTimer' => 'applications/countdown/storage/PhabricatorTimer.php',
|
|
|
|
'PhabricatorTransactionView' => 'view/layout/PhabricatorTransactionView.php',
|
2012-12-11 22:59:20 +01:00
|
|
|
'PhabricatorTransactions' => 'applications/transactions/constants/PhabricatorTransactions.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorTransformedFile' => 'applications/files/storage/PhabricatorTransformedFile.php',
|
2012-06-14 22:43:09 +02:00
|
|
|
'PhabricatorTranslation' => 'infrastructure/internationalization/PhabricatorTranslation.php',
|
2013-01-05 01:22:52 +01:00
|
|
|
'PhabricatorTranslationsConfigOptions' => 'applications/config/option/PhabricatorTranslationsConfigOptions.php',
|
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',
|
2012-08-01 21:36:19 +02:00
|
|
|
'PhabricatorTypeaheadResult' => 'applications/typeahead/storage/PhabricatorTypeaheadResult.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorUIExample' => 'applications/uiexample/examples/PhabricatorUIExample.php',
|
|
|
|
'PhabricatorUIExampleRenderController' => 'applications/uiexample/controller/PhabricatorUIExampleRenderController.php',
|
|
|
|
'PhabricatorUIListFilterExample' => 'applications/uiexample/examples/PhabricatorUIListFilterExample.php',
|
2012-06-14 00:00:24 +02:00
|
|
|
'PhabricatorUINotificationExample' => 'applications/uiexample/examples/PhabricatorUINotificationExample.php',
|
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',
|
|
|
|
'PhabricatorUserDAO' => 'applications/people/storage/PhabricatorUserDAO.php',
|
|
|
|
'PhabricatorUserEditor' => 'applications/people/PhabricatorUserEditor.php',
|
|
|
|
'PhabricatorUserEmail' => 'applications/people/storage/PhabricatorUserEmail.php',
|
2012-06-13 17:52:05 +02:00
|
|
|
'PhabricatorUserLDAPInfo' => 'applications/people/storage/PhabricatorUserLDAPInfo.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorUserLog' => 'applications/people/storage/PhabricatorUserLog.php',
|
|
|
|
'PhabricatorUserOAuthInfo' => 'applications/people/storage/PhabricatorUserOAuthInfo.php',
|
2012-08-13 21:37:18 +02:00
|
|
|
'PhabricatorUserPreferences' => 'applications/settings/storage/PhabricatorUserPreferences.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorUserProfile' => 'applications/people/storage/PhabricatorUserProfile.php',
|
2012-08-13 21:37:18 +02:00
|
|
|
'PhabricatorUserSSHKey' => 'applications/settings/storage/PhabricatorUserSSHKey.php',
|
Improve Search architecture
Summary:
The search indexing API has several problems right now:
- Always runs in-process.
- It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it.
- Being able to use the task queue will also make rebuilding indexes faster.
- Instead, make the API phid-oriented.
- No uniform indexing API.
- Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird.
- Instead, provide a uniform API.
- No uniform CLI.
- We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers.
- Instead, let indexers expose documents for indexing.
- Not application-oriented.
- All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world.
- Instead, move indexers to applications and load them with SymbolLoader.
Test Plan:
- `bin/search index`
- Indexed one revision, one task.
- Indexed `--type TASK`, `--type DREV`, etc., for all types.
- Indexed `--all`.
- Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it.
- Creating users is a pain; searched for a user after indexing.
- Creating commits is a pain; searched for a commit after indexing.
- Mocks aren't currently loadable in the result view, so their indexing is moot.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: 20after4, aran
Maniphest Tasks: T1991, T2104
Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
|
|
|
'PhabricatorUserSearchIndexer' => 'applications/people/search/PhabricatorUserSearchIndexer.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorUserStatus' => 'applications/people/storage/PhabricatorUserStatus.php',
|
2012-10-24 22:22:24 +02:00
|
|
|
'PhabricatorUserStatusInvalidEpochException' => 'applications/people/exception/PhabricatorUserStatusInvalidEpochException.php',
|
|
|
|
'PhabricatorUserStatusOverlapException' => 'applications/people/exception/PhabricatorUserStatusOverlapException.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorUserTestCase' => 'applications/people/storage/__tests__/PhabricatorUserTestCase.php',
|
|
|
|
'PhabricatorWorker' => 'infrastructure/daemon/workers/PhabricatorWorker.php',
|
2012-10-31 23:22:16 +01:00
|
|
|
'PhabricatorWorkerActiveTask' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerActiveTask.php',
|
|
|
|
'PhabricatorWorkerArchiveTask' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerArchiveTask.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorWorkerDAO' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerDAO.php',
|
2012-11-01 19:30:16 +01:00
|
|
|
'PhabricatorWorkerLeaseQuery' => 'infrastructure/daemon/workers/query/PhabricatorWorkerLeaseQuery.php',
|
2012-11-01 19:30:23 +01:00
|
|
|
'PhabricatorWorkerPermanentFailureException' => 'infrastructure/daemon/workers/exception/PhabricatorWorkerPermanentFailureException.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorWorkerTask' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerTask.php',
|
|
|
|
'PhabricatorWorkerTaskData' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerTaskData.php',
|
|
|
|
'PhabricatorWorkerTaskDetailController' => 'applications/daemon/controller/PhabricatorWorkerTaskDetailController.php',
|
|
|
|
'PhabricatorWorkerTaskUpdateController' => 'applications/daemon/controller/PhabricatorWorkerTaskUpdateController.php',
|
2012-11-01 19:30:23 +01:00
|
|
|
'PhabricatorWorkerTestCase' => 'infrastructure/daemon/workers/__tests__/PhabricatorWorkerTestCase.php',
|
2012-12-21 21:12:26 +01:00
|
|
|
'PhabricatorXHPASTViewController' => 'applications/phpast/controller/PhabricatorXHPASTViewController.php',
|
|
|
|
'PhabricatorXHPASTViewDAO' => 'applications/phpast/storage/PhabricatorXHPASTViewDAO.php',
|
|
|
|
'PhabricatorXHPASTViewFrameController' => 'applications/phpast/controller/PhabricatorXHPASTViewFrameController.php',
|
|
|
|
'PhabricatorXHPASTViewFramesetController' => 'applications/phpast/controller/PhabricatorXHPASTViewFramesetController.php',
|
|
|
|
'PhabricatorXHPASTViewInputController' => 'applications/phpast/controller/PhabricatorXHPASTViewInputController.php',
|
|
|
|
'PhabricatorXHPASTViewPanelController' => 'applications/phpast/controller/PhabricatorXHPASTViewPanelController.php',
|
|
|
|
'PhabricatorXHPASTViewParseTree' => 'applications/phpast/storage/PhabricatorXHPASTViewParseTree.php',
|
|
|
|
'PhabricatorXHPASTViewRunController' => 'applications/phpast/controller/PhabricatorXHPASTViewRunController.php',
|
|
|
|
'PhabricatorXHPASTViewStreamController' => 'applications/phpast/controller/PhabricatorXHPASTViewStreamController.php',
|
|
|
|
'PhabricatorXHPASTViewTreeController' => 'applications/phpast/controller/PhabricatorXHPASTViewTreeController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorXHProfController' => 'applications/xhprof/controller/PhabricatorXHProfController.php',
|
2012-08-25 00:14:38 +02:00
|
|
|
'PhabricatorXHProfDAO' => 'applications/xhprof/storage/PhabricatorXHProfDAO.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhabricatorXHProfProfileController' => 'applications/xhprof/controller/PhabricatorXHProfProfileController.php',
|
|
|
|
'PhabricatorXHProfProfileSymbolView' => 'applications/xhprof/view/PhabricatorXHProfProfileSymbolView.php',
|
|
|
|
'PhabricatorXHProfProfileTopLevelView' => 'applications/xhprof/view/PhabricatorXHProfProfileTopLevelView.php',
|
|
|
|
'PhabricatorXHProfProfileView' => 'applications/xhprof/view/PhabricatorXHProfProfileView.php',
|
2012-08-25 00:14:38 +02:00
|
|
|
'PhabricatorXHProfSample' => 'applications/xhprof/storage/PhabricatorXHProfSample.php',
|
|
|
|
'PhabricatorXHProfSampleListController' => 'applications/xhprof/controller/PhabricatorXHProfSampleListController.php',
|
|
|
|
'PhabricatorXHProfSampleListView' => 'applications/xhprof/view/PhabricatorXHProfSampleListView.php',
|
Move skins toward modularization
Summary:
Two high-level things happening here:
- We no longer ever need to put meta-UI (content creation, editing, notices, etc.) on live blog views, since this is all in Phame now. I pulled this out.
- On the other hand, I pushed more routing/control logic into Skins and made the root skin a Controller instead of a View. This simplifies some of the code above skins, and the theory behind this is that it gives us greater flexibility to, e.g., put a glue layer between Phame and Wordpress templates or whatever else, and allows skins to handle routing and thus add pages like "About" or "Bio".
- I added a basic skin below the root skin which is more like the old root skin and has standard rendering hooks.
- "Ten Eleven" is a play on the popular (default?) Wordpress themes called "Twenty Ten", "Twenty Eleven" and "Twenty Twelve".
Test Plan: Viewed live blog and live posts. They aren't pretty, but they don't have extraneous resources.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T1373
Differential Revision: https://secure.phabricator.com/D3714
2012-10-17 17:36:25 +02:00
|
|
|
'PhameBasicBlogSkin' => 'applications/phame/skins/PhameBasicBlogSkin.php',
|
2012-10-17 17:36:48 +02:00
|
|
|
'PhameBasicTemplateBlogSkin' => 'applications/phame/skins/PhameBasicTemplateBlogSkin.php',
|
2012-07-19 18:03:10 +02:00
|
|
|
'PhameBlog' => 'applications/phame/storage/PhameBlog.php',
|
|
|
|
'PhameBlogDeleteController' => 'applications/phame/controller/blog/PhameBlogDeleteController.php',
|
|
|
|
'PhameBlogEditController' => 'applications/phame/controller/blog/PhameBlogEditController.php',
|
2013-01-09 04:53:34 +01:00
|
|
|
'PhameBlogFeedController' => 'applications/phame/controller/blog/PhameBlogFeedController.php',
|
2012-10-15 23:50:12 +02:00
|
|
|
'PhameBlogListController' => 'applications/phame/controller/blog/PhameBlogListController.php',
|
|
|
|
'PhameBlogLiveController' => 'applications/phame/controller/blog/PhameBlogLiveController.php',
|
2012-07-19 18:03:10 +02:00
|
|
|
'PhameBlogQuery' => 'applications/phame/query/PhameBlogQuery.php',
|
Move skins toward modularization
Summary:
Two high-level things happening here:
- We no longer ever need to put meta-UI (content creation, editing, notices, etc.) on live blog views, since this is all in Phame now. I pulled this out.
- On the other hand, I pushed more routing/control logic into Skins and made the root skin a Controller instead of a View. This simplifies some of the code above skins, and the theory behind this is that it gives us greater flexibility to, e.g., put a glue layer between Phame and Wordpress templates or whatever else, and allows skins to handle routing and thus add pages like "About" or "Bio".
- I added a basic skin below the root skin which is more like the old root skin and has standard rendering hooks.
- "Ten Eleven" is a play on the popular (default?) Wordpress themes called "Twenty Ten", "Twenty Eleven" and "Twenty Twelve".
Test Plan: Viewed live blog and live posts. They aren't pretty, but they don't have extraneous resources.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T1373
Differential Revision: https://secure.phabricator.com/D3714
2012-10-17 17:36:25 +02:00
|
|
|
'PhameBlogSkin' => 'applications/phame/skins/PhameBlogSkin.php',
|
2012-07-19 18:03:10 +02:00
|
|
|
'PhameBlogViewController' => 'applications/phame/controller/blog/PhameBlogViewController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhameController' => 'applications/phame/controller/PhameController.php',
|
|
|
|
'PhameDAO' => 'applications/phame/storage/PhameDAO.php',
|
|
|
|
'PhamePost' => 'applications/phame/storage/PhamePost.php',
|
|
|
|
'PhamePostDeleteController' => 'applications/phame/controller/post/PhamePostDeleteController.php',
|
|
|
|
'PhamePostEditController' => 'applications/phame/controller/post/PhamePostEditController.php',
|
2012-10-15 23:50:45 +02:00
|
|
|
'PhamePostFramedController' => 'applications/phame/controller/post/PhamePostFramedController.php',
|
2012-10-15 23:50:37 +02:00
|
|
|
'PhamePostListController' => 'applications/phame/controller/post/PhamePostListController.php',
|
2012-10-15 23:50:45 +02:00
|
|
|
'PhamePostNewController' => 'applications/phame/controller/post/PhamePostNewController.php',
|
2012-10-15 23:51:30 +02:00
|
|
|
'PhamePostNotLiveController' => 'applications/phame/controller/post/PhamePostNotLiveController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhamePostPreviewController' => 'applications/phame/controller/post/PhamePostPreviewController.php',
|
2012-10-15 23:50:45 +02:00
|
|
|
'PhamePostPublishController' => 'applications/phame/controller/post/PhamePostPublishController.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhamePostQuery' => 'applications/phame/query/PhamePostQuery.php',
|
2012-10-15 23:50:45 +02:00
|
|
|
'PhamePostUnpublishController' => 'applications/phame/controller/post/PhamePostUnpublishController.php',
|
Move skins toward modularization
Summary:
Two high-level things happening here:
- We no longer ever need to put meta-UI (content creation, editing, notices, etc.) on live blog views, since this is all in Phame now. I pulled this out.
- On the other hand, I pushed more routing/control logic into Skins and made the root skin a Controller instead of a View. This simplifies some of the code above skins, and the theory behind this is that it gives us greater flexibility to, e.g., put a glue layer between Phame and Wordpress templates or whatever else, and allows skins to handle routing and thus add pages like "About" or "Bio".
- I added a basic skin below the root skin which is more like the old root skin and has standard rendering hooks.
- "Ten Eleven" is a play on the popular (default?) Wordpress themes called "Twenty Ten", "Twenty Eleven" and "Twenty Twelve".
Test Plan: Viewed live blog and live posts. They aren't pretty, but they don't have extraneous resources.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T1373
Differential Revision: https://secure.phabricator.com/D3714
2012-10-17 17:36:25 +02:00
|
|
|
'PhamePostView' => 'applications/phame/view/PhamePostView.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'PhamePostViewController' => 'applications/phame/controller/post/PhamePostViewController.php',
|
2012-10-17 17:37:05 +02:00
|
|
|
'PhameResourceController' => 'applications/phame/controller/PhameResourceController.php',
|
2012-10-17 17:36:48 +02:00
|
|
|
'PhameSkinSpecification' => 'applications/phame/skins/PhameSkinSpecification.php',
|
2012-11-22 02:27:44 +01:00
|
|
|
'PholioConstants' => 'applications/pholio/constants/PholioConstants.php',
|
Add very basic scaffolding for Pholio
Summary:
I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc.
Basic hierarchy is:
- **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas".
- **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed.
- **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits.
- **PixelComment**: Equivalent of an inline comment.
Test Plan: Created a fake object and viewed it.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: aran, davidreuss
Maniphest Tasks: T2097
Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
|
|
|
'PholioController' => 'applications/pholio/controller/PholioController.php',
|
|
|
|
'PholioDAO' => 'applications/pholio/storage/PholioDAO.php',
|
|
|
|
'PholioImage' => 'applications/pholio/storage/PholioImage.php',
|
|
|
|
'PholioMock' => 'applications/pholio/storage/PholioMock.php',
|
2012-11-22 02:27:20 +01:00
|
|
|
'PholioMockCommentController' => 'applications/pholio/controller/PholioMockCommentController.php',
|
2012-11-22 02:23:28 +01:00
|
|
|
'PholioMockEditController' => 'applications/pholio/controller/PholioMockEditController.php',
|
Add very basic scaffolding for Pholio
Summary:
I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc.
Basic hierarchy is:
- **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas".
- **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed.
- **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits.
- **PixelComment**: Equivalent of an inline comment.
Test Plan: Created a fake object and viewed it.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: aran, davidreuss
Maniphest Tasks: T2097
Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
|
|
|
'PholioMockEditor' => 'applications/pholio/editor/PholioMockEditor.php',
|
2013-01-20 18:29:34 +01:00
|
|
|
'PholioMockImagesView' => 'applications/pholio/view/PholioMockImagesView.php',
|
Add very basic scaffolding for Pholio
Summary:
I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc.
Basic hierarchy is:
- **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas".
- **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed.
- **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits.
- **PixelComment**: Equivalent of an inline comment.
Test Plan: Created a fake object and viewed it.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: aran, davidreuss
Maniphest Tasks: T2097
Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
|
|
|
'PholioMockListController' => 'applications/pholio/controller/PholioMockListController.php',
|
|
|
|
'PholioMockQuery' => 'applications/pholio/query/PholioMockQuery.php',
|
|
|
|
'PholioMockViewController' => 'applications/pholio/controller/PholioMockViewController.php',
|
2012-11-22 02:39:46 +01:00
|
|
|
'PholioReplyHandler' => 'applications/pholio/mail/PholioReplyHandler.php',
|
2012-12-21 23:21:50 +01:00
|
|
|
'PholioSearchIndexer' => 'applications/pholio/search/PholioSearchIndexer.php',
|
Add very basic scaffolding for Pholio
Summary:
I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc.
Basic hierarchy is:
- **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas".
- **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed.
- **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits.
- **PixelComment**: Equivalent of an inline comment.
Test Plan: Created a fake object and viewed it.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: aran, davidreuss
Maniphest Tasks: T2097
Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
|
|
|
'PholioTransaction' => 'applications/pholio/storage/PholioTransaction.php',
|
2012-12-11 22:59:20 +01:00
|
|
|
'PholioTransactionComment' => 'applications/pholio/storage/PholioTransactionComment.php',
|
2012-11-22 02:27:20 +01:00
|
|
|
'PholioTransactionQuery' => 'applications/pholio/query/PholioTransactionQuery.php',
|
2012-11-22 02:27:44 +01:00
|
|
|
'PholioTransactionType' => 'applications/pholio/constants/PholioTransactionType.php',
|
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',
|
2012-11-10 00:08:37 +01:00
|
|
|
'PhrictionNewController' => 'applications/phriction/controller/PhrictionNewController.php',
|
Improve Search architecture
Summary:
The search indexing API has several problems right now:
- Always runs in-process.
- It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it.
- Being able to use the task queue will also make rebuilding indexes faster.
- Instead, make the API phid-oriented.
- No uniform indexing API.
- Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird.
- Instead, provide a uniform API.
- No uniform CLI.
- We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers.
- Instead, let indexers expose documents for indexing.
- Not application-oriented.
- All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world.
- Instead, move indexers to applications and load them with SymbolLoader.
Test Plan:
- `bin/search index`
- Indexed one revision, one task.
- Indexed `--type TASK`, `--type DREV`, etc., for all types.
- Indexed `--all`.
- Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it.
- Creating users is a pain; searched for a user after indexing.
- Creating commits is a pain; searched for a commit after indexing.
- Mocks aren't currently loadable in the result view, so their indexing is moot.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: 20after4, aran
Maniphest Tasks: T1991, T2104
Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
|
|
|
'PhrictionSearchIndexer' => 'applications/phriction/search/PhrictionSearchIndexer.php',
|
2012-08-10 19:44:04 +02:00
|
|
|
'PonderAddAnswerView' => 'applications/ponder/view/PonderAddAnswerView.php',
|
adding comments to ponder
Summary: This is pretty spartan, but it does the job.
Test Plan:
Patch, update storage, add some comment
to your favorite question or answer.
Reviewers: nh, vrana, epriestley
Reviewed By: epriestley
CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7
Maniphest Tasks: T1645
Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
|
|
|
'PonderAddCommentView' => 'applications/ponder/view/PonderAddCommentView.php',
|
2012-08-10 19:44:04 +02:00
|
|
|
'PonderAnswer' => 'applications/ponder/storage/PonderAnswer.php',
|
|
|
|
'PonderAnswerEditor' => 'applications/ponder/editor/PonderAnswerEditor.php',
|
|
|
|
'PonderAnswerListView' => 'applications/ponder/view/PonderAnswerListView.php',
|
|
|
|
'PonderAnswerPreviewController' => 'applications/ponder/controller/PonderAnswerPreviewController.php',
|
|
|
|
'PonderAnswerQuery' => 'applications/ponder/query/PonderAnswerQuery.php',
|
|
|
|
'PonderAnswerSaveController' => 'applications/ponder/controller/PonderAnswerSaveController.php',
|
|
|
|
'PonderAnswerViewController' => 'applications/ponder/controller/PonderAnswerViewController.php',
|
2012-10-08 23:47:21 +02:00
|
|
|
'PonderAnsweredMail' => 'applications/ponder/mail/PonderAnsweredMail.php',
|
adding comments to ponder
Summary: This is pretty spartan, but it does the job.
Test Plan:
Patch, update storage, add some comment
to your favorite question or answer.
Reviewers: nh, vrana, epriestley
Reviewed By: epriestley
CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7
Maniphest Tasks: T1645
Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
|
|
|
'PonderComment' => 'applications/ponder/storage/PonderComment.php',
|
2012-10-07 23:35:01 +02:00
|
|
|
'PonderCommentEditor' => 'applications/ponder/editor/PonderCommentEditor.php',
|
adding comments to ponder
Summary: This is pretty spartan, but it does the job.
Test Plan:
Patch, update storage, add some comment
to your favorite question or answer.
Reviewers: nh, vrana, epriestley
Reviewed By: epriestley
CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7
Maniphest Tasks: T1645
Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
|
|
|
'PonderCommentListView' => 'applications/ponder/view/PonderCommentListView.php',
|
2012-10-08 23:47:21 +02:00
|
|
|
'PonderCommentMail' => 'applications/ponder/mail/PonderCommentMail.php',
|
adding comments to ponder
Summary: This is pretty spartan, but it does the job.
Test Plan:
Patch, update storage, add some comment
to your favorite question or answer.
Reviewers: nh, vrana, epriestley
Reviewed By: epriestley
CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7
Maniphest Tasks: T1645
Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
|
|
|
'PonderCommentQuery' => 'applications/ponder/query/PonderCommentQuery.php',
|
|
|
|
'PonderCommentSaveController' => 'applications/ponder/controller/PonderCommentSaveController.php',
|
2012-08-10 19:44:04 +02:00
|
|
|
'PonderConstants' => 'applications/ponder/PonderConstants.php',
|
|
|
|
'PonderController' => 'applications/ponder/controller/PonderController.php',
|
|
|
|
'PonderDAO' => 'applications/ponder/storage/PonderDAO.php',
|
|
|
|
'PonderFeedController' => 'applications/ponder/controller/PonderFeedController.php',
|
2012-10-08 23:47:21 +02:00
|
|
|
'PonderMail' => 'applications/ponder/mail/PonderMail.php',
|
|
|
|
'PonderMentionMail' => 'applications/ponder/mail/PonderMentionMail.php',
|
adding comments to ponder
Summary: This is pretty spartan, but it does the job.
Test Plan:
Patch, update storage, add some comment
to your favorite question or answer.
Reviewers: nh, vrana, epriestley
Reviewed By: epriestley
CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7
Maniphest Tasks: T1645
Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
|
|
|
'PonderPostBodyView' => 'applications/ponder/view/PonderPostBodyView.php',
|
2012-08-10 19:44:04 +02:00
|
|
|
'PonderQuestion' => 'applications/ponder/storage/PonderQuestion.php',
|
|
|
|
'PonderQuestionAskController' => 'applications/ponder/controller/PonderQuestionAskController.php',
|
|
|
|
'PonderQuestionDetailView' => 'applications/ponder/view/PonderQuestionDetailView.php',
|
2012-10-07 23:35:01 +02:00
|
|
|
'PonderQuestionEditor' => 'applications/ponder/editor/PonderQuestionEditor.php',
|
2012-08-10 19:44:04 +02:00
|
|
|
'PonderQuestionPreviewController' => 'applications/ponder/controller/PonderQuestionPreviewController.php',
|
|
|
|
'PonderQuestionQuery' => 'applications/ponder/query/PonderQuestionQuery.php',
|
|
|
|
'PonderQuestionSummaryView' => 'applications/ponder/view/PonderQuestionSummaryView.php',
|
|
|
|
'PonderQuestionViewController' => 'applications/ponder/controller/PonderQuestionViewController.php',
|
2012-10-08 23:47:21 +02:00
|
|
|
'PonderReplyHandler' => 'applications/ponder/PonderReplyHandler.php',
|
2012-08-10 19:44:04 +02:00
|
|
|
'PonderRuleQuestion' => 'infrastructure/markup/rule/PonderRuleQuestion.php',
|
Improve Search architecture
Summary:
The search indexing API has several problems right now:
- Always runs in-process.
- It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it.
- Being able to use the task queue will also make rebuilding indexes faster.
- Instead, make the API phid-oriented.
- No uniform indexing API.
- Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird.
- Instead, provide a uniform API.
- No uniform CLI.
- We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers.
- Instead, let indexers expose documents for indexing.
- Not application-oriented.
- All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world.
- Instead, move indexers to applications and load them with SymbolLoader.
Test Plan:
- `bin/search index`
- Indexed one revision, one task.
- Indexed `--type TASK`, `--type DREV`, etc., for all types.
- Indexed `--all`.
- Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it.
- Creating users is a pain; searched for a user after indexing.
- Creating commits is a pain; searched for a commit after indexing.
- Mocks aren't currently loadable in the result view, so their indexing is moot.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: 20after4, aran
Maniphest Tasks: T1991, T2104
Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
|
|
|
'PonderSearchIndexer' => 'applications/ponder/search/PonderSearchIndexer.php',
|
2012-08-10 19:44:04 +02:00
|
|
|
'PonderUserProfileView' => 'applications/ponder/view/PonderUserProfileView.php',
|
|
|
|
'PonderVotableInterface' => 'applications/ponder/storage/PonderVotableInterface.php',
|
|
|
|
'PonderVotableView' => 'applications/ponder/view/PonderVotableView.php',
|
|
|
|
'PonderVoteEditor' => 'applications/ponder/editor/PonderVoteEditor.php',
|
|
|
|
'PonderVoteSaveController' => 'applications/ponder/controller/PonderVoteSaveController.php',
|
2012-07-26 21:01:47 +02:00
|
|
|
'QueryFormattingTestCase' => 'infrastructure/storage/__tests__/QueryFormattingTestCase.php',
|
2011-01-16 22:51:39 +01:00
|
|
|
),
|
|
|
|
'function' =>
|
|
|
|
array(
|
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',
|
2013-01-31 18:05:26 +01:00
|
|
|
'javelin_tag' => 'infrastructure/javelin/markup.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'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',
|
2012-06-01 21:39:29 +02:00
|
|
|
'phabricator_format_relative_time_detailed' => 'view/viewutils.php',
|
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',
|
2012-10-23 04:06:56 +02:00
|
|
|
'phabricator_render_form_magic' => 'infrastructure/javelin/markup.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'phabricator_time' => 'view/viewutils.php',
|
2012-12-11 23:00:21 +01:00
|
|
|
'phid_get_subtype' => 'applications/phid/utils.php',
|
2012-06-01 21:10:26 +02:00
|
|
|
'phid_get_type' => 'applications/phid/utils.php',
|
|
|
|
'phid_group_by_type' => 'applications/phid/utils.php',
|
|
|
|
'require_celerity_resource' => 'infrastructure/celerity/api.php',
|
2011-01-16 22:51:39 +01:00
|
|
|
),
|
2012-05-30 23:26:29 +02:00
|
|
|
'xmap' =>
|
2011-01-16 22:51:39 +01:00
|
|
|
array(
|
2011-05-09 10:10:40 +02:00
|
|
|
'Aphront304Response' => 'AphrontResponse',
|
2011-01-30 21:08:40 +01:00
|
|
|
'Aphront400Response' => 'AphrontResponse',
|
2012-11-29 08:57:13 +01:00
|
|
|
'Aphront403Response' => 'AphrontHTMLResponse',
|
|
|
|
'Aphront404Response' => 'AphrontHTMLResponse',
|
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',
|
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',
|
2012-12-19 01:11:07 +01:00
|
|
|
'AphrontController' => 'Phobject',
|
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',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontDefaultApplicationConfiguration' => 'AphrontApplicationConfiguration',
|
|
|
|
'AphrontDialogResponse' => 'AphrontResponse',
|
|
|
|
'AphrontDialogView' => 'AphrontView',
|
|
|
|
'AphrontErrorView' => 'AphrontView',
|
2012-05-30 23:26:29 +02:00
|
|
|
'AphrontException' => 'Exception',
|
2011-01-23 03:33:00 +01:00
|
|
|
'AphrontFileResponse' => 'AphrontResponse',
|
2011-01-26 02:40:21 +01:00
|
|
|
'AphrontFormCheckboxControl' => 'AphrontFormControl',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontFormControl' => 'AphrontView',
|
2012-04-04 21:14:10 +02:00
|
|
|
'AphrontFormDateControl' => 'AphrontFormControl',
|
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',
|
2011-01-23 03:33:00 +01:00
|
|
|
'AphrontFormFileControl' => 'AphrontFormControl',
|
2012-06-26 17:14:15 +02:00
|
|
|
'AphrontFormImageControl' => 'AphrontFormControl',
|
2012-03-16 01:10:19 +01:00
|
|
|
'AphrontFormInsetView' => 'AphrontView',
|
2011-06-10 00:28:29 +02:00
|
|
|
'AphrontFormLayoutView' => 'AphrontView',
|
2011-01-24 20:36:53 +01:00
|
|
|
'AphrontFormMarkupControl' => 'AphrontFormControl',
|
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',
|
2011-01-31 20:55:26 +01:00
|
|
|
'AphrontFormRecaptchaControl' => 'AphrontFormControl',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontFormSelectControl' => 'AphrontFormControl',
|
2011-01-23 03:33:00 +01:00
|
|
|
'AphrontFormStaticControl' => 'AphrontFormControl',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontFormSubmitControl' => 'AphrontFormControl',
|
|
|
|
'AphrontFormTextAreaControl' => 'AphrontFormControl',
|
|
|
|
'AphrontFormTextControl' => 'AphrontFormControl',
|
2011-04-04 00:50:06 +02:00
|
|
|
'AphrontFormToggleButtonsControl' => 'AphrontFormControl',
|
2011-01-25 22:48:05 +01:00
|
|
|
'AphrontFormTokenizerControl' => 'AphrontFormControl',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontFormView' => 'AphrontView',
|
2012-11-29 08:57:13 +01:00
|
|
|
'AphrontHTMLResponse' => 'AphrontResponse',
|
2012-02-06 18:59:34 +01:00
|
|
|
'AphrontHTTPSinkTestCase' => 'PhabricatorTestCase',
|
2011-02-20 21:50:28 +01:00
|
|
|
'AphrontHeadsupActionListView' => 'AphrontView',
|
|
|
|
'AphrontHeadsupActionView' => 'AphrontView',
|
2012-03-30 23:12:10 +02:00
|
|
|
'AphrontHeadsupView' => 'AphrontView',
|
2011-04-30 19:11:41 +02:00
|
|
|
'AphrontIsolatedDatabaseConnectionTestCase' => 'PhabricatorTestCase',
|
2012-02-06 18:59:34 +01:00
|
|
|
'AphrontIsolatedHTTPSink' => 'AphrontHTTPSink',
|
2012-02-14 23:51:51 +01:00
|
|
|
'AphrontJSONResponse' => 'AphrontResponse',
|
2011-09-07 23:01:13 +02:00
|
|
|
'AphrontJavelinView' => 'AphrontView',
|
2011-06-08 20:53:10 +02:00
|
|
|
'AphrontKeyboardShortcutsAvailableView' => 'AphrontView',
|
2011-04-04 00:50:06 +02:00
|
|
|
'AphrontListFilterView' => 'AphrontView',
|
2012-02-15 01:23:53 +01:00
|
|
|
'AphrontMiniPanelView' => 'AphrontView',
|
2012-05-10 00:56:37 +02:00
|
|
|
'AphrontMoreView' => 'AphrontView',
|
2012-02-07 23:58:37 +01:00
|
|
|
'AphrontMySQLDatabaseConnectionTestCase' => 'PhabricatorTestCase',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontNullView' => 'AphrontView',
|
2012-02-06 18:59:34 +01:00
|
|
|
'AphrontPHPHTTPSink' => 'AphrontHTTPSink',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontPageView' => 'AphrontView',
|
2011-04-01 02:06:33 +02:00
|
|
|
'AphrontPagerView' => 'AphrontView',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontPanelView' => 'AphrontView',
|
2012-01-15 20:06:13 +01:00
|
|
|
'AphrontPlainTextResponse' => 'AphrontResponse',
|
2012-03-13 05:39:05 +01:00
|
|
|
'AphrontProxyResponse' => 'AphrontResponse',
|
2011-01-26 22:21:12 +01:00
|
|
|
'AphrontRedirectException' => 'AphrontException',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontRedirectResponse' => 'AphrontResponse',
|
2011-05-16 20:43:39 +02:00
|
|
|
'AphrontReloadResponse' => 'AphrontRedirectResponse',
|
2011-01-30 18:15:01 +01:00
|
|
|
'AphrontRequestFailureView' => 'AphrontView',
|
2012-01-04 06:57:45 +01:00
|
|
|
'AphrontRequestTestCase' => 'PhabricatorTestCase',
|
2011-12-17 02:08:18 +01:00
|
|
|
'AphrontSideNavFilterView' => 'AphrontView',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontTableView' => 'AphrontView',
|
2013-01-16 19:50:41 +01:00
|
|
|
'AphrontTagView' => 'AphrontView',
|
2011-03-23 04:41:02 +01:00
|
|
|
'AphrontTokenizerTemplateView' => 'AphrontView',
|
2011-04-04 04:20:47 +02:00
|
|
|
'AphrontTypeaheadTemplateView' => 'AphrontView',
|
2012-04-24 03:36:25 +02:00
|
|
|
'AphrontUsageException' => 'AphrontException',
|
2012-12-19 01:11:07 +01:00
|
|
|
'AphrontView' => 'Phobject',
|
2012-11-29 08:57:13 +01:00
|
|
|
'AphrontWebpageResponse' => 'AphrontHTMLResponse',
|
2013-02-05 22:46:02 +01:00
|
|
|
'AuditPeopleMenuEventListener' => 'PhutilEventListener',
|
2012-10-17 17:37:05 +02:00
|
|
|
'CelerityPhabricatorResourceController' => 'CelerityResourceController',
|
Make CelerityController extend PhabricatorController
Summary:
Currently, CelerityController extends AphrontController, not PhabricatorController. (I think I imagined Celerity being somewhat stand-alone and didn't want to create a dependency.)
This creates a concrete problem if a static resource is missing, since we throw an exception, but the higher-level exception handlers depend on the User existing in order to show an appropriate response page. This is the only controller which doesn't extend PhabricatorController, and it doesn't seem worthwhile to make a weird edge case out of it.
Specific repro case is:
- Remove `externals/javelin/` (or forget to run `git submodule update --init`).
- Load a static resource.
- Get "[Rendering Exception] Argument 1 passed to PhabricatorMainMenuView::setUser() must be an instance of PhabricatorUser, null given, called in /services/apache/phabricator/phabricator/src/view/page/PhabricatorStandardPageView.php on line 435 and defined"
Test Plan:
- Followed above steps, no more fataling.
- Verified this is the only weird controller.
Reviewers: voldern, vrana, btrahan
Reviewed By: voldern
CC: aran
Differential Revision: https://secure.phabricator.com/D3389
2012-08-28 22:46:35 +02:00
|
|
|
'CelerityResourceController' => 'PhabricatorController',
|
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',
|
2011-09-16 20:42:45 +02:00
|
|
|
'ConduitAPI_arcanist_Method' => 'ConduitAPIMethod',
|
|
|
|
'ConduitAPI_arcanist_projectinfo_Method' => 'ConduitAPI_arcanist_Method',
|
2012-03-07 00:12:27 +01:00
|
|
|
'ConduitAPI_audit_Method' => 'ConduitAPIMethod',
|
|
|
|
'ConduitAPI_audit_query_Method' => 'ConduitAPI_audit_Method',
|
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',
|
2011-01-24 20:30:10 +01:00
|
|
|
'ConduitAPI_conduit_connect_Method' => 'ConduitAPIMethod',
|
2011-06-14 21:17:14 +02:00
|
|
|
'ConduitAPI_conduit_getcertificate_Method' => 'ConduitAPIMethod',
|
2011-02-19 07:36:32 +01:00
|
|
|
'ConduitAPI_conduit_ping_Method' => 'ConduitAPIMethod',
|
2013-01-20 01:37:06 +01:00
|
|
|
'ConduitAPI_conduit_query_Method' => 'ConduitAPIMethod',
|
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',
|
2012-06-20 21:35:04 +02:00
|
|
|
'ConduitAPI_differential_Method' => 'ConduitAPIMethod',
|
2012-04-24 02:40:57 +02:00
|
|
|
'ConduitAPI_differential_close_Method' => 'ConduitAPIMethod',
|
2011-11-18 18:16:40 +01:00
|
|
|
'ConduitAPI_differential_createcomment_Method' => 'ConduitAPIMethod',
|
2011-01-24 20:01:53 +01:00
|
|
|
'ConduitAPI_differential_creatediff_Method' => 'ConduitAPIMethod',
|
2012-07-19 05:01:23 +02:00
|
|
|
'ConduitAPI_differential_createinline_Method' => 'ConduitAPI_differential_Method',
|
2012-06-20 21:35:04 +02:00
|
|
|
'ConduitAPI_differential_createrawdiff_Method' => 'ConduitAPI_differential_Method',
|
2011-02-06 22:49:23 +01:00
|
|
|
'ConduitAPI_differential_createrevision_Method' => 'ConduitAPIMethod',
|
2011-02-06 23:43:06 +01:00
|
|
|
'ConduitAPI_differential_find_Method' => 'ConduitAPIMethod',
|
2012-06-15 02:09:24 +02:00
|
|
|
'ConduitAPI_differential_finishpostponedlinters_Method' => 'ConduitAPIMethod',
|
2011-04-21 00:29:02 +02:00
|
|
|
'ConduitAPI_differential_getalldiffs_Method' => 'ConduitAPIMethod',
|
2011-02-09 18:41:26 +01:00
|
|
|
'ConduitAPI_differential_getcommitmessage_Method' => 'ConduitAPIMethod',
|
2011-02-19 07:28:03 +01:00
|
|
|
'ConduitAPI_differential_getcommitpaths_Method' => 'ConduitAPIMethod',
|
2011-02-19 07:15:28 +01:00
|
|
|
'ConduitAPI_differential_getdiff_Method' => 'ConduitAPIMethod',
|
2011-04-21 01:38:16 +02:00
|
|
|
'ConduitAPI_differential_getrevision_Method' => 'ConduitAPIMethod',
|
2012-07-19 05:01:23 +02:00
|
|
|
'ConduitAPI_differential_getrevisioncomments_Method' => 'ConduitAPI_differential_Method',
|
2011-04-20 01:24:45 +02:00
|
|
|
'ConduitAPI_differential_getrevisionfeedback_Method' => 'ConduitAPIMethod',
|
2011-02-09 18:48:26 +01:00
|
|
|
'ConduitAPI_differential_markcommitted_Method' => 'ConduitAPIMethod',
|
2011-02-06 22:42:00 +01:00
|
|
|
'ConduitAPI_differential_parsecommitmessage_Method' => 'ConduitAPIMethod',
|
2011-12-02 01:57:06 +01:00
|
|
|
'ConduitAPI_differential_query_Method' => 'ConduitAPIMethod',
|
2011-01-24 21:07:34 +01:00
|
|
|
'ConduitAPI_differential_setdiffproperty_Method' => 'ConduitAPIMethod',
|
2011-02-06 23:00:32 +01:00
|
|
|
'ConduitAPI_differential_updaterevision_Method' => 'ConduitAPIMethod',
|
2011-06-09 01:16:59 +02:00
|
|
|
'ConduitAPI_differential_updateunitresults_Method' => 'ConduitAPIMethod',
|
2011-12-21 18:39:33 +01:00
|
|
|
'ConduitAPI_diffusion_findsymbols_Method' => 'ConduitAPIMethod',
|
2011-04-14 01:39:08 +02:00
|
|
|
'ConduitAPI_diffusion_getcommits_Method' => 'ConduitAPIMethod',
|
2012-11-09 02:16:23 +01:00
|
|
|
'ConduitAPI_diffusion_getlintmessages_Method' => 'ConduitAPIMethod',
|
2011-05-20 00:36:17 +02:00
|
|
|
'ConduitAPI_diffusion_getrecentcommitsbypath_Method' => 'ConduitAPIMethod',
|
2011-07-05 17:35:18 +02:00
|
|
|
'ConduitAPI_feed_publish_Method' => 'ConduitAPIMethod',
|
2012-02-03 01:44:05 +01:00
|
|
|
'ConduitAPI_feed_query_Method' => 'ConduitAPIMethod',
|
2011-05-21 18:53:50 +02:00
|
|
|
'ConduitAPI_file_download_Method' => 'ConduitAPIMethod',
|
2011-07-29 19:00:16 +02:00
|
|
|
'ConduitAPI_file_info_Method' => 'ConduitAPIMethod',
|
2011-01-24 18:00:29 +01:00
|
|
|
'ConduitAPI_file_upload_Method' => 'ConduitAPIMethod',
|
2012-03-28 01:22:40 +02:00
|
|
|
'ConduitAPI_flag_Method' => 'ConduitAPIMethod',
|
2012-08-02 21:25:01 +02:00
|
|
|
'ConduitAPI_flag_delete_Method' => 'ConduitAPI_flag_Method',
|
2012-08-03 20:41:33 +02:00
|
|
|
'ConduitAPI_flag_edit_Method' => 'ConduitAPI_flag_Method',
|
2012-03-28 01:22:40 +02:00
|
|
|
'ConduitAPI_flag_query_Method' => 'ConduitAPI_flag_Method',
|
2012-03-09 21:40:03 +01:00
|
|
|
'ConduitAPI_macro_Method' => 'ConduitAPIMethod',
|
|
|
|
'ConduitAPI_macro_query_Method' => 'ConduitAPI_macro_Method',
|
2011-08-18 00:19:48 +02:00
|
|
|
'ConduitAPI_maniphest_Method' => 'ConduitAPIMethod',
|
|
|
|
'ConduitAPI_maniphest_createtask_Method' => 'ConduitAPI_maniphest_Method',
|
2012-06-29 18:17:19 +02:00
|
|
|
'ConduitAPI_maniphest_find_Method' => 'ConduitAPI_maniphest_query_Method',
|
2012-01-11 04:51:55 +01:00
|
|
|
'ConduitAPI_maniphest_gettasktransactions_Method' => 'ConduitAPI_maniphest_Method',
|
2011-08-18 00:19:48 +02:00
|
|
|
'ConduitAPI_maniphest_info_Method' => 'ConduitAPI_maniphest_Method',
|
2012-06-29 18:17:19 +02:00
|
|
|
'ConduitAPI_maniphest_query_Method' => 'ConduitAPI_maniphest_Method',
|
2012-01-06 04:02:50 +01:00
|
|
|
'ConduitAPI_maniphest_update_Method' => 'ConduitAPI_maniphest_Method',
|
2012-05-22 19:19:58 +02:00
|
|
|
'ConduitAPI_owners_query_Method' => 'ConduitAPIMethod',
|
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',
|
2012-08-24 22:20:20 +02:00
|
|
|
'ConduitAPI_paste_query_Method' => 'ConduitAPI_paste_Method',
|
2011-08-30 21:03:58 +02:00
|
|
|
'ConduitAPI_phid_Method' => 'ConduitAPIMethod',
|
|
|
|
'ConduitAPI_phid_info_Method' => 'ConduitAPI_phid_Method',
|
2012-08-03 20:41:33 +02:00
|
|
|
'ConduitAPI_phid_lookup_Method' => 'ConduitAPI_phid_Method',
|
2012-02-15 03:26:27 +01:00
|
|
|
'ConduitAPI_phid_query_Method' => 'ConduitAPI_phid_Method',
|
2012-08-15 04:18:28 +02:00
|
|
|
'ConduitAPI_phpast_getast_Method' => 'ConduitAPIMethod',
|
|
|
|
'ConduitAPI_phpast_version_Method' => 'ConduitAPIMethod',
|
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',
|
2012-01-18 01:29:35 +01:00
|
|
|
'ConduitAPI_project_Method' => 'ConduitAPIMethod',
|
|
|
|
'ConduitAPI_project_query_Method' => 'ConduitAPI_project_Method',
|
2012-02-03 01:42:29 +01:00
|
|
|
'ConduitAPI_remarkup_process_Method' => 'ConduitAPIMethod',
|
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',
|
2011-07-13 04:18:20 +02:00
|
|
|
'ConduitAPI_slowvote_info_Method' => 'ConduitAPIMethod',
|
2011-08-30 21:03:58 +02:00
|
|
|
'ConduitAPI_user_Method' => 'ConduitAPIMethod',
|
2012-05-04 00:47:34 +02:00
|
|
|
'ConduitAPI_user_addstatus_Method' => 'ConduitAPI_user_Method',
|
2012-05-18 20:51:24 +02:00
|
|
|
'ConduitAPI_user_disable_Method' => 'ConduitAPI_user_Method',
|
2012-06-19 23:36:08 +02:00
|
|
|
'ConduitAPI_user_enable_Method' => 'ConduitAPI_user_Method',
|
2011-08-30 21:03:58 +02:00
|
|
|
'ConduitAPI_user_find_Method' => 'ConduitAPI_user_Method',
|
|
|
|
'ConduitAPI_user_info_Method' => 'ConduitAPI_user_Method',
|
2012-05-07 22:35:09 +02:00
|
|
|
'ConduitAPI_user_query_Method' => 'ConduitAPI_user_Method',
|
2012-05-05 20:29:09 +02:00
|
|
|
'ConduitAPI_user_removestatus_Method' => 'ConduitAPI_user_Method',
|
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',
|
2012-05-30 23:26:29 +02:00
|
|
|
'ConduitException' => 'Exception',
|
Implement SSHD glue and Conduit SSH endpoint
Summary:
- Build "sshd-auth" (for authentication) and "sshd-exec" (for command execution) binaries. These are callable by "sshd-vcs", located [[https://github.com/epriestley/sshd-vcs | in my account on GitHub]]. They are based on precursors [[https://github.com/epriestley/sshd-vcs-glue | here on GitHub]] which I deployed for TenXer about a year ago, so I have some confidence they at least basically work.
- The problem this solves is that normally every user would need an account on a machine to connect to it, and/or their public keys would all need to be listed in `~/.authorized_keys`. This is a big pain in most installs. Software like Gitosis/Gitolite solve this problem by giving you an easy way to add public keys to `~/.authorized_keys`, but this is pretty gross.
- Roughly, instead of looking in `~/.authorized_keys` when a user connects, the patched sshd instead runs `echo <public key> | sshd-auth`. The `sshd-auth` script looks up the public key and authorizes the matching user, if they exist. It also forces sshd to run `sshd-exec` instead of a normal shell.
- `sshd-exec` receives the authenticated user and any command which was passed to ssh (like `git receive-pack`) and can route them appropriately.
- Overall, this permits a single account to be set up on a server which all Phabricator users can connect to without any extra work, and which can safely execute commands and apply appropriate permissions, and disable users when they are disabled in Phabricator and all that stuff.
- Build out "sshd-exec" to do more thorough checks and setup, and delegate command execution to Workflows (they now exist, and did not when I originally built this stuff).
- Convert @btrahan's conduit API script into a workflow and slightly simplify it (ConduitCall did not exist at the time it was written).
The next steps here on the Repository side are to implement Workflows for Git, SVN and HG wire protocols. These will mostly just proxy the protocols, but also need to enforce permissions. So the approach will basically be:
- Implement workflows for stuff like `git receive-pack`.
- These workflows will implement enough of the underlying protocol to determine what resource the user is trying to access, and whether they want to read or write it.
- They'll then do a permissons check, and kick the user out if they don't have permission to do whatever they are trying to do.
- If the user does have permission, we just proxy the rest of the transaction.
Next steps on the Conduit side are more simple:
- Make ConduitClient understand "ssh://" URLs.
Test Plan: Ran `sshd-exec --phabricator-ssh-user epriestley conduit differential.query`, etc. This will get a more comprehensive test once I set up sshd-vcs.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603, T550
Differential Revision: https://secure.phabricator.com/D4229
2012-12-19 20:08:07 +01:00
|
|
|
'ConduitSSHWorkflow' => 'PhabricatorSSHWorkflow',
|
2013-01-26 01:03:54 +01:00
|
|
|
'ConpherenceConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2013-01-25 02:23:05 +01:00
|
|
|
'ConpherenceController' => 'PhabricatorController',
|
|
|
|
'ConpherenceDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'ConpherenceEditor' => 'PhabricatorApplicationTransactionEditor',
|
|
|
|
'ConpherenceListController' => 'ConpherenceController',
|
|
|
|
'ConpherenceMenuItemView' => 'AphrontTagView',
|
|
|
|
'ConpherenceNewController' => 'ConpherenceController',
|
|
|
|
'ConpherenceParticipant' => 'ConpherenceDAO',
|
|
|
|
'ConpherenceParticipantQuery' => 'PhabricatorOffsetPagedQuery',
|
|
|
|
'ConpherenceParticipationStatus' => 'ConpherenceConstants',
|
2013-02-05 22:46:02 +01:00
|
|
|
'ConpherencePeopleMenuEventListener' => 'PhutilEventListener',
|
2013-01-26 01:03:54 +01:00
|
|
|
'ConpherenceReplyHandler' => 'PhabricatorMailReplyHandler',
|
2013-01-25 02:23:05 +01:00
|
|
|
'ConpherenceThread' =>
|
|
|
|
array(
|
|
|
|
0 => 'ConpherenceDAO',
|
|
|
|
1 => 'PhabricatorPolicyInterface',
|
|
|
|
),
|
|
|
|
'ConpherenceThreadQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
|
|
|
|
'ConpherenceTransaction' => 'PhabricatorApplicationTransaction',
|
|
|
|
'ConpherenceTransactionComment' => 'PhabricatorApplicationTransactionComment',
|
|
|
|
'ConpherenceTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
|
|
|
|
'ConpherenceTransactionType' => 'ConpherenceConstants',
|
|
|
|
'ConpherenceTransactionView' => 'AphrontView',
|
|
|
|
'ConpherenceUpdateController' => 'ConpherenceController',
|
|
|
|
'ConpherenceViewController' => 'ConpherenceController',
|
2011-02-03 07:38:42 +01:00
|
|
|
'DarkConsoleController' => 'PhabricatorController',
|
2011-02-02 22:48:52 +01:00
|
|
|
'DarkConsoleErrorLogPlugin' => 'DarkConsolePlugin',
|
2011-09-30 21:54:17 +02:00
|
|
|
'DarkConsoleEventPlugin' => 'DarkConsolePlugin',
|
2011-11-10 02:23:33 +01:00
|
|
|
'DarkConsoleEventPluginAPI' => 'PhutilEventListener',
|
2011-02-02 22:48:52 +01:00
|
|
|
'DarkConsoleRequestPlugin' => 'DarkConsolePlugin',
|
|
|
|
'DarkConsoleServicesPlugin' => 'DarkConsolePlugin',
|
|
|
|
'DarkConsoleXHProfPlugin' => 'DarkConsolePlugin',
|
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',
|
2011-01-30 20:02:22 +01:00
|
|
|
'DifferentialAddCommentView' => 'AphrontView',
|
2011-09-14 19:59:52 +02:00
|
|
|
'DifferentialAffectedPath' => 'DifferentialDAO',
|
2011-08-14 20:29:56 +02:00
|
|
|
'DifferentialApplyPatchFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-08-14 21:33:54 +02:00
|
|
|
'DifferentialArcanistProjectFieldSpecification' => 'DifferentialFieldSpecification',
|
2012-03-07 00:10:35 +01:00
|
|
|
'DifferentialAuditorsFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-08-14 21:33:54 +02:00
|
|
|
'DifferentialAuthorFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-08-10 20:29:08 +02:00
|
|
|
'DifferentialAuxiliaryField' => 'DifferentialDAO',
|
2011-08-11 00:36:18 +02:00
|
|
|
'DifferentialBlameRevisionFieldSpecification' => 'DifferentialFieldSpecification',
|
2012-02-07 01:34:25 +01:00
|
|
|
'DifferentialBranchFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-26 02:17:19 +01:00
|
|
|
'DifferentialCCWelcomeMail' => 'DifferentialReviewRequestMail',
|
2011-08-14 22:55:30 +02:00
|
|
|
'DifferentialCCsFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-24 20:01:53 +01:00
|
|
|
'DifferentialChangeset' => 'DifferentialDAO',
|
2011-01-24 22:18:41 +01:00
|
|
|
'DifferentialChangesetDetailView' => 'AphrontView',
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
|
|
|
'DifferentialChangesetHTMLRenderer' => 'DifferentialChangesetRenderer',
|
2012-12-06 20:33:04 +01:00
|
|
|
'DifferentialChangesetListView' => 'AphrontView',
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
|
|
|
'DifferentialChangesetOneUpRenderer' => 'DifferentialChangesetHTMLRenderer',
|
|
|
|
'DifferentialChangesetOneUpTestRenderer' => 'DifferentialChangesetTestRenderer',
|
|
|
|
'DifferentialChangesetParserTestCase' => 'PhabricatorTestCase',
|
|
|
|
'DifferentialChangesetTestRenderer' => 'DifferentialChangesetRenderer',
|
|
|
|
'DifferentialChangesetTwoUpRenderer' => 'DifferentialChangesetHTMLRenderer',
|
|
|
|
'DifferentialChangesetTwoUpTestRenderer' => 'DifferentialChangesetTestRenderer',
|
2011-01-25 00:52:35 +01:00
|
|
|
'DifferentialChangesetViewController' => 'DifferentialController',
|
2012-10-24 02:34:43 +02:00
|
|
|
'DifferentialComment' =>
|
|
|
|
array(
|
|
|
|
0 => 'DifferentialDAO',
|
|
|
|
1 => 'PhabricatorMarkupInterface',
|
|
|
|
),
|
2012-10-10 19:18:23 +02:00
|
|
|
'DifferentialCommentEditor' => 'PhabricatorEditor',
|
2011-01-30 21:08:40 +01:00
|
|
|
'DifferentialCommentMail' => 'DifferentialMail',
|
2011-02-01 03:05:20 +01:00
|
|
|
'DifferentialCommentPreviewController' => 'DifferentialController',
|
2011-01-30 21:08:40 +01:00
|
|
|
'DifferentialCommentSaveController' => 'DifferentialController',
|
2011-08-14 21:33:54 +02:00
|
|
|
'DifferentialCommitsFieldSpecification' => 'DifferentialFieldSpecification',
|
2012-12-12 01:34:08 +01:00
|
|
|
'DifferentialConflictsFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-24 22:18:41 +01:00
|
|
|
'DifferentialController' => 'PhabricatorController',
|
2011-01-24 20:01:53 +01:00
|
|
|
'DifferentialDAO' => 'PhabricatorLiskDAO',
|
2012-02-20 14:38:21 +01:00
|
|
|
'DifferentialDateCreatedFieldSpecification' => 'DifferentialFieldSpecification',
|
|
|
|
'DifferentialDateModifiedFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-08-10 20:29:08 +02:00
|
|
|
'DifferentialDefaultFieldSelector' => 'DifferentialFieldSelector',
|
2011-08-14 21:33:54 +02:00
|
|
|
'DifferentialDependenciesFieldSpecification' => 'DifferentialFieldSpecification',
|
2012-08-29 00:24:01 +02:00
|
|
|
'DifferentialDependsOnFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-24 20:01:53 +01:00
|
|
|
'DifferentialDiff' => 'DifferentialDAO',
|
2011-01-26 02:17:19 +01:00
|
|
|
'DifferentialDiffContentMail' => 'DifferentialMail',
|
2011-02-05 21:20:18 +01:00
|
|
|
'DifferentialDiffCreateController' => 'DifferentialController',
|
2011-01-24 21:07:34 +01:00
|
|
|
'DifferentialDiffProperty' => 'DifferentialDAO',
|
2011-01-24 22:18:41 +01:00
|
|
|
'DifferentialDiffTableOfContentsView' => 'AphrontView',
|
2012-11-21 21:30:38 +01:00
|
|
|
'DifferentialDiffTestCase' => 'ArcanistPhutilTestCase',
|
2011-01-24 22:18:41 +01:00
|
|
|
'DifferentialDiffViewController' => 'DifferentialController',
|
2012-05-30 23:26:29 +02:00
|
|
|
'DifferentialException' => 'Exception',
|
2011-05-01 04:40:05 +02:00
|
|
|
'DifferentialExceptionMail' => 'DifferentialMail',
|
2011-08-14 20:29:56 +02:00
|
|
|
'DifferentialExportPatchFieldSpecification' => 'DifferentialFieldSpecification',
|
2012-05-30 23:26:29 +02:00
|
|
|
'DifferentialFieldDataNotAvailableException' => 'Exception',
|
|
|
|
'DifferentialFieldParseException' => 'Exception',
|
|
|
|
'DifferentialFieldSpecificationIncompleteException' => 'Exception',
|
|
|
|
'DifferentialFieldValidationException' => 'Exception',
|
2012-09-11 19:37:30 +02:00
|
|
|
'DifferentialFreeformFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-08-15 03:52:09 +02:00
|
|
|
'DifferentialGitSVNIDFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-08-14 20:29:56 +02:00
|
|
|
'DifferentialHostFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-24 20:01:53 +01:00
|
|
|
'DifferentialHunk' => 'DifferentialDAO',
|
2013-01-09 22:11:17 +01:00
|
|
|
'DifferentialHunkParserTestCase' => 'PhabricatorTestCase',
|
2012-06-27 19:44:29 +02:00
|
|
|
'DifferentialHunkTestCase' => 'ArcanistPhutilTestCase',
|
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',
|
2012-02-29 23:28:48 +01:00
|
|
|
'DifferentialInlineCommentEditView' => 'AphrontView',
|
2012-07-23 20:01:28 +02:00
|
|
|
'DifferentialInlineCommentPreviewController' => 'PhabricatorInlineCommentPreviewController',
|
2011-02-02 01:42:36 +01:00
|
|
|
'DifferentialInlineCommentView' => 'AphrontView',
|
2011-08-14 20:29:56 +02:00
|
|
|
'DifferentialLinesFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-08-14 22:55:30 +02:00
|
|
|
'DifferentialLintFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-08-30 20:34:07 +02:00
|
|
|
'DifferentialLocalCommitsView' => 'AphrontView',
|
2011-08-14 21:33:54 +02:00
|
|
|
'DifferentialManiphestTasksFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-26 02:17:19 +01:00
|
|
|
'DifferentialNewDiffMail' => 'DifferentialReviewRequestMail',
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
|
|
|
'DifferentialParseRenderTestCase' => 'PhabricatorTestCase',
|
2011-08-14 20:29:56 +02:00
|
|
|
'DifferentialPathFieldSpecification' => 'DifferentialFieldSpecification',
|
2013-02-05 22:46:02 +01:00
|
|
|
'DifferentialPeopleMenuEventListener' => 'PhutilEventListener',
|
2012-12-06 20:33:04 +01:00
|
|
|
'DifferentialPrimaryPaneView' => 'AphrontView',
|
2011-05-10 01:31:26 +02:00
|
|
|
'DifferentialReplyHandler' => 'PhabricatorMailReplyHandler',
|
2012-05-01 19:15:56 +02:00
|
|
|
'DifferentialResultsTableView' => 'AphrontView',
|
2011-08-11 00:36:18 +02:00
|
|
|
'DifferentialRevertPlanFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-26 02:17:19 +01:00
|
|
|
'DifferentialReviewRequestMail' => 'DifferentialMail',
|
2011-08-15 03:52:09 +02:00
|
|
|
'DifferentialReviewedByFieldSpecification' => 'DifferentialFieldSpecification',
|
2012-07-25 02:58:33 +02:00
|
|
|
'DifferentialReviewerStatsTestCase' => 'PhabricatorTestCase',
|
2011-08-14 22:55:30 +02:00
|
|
|
'DifferentialReviewersFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-24 20:01:53 +01:00
|
|
|
'DifferentialRevision' => 'DifferentialDAO',
|
2011-01-30 19:37:36 +01:00
|
|
|
'DifferentialRevisionCommentListView' => 'AphrontView',
|
|
|
|
'DifferentialRevisionCommentView' => 'AphrontView',
|
2011-01-27 23:55:52 +01:00
|
|
|
'DifferentialRevisionDetailView' => 'AphrontView',
|
2011-01-25 22:26:09 +01:00
|
|
|
'DifferentialRevisionEditController' => 'DifferentialController',
|
2012-10-10 19:18:23 +02:00
|
|
|
'DifferentialRevisionEditor' => 'PhabricatorEditor',
|
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',
|
2011-08-15 03:52:09 +02:00
|
|
|
'DifferentialRevisionIDFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-26 00:19:06 +01:00
|
|
|
'DifferentialRevisionListController' => 'DifferentialController',
|
2011-10-02 20:42:41 +02:00
|
|
|
'DifferentialRevisionListView' => 'AphrontView',
|
2012-02-19 05:16:35 +01:00
|
|
|
'DifferentialRevisionStatsController' => 'DifferentialController',
|
|
|
|
'DifferentialRevisionStatsView' => 'AphrontView',
|
2011-08-14 22:55:30 +02:00
|
|
|
'DifferentialRevisionStatusFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-27 23:55:52 +01:00
|
|
|
'DifferentialRevisionUpdateHistoryView' => 'AphrontView',
|
|
|
|
'DifferentialRevisionViewController' => 'DifferentialController',
|
Improve Search architecture
Summary:
The search indexing API has several problems right now:
- Always runs in-process.
- It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it.
- Being able to use the task queue will also make rebuilding indexes faster.
- Instead, make the API phid-oriented.
- No uniform indexing API.
- Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird.
- Instead, provide a uniform API.
- No uniform CLI.
- We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers.
- Instead, let indexers expose documents for indexing.
- Not application-oriented.
- All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world.
- Instead, move indexers to applications and load them with SymbolLoader.
Test Plan:
- `bin/search index`
- Indexed one revision, one task.
- Indexed `--type TASK`, `--type DREV`, etc., for all types.
- Indexed `--all`.
- Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it.
- Creating users is a pain; searched for a user after indexing.
- Creating commits is a pain; searched for a commit after indexing.
- Mocks aren't currently loadable in the result view, so their indexing is moot.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: 20after4, aran
Maniphest Tasks: T1991, T2104
Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
|
|
|
'DifferentialSearchIndexer' => 'PhabricatorSearchDocumentIndexer',
|
2011-02-19 23:36:13 +01:00
|
|
|
'DifferentialSubscribeController' => 'DifferentialController',
|
2012-09-11 19:37:30 +02:00
|
|
|
'DifferentialSummaryFieldSpecification' => 'DifferentialFreeformFieldSpecification',
|
2011-08-14 23:28:08 +02:00
|
|
|
'DifferentialTestPlanFieldSpecification' => 'DifferentialFieldSpecification',
|
2012-09-11 19:37:30 +02:00
|
|
|
'DifferentialTitleFieldSpecification' => 'DifferentialFreeformFieldSpecification',
|
2011-08-14 22:55:30 +02:00
|
|
|
'DifferentialUnitFieldSpecification' => 'DifferentialFieldSpecification',
|
2012-05-10 09:28:19 +02:00
|
|
|
'DiffusionBranchTableController' => 'DiffusionController',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionBranchTableView' => 'DiffusionView',
|
2011-03-08 02:25:47 +01:00
|
|
|
'DiffusionBrowseController' => 'DiffusionController',
|
2011-03-08 18:54:55 +01:00
|
|
|
'DiffusionBrowseFileController' => 'DiffusionController',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionBrowseTableView' => 'DiffusionView',
|
2011-03-14 06:03:30 +01:00
|
|
|
'DiffusionChangeController' => 'DiffusionController',
|
2012-02-24 23:14:39 +01:00
|
|
|
'DiffusionCommentListView' => 'AphrontView',
|
|
|
|
'DiffusionCommentView' => 'AphrontView',
|
2012-08-01 01:27:48 +02:00
|
|
|
'DiffusionCommitBranchesController' => 'DiffusionController',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionCommitChangeTableView' => 'DiffusionView',
|
2011-03-11 18:34:22 +01:00
|
|
|
'DiffusionCommitController' => 'DiffusionController',
|
2012-08-08 19:03:41 +02:00
|
|
|
'DiffusionCommitEditController' => 'DiffusionController',
|
2012-03-26 21:21:48 +02:00
|
|
|
'DiffusionCommitParentsQuery' => 'DiffusionQuery',
|
2012-08-01 01:27:48 +02:00
|
|
|
'DiffusionCommitTagsController' => 'DiffusionController',
|
2012-04-24 03:36:25 +02:00
|
|
|
'DiffusionCommitTagsQuery' => 'DiffusionQuery',
|
2012-01-19 20:49:51 +01:00
|
|
|
'DiffusionContainsQuery' => 'DiffusionQuery',
|
2011-03-08 00:13:36 +01:00
|
|
|
'DiffusionController' => 'PhabricatorController',
|
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',
|
2012-02-03 01:42:29 +01:00
|
|
|
'DiffusionEmptyResultView' => 'DiffusionView',
|
2012-08-09 18:27:45 +02:00
|
|
|
'DiffusionExistsQuery' => 'DiffusionQuery',
|
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',
|
2012-03-27 05:54:26 +02:00
|
|
|
'DiffusionFileContentQuery' => 'DiffusionQuery',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionGitBranchQuery' => 'DiffusionBranchQuery',
|
2011-12-22 21:24:12 +01:00
|
|
|
'DiffusionGitBranchQueryTestCase' => 'PhabricatorTestCase',
|
2011-03-08 02:25:47 +01:00
|
|
|
'DiffusionGitBrowseQuery' => 'DiffusionBrowseQuery',
|
2012-03-26 21:21:48 +02:00
|
|
|
'DiffusionGitCommitParentsQuery' => 'DiffusionCommitParentsQuery',
|
2012-04-24 03:36:25 +02:00
|
|
|
'DiffusionGitCommitTagsQuery' => 'DiffusionCommitTagsQuery',
|
2012-01-19 20:49:51 +01:00
|
|
|
'DiffusionGitContainsQuery' => 'DiffusionContainsQuery',
|
2011-03-31 03:17:36 +02:00
|
|
|
'DiffusionGitDiffQuery' => 'DiffusionDiffQuery',
|
2012-08-09 18:27:45 +02:00
|
|
|
'DiffusionGitExistsQuery' => 'DiffusionExistsQuery',
|
2011-03-08 18:54:55 +01:00
|
|
|
'DiffusionGitFileContentQuery' => 'DiffusionFileContentQuery',
|
2011-03-09 02:31:44 +01:00
|
|
|
'DiffusionGitHistoryQuery' => 'DiffusionHistoryQuery',
|
2011-03-31 08:27:06 +02:00
|
|
|
'DiffusionGitLastModifiedQuery' => 'DiffusionLastModifiedQuery',
|
2012-03-23 23:32:26 +01:00
|
|
|
'DiffusionGitMergedCommitsQuery' => 'DiffusionMergedCommitsQuery',
|
2012-05-02 22:43:45 +02:00
|
|
|
'DiffusionGitRawDiffQuery' => 'DiffusionRawDiffQuery',
|
2011-03-08 23:29:02 +01:00
|
|
|
'DiffusionGitRequest' => 'DiffusionRequest',
|
2012-04-18 17:02:08 +02:00
|
|
|
'DiffusionGitTagListQuery' => 'DiffusionTagListQuery',
|
2011-03-09 02:31:44 +01:00
|
|
|
'DiffusionHistoryController' => 'DiffusionController',
|
2012-03-23 23:32:26 +01:00
|
|
|
'DiffusionHistoryQuery' => 'DiffusionQuery',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionHistoryTableView' => 'DiffusionView',
|
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',
|
2012-07-23 20:01:28 +02:00
|
|
|
'DiffusionInlineCommentPreviewController' => 'PhabricatorInlineCommentPreviewController',
|
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',
|
2012-11-08 20:11:44 +01:00
|
|
|
'DiffusionLintController' => 'DiffusionController',
|
2012-11-09 01:13:21 +01:00
|
|
|
'DiffusionLintDetailsController' => 'DiffusionController',
|
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',
|
2012-03-26 21:21:48 +02:00
|
|
|
'DiffusionMercurialCommitParentsQuery' => 'DiffusionCommitParentsQuery',
|
2012-04-24 03:36:25 +02:00
|
|
|
'DiffusionMercurialCommitTagsQuery' => 'DiffusionCommitTagsQuery',
|
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',
|
2012-08-09 18:27:45 +02:00
|
|
|
'DiffusionMercurialExistsQuery' => 'DiffusionExistsQuery',
|
Basic support for Mercurial in Diffusion
Summary: Change import script plus almost all the view stuff. Still some rough
edges but this seems to mostly work. Blame is currently unsupported but I think
everything else works properly.
Test Plan:
Imported the hg repository itself. It doesn't immediately seem completely
broken. Here are some screens:
https://secure.phabricator.com/file/view/PHID-FILE-1438b71cc7c4a2eb4569/
https://secure.phabricator.com/file/view/PHID-FILE-3cec4f72f39e7de2d041/
https://secure.phabricator.com/file/view/PHID-FILE-2ea4883f160e8e5098f9/
https://secure.phabricator.com/file/view/PHID-FILE-35f751a36ebf65399ade/
All the parsers were able to churn through it without errors.
Ran the new "reparse.php" script in various one-commit and repository modes.
Browsed/imported some git repos for good measure.
NOTE: The hg repository is only 15,000 commits and around 1,000 files.
Performance is okay but hg doesn't provide performant, native APIs to get some
data efficiently so we have to do some dumb stuff. If some of these interfaces
are cripplingly slow or whatever, let me know and we can start bundling some
Mercurial extensions with Arcanist.
Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran
Reviewed By: Makinde
CC: aran, Makinde, epriestley
Differential Revision: 960
2011-09-26 20:07:38 +02:00
|
|
|
'DiffusionMercurialFileContentQuery' => 'DiffusionFileContentQuery',
|
|
|
|
'DiffusionMercurialHistoryQuery' => 'DiffusionHistoryQuery',
|
|
|
|
'DiffusionMercurialLastModifiedQuery' => 'DiffusionLastModifiedQuery',
|
2012-03-23 23:32:26 +01:00
|
|
|
'DiffusionMercurialMergedCommitsQuery' => 'DiffusionMergedCommitsQuery',
|
2012-05-02 22:43:45 +02:00
|
|
|
'DiffusionMercurialRawDiffQuery' => 'DiffusionRawDiffQuery',
|
Basic support for Mercurial in Diffusion
Summary: Change import script plus almost all the view stuff. Still some rough
edges but this seems to mostly work. Blame is currently unsupported but I think
everything else works properly.
Test Plan:
Imported the hg repository itself. It doesn't immediately seem completely
broken. Here are some screens:
https://secure.phabricator.com/file/view/PHID-FILE-1438b71cc7c4a2eb4569/
https://secure.phabricator.com/file/view/PHID-FILE-3cec4f72f39e7de2d041/
https://secure.phabricator.com/file/view/PHID-FILE-2ea4883f160e8e5098f9/
https://secure.phabricator.com/file/view/PHID-FILE-35f751a36ebf65399ade/
All the parsers were able to churn through it without errors.
Ran the new "reparse.php" script in various one-commit and repository modes.
Browsed/imported some git repos for good measure.
NOTE: The hg repository is only 15,000 commits and around 1,000 files.
Performance is okay but hg doesn't provide performant, native APIs to get some
data efficiently so we have to do some dumb stuff. If some of these interfaces
are cripplingly slow or whatever, let me know and we can start bundling some
Mercurial extensions with Arcanist.
Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran
Reviewed By: Makinde
CC: aran, Makinde, epriestley
Differential Revision: 960
2011-09-26 20:07:38 +02:00
|
|
|
'DiffusionMercurialRequest' => 'DiffusionRequest',
|
2012-04-18 17:02:08 +02:00
|
|
|
'DiffusionMercurialTagListQuery' => 'DiffusionTagListQuery',
|
2012-03-23 23:32:26 +01:00
|
|
|
'DiffusionMergedCommitsQuery' => 'DiffusionQuery',
|
2011-04-04 04:20:47 +02:00
|
|
|
'DiffusionPathCompleteController' => 'DiffusionController',
|
2011-09-14 20:23:39 +02:00
|
|
|
'DiffusionPathQueryTestCase' => 'PhabricatorTestCase',
|
2011-04-04 04:20:47 +02:00
|
|
|
'DiffusionPathValidateController' => 'DiffusionController',
|
2013-02-05 22:46:02 +01:00
|
|
|
'DiffusionPeopleMenuEventListener' => 'PhutilEventListener',
|
2012-05-02 22:43:45 +02:00
|
|
|
'DiffusionRawDiffQuery' => 'DiffusionQuery',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionRepositoryController' => 'DiffusionController',
|
2012-05-12 03:29:14 +02:00
|
|
|
'DiffusionSetupException' => 'AphrontUsageException',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionSvnBrowseQuery' => 'DiffusionBrowseQuery',
|
2012-03-26 21:21:48 +02:00
|
|
|
'DiffusionSvnCommitParentsQuery' => 'DiffusionCommitParentsQuery',
|
2012-04-24 03:36:25 +02:00
|
|
|
'DiffusionSvnCommitTagsQuery' => 'DiffusionCommitTagsQuery',
|
2012-03-24 20:52:14 +01:00
|
|
|
'DiffusionSvnContainsQuery' => 'DiffusionContainsQuery',
|
2011-03-31 02:36:16 +02:00
|
|
|
'DiffusionSvnDiffQuery' => 'DiffusionDiffQuery',
|
2012-08-09 18:27:45 +02:00
|
|
|
'DiffusionSvnExistsQuery' => 'DiffusionExistsQuery',
|
2011-03-14 06:03:30 +01:00
|
|
|
'DiffusionSvnFileContentQuery' => 'DiffusionFileContentQuery',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionSvnHistoryQuery' => 'DiffusionHistoryQuery',
|
2011-03-31 08:27:06 +02:00
|
|
|
'DiffusionSvnLastModifiedQuery' => 'DiffusionLastModifiedQuery',
|
2012-03-23 23:32:26 +01:00
|
|
|
'DiffusionSvnMergedCommitsQuery' => 'DiffusionMergedCommitsQuery',
|
2012-05-02 22:43:45 +02:00
|
|
|
'DiffusionSvnRawDiffQuery' => 'DiffusionRawDiffQuery',
|
2011-03-23 03:34:47 +01:00
|
|
|
'DiffusionSvnRequest' => 'DiffusionRequest',
|
2012-04-18 17:02:08 +02:00
|
|
|
'DiffusionSvnTagListQuery' => 'DiffusionTagListQuery',
|
2011-09-05 19:43:24 +02:00
|
|
|
'DiffusionSymbolController' => 'DiffusionController',
|
2012-08-01 21:36:47 +02:00
|
|
|
'DiffusionSymbolQuery' => 'PhabricatorOffsetPagedQuery',
|
2012-04-19 18:39:19 +02:00
|
|
|
'DiffusionTagListController' => 'DiffusionController',
|
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',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionView' => 'AphrontView',
|
Port Diviner Core to Phabricator
Summary:
This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix:
**Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes.
**Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms.
**Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom.
**URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature.
**Search** Once we have a database generation target, we can index the documentation.
**Design** Chad has some nice mocks.
Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T988
Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
|
|
|
'DivinerArticleAtomizer' => 'DivinerAtomizer',
|
|
|
|
'DivinerAtomizeWorkflow' => 'DivinerWorkflow',
|
|
|
|
'DivinerFileAtomizer' => 'DivinerAtomizer',
|
|
|
|
'DivinerGenerateWorkflow' => 'DivinerWorkflow',
|
2012-10-01 21:56:51 +02:00
|
|
|
'DivinerListController' => 'PhabricatorController',
|
Port Diviner Core to Phabricator
Summary:
This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix:
**Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes.
**Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms.
**Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom.
**URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature.
**Search** Once we have a database generation target, we can index the documentation.
**Design** Chad has some nice mocks.
Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T988
Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
|
|
|
'DivinerWorkflow' => 'PhutilArgumentWorkflow',
|
2012-01-24 01:58:38 +01:00
|
|
|
'DrydockAllocatorWorker' => 'PhabricatorWorker',
|
2012-03-27 05:54:26 +02:00
|
|
|
'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',
|
|
|
|
'DrydockLease' => 'DrydockDAO',
|
|
|
|
'DrydockLeaseListController' => 'DrydockController',
|
2012-12-17 22:53:32 +01:00
|
|
|
'DrydockLeaseQuery' => 'PhabricatorOffsetPagedQuery',
|
2012-12-15 00:42:58 +01:00
|
|
|
'DrydockLeaseReleaseController' => 'DrydockController',
|
Drydock Rough Cut
Summary:
Rough cut of Drydock. This is very basic and doesn't do much of use yet (it
//does// allocate EC2 machines as host resources and expose interfaces to them),
but I think the overall structure is more or less reasonable.
== Interfaces
Vision: Applications interact with Drydock resources through DrydockInterfaces,
like **command**, **filesystem** and **httpd** interfaces. Each interface allows
applications to perform some kind of operation on the resource, like executing
commands, reading/writing files, or configuring a web server. Interfaces have a
concrete, specific API:
// Filesystem Interface
$fs = $lease->getInterface('filesystem'); // Constants, some day?
$fs->writeFile('index.html', 'hello world!');
// Command Interface
$cmd = $lease->getInterface('command');
echo $cmd->execx('uptime');
// HTTPD Interface
$httpd = $lease->getInterface('httpd');
$httpd->restart();
Interfaces are mostly just stock, although installs might add new interfaces if
they expose different ways to interact with resources (for instance, a resource
might want to expose a new 'MongoDB' interface or whatever).
Currently: We have like part of a command interface.
== Leases
Vision: Leases keep track of which resources are in use, and what they're being
used for. They allow us to know when we need to allocate more resources (too
many sandcastles on the existing hosts, e.g.) and when we can release resources
(because they are no longer being used). They also give applications something
to hold while resources are being allocated.
// EXAMPLE: How this should work some day.
$allocator = new DrydockAllocator();
$allocator->setResourceType('sandcastle');
$allocator->setAttributes(
array(
'diffID' => $diff->getID(),
));
$lease = $allocator->allocate();
$diff->setSandcastleLeaseID($lease->getID());
// ...
if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) {
$sandcastle_link = $lease->getInterface('httpd')->getURI('/');
} else {
$sandcastle_link = 'Still building your sandcastle...';
}
echo "Sandcastle for this diff: ".$sandcastle_link;
// EXAMPLE: How this actually works now.
$allocator = new DrydockAllocator();
$allocator->setResourceType('host');
// NOTE: Allocation is currently synchronous but will be task-driven soon.
$lease = $allocator->allocate();
Leases are completely stock, installs will not define new lease types.
Currently: Leases exist and work but are very very basic.
== Resources
Vision: Resources represent some actual thing we've put somewhere, whether it's
a host, a block of storage, a webroot, or whatever else. Applications interact
through resources by acquiring leases to them, and then getting interfaces
through these leases. The lease acquisition process has a side effect of
allocating new resources if a lease can't be acquired on existing resources
(e.g., the application wants storage but all storage resources are full) and
things are configured to autoscale.
Resources may themselves acquire leases in order to allocate. For instance, a
storage resource might first acquire a lease to a host resource. A 'test
scaffold' resource might lease a storage resource and a mysql resource.
Not all resources are auto-allocate: the entry-level version of Drydock is that
you manually allocate a couple boxes and configure them through the web console.
Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the
host pool itself does not autoscale.
Resources are completely stock, they are abstract shells representing any
arbitrary thing.
Currently: Resource exist ('host' only) but are very very basic.
== Blueprints
Vision: Blueprints contain instructions for building interfaces to, (possibly)
allocating, updating, managing, and destroying a specific type of resource in a
specific location. One way to think of them is that they are scripts for
creating and deleting resources. For example, the LocalHost, RemoteHost and
EC2Host blueprints can all manage 'host' resources.
Eventually, we will support more types of resources (storage, webroot,
sandcastle, test scaffold, phacility deployment) and more providers for resource
types, some of which will be in the Phabricator mainline and some of which will
be custom.
Blueprints are very custom and specific to application types, so installs will
define new blueprints if they are making significant use of Drydock.
Currently: They exist but have few capabilities. The stock blueprints do nearly
nothing useful. There is a technically functional blueprint for host allocation
in EC2.
== Allocator
This is just the actual code to execute the lease acquisition process.
Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2,
acquired a lease on it, interfaced with it, and then released the lease. Ran it
again, got a fresh lease on the existing resource.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
|
|
|
'DrydockLeaseStatus' => 'DrydockConstants',
|
2012-11-07 00:28:33 +01:00
|
|
|
'DrydockLeaseViewController' => 'DrydockController',
|
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
|
|
|
'DrydockLocalCommandInterface' => 'DrydockCommandInterface',
|
|
|
|
'DrydockLocalHostBlueprint' => 'DrydockBlueprint',
|
2012-03-27 05:54:26 +02:00
|
|
|
'DrydockLog' => 'DrydockDAO',
|
|
|
|
'DrydockLogController' => 'DrydockController',
|
|
|
|
'DrydockLogQuery' => 'PhabricatorOffsetPagedQuery',
|
2012-11-27 21:48:03 +01:00
|
|
|
'DrydockManagementCloseWorkflow' => 'DrydockManagementWorkflow',
|
2012-11-01 23:30:14 +01:00
|
|
|
'DrydockManagementLeaseWorkflow' => 'DrydockManagementWorkflow',
|
2012-12-15 00:42:58 +01:00
|
|
|
'DrydockManagementReleaseWorkflow' => 'DrydockManagementWorkflow',
|
2012-11-01 23:30:14 +01:00
|
|
|
'DrydockManagementWaitForLeaseWorkflow' => 'DrydockManagementWorkflow',
|
|
|
|
'DrydockManagementWorkflow' => 'PhutilArgumentWorkflow',
|
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
|
|
|
'DrydockResource' => 'DrydockDAO',
|
2012-11-27 21:48:03 +01:00
|
|
|
'DrydockResourceCloseController' => 'DrydockController',
|
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
|
|
|
'DrydockResourceListController' => 'DrydockController',
|
2012-12-17 23:47:21 +01:00
|
|
|
'DrydockResourceQuery' => 'PhabricatorOffsetPagedQuery',
|
Drydock Rough Cut
Summary:
Rough cut of Drydock. This is very basic and doesn't do much of use yet (it
//does// allocate EC2 machines as host resources and expose interfaces to them),
but I think the overall structure is more or less reasonable.
== Interfaces
Vision: Applications interact with Drydock resources through DrydockInterfaces,
like **command**, **filesystem** and **httpd** interfaces. Each interface allows
applications to perform some kind of operation on the resource, like executing
commands, reading/writing files, or configuring a web server. Interfaces have a
concrete, specific API:
// Filesystem Interface
$fs = $lease->getInterface('filesystem'); // Constants, some day?
$fs->writeFile('index.html', 'hello world!');
// Command Interface
$cmd = $lease->getInterface('command');
echo $cmd->execx('uptime');
// HTTPD Interface
$httpd = $lease->getInterface('httpd');
$httpd->restart();
Interfaces are mostly just stock, although installs might add new interfaces if
they expose different ways to interact with resources (for instance, a resource
might want to expose a new 'MongoDB' interface or whatever).
Currently: We have like part of a command interface.
== Leases
Vision: Leases keep track of which resources are in use, and what they're being
used for. They allow us to know when we need to allocate more resources (too
many sandcastles on the existing hosts, e.g.) and when we can release resources
(because they are no longer being used). They also give applications something
to hold while resources are being allocated.
// EXAMPLE: How this should work some day.
$allocator = new DrydockAllocator();
$allocator->setResourceType('sandcastle');
$allocator->setAttributes(
array(
'diffID' => $diff->getID(),
));
$lease = $allocator->allocate();
$diff->setSandcastleLeaseID($lease->getID());
// ...
if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) {
$sandcastle_link = $lease->getInterface('httpd')->getURI('/');
} else {
$sandcastle_link = 'Still building your sandcastle...';
}
echo "Sandcastle for this diff: ".$sandcastle_link;
// EXAMPLE: How this actually works now.
$allocator = new DrydockAllocator();
$allocator->setResourceType('host');
// NOTE: Allocation is currently synchronous but will be task-driven soon.
$lease = $allocator->allocate();
Leases are completely stock, installs will not define new lease types.
Currently: Leases exist and work but are very very basic.
== Resources
Vision: Resources represent some actual thing we've put somewhere, whether it's
a host, a block of storage, a webroot, or whatever else. Applications interact
through resources by acquiring leases to them, and then getting interfaces
through these leases. The lease acquisition process has a side effect of
allocating new resources if a lease can't be acquired on existing resources
(e.g., the application wants storage but all storage resources are full) and
things are configured to autoscale.
Resources may themselves acquire leases in order to allocate. For instance, a
storage resource might first acquire a lease to a host resource. A 'test
scaffold' resource might lease a storage resource and a mysql resource.
Not all resources are auto-allocate: the entry-level version of Drydock is that
you manually allocate a couple boxes and configure them through the web console.
Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the
host pool itself does not autoscale.
Resources are completely stock, they are abstract shells representing any
arbitrary thing.
Currently: Resource exist ('host' only) but are very very basic.
== Blueprints
Vision: Blueprints contain instructions for building interfaces to, (possibly)
allocating, updating, managing, and destroying a specific type of resource in a
specific location. One way to think of them is that they are scripts for
creating and deleting resources. For example, the LocalHost, RemoteHost and
EC2Host blueprints can all manage 'host' resources.
Eventually, we will support more types of resources (storage, webroot,
sandcastle, test scaffold, phacility deployment) and more providers for resource
types, some of which will be in the Phabricator mainline and some of which will
be custom.
Blueprints are very custom and specific to application types, so installs will
define new blueprints if they are making significant use of Drydock.
Currently: They exist but have few capabilities. The stock blueprints do nearly
nothing useful. There is a technically functional blueprint for host allocation
in EC2.
== Allocator
This is just the actual code to execute the lease acquisition process.
Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2,
acquired a lease on it, interfaced with it, and then released the lease. Ran it
again, got a fresh lease on the existing resource.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
|
|
|
'DrydockResourceStatus' => 'DrydockConstants',
|
2012-11-20 22:25:22 +01:00
|
|
|
'DrydockResourceViewController' => 'DrydockController',
|
Drydock Rough Cut
Summary:
Rough cut of Drydock. This is very basic and doesn't do much of use yet (it
//does// allocate EC2 machines as host resources and expose interfaces to them),
but I think the overall structure is more or less reasonable.
== Interfaces
Vision: Applications interact with Drydock resources through DrydockInterfaces,
like **command**, **filesystem** and **httpd** interfaces. Each interface allows
applications to perform some kind of operation on the resource, like executing
commands, reading/writing files, or configuring a web server. Interfaces have a
concrete, specific API:
// Filesystem Interface
$fs = $lease->getInterface('filesystem'); // Constants, some day?
$fs->writeFile('index.html', 'hello world!');
// Command Interface
$cmd = $lease->getInterface('command');
echo $cmd->execx('uptime');
// HTTPD Interface
$httpd = $lease->getInterface('httpd');
$httpd->restart();
Interfaces are mostly just stock, although installs might add new interfaces if
they expose different ways to interact with resources (for instance, a resource
might want to expose a new 'MongoDB' interface or whatever).
Currently: We have like part of a command interface.
== Leases
Vision: Leases keep track of which resources are in use, and what they're being
used for. They allow us to know when we need to allocate more resources (too
many sandcastles on the existing hosts, e.g.) and when we can release resources
(because they are no longer being used). They also give applications something
to hold while resources are being allocated.
// EXAMPLE: How this should work some day.
$allocator = new DrydockAllocator();
$allocator->setResourceType('sandcastle');
$allocator->setAttributes(
array(
'diffID' => $diff->getID(),
));
$lease = $allocator->allocate();
$diff->setSandcastleLeaseID($lease->getID());
// ...
if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) {
$sandcastle_link = $lease->getInterface('httpd')->getURI('/');
} else {
$sandcastle_link = 'Still building your sandcastle...';
}
echo "Sandcastle for this diff: ".$sandcastle_link;
// EXAMPLE: How this actually works now.
$allocator = new DrydockAllocator();
$allocator->setResourceType('host');
// NOTE: Allocation is currently synchronous but will be task-driven soon.
$lease = $allocator->allocate();
Leases are completely stock, installs will not define new lease types.
Currently: Leases exist and work but are very very basic.
== Resources
Vision: Resources represent some actual thing we've put somewhere, whether it's
a host, a block of storage, a webroot, or whatever else. Applications interact
through resources by acquiring leases to them, and then getting interfaces
through these leases. The lease acquisition process has a side effect of
allocating new resources if a lease can't be acquired on existing resources
(e.g., the application wants storage but all storage resources are full) and
things are configured to autoscale.
Resources may themselves acquire leases in order to allocate. For instance, a
storage resource might first acquire a lease to a host resource. A 'test
scaffold' resource might lease a storage resource and a mysql resource.
Not all resources are auto-allocate: the entry-level version of Drydock is that
you manually allocate a couple boxes and configure them through the web console.
Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the
host pool itself does not autoscale.
Resources are completely stock, they are abstract shells representing any
arbitrary thing.
Currently: Resource exist ('host' only) but are very very basic.
== Blueprints
Vision: Blueprints contain instructions for building interfaces to, (possibly)
allocating, updating, managing, and destroying a specific type of resource in a
specific location. One way to think of them is that they are scripts for
creating and deleting resources. For example, the LocalHost, RemoteHost and
EC2Host blueprints can all manage 'host' resources.
Eventually, we will support more types of resources (storage, webroot,
sandcastle, test scaffold, phacility deployment) and more providers for resource
types, some of which will be in the Phabricator mainline and some of which will
be custom.
Blueprints are very custom and specific to application types, so installs will
define new blueprints if they are making significant use of Drydock.
Currently: They exist but have few capabilities. The stock blueprints do nearly
nothing useful. There is a technically functional blueprint for host allocation
in EC2.
== Allocator
This is just the actual code to execute the lease acquisition process.
Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2,
acquired a lease on it, interfaced with it, and then released the lease. Ran it
again, got a fresh lease on the existing resource.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
|
|
|
'DrydockSSHCommandInterface' => 'DrydockCommandInterface',
|
2012-03-27 05:54:26 +02:00
|
|
|
'DrydockWebrootInterface' => 'DrydockInterface',
|
2012-11-27 21:48:14 +01:00
|
|
|
'DrydockWorkingCopyBlueprint' => 'DrydockBlueprint',
|
2012-11-02 21:34:18 +01:00
|
|
|
'FeedPublisherWorker' => 'PhabricatorWorker',
|
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',
|
2012-07-09 19:39:14 +02:00
|
|
|
'HarbormasterObject' => 'HarbormasterDAO',
|
2012-12-17 22:43:26 +01:00
|
|
|
'HarbormasterRunnerWorker' => 'PhabricatorWorker',
|
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',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldAction' => 'HeraldDAO',
|
|
|
|
'HeraldApplyTranscript' => 'HeraldDAO',
|
2011-04-04 08:23:36 +02:00
|
|
|
'HeraldCommitAdapter' => 'HeraldObjectAdapter',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldCondition' => 'HeraldDAO',
|
2011-03-22 21:49:46 +01:00
|
|
|
'HeraldController' => 'PhabricatorController',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldDAO' => 'PhabricatorLiskDAO',
|
2011-03-24 19:07:36 +01:00
|
|
|
'HeraldDeleteController' => 'HeraldController',
|
2011-03-25 05:32:26 +01:00
|
|
|
'HeraldDifferentialRevisionAdapter' => 'HeraldObjectAdapter',
|
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',
|
2011-03-22 21:49:46 +01:00
|
|
|
'HeraldHomeController' => 'HeraldController',
|
2012-05-30 23:26:29 +02:00
|
|
|
'HeraldInvalidConditionException' => 'Exception',
|
|
|
|
'HeraldInvalidFieldException' => 'Exception',
|
2011-03-22 22:34:38 +01:00
|
|
|
'HeraldNewController' => 'HeraldController',
|
2012-05-30 23:26:29 +02:00
|
|
|
'HeraldRecursiveConditionsException' => 'Exception',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldRule' => 'HeraldDAO',
|
2011-03-22 23:27:52 +01:00
|
|
|
'HeraldRuleController' => 'HeraldController',
|
2012-01-30 20:51:23 +01:00
|
|
|
'HeraldRuleEdit' => 'HeraldDAO',
|
|
|
|
'HeraldRuleEditHistoryController' => 'HeraldController',
|
|
|
|
'HeraldRuleEditHistoryView' => 'AphrontView',
|
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',
|
2011-03-24 21:49:21 +01:00
|
|
|
'HeraldTestConsoleController' => 'HeraldController',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldTranscript' => 'HeraldDAO',
|
2011-03-25 05:32:26 +01:00
|
|
|
'HeraldTranscriptController' => 'HeraldController',
|
|
|
|
'HeraldTranscriptListController' => 'HeraldController',
|
2011-09-07 23:01:13 +02:00
|
|
|
'JavelinReactorExample' => 'PhabricatorUIExample',
|
2012-07-31 01:08:10 +02:00
|
|
|
'JavelinUIExample' => 'PhabricatorUIExample',
|
2011-09-07 23:01:13 +02:00
|
|
|
'JavelinViewExample' => 'PhabricatorUIExample',
|
|
|
|
'JavelinViewExampleServerView' => 'AphrontView',
|
Implement a more compact, general database-backed key-value cache
Summary:
See discussion in D4204. Facebook currently has a 314MB remarkup cache with a 55MB index, which is slow to access. Under the theory that this is an index size/quality problem (the current index is on a potentially-384-byte field, with many keys sharing prefixes), provide a more general index with fancy new features:
- It implements PhutilKeyValueCache, so it can be a component in cache stacks and supports TTL.
- It has a 12-byte hash-based key.
- It automatically compresses large blocks of data (most of what we store is highly-compressible HTML).
Test Plan:
- Basics:
- Loaded /paste/, saw caches generate and save.
- Reloaded /paste/, saw the page hit cache.
- GC:
- Ran GC daemon, saw nothing.
- Set maximum lifetime to 1 second, ran GC daemon, saw it collect the entire cache.
- Deflate:
- Selected row formats from the database, saw a mixture of 'raw' and 'deflate' storage.
- Used profiler to verify that 'deflate' is fast (12 calls @ 220us on my paste list).
- Ran unit tests
Reviewers: vrana, btrahan
Reviewed By: vrana
CC: aran
Differential Revision: https://secure.phabricator.com/D4259
2012-12-21 23:17:56 +01:00
|
|
|
'LiskChunkTestCase' => 'PhabricatorTestCase',
|
2012-10-24 21:47:53 +02:00
|
|
|
'LiskDAOTestCase' => 'PhabricatorTestCase',
|
2012-05-30 23:26:29 +02:00
|
|
|
'LiskEphemeralObjectException' => 'Exception',
|
2012-05-02 21:42:23 +02:00
|
|
|
'LiskFixtureTestCase' => 'PhabricatorTestCase',
|
2011-04-30 19:11:59 +02:00
|
|
|
'LiskIsolationTestCase' => 'PhabricatorTestCase',
|
|
|
|
'LiskIsolationTestDAO' => 'LiskDAO',
|
2012-05-30 23:26:29 +02:00
|
|
|
'LiskIsolationTestDAOException' => 'Exception',
|
2012-07-26 22:09:36 +02:00
|
|
|
'LiskMigrationIterator' => 'PhutilBufferedIterator',
|
2012-06-13 23:41:43 +02:00
|
|
|
'ManiphestAction' => 'ManiphestConstants',
|
2011-07-27 18:49:50 +02:00
|
|
|
'ManiphestAuxiliaryFieldDefaultSpecification' => 'ManiphestAuxiliaryFieldSpecification',
|
2012-05-30 23:26:29 +02:00
|
|
|
'ManiphestAuxiliaryFieldTypeException' => 'Exception',
|
|
|
|
'ManiphestAuxiliaryFieldValidationException' => 'Exception',
|
2012-02-24 22:00:48 +01:00
|
|
|
'ManiphestBatchEditController' => 'ManiphestController',
|
2011-02-08 19:53:59 +01:00
|
|
|
'ManiphestController' => 'PhabricatorController',
|
|
|
|
'ManiphestDAO' => 'PhabricatorLiskDAO',
|
2011-08-05 18:44:43 +02:00
|
|
|
'ManiphestDefaultTaskExtensions' => 'ManiphestTaskExtensions',
|
2012-07-03 00:42:06 +02:00
|
|
|
'ManiphestEdgeEventListener' => 'PhutilEventListener',
|
2012-02-29 06:07:12 +01:00
|
|
|
'ManiphestExportController' => 'ManiphestController',
|
2013-02-05 22:46:02 +01:00
|
|
|
'ManiphestPeopleMenuEventListener' => 'PhutilEventListener',
|
2011-05-10 01:31:26 +02:00
|
|
|
'ManiphestReplyHandler' => 'PhabricatorMailReplyHandler',
|
2012-02-08 18:47:14 +01:00
|
|
|
'ManiphestReportController' => 'ManiphestController',
|
2012-04-10 18:46:04 +02:00
|
|
|
'ManiphestSavedQuery' => 'ManiphestDAO',
|
|
|
|
'ManiphestSavedQueryDeleteController' => 'ManiphestController',
|
|
|
|
'ManiphestSavedQueryEditController' => 'ManiphestController',
|
|
|
|
'ManiphestSavedQueryListController' => 'ManiphestController',
|
Improve Search architecture
Summary:
The search indexing API has several problems right now:
- Always runs in-process.
- It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it.
- Being able to use the task queue will also make rebuilding indexes faster.
- Instead, make the API phid-oriented.
- No uniform indexing API.
- Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird.
- Instead, provide a uniform API.
- No uniform CLI.
- We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers.
- Instead, let indexers expose documents for indexing.
- Not application-oriented.
- All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world.
- Instead, move indexers to applications and load them with SymbolLoader.
Test Plan:
- `bin/search index`
- Indexed one revision, one task.
- Indexed `--type TASK`, `--type DREV`, etc., for all types.
- Indexed `--all`.
- Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it.
- Creating users is a pain; searched for a user after indexing.
- Creating commits is a pain; searched for a commit after indexing.
- Mocks aren't currently loadable in the result view, so their indexing is moot.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: 20after4, aran
Maniphest Tasks: T1991, T2104
Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
|
|
|
'ManiphestSearchIndexer' => 'PhabricatorSearchDocumentIndexer',
|
2012-04-02 21:12:04 +02:00
|
|
|
'ManiphestSubpriorityController' => 'ManiphestController',
|
2012-07-16 20:49:06 +02:00
|
|
|
'ManiphestTask' =>
|
|
|
|
array(
|
|
|
|
0 => 'ManiphestDAO',
|
|
|
|
1 => 'PhabricatorMarkupInterface',
|
|
|
|
),
|
2011-07-26 00:34:56 +02:00
|
|
|
'ManiphestTaskAuxiliaryStorage' => 'ManiphestDAO',
|
2011-05-21 03:56:18 +02:00
|
|
|
'ManiphestTaskDescriptionChangeController' => 'ManiphestController',
|
2012-01-25 20:23:00 +01:00
|
|
|
'ManiphestTaskDescriptionPreviewController' => 'ManiphestController',
|
2011-02-08 19:53:59 +01:00
|
|
|
'ManiphestTaskDetailController' => 'ManiphestController',
|
2011-02-20 23:15:53 +01:00
|
|
|
'ManiphestTaskEditController' => 'ManiphestController',
|
2011-02-08 19:53:59 +01:00
|
|
|
'ManiphestTaskListController' => 'ManiphestController',
|
2011-07-04 22:04:22 +02:00
|
|
|
'ManiphestTaskListView' => 'ManiphestView',
|
|
|
|
'ManiphestTaskOwner' => 'ManiphestConstants',
|
|
|
|
'ManiphestTaskPriority' => 'ManiphestConstants',
|
2011-06-30 01:16:33 +02:00
|
|
|
'ManiphestTaskProject' => 'ManiphestDAO',
|
2012-04-02 19:27:31 +02:00
|
|
|
'ManiphestTaskProjectsView' => 'ManiphestView',
|
2012-10-05 22:18:05 +02:00
|
|
|
'ManiphestTaskQuery' => 'PhabricatorQuery',
|
2011-07-04 22:04:22 +02:00
|
|
|
'ManiphestTaskStatus' => 'ManiphestConstants',
|
2011-07-07 19:24:49 +02:00
|
|
|
'ManiphestTaskSubscriber' => 'ManiphestDAO',
|
2011-07-04 22:04:22 +02:00
|
|
|
'ManiphestTaskSummaryView' => 'ManiphestView',
|
2012-07-16 20:49:06 +02:00
|
|
|
'ManiphestTransaction' =>
|
|
|
|
array(
|
|
|
|
0 => 'ManiphestDAO',
|
|
|
|
1 => 'PhabricatorMarkupInterface',
|
|
|
|
),
|
2011-07-04 22:04:22 +02:00
|
|
|
'ManiphestTransactionDetailView' => 'ManiphestView',
|
2012-10-10 19:18:23 +02:00
|
|
|
'ManiphestTransactionEditor' => 'PhabricatorEditor',
|
2011-07-04 22:04:22 +02:00
|
|
|
'ManiphestTransactionListView' => 'ManiphestView',
|
2011-05-10 17:29:28 +02:00
|
|
|
'ManiphestTransactionPreviewController' => 'ManiphestController',
|
2011-02-08 19:53:59 +01:00
|
|
|
'ManiphestTransactionSaveController' => 'ManiphestController',
|
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',
|
2011-01-30 01:16:09 +01:00
|
|
|
'Phabricator404Controller' => 'PhabricatorController',
|
2013-01-01 23:09:29 +01:00
|
|
|
'PhabricatorAWSConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2013-01-01 23:09:17 +01:00
|
|
|
'PhabricatorAccessLogConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2012-10-03 19:21:39 +02:00
|
|
|
'PhabricatorActionListExample' => 'PhabricatorUIExample',
|
2012-08-15 19:45:06 +02:00
|
|
|
'PhabricatorActionListView' => 'AphrontView',
|
|
|
|
'PhabricatorActionView' => 'AphrontView',
|
2013-01-25 01:11:30 +01:00
|
|
|
'PhabricatorAllCapsTranslation' => 'PhabricatorTranslation',
|
2012-08-22 00:01:20 +02:00
|
|
|
'PhabricatorAnchorView' => 'AphrontView',
|
2012-08-02 23:07:21 +02:00
|
|
|
'PhabricatorApplicationApplications' => 'PhabricatorApplication',
|
|
|
|
'PhabricatorApplicationAudit' => 'PhabricatorApplication',
|
2012-08-05 23:12:43 +02:00
|
|
|
'PhabricatorApplicationAuth' => 'PhabricatorApplication',
|
2012-10-24 22:22:24 +02:00
|
|
|
'PhabricatorApplicationCalendar' => 'PhabricatorApplication',
|
2012-10-01 21:56:10 +02:00
|
|
|
'PhabricatorApplicationConduit' => 'PhabricatorApplication',
|
2012-12-28 00:20:09 +01:00
|
|
|
'PhabricatorApplicationConfig' => 'PhabricatorApplication',
|
2012-12-31 00:36:06 +01:00
|
|
|
'PhabricatorApplicationConfigOptions' => 'Phobject',
|
2013-01-25 02:23:05 +01:00
|
|
|
'PhabricatorApplicationConpherence' => 'PhabricatorApplication',
|
2012-10-01 21:56:02 +02:00
|
|
|
'PhabricatorApplicationCountdown' => 'PhabricatorApplication',
|
2012-08-14 00:27:45 +02:00
|
|
|
'PhabricatorApplicationDaemons' => 'PhabricatorApplication',
|
2013-01-24 21:13:31 +01:00
|
|
|
'PhabricatorApplicationDetailViewController' => 'PhabricatorApplicationsController',
|
2012-07-30 19:43:49 +02:00
|
|
|
'PhabricatorApplicationDifferential' => 'PhabricatorApplication',
|
2012-08-02 23:07:21 +02:00
|
|
|
'PhabricatorApplicationDiffusion' => 'PhabricatorApplication',
|
2012-08-14 00:28:41 +02:00
|
|
|
'PhabricatorApplicationDiviner' => 'PhabricatorApplication',
|
2012-10-31 17:57:57 +01:00
|
|
|
'PhabricatorApplicationDrydock' => 'PhabricatorApplication',
|
2012-07-30 19:44:08 +02:00
|
|
|
'PhabricatorApplicationFact' => 'PhabricatorApplication',
|
2013-01-11 01:06:29 +01:00
|
|
|
'PhabricatorApplicationFeed' => 'PhabricatorApplication',
|
2012-10-01 23:05:12 +02:00
|
|
|
'PhabricatorApplicationFiles' => 'PhabricatorApplication',
|
2012-08-02 23:07:21 +02:00
|
|
|
'PhabricatorApplicationFlags' => 'PhabricatorApplication',
|
2012-10-01 21:56:10 +02:00
|
|
|
'PhabricatorApplicationHerald' => 'PhabricatorApplication',
|
2012-08-02 23:07:21 +02:00
|
|
|
'PhabricatorApplicationLaunchView' => 'AphrontView',
|
2012-10-01 23:04:03 +02:00
|
|
|
'PhabricatorApplicationMacro' => 'PhabricatorApplication',
|
2012-08-13 04:19:46 +02:00
|
|
|
'PhabricatorApplicationMailingLists' => 'PhabricatorApplication',
|
2012-07-30 19:43:49 +02:00
|
|
|
'PhabricatorApplicationManiphest' => 'PhabricatorApplication',
|
2012-08-13 21:37:06 +02:00
|
|
|
'PhabricatorApplicationMetaMTA' => 'PhabricatorApplication',
|
2012-10-01 21:56:33 +02:00
|
|
|
'PhabricatorApplicationOwners' => 'PhabricatorApplication',
|
|
|
|
'PhabricatorApplicationPHID' => 'PhabricatorApplication',
|
|
|
|
'PhabricatorApplicationPHPAST' => 'PhabricatorApplication',
|
2012-08-15 19:45:06 +02:00
|
|
|
'PhabricatorApplicationPaste' => 'PhabricatorApplication',
|
2012-08-05 23:12:43 +02:00
|
|
|
'PhabricatorApplicationPeople' => 'PhabricatorApplication',
|
2012-10-02 00:37:02 +02:00
|
|
|
'PhabricatorApplicationPhame' => 'PhabricatorApplication',
|
Add very basic scaffolding for Pholio
Summary:
I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc.
Basic hierarchy is:
- **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas".
- **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed.
- **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits.
- **PixelComment**: Equivalent of an inline comment.
Test Plan: Created a fake object and viewed it.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: aran, davidreuss
Maniphest Tasks: T2097
Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
|
|
|
'PhabricatorApplicationPholio' => 'PhabricatorApplication',
|
2012-08-02 23:07:21 +02:00
|
|
|
'PhabricatorApplicationPhriction' => 'PhabricatorApplication',
|
2012-08-10 19:44:04 +02:00
|
|
|
'PhabricatorApplicationPonder' => 'PhabricatorApplication',
|
2012-08-07 20:54:49 +02:00
|
|
|
'PhabricatorApplicationProject' => 'PhabricatorApplication',
|
2012-10-01 21:56:33 +02:00
|
|
|
'PhabricatorApplicationRepositories' => 'PhabricatorApplication',
|
2012-08-05 23:12:43 +02:00
|
|
|
'PhabricatorApplicationSettings' => 'PhabricatorApplication',
|
2012-10-01 21:56:02 +02:00
|
|
|
'PhabricatorApplicationSlowvote' => 'PhabricatorApplication',
|
2012-08-02 23:07:21 +02:00
|
|
|
'PhabricatorApplicationStatusView' => 'AphrontView',
|
2012-10-05 22:18:05 +02:00
|
|
|
'PhabricatorApplicationSubscriptions' => 'PhabricatorApplication',
|
2012-12-11 23:00:21 +01:00
|
|
|
'PhabricatorApplicationTransaction' =>
|
|
|
|
array(
|
|
|
|
0 => 'PhabricatorLiskDAO',
|
|
|
|
1 => 'PhabricatorPolicyInterface',
|
|
|
|
),
|
2012-12-11 22:59:20 +01:00
|
|
|
'PhabricatorApplicationTransactionComment' =>
|
|
|
|
array(
|
|
|
|
0 => 'PhabricatorLiskDAO',
|
|
|
|
1 => 'PhabricatorMarkupInterface',
|
2012-12-11 23:00:21 +01:00
|
|
|
2 => 'PhabricatorPolicyInterface',
|
2012-12-11 22:59:20 +01:00
|
|
|
),
|
2012-12-11 23:01:51 +01:00
|
|
|
'PhabricatorApplicationTransactionCommentEditController' => 'PhabricatorApplicationTransactionController',
|
2012-12-11 22:59:20 +01:00
|
|
|
'PhabricatorApplicationTransactionCommentEditor' => 'PhabricatorEditor',
|
2012-12-11 23:01:51 +01:00
|
|
|
'PhabricatorApplicationTransactionCommentHistoryController' => 'PhabricatorApplicationTransactionController',
|
2012-12-11 22:59:20 +01:00
|
|
|
'PhabricatorApplicationTransactionCommentQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
|
2012-12-21 14:51:33 +01:00
|
|
|
'PhabricatorApplicationTransactionCommentView' => 'AphrontView',
|
2012-12-11 23:01:51 +01:00
|
|
|
'PhabricatorApplicationTransactionController' => 'PhabricatorController',
|
2012-12-11 22:59:20 +01:00
|
|
|
'PhabricatorApplicationTransactionEditor' => 'PhabricatorEditor',
|
2012-12-11 23:00:21 +01:00
|
|
|
'PhabricatorApplicationTransactionFeedStory' => 'PhabricatorFeedStory',
|
Add ApplicationTransaction handling for transactions with no effect
Summary:
When a user submits an action with no effect (like an empty comment, an "abandon" on an already-accepted revision, or a "close, resolved" on a closed task) we want to alert them that their action isn't effective. These warnings fall into two general buckets:
- User is submitting two or more actions, and some aren't effective but some are. Prompt them to apply the effective actions only.
- A special case of this is where the only effective action is a comment. We provide tailored text ("Post Comment") in this case.
- User is submitting one action, which isn't effective. Tell them they're out of luck.
- A special case of this is an empty comment. We provide tailored text in this case.
By default, the transaction editor throws when transactions have no effect. The caller can then deal with this, or use `PhabricatorApplicationTransactionNoEffectResponse` to provide a standard dialog that gives the user information as above. For cases where we expect transactions to have no effect (notably, "edit" forms) we just continue on no-effect unconditionally.
Also fix an issue where new, combined or filtered transactions would not be represented properly in the Ajax response (i.e., return final transactions from `applyTransactions()`), and translate some strings.
Test Plan:
- Submitted empty and nonempy comments in Macro and Pholio.
- Submitted comments with new and existing "@mentions".
- Submitted edits in both applications.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T912, T2104
Differential Revision: https://secure.phabricator.com/D4160
2012-12-12 02:27:40 +01:00
|
|
|
'PhabricatorApplicationTransactionNoEffectException' => 'Exception',
|
|
|
|
'PhabricatorApplicationTransactionNoEffectResponse' => 'AphrontProxyResponse',
|
2012-12-11 22:59:20 +01:00
|
|
|
'PhabricatorApplicationTransactionQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
|
2012-12-11 23:02:29 +01:00
|
|
|
'PhabricatorApplicationTransactionResponse' => 'AphrontProxyResponse',
|
Modernize Macro application
Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro.
Test Plan:
{F26839}
{F26840}
{F26841}
{F26842}
{F26843}
{F26844}
{F26845}
Reviewers: vrana, btrahan, chad
Reviewed By: vrana
CC: aran
Maniphest Tasks: T2157, T175, T2104
Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
|
|
|
'PhabricatorApplicationTransactionView' => 'AphrontView',
|
2012-12-11 22:59:20 +01:00
|
|
|
'PhabricatorApplicationTransactions' => 'PhabricatorApplication',
|
2012-09-11 18:56:40 +02:00
|
|
|
'PhabricatorApplicationUIExamples' => 'PhabricatorApplication',
|
2013-01-29 18:14:03 +01:00
|
|
|
'PhabricatorApplicationUninstallController' => 'PhabricatorApplicationsController',
|
2013-01-19 22:46:48 +01:00
|
|
|
'PhabricatorApplicationsController' => 'PhabricatorController',
|
|
|
|
'PhabricatorApplicationsListController' => 'PhabricatorApplicationsController',
|
2012-02-25 00:04:53 +01:00
|
|
|
'PhabricatorAuditAddCommentController' => 'PhabricatorAuditController',
|
2012-10-24 22:22:24 +02:00
|
|
|
'PhabricatorAuditComment' =>
|
|
|
|
array(
|
|
|
|
0 => 'PhabricatorAuditDAO',
|
|
|
|
1 => 'PhabricatorMarkupInterface',
|
|
|
|
),
|
2012-10-10 19:18:23 +02:00
|
|
|
'PhabricatorAuditCommentEditor' => 'PhabricatorEditor',
|
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',
|
2012-05-30 23:26:29 +02:00
|
|
|
'PhabricatorAuditInlineComment' =>
|
|
|
|
array(
|
|
|
|
0 => 'PhabricatorAuditDAO',
|
|
|
|
1 => 'PhabricatorInlineCommentInterface',
|
|
|
|
),
|
2012-02-24 22:02:14 +01:00
|
|
|
'PhabricatorAuditListController' => 'PhabricatorAuditController',
|
|
|
|
'PhabricatorAuditListView' => 'AphrontView',
|
2012-02-27 22:00:23 +01:00
|
|
|
'PhabricatorAuditPreviewController' => 'PhabricatorAuditController',
|
2012-02-27 21:57:57 +01:00
|
|
|
'PhabricatorAuditReplyHandler' => 'PhabricatorMailReplyHandler',
|
2011-01-26 22:21:12 +01:00
|
|
|
'PhabricatorAuthController' => 'PhabricatorController',
|
2013-01-07 21:48:39 +01:00
|
|
|
'PhabricatorAuthenticationConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2012-10-16 19:33:47 +02:00
|
|
|
'PhabricatorBarePageExample' => 'PhabricatorUIExample',
|
|
|
|
'PhabricatorBarePageView' => 'AphrontPageView',
|
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',
|
2012-11-08 17:22:08 +01:00
|
|
|
'PhabricatorButtonsExample' => 'PhabricatorUIExample',
|
Add a generic multistep Markup cache
Summary:
The immediate issue this addresses is T1366, adding a rendering cache to Phriction. For wiki pages with code blocks especially, rerendering them each time is expensive.
The broader issue is that out markup caches aren't very good right now. They have three major problems:
**Problem 1: the data is stored in the wrong place.** We currently store remarkup caches on objects. This means we're always loading it and passing it around even when we don't need it, can't genericize cache management code (e.g., have one simple script to drop/GC caches), need to update authoritative rows to clear caches, and can't genericize rendering code since each object is different.
To solve this, I created a dedicated cache database that I plan to move all markup caches to use.
**Problem 2: time-variant rules break when cached.** Some rules like `**bold**` are time-invariant and always produce the same output, but some rules like `{Tnnn}` and `@username` are variant and may render differently (because a task was closed or a user is on vacation). Currently, we cache the raw output, so these time-variant rules get locked at whatever values they had when they were first rendered. This is the main reason Phriction doesn't have a cache right now -- I wanted `{Tnnn}` rules to reflect open/closed tasks.
To solve this, I split markup into a "preprocessing" phase (which does all the parsing and evaluates all time-invariant rules) and a "postprocessing" phase (which evaluates time-variant rules only). The preprocessing phase is most of the expense (and, notably, includes syntax highlighting) so this is nearly as good as caching the final output. I did most of the work here in D737 / D738, but we never moved to use it in Phabricator -- we currently just do the two operations serially in all cases.
This diff splits them apart and caches the output of preprocessing only, so we benefit from caching but also get accurate time-variant rendering.
**Problem 3: cache access isn't batched/pipelined optimally.** When we're rendering a list of markup blocks, we should be able to batch datafetching better than we do. D738 helped with this (fetching is batched within a single hunk of markup) and this improves batching on cache access. We could still do better here, but this is at least a step forward.
Also fixes a bug with generating a link in the Phriction history interface ($uri gets clobbered).
I'm using PHP serialization instead of JSON serialization because Remarkup does some stuff with non-ascii characters that might not survive JSON.
Test Plan:
- Created a Phriction document and verified that previews don't go to cache (no rows appear in the cache table).
- Verified that published documents come out of cache.
- Verified that caches generate/regenerate correctly, time-variant rules render properly and old documents hit the right caches.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T1366
Differential Revision: https://secure.phabricator.com/D2945
2012-07-10 00:20:56 +02:00
|
|
|
'PhabricatorCacheDAO' => 'PhabricatorLiskDAO',
|
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',
|
2012-05-03 09:21:47 +02:00
|
|
|
'PhabricatorCalendarDAO' => 'PhabricatorLiskDAO',
|
2012-10-24 22:22:24 +02:00
|
|
|
'PhabricatorCalendarDeleteStatusController' => 'PhabricatorCalendarController',
|
|
|
|
'PhabricatorCalendarEditStatusController' => 'PhabricatorCalendarController',
|
2012-05-03 09:21:47 +02:00
|
|
|
'PhabricatorCalendarHoliday' => 'PhabricatorCalendarDAO',
|
2012-05-03 21:16:09 +02:00
|
|
|
'PhabricatorCalendarHolidayTestCase' => 'PhabricatorTestCase',
|
2012-10-24 22:22:24 +02:00
|
|
|
'PhabricatorCalendarViewStatusController' => 'PhabricatorCalendarController',
|
2012-03-13 05:39:05 +01:00
|
|
|
'PhabricatorChangesetResponse' => 'AphrontProxyResponse',
|
2012-02-17 19:21:38 +01:00
|
|
|
'PhabricatorChatLogChannelListController' => 'PhabricatorChatLogController',
|
|
|
|
'PhabricatorChatLogChannelLogController' => 'PhabricatorChatLogController',
|
|
|
|
'PhabricatorChatLogController' => 'PhabricatorController',
|
|
|
|
'PhabricatorChatLogDAO' => 'PhabricatorLiskDAO',
|
2012-06-02 23:00:08 +02:00
|
|
|
'PhabricatorChatLogEvent' =>
|
|
|
|
array(
|
|
|
|
0 => 'PhabricatorChatLogDAO',
|
|
|
|
1 => 'PhabricatorPolicyInterface',
|
|
|
|
),
|
2012-02-17 19:21:38 +01:00
|
|
|
'PhabricatorChatLogEventType' => 'PhabricatorChatLogConstants',
|
2012-09-13 19:15:08 +02:00
|
|
|
'PhabricatorChatLogQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
|
2011-01-24 18:00:29 +01:00
|
|
|
'PhabricatorConduitAPIController' => 'PhabricatorConduitController',
|
2011-06-14 21:17:14 +02:00
|
|
|
'PhabricatorConduitCertificateToken' => 'PhabricatorConduitDAO',
|
2011-01-24 18:00:29 +01:00
|
|
|
'PhabricatorConduitConnectionLog' => 'PhabricatorConduitDAO',
|
|
|
|
'PhabricatorConduitConsoleController' => 'PhabricatorConduitController',
|
|
|
|
'PhabricatorConduitController' => 'PhabricatorController',
|
|
|
|
'PhabricatorConduitDAO' => 'PhabricatorLiskDAO',
|
2012-04-27 07:25:05 +02:00
|
|
|
'PhabricatorConduitListController' => 'PhabricatorConduitController',
|
2011-01-24 18:00:29 +01:00
|
|
|
'PhabricatorConduitLogController' => 'PhabricatorConduitController',
|
|
|
|
'PhabricatorConduitMethodCallLog' => 'PhabricatorConduitDAO',
|
2011-06-14 21:17:14 +02:00
|
|
|
'PhabricatorConduitTokenController' => 'PhabricatorConduitController',
|
2013-01-16 20:10:41 +01:00
|
|
|
'PhabricatorConfigAllController' => 'PhabricatorConfigController',
|
2012-12-28 00:20:09 +01:00
|
|
|
'PhabricatorConfigController' => 'PhabricatorController',
|
Add database configuration source to the source stack
Summary:
Read configuration from the new database source.
This adds an extra MySQL connect + query to every page. They're very cheap so I think we can suffer them for now, but I'd like to put cache in front of this at some point. The difficulties are:
- If we use APC, multi-frontend installs (Facebook) can't dirty it (major problem), and the CLI can't dirty it (fine for now, maybe a major problem later).
- If we use Memcache, we need to add config stuff.
- We could use APC in all non-Facebook installs if we can make it dirtyable from the CLI, but I don't see a reasonable way to do that.
- We don't have any other caches which are faster than the database.
So I'll probably implement Memcache support at some point, although this is a lame excuse for it.
Test Plan: Added some config values via web UI, saw them active on the install.
Reviewers: btrahan, codeblock, vrana
Reviewed By: codeblock
CC: aran
Maniphest Tasks: T2221
Differential Revision: https://secure.phabricator.com/D4296
2013-01-18 00:10:21 +01:00
|
|
|
'PhabricatorConfigDatabaseSource' => 'PhabricatorConfigProxySource',
|
2013-01-01 23:10:33 +01:00
|
|
|
'PhabricatorConfigDefaultSource' => 'PhabricatorConfigProxySource',
|
2012-12-25 15:44:29 +01:00
|
|
|
'PhabricatorConfigDictionarySource' => 'PhabricatorConfigSource',
|
2012-12-28 00:20:09 +01:00
|
|
|
'PhabricatorConfigEditController' => 'PhabricatorConfigController',
|
2013-01-02 03:14:41 +01:00
|
|
|
'PhabricatorConfigEditor' => 'PhabricatorApplicationTransactionEditor',
|
2012-12-28 00:20:09 +01:00
|
|
|
'PhabricatorConfigEntry' => 'PhabricatorConfigEntryDAO',
|
|
|
|
'PhabricatorConfigEntryDAO' => 'PhabricatorLiskDAO',
|
2012-12-25 15:44:29 +01:00
|
|
|
'PhabricatorConfigFileSource' => 'PhabricatorConfigProxySource',
|
2012-12-31 00:36:06 +01:00
|
|
|
'PhabricatorConfigGroupController' => 'PhabricatorConfigController',
|
2012-12-30 15:37:49 +01:00
|
|
|
'PhabricatorConfigIssueListController' => 'PhabricatorConfigController',
|
|
|
|
'PhabricatorConfigIssueViewController' => 'PhabricatorConfigController',
|
2012-12-28 00:20:09 +01:00
|
|
|
'PhabricatorConfigListController' => 'PhabricatorConfigController',
|
Add a local configuration source and a non-environmental ENV config source
Summary:
See discussion in T2221. Before we can move configuration to the database, we have a bootstrapping problem: we need database credentials to live //somewhere// if we can't guess them (and we can only really guess localhost / root / no password).
Some options for this are:
- Have them live in ENV variables.
- These are often somewhat unfamiliar to users.
- Scripts would become a huge pain -- you'd have to dump a bunch of stuff into ENV.
- Some environments have limited ability to set ENV vars.
- SSH is also a pain.
- Have them live in a normal config file.
- This probably isn't really too awful, but:
- Since we deploy/upgrade with git, we can't currently let them edit a file which already exists, or their working copy will become dirty.
- So they have to copy or create a file, then edit it.
- The biggest issue I have with this is that it will be difficult to give specific, easily-followed directions from Setup. The instructions need to be like "Copy template.conf.php to real.conf.php, then edit these keys: x, y, z". This isn't as easy to follow as "run script Y".
- Have them live in an abnormal config file with script access (this diff).
- I think this is a little better than a normal config file, because we can tell users 'run phabricator/bin/config set mysql.user phabricator' and such, which is easier to follow than editing a config file.
I think this is only a marginal improvement over a normal config file and am open to arguments against this approach, but I think it will be a little easier for users to deal with than a normal config file. In most cases they should only need to store three values in this file -- db user/host/pass -- since once we have those we can bootstrap everything else. Normal config files also aren't going away for more advanced users, we're just offering a simple alternative for most users.
This also adds an ENVIRONMENT file as an alternative to PHABRICATOR_ENV. This is just a simple way to specify the environment if you don't have convenient access to env vars.
Test Plan: Ran `config set x y`, verified writes. Wrote to ENVIRONMENT, ran `PHABRICATOR_ENV= ./bin/repository`.
Reviewers: btrahan, vrana, codeblock
Reviewed By: codeblock
CC: aran
Maniphest Tasks: T2221
Differential Revision: https://secure.phabricator.com/D4294
2012-12-30 15:16:15 +01:00
|
|
|
'PhabricatorConfigLocalSource' => 'PhabricatorConfigProxySource',
|
2013-01-22 00:27:42 +01:00
|
|
|
'PhabricatorConfigManagementDeleteWorkflow' => 'PhabricatorConfigManagementWorkflow',
|
|
|
|
'PhabricatorConfigManagementGetWorkflow' => 'PhabricatorConfigManagementWorkflow',
|
|
|
|
'PhabricatorConfigManagementListWorkflow' => 'PhabricatorConfigManagementWorkflow',
|
Add a local configuration source and a non-environmental ENV config source
Summary:
See discussion in T2221. Before we can move configuration to the database, we have a bootstrapping problem: we need database credentials to live //somewhere// if we can't guess them (and we can only really guess localhost / root / no password).
Some options for this are:
- Have them live in ENV variables.
- These are often somewhat unfamiliar to users.
- Scripts would become a huge pain -- you'd have to dump a bunch of stuff into ENV.
- Some environments have limited ability to set ENV vars.
- SSH is also a pain.
- Have them live in a normal config file.
- This probably isn't really too awful, but:
- Since we deploy/upgrade with git, we can't currently let them edit a file which already exists, or their working copy will become dirty.
- So they have to copy or create a file, then edit it.
- The biggest issue I have with this is that it will be difficult to give specific, easily-followed directions from Setup. The instructions need to be like "Copy template.conf.php to real.conf.php, then edit these keys: x, y, z". This isn't as easy to follow as "run script Y".
- Have them live in an abnormal config file with script access (this diff).
- I think this is a little better than a normal config file, because we can tell users 'run phabricator/bin/config set mysql.user phabricator' and such, which is easier to follow than editing a config file.
I think this is only a marginal improvement over a normal config file and am open to arguments against this approach, but I think it will be a little easier for users to deal with than a normal config file. In most cases they should only need to store three values in this file -- db user/host/pass -- since once we have those we can bootstrap everything else. Normal config files also aren't going away for more advanced users, we're just offering a simple alternative for most users.
This also adds an ENVIRONMENT file as an alternative to PHABRICATOR_ENV. This is just a simple way to specify the environment if you don't have convenient access to env vars.
Test Plan: Ran `config set x y`, verified writes. Wrote to ENVIRONMENT, ran `PHABRICATOR_ENV= ./bin/repository`.
Reviewers: btrahan, vrana, codeblock
Reviewed By: codeblock
CC: aran
Maniphest Tasks: T2221
Differential Revision: https://secure.phabricator.com/D4294
2012-12-30 15:16:15 +01:00
|
|
|
'PhabricatorConfigManagementSetWorkflow' => 'PhabricatorConfigManagementWorkflow',
|
|
|
|
'PhabricatorConfigManagementWorkflow' => 'PhutilArgumentWorkflow',
|
2013-01-01 23:09:29 +01:00
|
|
|
'PhabricatorConfigOption' =>
|
|
|
|
array(
|
|
|
|
0 => 'Phobject',
|
|
|
|
1 => 'PhabricatorMarkupInterface',
|
|
|
|
),
|
2012-12-25 15:44:29 +01:00
|
|
|
'PhabricatorConfigProxySource' => 'PhabricatorConfigSource',
|
2013-01-23 00:16:26 +01:00
|
|
|
'PhabricatorConfigResponse' => 'AphrontHTMLResponse',
|
2012-12-25 15:44:29 +01:00
|
|
|
'PhabricatorConfigStackSource' => 'PhabricatorConfigSource',
|
2013-01-02 03:14:41 +01:00
|
|
|
'PhabricatorConfigTransaction' => 'PhabricatorApplicationTransaction',
|
|
|
|
'PhabricatorConfigTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
|
2013-01-02 03:15:03 +01:00
|
|
|
'PhabricatorConfigValidationException' => 'Exception',
|
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',
|
2011-01-23 02:48:55 +01:00
|
|
|
'PhabricatorController' => 'AphrontController',
|
2013-01-02 03:22:48 +01:00
|
|
|
'PhabricatorCoreConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2011-06-13 01:06:17 +02:00
|
|
|
'PhabricatorCountdownController' => 'PhabricatorController',
|
|
|
|
'PhabricatorCountdownDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'PhabricatorCountdownDeleteController' => 'PhabricatorCountdownController',
|
|
|
|
'PhabricatorCountdownEditController' => 'PhabricatorCountdownController',
|
|
|
|
'PhabricatorCountdownListController' => 'PhabricatorCountdownController',
|
|
|
|
'PhabricatorCountdownViewController' => 'PhabricatorCountdownController',
|
2012-12-07 22:35:17 +01:00
|
|
|
'PhabricatorCrumbView' => 'AphrontView',
|
|
|
|
'PhabricatorCrumbsView' => 'AphrontView',
|
2012-09-13 19:15:08 +02:00
|
|
|
'PhabricatorCursorPagedPolicyAwareQuery' => 'PhabricatorPolicyAwareQuery',
|
2011-03-07 07:29:22 +01:00
|
|
|
'PhabricatorDaemon' => 'PhutilDaemon',
|
2011-05-03 02:05:22 +02:00
|
|
|
'PhabricatorDaemonCombinedLogController' => 'PhabricatorDaemonController',
|
2011-03-10 22:48:29 +01:00
|
|
|
'PhabricatorDaemonConsoleController' => 'PhabricatorDaemonController',
|
|
|
|
'PhabricatorDaemonController' => 'PhabricatorController',
|
2011-03-15 21:38:14 +01:00
|
|
|
'PhabricatorDaemonDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'PhabricatorDaemonLog' => 'PhabricatorDaemonDAO',
|
|
|
|
'PhabricatorDaemonLogEvent' => 'PhabricatorDaemonDAO',
|
2011-05-03 02:05:22 +02:00
|
|
|
'PhabricatorDaemonLogEventsView' => 'AphrontView',
|
|
|
|
'PhabricatorDaemonLogListController' => 'PhabricatorDaemonController',
|
|
|
|
'PhabricatorDaemonLogListView' => 'AphrontView',
|
2011-03-15 21:38:14 +01:00
|
|
|
'PhabricatorDaemonLogViewController' => 'PhabricatorDaemonController',
|
2011-07-20 07:48:38 +02:00
|
|
|
'PhabricatorDefaultFileStorageEngineSelector' => 'PhabricatorFileStorageEngineSelector',
|
2011-08-08 00:14:23 +02:00
|
|
|
'PhabricatorDefaultSearchEngineSelector' => 'PhabricatorSearchEngineSelector',
|
2013-01-01 23:09:17 +01:00
|
|
|
'PhabricatorDeveloperConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2012-12-31 00:36:06 +01:00
|
|
|
'PhabricatorDifferentialConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2013-01-16 18:08:13 +01:00
|
|
|
'PhabricatorDiffusionConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2011-01-23 02:48:55 +01:00
|
|
|
'PhabricatorDirectoryController' => 'PhabricatorController',
|
2012-05-01 19:15:56 +02:00
|
|
|
'PhabricatorDirectoryMainController' => 'PhabricatorDirectoryController',
|
2011-05-12 19:06:54 +02:00
|
|
|
'PhabricatorDisabledUserController' => 'PhabricatorAuthController',
|
2013-01-01 23:09:29 +01:00
|
|
|
'PhabricatorDisqusConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
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',
|
2012-10-10 19:18:23 +02:00
|
|
|
'PhabricatorEdgeEditor' => 'PhabricatorEditor',
|
Allow edges to be configured to prevent cycles
Summary:
Certain types of things we should be storing in edges (notably, Task X depends on Task Y) should always be acyclic. Allow `PhabricatorEdgeEditor` to enforce this, since we can't correctly enforce it outside of the editor without being vulnerable to races.
Each edge type can be marked acyclic. If an edge type is acyclic, we perform additional steps when writing new edges of that type:
- We acquire a global lock on the edge type before performing any reads or writes. This ensures we can't produce a cycle as a result of a race where two edits add edges which independently do not produce a cycle, but do produce a cycle when combined.
- After performing writes but before committing transactions, we load the edge graph for each acyclic type and verify that it is, in fact, acyclic. If we detect cycles, we abort the edit.
- When we're done, we release the edge type locks.
This is a relatively high-complexity change, but gives us a simple way to flag an edge type as acyclic in a robust way.
Test Plan: Ran unit tests.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T1162
Differential Revision: https://secure.phabricator.com/D2940
2012-07-09 19:39:38 +02:00
|
|
|
'PhabricatorEdgeGraph' => 'AbstractDirectedGraph',
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-05 00:30:21 +02:00
|
|
|
'PhabricatorEdgeQuery' => 'PhabricatorQuery',
|
Allow edges to be configured to prevent cycles
Summary:
Certain types of things we should be storing in edges (notably, Task X depends on Task Y) should always be acyclic. Allow `PhabricatorEdgeEditor` to enforce this, since we can't correctly enforce it outside of the editor without being vulnerable to races.
Each edge type can be marked acyclic. If an edge type is acyclic, we perform additional steps when writing new edges of that type:
- We acquire a global lock on the edge type before performing any reads or writes. This ensures we can't produce a cycle as a result of a race where two edits add edges which independently do not produce a cycle, but do produce a cycle when combined.
- After performing writes but before committing transactions, we load the edge graph for each acyclic type and verify that it is, in fact, acyclic. If we detect cycles, we abort the edit.
- When we're done, we release the edge type locks.
This is a relatively high-complexity change, but gives us a simple way to flag an edge type as acyclic in a robust way.
Test Plan: Ran unit tests.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T1162
Differential Revision: https://secure.phabricator.com/D2940
2012-07-09 19:39:38 +02:00
|
|
|
'PhabricatorEdgeTestCase' => 'PhabricatorTestCase',
|
2012-10-23 04:06:56 +02:00
|
|
|
'PhabricatorEditor' => 'Phobject',
|
2011-01-31 20:55:26 +01:00
|
|
|
'PhabricatorEmailLoginController' => 'PhabricatorAuthController',
|
|
|
|
'PhabricatorEmailTokenController' => 'PhabricatorAuthController',
|
2012-05-07 19:29:33 +02:00
|
|
|
'PhabricatorEmailVerificationController' => 'PhabricatorPeopleController',
|
2012-06-15 04:01:57 +02:00
|
|
|
'PhabricatorEnglishTranslation' => 'PhabricatorBaseEnglishTranslation',
|
2012-01-12 01:07:36 +01:00
|
|
|
'PhabricatorEnvTestCase' => 'PhabricatorTestCase',
|
2012-04-08 02:25:31 +02:00
|
|
|
'PhabricatorErrorExample' => 'PhabricatorUIExample',
|
2011-11-10 02:23:33 +01:00
|
|
|
'PhabricatorEvent' => 'PhutilEvent',
|
|
|
|
'PhabricatorEventType' => 'PhutilEventType',
|
2012-07-04 01:46:27 +02:00
|
|
|
'PhabricatorExampleEventListener' => 'PhutilEventListener',
|
2013-01-03 00:52:30 +01:00
|
|
|
'PhabricatorExtendingPhabricatorConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2013-01-01 23:09:29 +01:00
|
|
|
'PhabricatorFacebookConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2012-07-27 22:46:01 +02:00
|
|
|
'PhabricatorFactAggregate' => 'PhabricatorFactDAO',
|
2012-07-30 19:44:08 +02:00
|
|
|
'PhabricatorFactChartController' => 'PhabricatorFactController',
|
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',
|
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',
|
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',
|
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',
|
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',
|
2013-01-15 02:49:32 +01:00
|
|
|
'PhabricatorFeedConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2011-07-05 17:35:18 +02:00
|
|
|
'PhabricatorFeedController' => 'PhabricatorController',
|
|
|
|
'PhabricatorFeedDAO' => 'PhabricatorLiskDAO',
|
2013-01-11 01:06:29 +01:00
|
|
|
'PhabricatorFeedMainController' => 'PhabricatorFeedController',
|
2011-07-10 03:03:59 +02:00
|
|
|
'PhabricatorFeedPublicStreamController' => 'PhabricatorFeedController',
|
2012-09-13 19:15:08 +02:00
|
|
|
'PhabricatorFeedQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
|
2012-07-04 01:46:27 +02:00
|
|
|
'PhabricatorFeedStory' => 'PhabricatorPolicyInterface',
|
2012-07-01 20:08:59 +02:00
|
|
|
'PhabricatorFeedStoryAggregate' => 'PhabricatorFeedStory',
|
2012-02-27 18:49:01 +01:00
|
|
|
'PhabricatorFeedStoryAudit' => 'PhabricatorFeedStory',
|
2012-06-20 15:03:44 +02:00
|
|
|
'PhabricatorFeedStoryCommit' => 'PhabricatorFeedStory',
|
2011-07-05 17:35:18 +02:00
|
|
|
'PhabricatorFeedStoryData' => 'PhabricatorFeedDAO',
|
2011-07-10 00:44:49 +02:00
|
|
|
'PhabricatorFeedStoryDifferential' => 'PhabricatorFeedStory',
|
2012-08-22 17:19:38 +02:00
|
|
|
'PhabricatorFeedStoryDifferentialAggregate' => 'PhabricatorFeedStoryAggregate',
|
2011-12-17 22:27:11 +01:00
|
|
|
'PhabricatorFeedStoryManiphest' => 'PhabricatorFeedStory',
|
2012-07-01 20:08:59 +02:00
|
|
|
'PhabricatorFeedStoryManiphestAggregate' => 'PhabricatorFeedStoryAggregate',
|
2012-06-08 15:31:30 +02:00
|
|
|
'PhabricatorFeedStoryNotification' => 'PhabricatorFeedDAO',
|
2011-07-12 16:23:04 +02:00
|
|
|
'PhabricatorFeedStoryPhriction' => 'PhabricatorFeedStory',
|
2012-01-24 16:11:37 +01:00
|
|
|
'PhabricatorFeedStoryProject' => 'PhabricatorFeedStory',
|
2011-07-05 17:35:18 +02:00
|
|
|
'PhabricatorFeedStoryReference' => 'PhabricatorFeedDAO',
|
2011-07-09 22:28:09 +02:00
|
|
|
'PhabricatorFeedStoryStatus' => 'PhabricatorFeedStory',
|
2011-07-10 00:44:49 +02:00
|
|
|
'PhabricatorFeedStoryTypeConstants' => 'PhabricatorFeedConstants',
|
2011-07-05 17:35:18 +02:00
|
|
|
'PhabricatorFeedStoryView' => 'PhabricatorFeedView',
|
|
|
|
'PhabricatorFeedView' => 'AphrontView',
|
2012-10-31 17:57:46 +01:00
|
|
|
'PhabricatorFile' =>
|
|
|
|
array(
|
|
|
|
0 => 'PhabricatorFileDAO',
|
|
|
|
1 => 'PhabricatorPolicyInterface',
|
|
|
|
),
|
2011-01-23 03:33:00 +01:00
|
|
|
'PhabricatorFileController' => 'PhabricatorController',
|
|
|
|
'PhabricatorFileDAO' => 'PhabricatorLiskDAO',
|
Move ALL files to serve from the alternate file domain, not just files without
"Content-Disposition: attachment"
Summary:
We currently serve some files off the primary domain (with "Content-Disposition:
attachment" + a CSRF check) and some files off the alternate domain (without
either).
This is not sufficient, because some UAs (like the iPad) ignore
"Content-Disposition: attachment". So there's an attack that goes like this:
- Alice uploads xss.html
- Alice says to Bob "hey download this file on your iPad"
- Bob clicks "Download" on Phabricator on his iPad, gets XSS'd.
NOTE: This removes the CSRF check for downloading files. The check is nice to
have but only raises the barrier to entry slightly. Between iPad / sniffing /
flash bytecode attacks, single-domain installs are simply insecure. We could
restore the check at some point in conjunction with a derived authentication
cookie (i.e., a mini-session-token which is only useful for downloading files),
but that's a lot of complexity to drop all at once.
(Because files are now authenticated only by knowing the PHID and secret key,
this also fixes the "no profile pictures in public feed while logged out"
issue.)
Test Plan: Viewed, info'd, and downloaded files
Reviewers: btrahan, arice, alok
Reviewed By: arice
CC: aran, epriestley
Maniphest Tasks: T843
Differential Revision: https://secure.phabricator.com/D1608
2012-02-14 23:52:27 +01:00
|
|
|
'PhabricatorFileDataController' => 'PhabricatorFileController',
|
2012-01-16 22:26:44 +01:00
|
|
|
'PhabricatorFileDeleteController' => 'PhabricatorFileController',
|
2011-05-22 20:55:10 +02:00
|
|
|
'PhabricatorFileDropUploadController' => 'PhabricatorFileController',
|
Modernize Macro application
Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro.
Test Plan:
{F26839}
{F26840}
{F26841}
{F26842}
{F26843}
{F26844}
{F26845}
Reviewers: vrana, btrahan, chad
Reviewed By: vrana
CC: aran
Maniphest Tasks: T2157, T175, T2104
Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
|
|
|
'PhabricatorFileImageMacro' =>
|
|
|
|
array(
|
|
|
|
0 => 'PhabricatorFileDAO',
|
|
|
|
1 => 'PhabricatorSubscribableInterface',
|
|
|
|
),
|
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',
|
2012-10-23 04:06:56 +02:00
|
|
|
'PhabricatorFileLinkListView' => 'AphrontView',
|
|
|
|
'PhabricatorFileLinkView' => 'AphrontView',
|
2011-01-23 03:33:00 +01:00
|
|
|
'PhabricatorFileListController' => 'PhabricatorFileController',
|
2012-10-31 17:57:46 +01:00
|
|
|
'PhabricatorFileQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
|
2012-05-03 23:46:11 +02:00
|
|
|
'PhabricatorFileShortcutController' => 'PhabricatorFileController',
|
2011-01-23 03:33:00 +01:00
|
|
|
'PhabricatorFileStorageBlob' => 'PhabricatorFileDAO',
|
2012-05-30 23:26:29 +02:00
|
|
|
'PhabricatorFileStorageConfigurationException' => 'Exception',
|
2011-05-22 23:40:51 +02:00
|
|
|
'PhabricatorFileTransformController' => 'PhabricatorFileController',
|
2011-01-23 03:33:00 +01:00
|
|
|
'PhabricatorFileUploadController' => 'PhabricatorFileController',
|
2012-05-30 23:26:29 +02:00
|
|
|
'PhabricatorFileUploadException' => 'Exception',
|
2013-01-14 02:01:00 +01:00
|
|
|
'PhabricatorFilesConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2012-10-25 20:36:38 +02:00
|
|
|
'PhabricatorFilesManagementEnginesWorkflow' => 'PhabricatorFilesManagementWorkflow',
|
2013-01-07 18:43:35 +01:00
|
|
|
'PhabricatorFilesManagementMetadataWorkflow' => 'PhabricatorFilesManagementWorkflow',
|
2012-10-25 20:36:38 +02:00
|
|
|
'PhabricatorFilesManagementMigrateWorkflow' => 'PhabricatorFilesManagementWorkflow',
|
|
|
|
'PhabricatorFilesManagementWorkflow' => 'PhutilArgumentWorkflow',
|
2012-03-28 01:22:40 +02:00
|
|
|
'PhabricatorFlag' => 'PhabricatorFlagDAO',
|
|
|
|
'PhabricatorFlagColor' => 'PhabricatorFlagConstants',
|
|
|
|
'PhabricatorFlagController' => 'PhabricatorController',
|
|
|
|
'PhabricatorFlagDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'PhabricatorFlagDeleteController' => 'PhabricatorFlagController',
|
|
|
|
'PhabricatorFlagEditController' => 'PhabricatorFlagController',
|
|
|
|
'PhabricatorFlagListController' => 'PhabricatorFlagController',
|
|
|
|
'PhabricatorFlagListView' => 'AphrontView',
|
2012-08-24 22:19:47 +02:00
|
|
|
'PhabricatorFlagsUIEventListener' => 'PhutilEventListener',
|
2012-04-04 21:14:10 +02:00
|
|
|
'PhabricatorFormExample' => 'PhabricatorUIExample',
|
2013-01-02 23:03:08 +01:00
|
|
|
'PhabricatorGarbageCollectorConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2011-07-03 18:47:31 +02:00
|
|
|
'PhabricatorGarbageCollectorDaemon' => 'PhabricatorDaemon',
|
2013-01-01 23:09:29 +01:00
|
|
|
'PhabricatorGitHubConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2012-06-27 22:59:12 +02:00
|
|
|
'PhabricatorGlobalLock' => 'PhutilLock',
|
Modernize file uploads
Summary:
Modernizes file uploads. In particular:
- Adds a mobile menu, with an "Upload File" item.
- Adds crumbs to the list view, detail view and upload view.
- Adds "Upload File" action to crumbs.
- Moves upload file to a separate page.
- Removes the combined upload file + recent files page.
- Makes upload file use a normal file control by default (works on mobile).
- Home page, file list and file upload page are now global drop targets which accept files dropped anywhere on them. Dragging a file into the window shows a mask and an instructional message.
- User education on this is a little weak but I think that's a big can of worms?
- Fixes a bug where dropping multiple files into a Remarkup text area produced bad results (resolves T2190).
T879 is related, although it's specifically about Maniphest. I've declined to make global drop targets yet there because there are multiple drop targets on the page with different meanings. That UI needs updating in general.
@chad, do we have an "upload" icon (counterpart to "download")?
Test Plan: Uploaded files in Maniphest, Differential, Files, and from Home. Dragged and dropped multiple files into Differential. Used crumbs, mobile.
Reviewers: chad, btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2190
Differential Revision: https://secure.phabricator.com/D4200
2012-12-17 01:34:01 +01:00
|
|
|
'PhabricatorGlobalUploadTargetView' => 'AphrontView',
|
2013-01-01 23:09:29 +01:00
|
|
|
'PhabricatorGoogleConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2012-12-21 14:43:33 +01:00
|
|
|
'PhabricatorHashTestCase' => 'PhabricatorTestCase',
|
2012-08-15 19:45:06 +02:00
|
|
|
'PhabricatorHeaderView' => 'AphrontView',
|
2011-05-28 20:36:00 +02:00
|
|
|
'PhabricatorHelpController' => 'PhabricatorController',
|
|
|
|
'PhabricatorHelpKeyboardShortcutController' => 'PhabricatorHelpController',
|
2011-05-15 18:29:48 +02:00
|
|
|
'PhabricatorIRCBot' => 'PhabricatorDaemon',
|
2012-01-06 20:31:00 +01:00
|
|
|
'PhabricatorIRCDifferentialNotificationHandler' => 'PhabricatorIRCHandler',
|
2013-01-19 14:45:04 +01:00
|
|
|
'PhabricatorIRCFeedNotificationHandler' => 'PhabricatorIRCHandler',
|
2012-02-17 19:21:38 +01:00
|
|
|
'PhabricatorIRCLogHandler' => 'PhabricatorIRCHandler',
|
2012-03-09 21:40:03 +01:00
|
|
|
'PhabricatorIRCMacroHandler' => 'PhabricatorIRCHandler',
|
2011-05-17 23:40:25 +02:00
|
|
|
'PhabricatorIRCObjectNameHandler' => 'PhabricatorIRCHandler',
|
2011-05-15 18:29:48 +02:00
|
|
|
'PhabricatorIRCProtocolHandler' => 'PhabricatorIRCHandler',
|
2013-01-15 22:17:34 +01:00
|
|
|
'PhabricatorIRCSymbolHandler' => 'PhabricatorIRCHandler',
|
2012-02-24 03:01:25 +01:00
|
|
|
'PhabricatorIRCWhatsNewHandler' => 'PhabricatorIRCHandler',
|
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',
|
2012-10-24 02:34:43 +02:00
|
|
|
'PhabricatorInlineCommentInterface' => 'PhabricatorMarkupInterface',
|
2012-07-23 20:01:28 +02:00
|
|
|
'PhabricatorInlineCommentPreviewController' => 'PhabricatorController',
|
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',
|
Implement a more compact, general database-backed key-value cache
Summary:
See discussion in D4204. Facebook currently has a 314MB remarkup cache with a 55MB index, which is slow to access. Under the theory that this is an index size/quality problem (the current index is on a potentially-384-byte field, with many keys sharing prefixes), provide a more general index with fancy new features:
- It implements PhutilKeyValueCache, so it can be a component in cache stacks and supports TTL.
- It has a 12-byte hash-based key.
- It automatically compresses large blocks of data (most of what we store is highly-compressible HTML).
Test Plan:
- Basics:
- Loaded /paste/, saw caches generate and save.
- Reloaded /paste/, saw the page hit cache.
- GC:
- Ran GC daemon, saw nothing.
- Set maximum lifetime to 1 second, ran GC daemon, saw it collect the entire cache.
- Deflate:
- Selected row formats from the database, saw a mixture of 'raw' and 'deflate' storage.
- Used profiler to verify that 'deflate' is fast (12 calls @ 220us on my paste list).
- Ran unit tests
Reviewers: vrana, btrahan
Reviewed By: vrana
CC: aran
Differential Revision: https://secure.phabricator.com/D4259
2012-12-21 23:17:56 +01:00
|
|
|
'PhabricatorKeyValueDatabaseCache' => 'PhutilKeyValueCache',
|
2013-01-02 23:04:05 +01:00
|
|
|
'PhabricatorLDAPConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2012-06-13 17:52:05 +02:00
|
|
|
'PhabricatorLDAPLoginController' => 'PhabricatorAuthController',
|
|
|
|
'PhabricatorLDAPRegistrationController' => 'PhabricatorAuthController',
|
2012-07-26 23:32:51 +02:00
|
|
|
'PhabricatorLDAPUnknownUserException' => 'Exception',
|
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',
|
2011-01-23 02:48:55 +01:00
|
|
|
'PhabricatorLiskDAO' => 'LiskDAO',
|
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',
|
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',
|
2011-01-31 03:52:29 +01:00
|
|
|
'PhabricatorLogoutController' => 'PhabricatorAuthController',
|
Modernize Macro application
Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro.
Test Plan:
{F26839}
{F26840}
{F26841}
{F26842}
{F26843}
{F26844}
{F26845}
Reviewers: vrana, btrahan, chad
Reviewed By: vrana
CC: aran
Maniphest Tasks: T2157, T175, T2104
Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
|
|
|
'PhabricatorMacroCommentController' => 'PhabricatorMacroController',
|
2013-01-16 19:52:30 +01:00
|
|
|
'PhabricatorMacroConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2012-10-01 23:04:03 +02:00
|
|
|
'PhabricatorMacroController' => 'PhabricatorController',
|
Modernize Macro application
Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro.
Test Plan:
{F26839}
{F26840}
{F26841}
{F26842}
{F26843}
{F26844}
{F26845}
Reviewers: vrana, btrahan, chad
Reviewed By: vrana
CC: aran
Maniphest Tasks: T2157, T175, T2104
Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
|
|
|
'PhabricatorMacroDisableController' => 'PhabricatorMacroController',
|
2012-10-01 23:04:03 +02:00
|
|
|
'PhabricatorMacroEditController' => 'PhabricatorMacroController',
|
Modernize Macro application
Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro.
Test Plan:
{F26839}
{F26840}
{F26841}
{F26842}
{F26843}
{F26844}
{F26845}
Reviewers: vrana, btrahan, chad
Reviewed By: vrana
CC: aran
Maniphest Tasks: T2157, T175, T2104
Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
|
|
|
'PhabricatorMacroEditor' => 'PhabricatorApplicationTransactionEditor',
|
2012-10-01 23:04:03 +02:00
|
|
|
'PhabricatorMacroListController' => 'PhabricatorMacroController',
|
2013-01-20 03:43:35 +01:00
|
|
|
'PhabricatorMacroMemeController' => 'PhabricatorMacroController',
|
2013-01-22 03:46:04 +01:00
|
|
|
'PhabricatorMacroMemeDialogController' => 'PhabricatorMacroController',
|
Modernize Macro application
Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro.
Test Plan:
{F26839}
{F26840}
{F26841}
{F26842}
{F26843}
{F26844}
{F26845}
Reviewers: vrana, btrahan, chad
Reviewed By: vrana
CC: aran
Maniphest Tasks: T2157, T175, T2104
Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
|
|
|
'PhabricatorMacroReplyHandler' => 'PhabricatorMailReplyHandler',
|
|
|
|
'PhabricatorMacroTransaction' => 'PhabricatorApplicationTransaction',
|
|
|
|
'PhabricatorMacroTransactionComment' => 'PhabricatorApplicationTransactionComment',
|
|
|
|
'PhabricatorMacroTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
|
|
|
|
'PhabricatorMacroViewController' => 'PhabricatorMacroController',
|
2011-02-10 02:39:55 +01:00
|
|
|
'PhabricatorMailImplementationAmazonSESAdapter' => 'PhabricatorMailImplementationPHPMailerLiteAdapter',
|
2012-12-09 11:36:40 +01:00
|
|
|
'PhabricatorMailImplementationPHPMailerAdapter' => 'PhabricatorMailImplementationAdapter',
|
2011-01-26 18:33:31 +01:00
|
|
|
'PhabricatorMailImplementationPHPMailerLiteAdapter' => 'PhabricatorMailImplementationAdapter',
|
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',
|
2013-01-24 01:36:21 +01:00
|
|
|
'PhabricatorMailingListsController' => 'PhabricatorController',
|
|
|
|
'PhabricatorMailingListsEditController' => 'PhabricatorMailingListsController',
|
|
|
|
'PhabricatorMailingListsListController' => 'PhabricatorMailingListsController',
|
2012-07-31 01:09:14 +02:00
|
|
|
'PhabricatorMainMenuGroupView' => 'AphrontView',
|
|
|
|
'PhabricatorMainMenuIconView' => 'AphrontView',
|
|
|
|
'PhabricatorMainMenuSearchView' => 'AphrontView',
|
|
|
|
'PhabricatorMainMenuView' => 'AphrontView',
|
2013-01-11 19:24:35 +01:00
|
|
|
'PhabricatorManiphestConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
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',
|
2013-01-17 00:06:39 +01:00
|
|
|
'PhabricatorMenuItemView' => 'AphrontTagView',
|
2013-01-16 19:50:41 +01:00
|
|
|
'PhabricatorMenuView' => 'AphrontTagView',
|
2013-02-03 19:02:35 +01:00
|
|
|
'PhabricatorMenuViewTestCase' => 'PhabricatorTestCase',
|
2013-01-17 00:06:39 +01:00
|
|
|
'PhabricatorMetaMTAConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2011-01-26 02:40:21 +01:00
|
|
|
'PhabricatorMetaMTAController' => 'PhabricatorController',
|
|
|
|
'PhabricatorMetaMTADAO' => 'PhabricatorLiskDAO',
|
2011-06-01 17:33:14 +02:00
|
|
|
'PhabricatorMetaMTAEmailBodyParserTestCase' => 'PhabricatorTestCase',
|
2011-01-26 02:40:21 +01:00
|
|
|
'PhabricatorMetaMTAListController' => 'PhabricatorMetaMTAController',
|
|
|
|
'PhabricatorMetaMTAMail' => 'PhabricatorMetaMTADAO',
|
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',
|
2011-01-26 19:40:38 +01:00
|
|
|
'PhabricatorMetaMTAMailingList' => 'PhabricatorMetaMTADAO',
|
2011-05-05 08:09:42 +02:00
|
|
|
'PhabricatorMetaMTAReceiveController' => 'PhabricatorMetaMTAController',
|
|
|
|
'PhabricatorMetaMTAReceivedListController' => 'PhabricatorMetaMTAController',
|
|
|
|
'PhabricatorMetaMTAReceivedMail' => 'PhabricatorMetaMTADAO',
|
2011-01-26 02:40:21 +01:00
|
|
|
'PhabricatorMetaMTASendController' => 'PhabricatorMetaMTAController',
|
2011-05-30 20:07:05 +02:00
|
|
|
'PhabricatorMetaMTASendGridReceiveController' => 'PhabricatorMetaMTAController',
|
2011-01-26 18:08:26 +01:00
|
|
|
'PhabricatorMetaMTAViewController' => 'PhabricatorMetaMTAController',
|
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',
|
2013-01-03 15:01:14 +01:00
|
|
|
'PhabricatorMySQLConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2011-07-20 07:48:38 +02:00
|
|
|
'PhabricatorMySQLFileStorageEngine' => 'PhabricatorFileStorageEngine',
|
2012-06-20 22:51:19 +02:00
|
|
|
'PhabricatorNotificationClearController' => 'PhabricatorNotificationController',
|
2013-01-03 18:29:19 +01:00
|
|
|
'PhabricatorNotificationConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2012-06-08 15:31:30 +02:00
|
|
|
'PhabricatorNotificationController' => 'PhabricatorController',
|
2012-06-12 02:49:32 +02:00
|
|
|
'PhabricatorNotificationIndividualController' => 'PhabricatorNotificationController',
|
2012-06-18 23:07:38 +02:00
|
|
|
'PhabricatorNotificationListController' => 'PhabricatorNotificationController',
|
2012-06-11 18:37:06 +02:00
|
|
|
'PhabricatorNotificationPanelController' => 'PhabricatorNotificationController',
|
2012-10-24 02:34:43 +02:00
|
|
|
'PhabricatorNotificationQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
|
2012-06-17 20:35:18 +02:00
|
|
|
'PhabricatorNotificationStatusController' => 'PhabricatorNotificationController',
|
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',
|
2012-02-22 19:21:39 +01:00
|
|
|
'PhabricatorOAuthClientAuthorizationBaseController' => 'PhabricatorOAuthServerController',
|
|
|
|
'PhabricatorOAuthClientAuthorizationDeleteController' => 'PhabricatorOAuthClientAuthorizationBaseController',
|
|
|
|
'PhabricatorOAuthClientAuthorizationEditController' => 'PhabricatorOAuthClientAuthorizationBaseController',
|
|
|
|
'PhabricatorOAuthClientAuthorizationListController' => 'PhabricatorOAuthClientAuthorizationBaseController',
|
2012-04-05 02:51:16 +02:00
|
|
|
'PhabricatorOAuthClientAuthorizationQuery' => 'PhabricatorOffsetPagedQuery',
|
2012-02-22 19:21:39 +01:00
|
|
|
'PhabricatorOAuthClientBaseController' => 'PhabricatorOAuthServerController',
|
|
|
|
'PhabricatorOAuthClientDeleteController' => 'PhabricatorOAuthClientBaseController',
|
|
|
|
'PhabricatorOAuthClientEditController' => 'PhabricatorOAuthClientBaseController',
|
|
|
|
'PhabricatorOAuthClientListController' => 'PhabricatorOAuthClientBaseController',
|
|
|
|
'PhabricatorOAuthClientViewController' => 'PhabricatorOAuthClientBaseController',
|
2011-02-28 04:47:22 +01:00
|
|
|
'PhabricatorOAuthDefaultRegistrationController' => 'PhabricatorOAuthRegistrationController',
|
2011-02-21 07:47:56 +01:00
|
|
|
'PhabricatorOAuthDiagnosticsController' => 'PhabricatorAuthController',
|
|
|
|
'PhabricatorOAuthFailureView' => 'AphrontView',
|
|
|
|
'PhabricatorOAuthLoginController' => 'PhabricatorAuthController',
|
2012-05-08 21:08:05 +02:00
|
|
|
'PhabricatorOAuthProviderDisqus' => 'PhabricatorOAuthProvider',
|
2012-05-30 23:26:29 +02:00
|
|
|
'PhabricatorOAuthProviderException' => 'Exception',
|
2011-02-21 07:47:56 +01:00
|
|
|
'PhabricatorOAuthProviderFacebook' => 'PhabricatorOAuthProvider',
|
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',
|
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',
|
2012-04-05 02:51:16 +02:00
|
|
|
'PhabricatorOAuthServerClientQuery' => 'PhabricatorOffsetPagedQuery',
|
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',
|
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',
|
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',
|
2012-08-15 19:45:06 +02:00
|
|
|
'PhabricatorObjectItemListView' => 'AphrontView',
|
|
|
|
'PhabricatorObjectItemView' => 'AphrontView',
|
2012-08-07 20:57:38 +02:00
|
|
|
'PhabricatorObjectListView' => 'AphrontView',
|
2012-03-27 05:54:26 +02:00
|
|
|
'PhabricatorOffsetPagedQuery' => 'PhabricatorQuery',
|
2013-01-16 19:52:30 +01:00
|
|
|
'PhabricatorOwnersConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2011-04-03 23:48:36 +02:00
|
|
|
'PhabricatorOwnersController' => 'PhabricatorController',
|
|
|
|
'PhabricatorOwnersDAO' => 'PhabricatorLiskDAO',
|
2011-04-04 07:03:27 +02:00
|
|
|
'PhabricatorOwnersDeleteController' => 'PhabricatorOwnersController',
|
2011-04-03 23:48:36 +02:00
|
|
|
'PhabricatorOwnersDetailController' => 'PhabricatorOwnersController',
|
2011-04-04 07:03:27 +02:00
|
|
|
'PhabricatorOwnersEditController' => 'PhabricatorOwnersController',
|
2011-04-03 23:48:36 +02:00
|
|
|
'PhabricatorOwnersListController' => 'PhabricatorOwnersController',
|
|
|
|
'PhabricatorOwnersOwner' => 'PhabricatorOwnersDAO',
|
2012-08-08 21:25:11 +02:00
|
|
|
'PhabricatorOwnersPackage' =>
|
|
|
|
array(
|
|
|
|
0 => 'PhabricatorOwnersDAO',
|
|
|
|
1 => 'PhabricatorPolicyInterface',
|
|
|
|
),
|
2012-09-13 19:15:08 +02:00
|
|
|
'PhabricatorOwnersPackageQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
|
2012-12-07 02:23:56 +01:00
|
|
|
'PhabricatorOwnersPackageTestCase' => 'PhabricatorTestCase',
|
2011-04-03 23:48:36 +02:00
|
|
|
'PhabricatorOwnersPath' => 'PhabricatorOwnersDAO',
|
2013-01-09 15:05:34 +01:00
|
|
|
'PhabricatorPHDConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2013-01-19 19:20:22 +01:00
|
|
|
'PhabricatorPHIDConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2011-01-23 06:09:13 +01:00
|
|
|
'PhabricatorPHIDController' => 'PhabricatorController',
|
2011-01-26 18:02:09 +01:00
|
|
|
'PhabricatorPHIDLookupController' => 'PhabricatorPHIDController',
|
2013-01-15 21:03:44 +01:00
|
|
|
'PhabricatorPHPMailerConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2012-05-30 23:26:29 +02:00
|
|
|
'PhabricatorPaste' =>
|
|
|
|
array(
|
|
|
|
0 => 'PhabricatorPasteDAO',
|
|
|
|
1 => 'PhabricatorPolicyInterface',
|
|
|
|
),
|
2011-06-10 08:53:53 +02:00
|
|
|
'PhabricatorPasteController' => 'PhabricatorController',
|
|
|
|
'PhabricatorPasteDAO' => 'PhabricatorLiskDAO',
|
2012-08-24 22:19:14 +02:00
|
|
|
'PhabricatorPasteEditController' => 'PhabricatorPasteController',
|
2011-06-14 04:12:30 +02:00
|
|
|
'PhabricatorPasteListController' => 'PhabricatorPasteController',
|
2012-09-13 19:15:08 +02:00
|
|
|
'PhabricatorPasteQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
|
2011-06-10 08:53:53 +02:00
|
|
|
'PhabricatorPasteViewController' => 'PhabricatorPasteController',
|
2011-01-24 03:09:16 +01:00
|
|
|
'PhabricatorPeopleController' => 'PhabricatorController',
|
|
|
|
'PhabricatorPeopleEditController' => 'PhabricatorPeopleController',
|
2012-07-04 04:10:38 +02:00
|
|
|
'PhabricatorPeopleLdapController' => 'PhabricatorPeopleController',
|
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',
|
2011-01-24 03:09:16 +01:00
|
|
|
'PhabricatorPeopleProfileController' => 'PhabricatorPeopleController',
|
2012-05-07 22:35:09 +02:00
|
|
|
'PhabricatorPeopleQuery' => 'PhabricatorOffsetPagedQuery',
|
2013-01-16 19:00:51 +01:00
|
|
|
'PhabricatorPhabricatorOAuthConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2013-01-16 00:36:49 +01:00
|
|
|
'PhabricatorPhameConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2013-01-16 19:52:30 +01:00
|
|
|
'PhabricatorPholioConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2013-01-15 15:31:53 +01:00
|
|
|
'PhabricatorPhrictionConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2012-10-01 23:06:00 +02:00
|
|
|
'PhabricatorPinboardItemView' => 'AphrontView',
|
|
|
|
'PhabricatorPinboardView' => 'AphrontView',
|
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',
|
2012-09-13 19:15:08 +02:00
|
|
|
'PhabricatorPolicyAwareQuery' => 'PhabricatorOffsetPagedQuery',
|
|
|
|
'PhabricatorPolicyAwareTestQuery' => 'PhabricatorPolicyAwareQuery',
|
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
|
|
|
'PhabricatorPolicyCapability' => 'PhabricatorPolicyConstants',
|
2013-01-07 21:47:26 +01:00
|
|
|
'PhabricatorPolicyConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2012-05-30 23:26:29 +02:00
|
|
|
'PhabricatorPolicyException' => 'Exception',
|
2012-09-13 19:15:08 +02:00
|
|
|
'PhabricatorPolicyQuery' => 'PhabricatorQuery',
|
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',
|
2012-05-30 23:26:29 +02:00
|
|
|
'PhabricatorPolicyTestObject' => 'PhabricatorPolicyInterface',
|
2012-09-13 19:15:08 +02:00
|
|
|
'PhabricatorPolicyType' => 'PhabricatorPolicyConstants',
|
2011-12-17 05:01:38 +01:00
|
|
|
'PhabricatorProfileHeaderView' => 'AphrontView',
|
2012-08-10 00:42:44 +02:00
|
|
|
'PhabricatorProject' =>
|
|
|
|
array(
|
|
|
|
0 => 'PhabricatorProjectDAO',
|
|
|
|
1 => 'PhabricatorPolicyInterface',
|
|
|
|
),
|
2011-02-21 03:41:23 +01:00
|
|
|
'PhabricatorProjectController' => 'PhabricatorController',
|
2011-06-26 17:37:47 +02:00
|
|
|
'PhabricatorProjectCreateController' => 'PhabricatorProjectController',
|
2011-02-21 03:41:23 +01:00
|
|
|
'PhabricatorProjectDAO' => 'PhabricatorLiskDAO',
|
2012-10-10 19:18:23 +02:00
|
|
|
'PhabricatorProjectEditor' => 'PhabricatorEditor',
|
2012-08-11 16:05:20 +02:00
|
|
|
'PhabricatorProjectEditorTestCase' => 'PhabricatorTestCase',
|
2011-02-21 03:41:23 +01:00
|
|
|
'PhabricatorProjectListController' => 'PhabricatorProjectController',
|
2012-08-07 20:57:38 +02:00
|
|
|
'PhabricatorProjectMembersEditController' => 'PhabricatorProjectController',
|
2012-05-30 23:26:29 +02:00
|
|
|
'PhabricatorProjectNameCollisionException' => 'Exception',
|
2011-02-21 03:41:23 +01:00
|
|
|
'PhabricatorProjectProfile' => 'PhabricatorProjectDAO',
|
|
|
|
'PhabricatorProjectProfileController' => 'PhabricatorProjectController',
|
2011-06-18 10:13:56 +02:00
|
|
|
'PhabricatorProjectProfileEditController' => 'PhabricatorProjectController',
|
2012-09-13 19:15:08 +02:00
|
|
|
'PhabricatorProjectQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
|
2012-01-24 16:11:37 +01:00
|
|
|
'PhabricatorProjectTransaction' => 'PhabricatorProjectDAO',
|
|
|
|
'PhabricatorProjectTransactionType' => 'PhabricatorProjectConstants',
|
2012-01-25 20:51:20 +01:00
|
|
|
'PhabricatorProjectUpdateController' => 'PhabricatorProjectController',
|
2012-10-15 23:50:53 +02:00
|
|
|
'PhabricatorPropertyListExample' => 'PhabricatorUIExample',
|
2012-08-15 19:45:06 +02:00
|
|
|
'PhabricatorPropertyListView' => 'AphrontView',
|
2013-01-03 18:17:38 +01:00
|
|
|
'PhabricatorRecaptchaConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
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',
|
2012-09-19 21:27:28 +02:00
|
|
|
'PhabricatorRemarkupControl' => 'AphrontFormTextAreaControl',
|
2012-08-15 04:19:23 +02:00
|
|
|
'PhabricatorRemarkupRuleCountdown' => 'PhutilRemarkupRule',
|
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',
|
2012-12-17 01:33:42 +01:00
|
|
|
'PhabricatorRemarkupRuleDiffusion' => 'PhabricatorRemarkupRuleObjectName',
|
2011-07-15 23:17:55 +02:00
|
|
|
'PhabricatorRemarkupRuleEmbedFile' => 'PhutilRemarkupRule',
|
2011-04-14 00:15:48 +02:00
|
|
|
'PhabricatorRemarkupRuleImageMacro' => 'PhutilRemarkupRule',
|
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',
|
2013-01-24 18:57:58 +01:00
|
|
|
'PhabricatorRemarkupRuleMeme' => 'PhutilRemarkupRule',
|
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',
|
2011-05-31 19:23:31 +02:00
|
|
|
'PhabricatorRemarkupRuleObjectName' => 'PhutilRemarkupRule',
|
2011-06-27 08:57:43 +02:00
|
|
|
'PhabricatorRemarkupRulePaste' => 'PhabricatorRemarkupRuleObjectName',
|
2011-07-12 05:14:46 +02:00
|
|
|
'PhabricatorRemarkupRulePhriction' => 'PhutilRemarkupRule',
|
2011-05-27 21:50:02 +02:00
|
|
|
'PhabricatorRemarkupRuleYoutube' => 'PhutilRemarkupRule',
|
2012-12-19 20:07:06 +01:00
|
|
|
'PhabricatorRepository' =>
|
|
|
|
array(
|
|
|
|
0 => 'PhabricatorRepositoryDAO',
|
|
|
|
1 => 'PhabricatorPolicyInterface',
|
|
|
|
),
|
2011-04-06 05:49:31 +02:00
|
|
|
'PhabricatorRepositoryArcanistProject' => 'PhabricatorRepositoryDAO',
|
2012-10-04 22:25:58 +02:00
|
|
|
'PhabricatorRepositoryArcanistProjectDeleteController' => 'PhabricatorRepositoryController',
|
2011-04-06 05:49:31 +02:00
|
|
|
'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',
|
2012-11-06 08:09:36 +01:00
|
|
|
'PhabricatorRepositoryBranch' => 'PhabricatorRepositoryDAO',
|
2011-03-07 07:29:22 +01:00
|
|
|
'PhabricatorRepositoryCommit' => 'PhabricatorRepositoryDAO',
|
2011-03-11 18:34:22 +01:00
|
|
|
'PhabricatorRepositoryCommitChangeParserWorker' => 'PhabricatorRepositoryCommitParserWorker',
|
|
|
|
'PhabricatorRepositoryCommitData' => 'PhabricatorRepositoryDAO',
|
2011-04-04 08:23:36 +02:00
|
|
|
'PhabricatorRepositoryCommitHeraldWorker' => 'PhabricatorRepositoryCommitParserWorker',
|
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',
|
2011-03-11 18:34:22 +01:00
|
|
|
'PhabricatorRepositoryCommitParserWorker' => 'PhabricatorWorker',
|
Improve Search architecture
Summary:
The search indexing API has several problems right now:
- Always runs in-process.
- It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it.
- Being able to use the task queue will also make rebuilding indexes faster.
- Instead, make the API phid-oriented.
- No uniform indexing API.
- Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird.
- Instead, provide a uniform API.
- No uniform CLI.
- We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers.
- Instead, let indexers expose documents for indexing.
- Not application-oriented.
- All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world.
- Instead, move indexers to applications and load them with SymbolLoader.
Test Plan:
- `bin/search index`
- Indexed one revision, one task.
- Indexed `--type TASK`, `--type DREV`, etc., for all types.
- Indexed `--all`.
- Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it.
- Creating users is a pain; searched for a user after indexing.
- Creating commits is a pain; searched for a commit after indexing.
- Mocks aren't currently loadable in the result view, so their indexing is moot.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: 20after4, aran
Maniphest Tasks: T1991, T2104
Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
|
|
|
'PhabricatorRepositoryCommitSearchIndexer' => 'PhabricatorSearchDocumentIndexer',
|
2013-01-16 18:35:47 +01:00
|
|
|
'PhabricatorRepositoryConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2011-02-13 03:26:15 +01:00
|
|
|
'PhabricatorRepositoryController' => 'PhabricatorController',
|
2011-03-11 23:13:23 +01:00
|
|
|
'PhabricatorRepositoryCreateController' => 'PhabricatorRepositoryController',
|
2011-02-13 03:26:15 +01:00
|
|
|
'PhabricatorRepositoryDAO' => 'PhabricatorLiskDAO',
|
2011-05-05 21:53:39 +02:00
|
|
|
'PhabricatorRepositoryDeleteController' => 'PhabricatorRepositoryController',
|
2011-03-11 23:13:23 +01:00
|
|
|
'PhabricatorRepositoryEditController' => 'PhabricatorRepositoryController',
|
2011-03-11 18:34:22 +01:00
|
|
|
'PhabricatorRepositoryGitCommitChangeParserWorker' => 'PhabricatorRepositoryCommitChangeParserWorker',
|
|
|
|
'PhabricatorRepositoryGitCommitMessageParserWorker' => 'PhabricatorRepositoryCommitMessageParserWorker',
|
2011-03-11 23:13:23 +01:00
|
|
|
'PhabricatorRepositoryListController' => 'PhabricatorRepositoryController',
|
2012-10-26 01:23:41 +02:00
|
|
|
'PhabricatorRepositoryManagementDeleteWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
|
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',
|
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',
|
2012-12-19 20:07:06 +01:00
|
|
|
'PhabricatorRepositoryQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
|
2011-03-31 09:33:44 +02:00
|
|
|
'PhabricatorRepositoryShortcut' => 'PhabricatorRepositoryDAO',
|
2011-03-11 23:13:23 +01:00
|
|
|
'PhabricatorRepositorySvnCommitChangeParserWorker' => 'PhabricatorRepositoryCommitChangeParserWorker',
|
2011-03-11 18:34:22 +01:00
|
|
|
'PhabricatorRepositorySvnCommitMessageParserWorker' => 'PhabricatorRepositoryCommitMessageParserWorker',
|
2011-09-05 02:31:16 +02:00
|
|
|
'PhabricatorRepositorySymbol' => 'PhabricatorRepositoryDAO',
|
2011-12-23 17:11:11 +01:00
|
|
|
'PhabricatorRepositoryTestCase' => 'PhabricatorTestCase',
|
2011-07-31 22:54:58 +02:00
|
|
|
'PhabricatorS3FileStorageEngine' => 'PhabricatorFileStorageEngine',
|
Implement SSHD glue and Conduit SSH endpoint
Summary:
- Build "sshd-auth" (for authentication) and "sshd-exec" (for command execution) binaries. These are callable by "sshd-vcs", located [[https://github.com/epriestley/sshd-vcs | in my account on GitHub]]. They are based on precursors [[https://github.com/epriestley/sshd-vcs-glue | here on GitHub]] which I deployed for TenXer about a year ago, so I have some confidence they at least basically work.
- The problem this solves is that normally every user would need an account on a machine to connect to it, and/or their public keys would all need to be listed in `~/.authorized_keys`. This is a big pain in most installs. Software like Gitosis/Gitolite solve this problem by giving you an easy way to add public keys to `~/.authorized_keys`, but this is pretty gross.
- Roughly, instead of looking in `~/.authorized_keys` when a user connects, the patched sshd instead runs `echo <public key> | sshd-auth`. The `sshd-auth` script looks up the public key and authorizes the matching user, if they exist. It also forces sshd to run `sshd-exec` instead of a normal shell.
- `sshd-exec` receives the authenticated user and any command which was passed to ssh (like `git receive-pack`) and can route them appropriately.
- Overall, this permits a single account to be set up on a server which all Phabricator users can connect to without any extra work, and which can safely execute commands and apply appropriate permissions, and disable users when they are disabled in Phabricator and all that stuff.
- Build out "sshd-exec" to do more thorough checks and setup, and delegate command execution to Workflows (they now exist, and did not when I originally built this stuff).
- Convert @btrahan's conduit API script into a workflow and slightly simplify it (ConduitCall did not exist at the time it was written).
The next steps here on the Repository side are to implement Workflows for Git, SVN and HG wire protocols. These will mostly just proxy the protocols, but also need to enforce permissions. So the approach will basically be:
- Implement workflows for stuff like `git receive-pack`.
- These workflows will implement enough of the underlying protocol to determine what resource the user is trying to access, and whether they want to read or write it.
- They'll then do a permissons check, and kick the user out if they don't have permission to do whatever they are trying to do.
- If the user does have permission, we just proxy the rest of the transaction.
Next steps on the Conduit side are more simple:
- Make ConduitClient understand "ssh://" URLs.
Test Plan: Ran `sshd-exec --phabricator-ssh-user epriestley conduit differential.query`, etc. This will get a more comprehensive test once I set up sshd-vcs.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603, T550
Differential Revision: https://secure.phabricator.com/D4229
2012-12-19 20:08:07 +01:00
|
|
|
'PhabricatorSSHWorkflow' => 'PhutilArgumentWorkflow',
|
2012-03-10 00:46:25 +01:00
|
|
|
'PhabricatorSearchAttachController' => 'PhabricatorSearchBaseController',
|
2011-02-15 00:34:20 +01:00
|
|
|
'PhabricatorSearchBaseController' => 'PhabricatorController',
|
2013-01-12 00:28:16 +01:00
|
|
|
'PhabricatorSearchConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2011-02-15 00:34:20 +01:00
|
|
|
'PhabricatorSearchController' => 'PhabricatorSearchBaseController',
|
|
|
|
'PhabricatorSearchDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'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',
|
2011-08-08 00:14:23 +02:00
|
|
|
'PhabricatorSearchEngineMySQL' => 'PhabricatorSearchEngine',
|
Improve Search architecture
Summary:
The search indexing API has several problems right now:
- Always runs in-process.
- It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it.
- Being able to use the task queue will also make rebuilding indexes faster.
- Instead, make the API phid-oriented.
- No uniform indexing API.
- Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird.
- Instead, provide a uniform API.
- No uniform CLI.
- We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers.
- Instead, let indexers expose documents for indexing.
- Not application-oriented.
- All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world.
- Instead, move indexers to applications and load them with SymbolLoader.
Test Plan:
- `bin/search index`
- Indexed one revision, one task.
- Indexed `--type TASK`, `--type DREV`, etc., for all types.
- Indexed `--all`.
- Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it.
- Creating users is a pain; searched for a user after indexing.
- Creating commits is a pain; searched for a commit after indexing.
- Mocks aren't currently loadable in the result view, so their indexing is moot.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: 20after4, aran
Maniphest Tasks: T1991, T2104
Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
|
|
|
'PhabricatorSearchManagementIndexWorkflow' => 'PhabricatorSearchManagementWorkflow',
|
|
|
|
'PhabricatorSearchManagementWorkflow' => 'PhutilArgumentWorkflow',
|
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',
|
2012-03-10 00:46:25 +01:00
|
|
|
'PhabricatorSearchSelectController' => 'PhabricatorSearchBaseController',
|
2013-01-03 14:45:23 +01:00
|
|
|
'PhabricatorSecurityConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2013-01-15 21:04:05 +01:00
|
|
|
'PhabricatorSendGridConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2012-08-13 21:37:18 +02:00
|
|
|
'PhabricatorSettingsAdjustController' => 'PhabricatorController',
|
|
|
|
'PhabricatorSettingsMainController' => 'PhabricatorController',
|
2012-08-13 21:37:26 +02:00
|
|
|
'PhabricatorSettingsPanelAccount' => 'PhabricatorSettingsPanel',
|
|
|
|
'PhabricatorSettingsPanelConduit' => 'PhabricatorSettingsPanel',
|
2013-02-05 02:00:27 +01:00
|
|
|
'PhabricatorSettingsPanelDiffPreferences' => 'PhabricatorSettingsPanel',
|
2012-08-13 21:37:26 +02:00
|
|
|
'PhabricatorSettingsPanelDisplayPreferences' => 'PhabricatorSettingsPanel',
|
|
|
|
'PhabricatorSettingsPanelEmailAddresses' => 'PhabricatorSettingsPanel',
|
|
|
|
'PhabricatorSettingsPanelEmailPreferences' => 'PhabricatorSettingsPanel',
|
2013-01-16 18:00:11 +01:00
|
|
|
'PhabricatorSettingsPanelHomePreferences' => 'PhabricatorSettingsPanel',
|
2012-08-13 21:37:26 +02:00
|
|
|
'PhabricatorSettingsPanelLDAP' => 'PhabricatorSettingsPanel',
|
|
|
|
'PhabricatorSettingsPanelOAuth' => 'PhabricatorSettingsPanel',
|
|
|
|
'PhabricatorSettingsPanelPassword' => 'PhabricatorSettingsPanel',
|
|
|
|
'PhabricatorSettingsPanelProfile' => 'PhabricatorSettingsPanel',
|
|
|
|
'PhabricatorSettingsPanelSSHKeys' => 'PhabricatorSettingsPanel',
|
|
|
|
'PhabricatorSettingsPanelSearchPreferences' => 'PhabricatorSettingsPanel',
|
2012-12-30 15:37:49 +01:00
|
|
|
'PhabricatorSetupCheckAPC' => 'PhabricatorSetupCheck',
|
2013-01-22 22:57:02 +01:00
|
|
|
'PhabricatorSetupCheckBaseURI' => 'PhabricatorSetupCheck',
|
2013-01-23 01:16:24 +01:00
|
|
|
'PhabricatorSetupCheckDatabase' => 'PhabricatorSetupCheck',
|
2013-01-23 00:16:26 +01:00
|
|
|
'PhabricatorSetupCheckExtensions' => 'PhabricatorSetupCheck',
|
2013-01-01 23:09:17 +01:00
|
|
|
'PhabricatorSetupCheckExtraConfig' => 'PhabricatorSetupCheck',
|
2013-01-19 17:42:15 +01:00
|
|
|
'PhabricatorSetupCheckFacebook' => 'PhabricatorSetupCheck',
|
2013-01-19 17:41:45 +01:00
|
|
|
'PhabricatorSetupCheckGD' => 'PhabricatorSetupCheck',
|
2013-01-02 03:15:03 +01:00
|
|
|
'PhabricatorSetupCheckInvalidConfig' => 'PhabricatorSetupCheck',
|
2013-01-18 22:28:30 +01:00
|
|
|
'PhabricatorSetupCheckMail' => 'PhabricatorSetupCheck',
|
2013-01-19 17:41:45 +01:00
|
|
|
'PhabricatorSetupCheckMySQL' => 'PhabricatorSetupCheck',
|
2013-01-23 01:15:54 +01:00
|
|
|
'PhabricatorSetupCheckPHPConfig' => 'PhabricatorSetupCheck',
|
2013-01-22 23:45:19 +01:00
|
|
|
'PhabricatorSetupCheckPath' => 'PhabricatorSetupCheck',
|
2013-01-19 17:39:27 +01:00
|
|
|
'PhabricatorSetupCheckStorage' => 'PhabricatorSetupCheck',
|
2012-12-31 02:04:38 +01:00
|
|
|
'PhabricatorSetupCheckTimezone' => 'PhabricatorSetupCheck',
|
2012-12-30 15:37:49 +01:00
|
|
|
'PhabricatorSetupIssueView' => 'AphrontView',
|
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',
|
2012-04-10 23:18:20 +02:00
|
|
|
'PhabricatorSlugTestCase' => 'PhabricatorTestCase',
|
2012-03-20 03:48:22 +01:00
|
|
|
'PhabricatorSortTableExample' => 'PhabricatorUIExample',
|
2012-08-15 19:45:06 +02:00
|
|
|
'PhabricatorSourceCodeView' => 'AphrontView',
|
2012-10-16 19:33:47 +02:00
|
|
|
'PhabricatorStandardPageView' => 'PhabricatorBarePageView',
|
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',
|
2012-10-05 22:18:05 +02:00
|
|
|
'PhabricatorSubscribersQuery' => 'PhabricatorQuery',
|
|
|
|
'PhabricatorSubscriptionsEditController' => 'PhabricatorController',
|
2012-10-10 19:18:23 +02:00
|
|
|
'PhabricatorSubscriptionsEditor' => 'PhabricatorEditor',
|
2012-10-05 22:18:05 +02:00
|
|
|
'PhabricatorSubscriptionsUIEventListener' => 'PhutilEventListener',
|
2011-08-30 22:12:20 +02:00
|
|
|
'PhabricatorSymbolNameLinter' => 'ArcanistXHPASTLintNamingHook',
|
2013-01-10 18:56:36 +01:00
|
|
|
'PhabricatorSyntaxHighlightingConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2012-11-24 15:47:06 +01:00
|
|
|
'PhabricatorTagExample' => 'PhabricatorUIExample',
|
|
|
|
'PhabricatorTagView' => 'AphrontView',
|
2011-03-10 22:48:29 +01:00
|
|
|
'PhabricatorTaskmasterDaemon' => 'PhabricatorDaemon',
|
2011-04-30 19:11:41 +02:00
|
|
|
'PhabricatorTestCase' => 'ArcanistPhutilTestCase',
|
2012-11-01 19:30:23 +01:00
|
|
|
'PhabricatorTestWorker' => 'PhabricatorWorker',
|
2011-03-07 07:29:22 +01:00
|
|
|
'PhabricatorTimelineCursor' => 'PhabricatorTimelineDAO',
|
|
|
|
'PhabricatorTimelineDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'PhabricatorTimelineEvent' => 'PhabricatorTimelineDAO',
|
|
|
|
'PhabricatorTimelineEventData' => 'PhabricatorTimelineDAO',
|
2012-11-22 02:24:56 +01:00
|
|
|
'PhabricatorTimelineEventView' => 'AphrontView',
|
|
|
|
'PhabricatorTimelineExample' => 'PhabricatorUIExample',
|
2012-05-30 23:26:29 +02:00
|
|
|
'PhabricatorTimelineIterator' => 'Iterator',
|
2012-11-22 02:24:56 +01:00
|
|
|
'PhabricatorTimelineView' => 'AphrontView',
|
2011-06-13 01:06:17 +02:00
|
|
|
'PhabricatorTimer' => 'PhabricatorCountdownDAO',
|
2012-02-24 22:02:35 +01:00
|
|
|
'PhabricatorTransactionView' => 'AphrontView',
|
2011-05-22 23:40:51 +02:00
|
|
|
'PhabricatorTransformedFile' => 'PhabricatorFileDAO',
|
2013-01-05 01:22:52 +01:00
|
|
|
'PhabricatorTranslationsConfigOptions' => 'PhabricatorApplicationConfigOptions',
|
2011-08-03 17:17:53 +02:00
|
|
|
'PhabricatorTrivialTestCase' => 'PhabricatorTestCase',
|
2011-01-25 22:48:05 +01:00
|
|
|
'PhabricatorTypeaheadCommonDatasourceController' => 'PhabricatorTypeaheadDatasourceController',
|
|
|
|
'PhabricatorTypeaheadDatasourceController' => 'PhabricatorController',
|
2012-09-11 18:56:40 +02:00
|
|
|
'PhabricatorUIExampleRenderController' => 'PhabricatorController',
|
2011-04-04 00:50:06 +02:00
|
|
|
'PhabricatorUIListFilterExample' => 'PhabricatorUIExample',
|
2012-06-14 00:00:24 +02:00
|
|
|
'PhabricatorUINotificationExample' => 'PhabricatorUIExample',
|
2011-04-01 02:06:33 +02:00
|
|
|
'PhabricatorUIPagerExample' => 'PhabricatorUIExample',
|
2012-03-13 02:21:02 +01:00
|
|
|
'PhabricatorUITooltipExample' => 'PhabricatorUIExample',
|
2012-05-04 02:30:17 +02:00
|
|
|
'PhabricatorUnitsTestCase' => 'PhabricatorTestCase',
|
2012-06-15 03:08:06 +02:00
|
|
|
'PhabricatorUser' =>
|
|
|
|
array(
|
|
|
|
0 => 'PhabricatorUserDAO',
|
|
|
|
1 => 'PhutilPerson',
|
|
|
|
),
|
2011-01-24 03:09:16 +01:00
|
|
|
'PhabricatorUserDAO' => 'PhabricatorLiskDAO',
|
2012-10-10 19:18:23 +02:00
|
|
|
'PhabricatorUserEditor' => 'PhabricatorEditor',
|
2012-05-07 19:29:33 +02:00
|
|
|
'PhabricatorUserEmail' => 'PhabricatorUserDAO',
|
2012-06-13 17:52:05 +02:00
|
|
|
'PhabricatorUserLDAPInfo' => 'PhabricatorUserDAO',
|
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',
|
2011-02-21 07:47:56 +01:00
|
|
|
'PhabricatorUserOAuthInfo' => 'PhabricatorUserDAO',
|
2011-03-31 04:21:09 +02:00
|
|
|
'PhabricatorUserPreferences' => 'PhabricatorUserDAO',
|
2011-02-20 03:28:41 +01:00
|
|
|
'PhabricatorUserProfile' => 'PhabricatorUserDAO',
|
2011-07-22 19:17:57 +02:00
|
|
|
'PhabricatorUserSSHKey' => 'PhabricatorUserDAO',
|
Improve Search architecture
Summary:
The search indexing API has several problems right now:
- Always runs in-process.
- It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it.
- Being able to use the task queue will also make rebuilding indexes faster.
- Instead, make the API phid-oriented.
- No uniform indexing API.
- Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird.
- Instead, provide a uniform API.
- No uniform CLI.
- We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers.
- Instead, let indexers expose documents for indexing.
- Not application-oriented.
- All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world.
- Instead, move indexers to applications and load them with SymbolLoader.
Test Plan:
- `bin/search index`
- Indexed one revision, one task.
- Indexed `--type TASK`, `--type DREV`, etc., for all types.
- Indexed `--all`.
- Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it.
- Creating users is a pain; searched for a user after indexing.
- Creating commits is a pain; searched for a commit after indexing.
- Mocks aren't currently loadable in the result view, so their indexing is moot.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: 20after4, aran
Maniphest Tasks: T1991, T2104
Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
|
|
|
'PhabricatorUserSearchIndexer' => 'PhabricatorSearchDocumentIndexer',
|
2012-05-04 00:47:34 +02:00
|
|
|
'PhabricatorUserStatus' => 'PhabricatorUserDAO',
|
2012-10-24 22:22:24 +02:00
|
|
|
'PhabricatorUserStatusInvalidEpochException' => 'Exception',
|
|
|
|
'PhabricatorUserStatusOverlapException' => 'Exception',
|
2012-01-16 16:30:28 +01:00
|
|
|
'PhabricatorUserTestCase' => 'PhabricatorTestCase',
|
2012-10-31 23:22:16 +01:00
|
|
|
'PhabricatorWorkerActiveTask' => 'PhabricatorWorkerTask',
|
|
|
|
'PhabricatorWorkerArchiveTask' => 'PhabricatorWorkerTask',
|
2011-03-10 22:48:29 +01:00
|
|
|
'PhabricatorWorkerDAO' => 'PhabricatorLiskDAO',
|
2012-11-01 19:30:16 +01:00
|
|
|
'PhabricatorWorkerLeaseQuery' => 'PhabricatorQuery',
|
2012-11-01 19:30:23 +01:00
|
|
|
'PhabricatorWorkerPermanentFailureException' => 'Exception',
|
2011-03-10 22:48:29 +01:00
|
|
|
'PhabricatorWorkerTask' => 'PhabricatorWorkerDAO',
|
|
|
|
'PhabricatorWorkerTaskData' => 'PhabricatorWorkerDAO',
|
2011-03-27 07:55:18 +02:00
|
|
|
'PhabricatorWorkerTaskDetailController' => 'PhabricatorDaemonController',
|
2012-01-24 01:36:32 +01:00
|
|
|
'PhabricatorWorkerTaskUpdateController' => 'PhabricatorDaemonController',
|
2012-11-01 19:30:23 +01:00
|
|
|
'PhabricatorWorkerTestCase' => 'PhabricatorTestCase',
|
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',
|
2011-02-02 22:48:52 +01:00
|
|
|
'PhabricatorXHProfController' => 'PhabricatorController',
|
2012-08-25 00:14:38 +02:00
|
|
|
'PhabricatorXHProfDAO' => 'PhabricatorLiskDAO',
|
2011-02-02 22:48:52 +01:00
|
|
|
'PhabricatorXHProfProfileController' => 'PhabricatorXHProfController',
|
2012-01-28 20:17:19 +01:00
|
|
|
'PhabricatorXHProfProfileSymbolView' => 'PhabricatorXHProfProfileView',
|
|
|
|
'PhabricatorXHProfProfileTopLevelView' => 'PhabricatorXHProfProfileView',
|
|
|
|
'PhabricatorXHProfProfileView' => 'AphrontView',
|
2012-08-25 00:14:38 +02:00
|
|
|
'PhabricatorXHProfSample' => 'PhabricatorXHProfDAO',
|
|
|
|
'PhabricatorXHProfSampleListController' => 'PhabricatorXHProfController',
|
|
|
|
'PhabricatorXHProfSampleListView' => 'AphrontView',
|
Move skins toward modularization
Summary:
Two high-level things happening here:
- We no longer ever need to put meta-UI (content creation, editing, notices, etc.) on live blog views, since this is all in Phame now. I pulled this out.
- On the other hand, I pushed more routing/control logic into Skins and made the root skin a Controller instead of a View. This simplifies some of the code above skins, and the theory behind this is that it gives us greater flexibility to, e.g., put a glue layer between Phame and Wordpress templates or whatever else, and allows skins to handle routing and thus add pages like "About" or "Bio".
- I added a basic skin below the root skin which is more like the old root skin and has standard rendering hooks.
- "Ten Eleven" is a play on the popular (default?) Wordpress themes called "Twenty Ten", "Twenty Eleven" and "Twenty Twelve".
Test Plan: Viewed live blog and live posts. They aren't pretty, but they don't have extraneous resources.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T1373
Differential Revision: https://secure.phabricator.com/D3714
2012-10-17 17:36:25 +02:00
|
|
|
'PhameBasicBlogSkin' => 'PhameBlogSkin',
|
2012-10-17 17:36:48 +02:00
|
|
|
'PhameBasicTemplateBlogSkin' => 'PhameBasicBlogSkin',
|
2012-10-15 23:49:52 +02:00
|
|
|
'PhameBlog' =>
|
|
|
|
array(
|
|
|
|
0 => 'PhameDAO',
|
|
|
|
1 => 'PhabricatorPolicyInterface',
|
2012-10-15 23:51:30 +02:00
|
|
|
2 => 'PhabricatorMarkupInterface',
|
2012-10-15 23:49:52 +02:00
|
|
|
),
|
2012-07-19 18:03:10 +02:00
|
|
|
'PhameBlogDeleteController' => 'PhameController',
|
|
|
|
'PhameBlogEditController' => 'PhameController',
|
2013-01-09 04:53:34 +01:00
|
|
|
'PhameBlogFeedController' => 'PhameController',
|
2012-10-15 23:50:12 +02:00
|
|
|
'PhameBlogListController' => 'PhameController',
|
|
|
|
'PhameBlogLiveController' => 'PhameController',
|
2012-10-15 23:49:52 +02:00
|
|
|
'PhameBlogQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
|
Move skins toward modularization
Summary:
Two high-level things happening here:
- We no longer ever need to put meta-UI (content creation, editing, notices, etc.) on live blog views, since this is all in Phame now. I pulled this out.
- On the other hand, I pushed more routing/control logic into Skins and made the root skin a Controller instead of a View. This simplifies some of the code above skins, and the theory behind this is that it gives us greater flexibility to, e.g., put a glue layer between Phame and Wordpress templates or whatever else, and allows skins to handle routing and thus add pages like "About" or "Bio".
- I added a basic skin below the root skin which is more like the old root skin and has standard rendering hooks.
- "Ten Eleven" is a play on the popular (default?) Wordpress themes called "Twenty Ten", "Twenty Eleven" and "Twenty Twelve".
Test Plan: Viewed live blog and live posts. They aren't pretty, but they don't have extraneous resources.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T1373
Differential Revision: https://secure.phabricator.com/D3714
2012-10-17 17:36:25 +02:00
|
|
|
'PhameBlogSkin' => 'PhabricatorController',
|
2012-07-19 18:03:10 +02:00
|
|
|
'PhameBlogViewController' => 'PhameController',
|
2012-04-12 22:09:04 +02:00
|
|
|
'PhameController' => 'PhabricatorController',
|
|
|
|
'PhameDAO' => 'PhabricatorLiskDAO',
|
2012-10-15 23:50:12 +02:00
|
|
|
'PhamePost' =>
|
|
|
|
array(
|
|
|
|
0 => 'PhameDAO',
|
|
|
|
1 => 'PhabricatorPolicyInterface',
|
2012-10-15 23:51:30 +02:00
|
|
|
2 => 'PhabricatorMarkupInterface',
|
2012-10-15 23:50:12 +02:00
|
|
|
),
|
2012-04-12 22:09:04 +02:00
|
|
|
'PhamePostDeleteController' => 'PhameController',
|
|
|
|
'PhamePostEditController' => 'PhameController',
|
2012-10-15 23:50:45 +02:00
|
|
|
'PhamePostFramedController' => 'PhameController',
|
2012-10-15 23:50:37 +02:00
|
|
|
'PhamePostListController' => 'PhameController',
|
2012-10-15 23:50:45 +02:00
|
|
|
'PhamePostNewController' => 'PhameController',
|
2012-10-15 23:51:30 +02:00
|
|
|
'PhamePostNotLiveController' => 'PhameController',
|
2012-04-12 22:09:04 +02:00
|
|
|
'PhamePostPreviewController' => 'PhameController',
|
2012-10-15 23:50:45 +02:00
|
|
|
'PhamePostPublishController' => 'PhameController',
|
2012-10-15 23:50:12 +02:00
|
|
|
'PhamePostQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
|
2012-10-15 23:50:45 +02:00
|
|
|
'PhamePostUnpublishController' => 'PhameController',
|
Move skins toward modularization
Summary:
Two high-level things happening here:
- We no longer ever need to put meta-UI (content creation, editing, notices, etc.) on live blog views, since this is all in Phame now. I pulled this out.
- On the other hand, I pushed more routing/control logic into Skins and made the root skin a Controller instead of a View. This simplifies some of the code above skins, and the theory behind this is that it gives us greater flexibility to, e.g., put a glue layer between Phame and Wordpress templates or whatever else, and allows skins to handle routing and thus add pages like "About" or "Bio".
- I added a basic skin below the root skin which is more like the old root skin and has standard rendering hooks.
- "Ten Eleven" is a play on the popular (default?) Wordpress themes called "Twenty Ten", "Twenty Eleven" and "Twenty Twelve".
Test Plan: Viewed live blog and live posts. They aren't pretty, but they don't have extraneous resources.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T1373
Differential Revision: https://secure.phabricator.com/D3714
2012-10-17 17:36:25 +02:00
|
|
|
'PhamePostView' => 'AphrontView',
|
2012-04-12 22:09:04 +02:00
|
|
|
'PhamePostViewController' => 'PhameController',
|
2012-10-17 17:37:05 +02:00
|
|
|
'PhameResourceController' => 'CelerityResourceController',
|
Add very basic scaffolding for Pholio
Summary:
I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc.
Basic hierarchy is:
- **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas".
- **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed.
- **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits.
- **PixelComment**: Equivalent of an inline comment.
Test Plan: Created a fake object and viewed it.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: aran, davidreuss
Maniphest Tasks: T2097
Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
|
|
|
'PholioController' => 'PhabricatorController',
|
|
|
|
'PholioDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'PholioImage' =>
|
|
|
|
array(
|
|
|
|
0 => 'PholioDAO',
|
|
|
|
1 => 'PhabricatorMarkupInterface',
|
|
|
|
),
|
|
|
|
'PholioMock' =>
|
|
|
|
array(
|
|
|
|
0 => 'PholioDAO',
|
|
|
|
1 => 'PhabricatorMarkupInterface',
|
|
|
|
2 => 'PhabricatorPolicyInterface',
|
|
|
|
3 => 'PhabricatorSubscribableInterface',
|
|
|
|
),
|
2012-11-22 02:27:20 +01:00
|
|
|
'PholioMockCommentController' => 'PholioController',
|
2012-11-22 02:23:28 +01:00
|
|
|
'PholioMockEditController' => 'PholioController',
|
2012-12-11 22:59:20 +01:00
|
|
|
'PholioMockEditor' => 'PhabricatorApplicationTransactionEditor',
|
2013-01-20 18:29:34 +01:00
|
|
|
'PholioMockImagesView' => 'AphrontView',
|
Add very basic scaffolding for Pholio
Summary:
I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc.
Basic hierarchy is:
- **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas".
- **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed.
- **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits.
- **PixelComment**: Equivalent of an inline comment.
Test Plan: Created a fake object and viewed it.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: aran, davidreuss
Maniphest Tasks: T2097
Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
|
|
|
'PholioMockListController' => 'PholioController',
|
|
|
|
'PholioMockQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
|
|
|
|
'PholioMockViewController' => 'PholioController',
|
2012-11-22 02:39:46 +01:00
|
|
|
'PholioReplyHandler' => 'PhabricatorMailReplyHandler',
|
Improve Search architecture
Summary:
The search indexing API has several problems right now:
- Always runs in-process.
- It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it.
- Being able to use the task queue will also make rebuilding indexes faster.
- Instead, make the API phid-oriented.
- No uniform indexing API.
- Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird.
- Instead, provide a uniform API.
- No uniform CLI.
- We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers.
- Instead, let indexers expose documents for indexing.
- Not application-oriented.
- All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world.
- Instead, move indexers to applications and load them with SymbolLoader.
Test Plan:
- `bin/search index`
- Indexed one revision, one task.
- Indexed `--type TASK`, `--type DREV`, etc., for all types.
- Indexed `--all`.
- Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it.
- Creating users is a pain; searched for a user after indexing.
- Creating commits is a pain; searched for a commit after indexing.
- Mocks aren't currently loadable in the result view, so their indexing is moot.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: 20after4, aran
Maniphest Tasks: T1991, T2104
Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
|
|
|
'PholioSearchIndexer' => 'PhabricatorSearchDocumentIndexer',
|
2012-12-11 22:59:20 +01:00
|
|
|
'PholioTransaction' => 'PhabricatorApplicationTransaction',
|
|
|
|
'PholioTransactionComment' => 'PhabricatorApplicationTransactionComment',
|
2012-12-11 23:00:21 +01:00
|
|
|
'PholioTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
|
2012-11-22 02:27:44 +01:00
|
|
|
'PholioTransactionType' => 'PholioConstants',
|
2012-04-05 01:09:29 +02:00
|
|
|
'PhortuneMonthYearExpiryControl' => 'AphrontFormControl',
|
|
|
|
'PhortuneStripeBaseController' => 'PhabricatorController',
|
|
|
|
'PhortuneStripePaymentFormView' => 'AphrontView',
|
|
|
|
'PhortuneStripeTestPaymentFormController' => 'PhortuneStripeBaseController',
|
2011-07-12 16:23:04 +02:00
|
|
|
'PhrictionActionConstants' => 'PhrictionConstants',
|
2011-12-17 18:19:08 +01:00
|
|
|
'PhrictionChangeType' => 'PhrictionConstants',
|
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',
|
|
|
|
),
|
2012-07-16 20:49:06 +02:00
|
|
|
'PhrictionController' => 'PhabricatorController',
|
|
|
|
'PhrictionDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'PhrictionDeleteController' => 'PhrictionController',
|
|
|
|
'PhrictionDiffController' => 'PhrictionController',
|
2013-01-12 00:28:16 +01:00
|
|
|
'PhrictionDocument' =>
|
|
|
|
array(
|
|
|
|
0 => 'PhrictionDAO',
|
|
|
|
1 => 'PhabricatorPolicyInterface',
|
|
|
|
),
|
2011-07-11 17:54:22 +02:00
|
|
|
'PhrictionDocumentController' => 'PhrictionController',
|
2012-10-10 19:18:23 +02:00
|
|
|
'PhrictionDocumentEditor' => 'PhabricatorEditor',
|
2011-07-17 03:25:45 +02:00
|
|
|
'PhrictionDocumentPreviewController' => 'PhrictionController',
|
2011-12-17 18:19:08 +01:00
|
|
|
'PhrictionDocumentStatus' => 'PhrictionConstants',
|
2011-07-12 17:08:03 +02:00
|
|
|
'PhrictionDocumentTestCase' => 'PhabricatorTestCase',
|
2011-07-11 21:34:53 +02:00
|
|
|
'PhrictionEditController' => 'PhrictionController',
|
2011-07-12 00:06:19 +02:00
|
|
|
'PhrictionHistoryController' => 'PhrictionController',
|
2011-07-12 00:42:12 +02:00
|
|
|
'PhrictionListController' => 'PhrictionController',
|
2012-11-10 00:08:37 +01:00
|
|
|
'PhrictionNewController' => 'PhrictionController',
|
Improve Search architecture
Summary:
The search indexing API has several problems right now:
- Always runs in-process.
- It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it.
- Being able to use the task queue will also make rebuilding indexes faster.
- Instead, make the API phid-oriented.
- No uniform indexing API.
- Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird.
- Instead, provide a uniform API.
- No uniform CLI.
- We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers.
- Instead, let indexers expose documents for indexing.
- Not application-oriented.
- All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world.
- Instead, move indexers to applications and load them with SymbolLoader.
Test Plan:
- `bin/search index`
- Indexed one revision, one task.
- Indexed `--type TASK`, `--type DREV`, etc., for all types.
- Indexed `--all`.
- Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it.
- Creating users is a pain; searched for a user after indexing.
- Creating commits is a pain; searched for a commit after indexing.
- Mocks aren't currently loadable in the result view, so their indexing is moot.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: 20after4, aran
Maniphest Tasks: T1991, T2104
Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
|
|
|
'PhrictionSearchIndexer' => 'PhabricatorSearchDocumentIndexer',
|
2012-08-10 19:44:04 +02:00
|
|
|
'PonderAddAnswerView' => 'AphrontView',
|
adding comments to ponder
Summary: This is pretty spartan, but it does the job.
Test Plan:
Patch, update storage, add some comment
to your favorite question or answer.
Reviewers: nh, vrana, epriestley
Reviewed By: epriestley
CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7
Maniphest Tasks: T1645
Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
|
|
|
'PonderAddCommentView' => 'AphrontView',
|
2012-08-10 19:44:04 +02:00
|
|
|
'PonderAnswer' =>
|
|
|
|
array(
|
|
|
|
0 => 'PonderDAO',
|
|
|
|
1 => 'PhabricatorMarkupInterface',
|
|
|
|
2 => 'PonderVotableInterface',
|
|
|
|
),
|
2012-10-10 19:18:23 +02:00
|
|
|
'PonderAnswerEditor' => 'PhabricatorEditor',
|
2012-08-10 19:44:04 +02:00
|
|
|
'PonderAnswerListView' => 'AphrontView',
|
|
|
|
'PonderAnswerPreviewController' => 'PonderController',
|
|
|
|
'PonderAnswerQuery' => 'PhabricatorOffsetPagedQuery',
|
|
|
|
'PonderAnswerSaveController' => 'PonderController',
|
|
|
|
'PonderAnswerViewController' => 'PonderController',
|
2012-10-08 23:47:21 +02:00
|
|
|
'PonderAnsweredMail' => 'PonderMail',
|
adding comments to ponder
Summary: This is pretty spartan, but it does the job.
Test Plan:
Patch, update storage, add some comment
to your favorite question or answer.
Reviewers: nh, vrana, epriestley
Reviewed By: epriestley
CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7
Maniphest Tasks: T1645
Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
|
|
|
'PonderComment' =>
|
|
|
|
array(
|
|
|
|
0 => 'PonderDAO',
|
|
|
|
1 => 'PhabricatorMarkupInterface',
|
|
|
|
),
|
2012-10-10 19:18:23 +02:00
|
|
|
'PonderCommentEditor' => 'PhabricatorEditor',
|
adding comments to ponder
Summary: This is pretty spartan, but it does the job.
Test Plan:
Patch, update storage, add some comment
to your favorite question or answer.
Reviewers: nh, vrana, epriestley
Reviewed By: epriestley
CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7
Maniphest Tasks: T1645
Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
|
|
|
'PonderCommentListView' => 'AphrontView',
|
2012-10-08 23:47:21 +02:00
|
|
|
'PonderCommentMail' => 'PonderMail',
|
adding comments to ponder
Summary: This is pretty spartan, but it does the job.
Test Plan:
Patch, update storage, add some comment
to your favorite question or answer.
Reviewers: nh, vrana, epriestley
Reviewed By: epriestley
CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7
Maniphest Tasks: T1645
Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
|
|
|
'PonderCommentQuery' => 'PhabricatorQuery',
|
|
|
|
'PonderCommentSaveController' => 'PonderController',
|
2012-08-10 19:44:04 +02:00
|
|
|
'PonderController' => 'PhabricatorController',
|
|
|
|
'PonderDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'PonderFeedController' => 'PonderController',
|
2012-10-08 23:47:21 +02:00
|
|
|
'PonderMentionMail' => 'PonderMail',
|
adding comments to ponder
Summary: This is pretty spartan, but it does the job.
Test Plan:
Patch, update storage, add some comment
to your favorite question or answer.
Reviewers: nh, vrana, epriestley
Reviewed By: epriestley
CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7
Maniphest Tasks: T1645
Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
|
|
|
'PonderPostBodyView' => 'AphrontView',
|
2012-08-10 19:44:04 +02:00
|
|
|
'PonderQuestion' =>
|
|
|
|
array(
|
|
|
|
0 => 'PonderDAO',
|
|
|
|
1 => 'PhabricatorMarkupInterface',
|
|
|
|
2 => 'PonderVotableInterface',
|
2012-10-08 23:47:21 +02:00
|
|
|
3 => 'PhabricatorSubscribableInterface',
|
upgrade diffusion to use modern header UI and fix a few quirks
Summary:
upgrades are CrumbsView, HeaderView, PropertyListView, and ActionListView. I had to modify CrumbsView stuff a bit to handle the "advanced" diffusion crumbs.
Quirks fixed include making file tree view show up in diffusion, the page not have extra space when the file tree is hidden, links no longer breaking once you visit files (since without the change the files always got "/" appended and thus 404'd), and a differential quirk where it read "next step:" and that colon is a no no,
Test Plan: played around in diffusion and differential
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin, chad
Maniphest Tasks: T2048, T2178
Differential Revision: https://secure.phabricator.com/D4169
2012-12-13 02:50:42 +01:00
|
|
|
4 => 'PhabricatorPolicyInterface',
|
2012-08-10 19:44:04 +02:00
|
|
|
),
|
|
|
|
'PonderQuestionAskController' => 'PonderController',
|
|
|
|
'PonderQuestionDetailView' => 'AphrontView',
|
2012-10-10 19:18:23 +02:00
|
|
|
'PonderQuestionEditor' => 'PhabricatorEditor',
|
2012-08-10 19:44:04 +02:00
|
|
|
'PonderQuestionPreviewController' => 'PonderController',
|
upgrade diffusion to use modern header UI and fix a few quirks
Summary:
upgrades are CrumbsView, HeaderView, PropertyListView, and ActionListView. I had to modify CrumbsView stuff a bit to handle the "advanced" diffusion crumbs.
Quirks fixed include making file tree view show up in diffusion, the page not have extra space when the file tree is hidden, links no longer breaking once you visit files (since without the change the files always got "/" appended and thus 404'd), and a differential quirk where it read "next step:" and that colon is a no no,
Test Plan: played around in diffusion and differential
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin, chad
Maniphest Tasks: T2048, T2178
Differential Revision: https://secure.phabricator.com/D4169
2012-12-13 02:50:42 +01:00
|
|
|
'PonderQuestionQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
|
2012-08-10 19:44:04 +02:00
|
|
|
'PonderQuestionSummaryView' => 'AphrontView',
|
|
|
|
'PonderQuestionViewController' => 'PonderController',
|
2012-10-08 23:47:21 +02:00
|
|
|
'PonderReplyHandler' => 'PhabricatorMailReplyHandler',
|
2012-08-10 19:44:04 +02:00
|
|
|
'PonderRuleQuestion' => 'PhabricatorRemarkupRuleObjectName',
|
Improve Search architecture
Summary:
The search indexing API has several problems right now:
- Always runs in-process.
- It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it.
- Being able to use the task queue will also make rebuilding indexes faster.
- Instead, make the API phid-oriented.
- No uniform indexing API.
- Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird.
- Instead, provide a uniform API.
- No uniform CLI.
- We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers.
- Instead, let indexers expose documents for indexing.
- Not application-oriented.
- All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world.
- Instead, move indexers to applications and load them with SymbolLoader.
Test Plan:
- `bin/search index`
- Indexed one revision, one task.
- Indexed `--type TASK`, `--type DREV`, etc., for all types.
- Indexed `--all`.
- Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it.
- Creating users is a pain; searched for a user after indexing.
- Creating commits is a pain; searched for a commit after indexing.
- Mocks aren't currently loadable in the result view, so their indexing is moot.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: 20after4, aran
Maniphest Tasks: T1991, T2104
Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
|
|
|
'PonderSearchIndexer' => 'PhabricatorSearchDocumentIndexer',
|
2012-08-10 19:44:04 +02:00
|
|
|
'PonderUserProfileView' => 'AphrontView',
|
|
|
|
'PonderVotableView' => 'AphrontView',
|
2012-10-10 19:18:23 +02:00
|
|
|
'PonderVoteEditor' => 'PhabricatorEditor',
|
2012-08-10 19:44:04 +02:00
|
|
|
'PonderVoteSaveController' => 'PonderController',
|
2012-07-26 21:01:47 +02:00
|
|
|
'QueryFormattingTestCase' => 'PhabricatorTestCase',
|
2011-01-16 22:51:39 +01:00
|
|
|
),
|
|
|
|
));
|