1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-27 09:12:41 +01:00
phorge-phorge/src/__phutil_library_map__.php

1915 lines
134 KiB
PHP
Raw Normal View History

<?php
/**
* This file is automatically generated. Use 'phutil_mapper.php' to rebuild it.
* @generated
*/
phutil_register_library_map(array(
'class' =>
array(
'Aphront304Response' => 'aphront/response/304',
'Aphront400Response' => 'aphront/response/400',
'Aphront403Response' => 'aphront/response/403',
'Aphront404Response' => 'aphront/response/404',
2011-01-25 20:57:47 +01:00
'AphrontAjaxResponse' => 'aphront/response/ajax',
'AphrontApplicationConfiguration' => 'aphront/applicationconfiguration',
'AphrontAttachedFileView' => 'view/control/attachedfile',
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' => 'aphront/exception/csrf',
'AphrontCalendarMonthView' => 'applications/calendar/view/month',
'AphrontContextBarView' => 'view/layout/contextbar',
'AphrontController' => 'aphront/controller',
'AphrontCrumbsView' => 'view/layout/crumbs',
'AphrontDatabaseConnection' => 'storage/connection/base',
'AphrontDatabaseTransactionState' => 'storage/transaction',
'AphrontDefaultApplicationConfiguration' => 'aphront/default/configuration',
'AphrontDialogResponse' => 'aphront/response/dialog',
'AphrontDialogView' => 'view/dialog',
'AphrontErrorView' => 'view/form/error',
2011-01-26 22:21:12 +01:00
'AphrontException' => 'aphront/exception/base',
'AphrontFilePreviewView' => 'view/layout/filepreview',
2011-01-23 03:33:00 +01:00
'AphrontFileResponse' => 'aphront/response/file',
2011-01-26 02:40:21 +01:00
'AphrontFormCheckboxControl' => 'view/form/control/checkbox',
'AphrontFormControl' => 'view/form/control/base',
'AphrontFormDateControl' => 'view/form/control/date',
'AphrontFormDividerControl' => 'view/form/control/divider',
'AphrontFormDragAndDropUploadControl' => 'view/form/control/draganddropupload',
2011-01-23 03:33:00 +01:00
'AphrontFormFileControl' => 'view/form/control/file',
'AphrontFormInsetView' => 'view/form/inset',
'AphrontFormLayoutView' => 'view/form/layout',
2011-01-24 20:36:53 +01:00
'AphrontFormMarkupControl' => 'view/form/control/markup',
'AphrontFormPasswordControl' => 'view/form/control/password',
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' => 'view/form/control/policy',
'AphrontFormRadioButtonControl' => 'view/form/control/radio',
'AphrontFormRecaptchaControl' => 'view/form/control/recaptcha',
'AphrontFormSelectControl' => 'view/form/control/select',
2011-01-23 03:33:00 +01:00
'AphrontFormStaticControl' => 'view/form/control/static',
'AphrontFormSubmitControl' => 'view/form/control/submit',
'AphrontFormTextAreaControl' => 'view/form/control/textarea',
'AphrontFormTextControl' => 'view/form/control/text',
'AphrontFormToggleButtonsControl' => 'view/form/control/togglebuttons',
2011-01-25 22:48:05 +01:00
'AphrontFormTokenizerControl' => 'view/form/control/tokenizer',
'AphrontFormView' => 'view/form/base',
'AphrontHTTPSink' => 'aphront/sink/base',
'AphrontHTTPSinkTestCase' => 'aphront/sink/base/__tests__',
'AphrontHeadsupActionListView' => 'view/layout/headsup/actionlist',
'AphrontHeadsupActionView' => 'view/layout/headsup/action',
'AphrontHeadsupView' => 'view/layout/headsup/panel',
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
'AphrontIDPagerView' => 'view/control/idpager',
'AphrontIsolatedDatabaseConnection' => 'storage/connection/isolated',
'AphrontIsolatedDatabaseConnectionTestCase' => 'storage/connection/isolated/__tests__',
'AphrontIsolatedHTTPSink' => 'aphront/sink/test',
'AphrontJSONResponse' => 'aphront/response/json',
'AphrontJavelinView' => 'view/javelin-view',
'AphrontKeyboardShortcutsAvailableView' => 'view/widget/keyboardshortcuts',
'AphrontListFilterView' => 'view/layout/listfilter',
'AphrontMiniPanelView' => 'view/layout/minipanel',
'AphrontMySQLDatabaseConnection' => 'storage/connection/mysql/mysql',
'AphrontMySQLDatabaseConnectionBase' => 'storage/connection/mysql/base',
'AphrontMySQLDatabaseConnectionTestCase' => 'storage/connection/mysql/__tests__',
'AphrontMySQLiDatabaseConnection' => 'storage/connection/mysql/mysqli',
'AphrontNullView' => 'view/null',
'AphrontPHPHTTPSink' => 'aphront/sink/php',
'AphrontPageView' => 'view/page/base',
2011-04-01 02:06:33 +02:00
'AphrontPagerView' => 'view/control/pager',
'AphrontPanelView' => 'view/layout/panel',
'AphrontPlainTextResponse' => 'aphront/response/plaintext',
'AphrontProxyResponse' => 'aphront/response/proxy',
'AphrontQueryAccessDeniedException' => 'storage/exception/accessdenied',
'AphrontQueryConnectionException' => 'storage/exception/connection',
'AphrontQueryConnectionLostException' => 'storage/exception/connectionlost',
'AphrontQueryCountException' => 'storage/exception/count',
2011-01-31 06:28:45 +01:00
'AphrontQueryDuplicateKeyException' => 'storage/exception/duplicatekey',
'AphrontQueryException' => 'storage/exception/base',
'AphrontQueryObjectMissingException' => 'storage/exception/objectmissing',
'AphrontQueryParameterException' => 'storage/exception/parameter',
'AphrontQueryRecoverableException' => 'storage/exception/recoverable',
'AphrontQuerySchemaException' => 'storage/exception/schema',
2011-01-26 22:21:12 +01:00
'AphrontRedirectException' => 'aphront/exception/redirect',
'AphrontRedirectResponse' => 'aphront/response/redirect',
'AphrontReloadResponse' => 'aphront/response/reload',
'AphrontRequest' => 'aphront/request',
2011-01-30 18:15:01 +01:00
'AphrontRequestFailureView' => 'view/page/failure',
'AphrontRequestTestCase' => 'aphront/request/__tests__',
'AphrontResponse' => 'aphront/response/base',
'AphrontScopedUnguardedWriteCapability' => 'aphront/writeguard/scopeguard',
'AphrontSideNavFilterView' => 'view/layout/sidenavfilter',
2011-01-24 18:00:29 +01:00
'AphrontSideNavView' => 'view/layout/sidenav',
'AphrontTableView' => 'view/control/table',
2011-03-23 04:41:02 +01:00
'AphrontTokenizerTemplateView' => 'view/control/tokenizer',
2011-04-04 04:20:47 +02:00
'AphrontTypeaheadTemplateView' => 'view/control/typeahead',
'AphrontURIMapper' => 'aphront/mapper',
'AphrontUsageException' => 'aphront/exception/usage',
'AphrontView' => 'view/base',
'AphrontWebpageResponse' => 'aphront/response/webpage',
'AphrontWriteGuard' => 'aphront/writeguard',
'CelerityAPI' => 'infrastructure/celerity/api',
'CelerityResourceController' => 'infrastructure/celerity/controller',
'CelerityResourceGraph' => 'infrastructure/celerity/graph',
'CelerityResourceMap' => 'infrastructure/celerity/map',
'CelerityResourceTransformer' => 'infrastructure/celerity/transformer',
'CelerityResourceTransformerTestCase' => 'infrastructure/celerity/transformer/__tests__',
'CelerityStaticResourceResponse' => 'infrastructure/celerity/response',
2011-01-24 18:00:29 +01:00
'ConduitAPIMethod' => 'applications/conduit/method/base',
'ConduitAPIRequest' => 'applications/conduit/protocol/request',
'ConduitAPIResponse' => 'applications/conduit/protocol/response',
'ConduitAPI_arcanist_Method' => 'applications/conduit/method/arcanist/base',
'ConduitAPI_arcanist_projectinfo_Method' => 'applications/conduit/method/arcanist/projectinfo',
'ConduitAPI_audit_Method' => 'applications/conduit/method/audit/base',
'ConduitAPI_audit_query_Method' => 'applications/conduit/method/audit/query',
'ConduitAPI_chatlog_Method' => 'applications/conduit/method/chatlog/base',
'ConduitAPI_chatlog_query_Method' => 'applications/conduit/method/chatlog/query',
'ConduitAPI_chatlog_record_Method' => 'applications/conduit/method/chatlog/record',
2011-01-24 20:30:10 +01:00
'ConduitAPI_conduit_connect_Method' => 'applications/conduit/method/conduit/connect',
'ConduitAPI_conduit_getcertificate_Method' => 'applications/conduit/method/conduit/getcertificate',
'ConduitAPI_conduit_ping_Method' => 'applications/conduit/method/conduit/ping',
2011-03-15 21:38:14 +01:00
'ConduitAPI_daemon_launched_Method' => 'applications/conduit/method/daemon/launched',
'ConduitAPI_daemon_log_Method' => 'applications/conduit/method/daemon/log',
'ConduitAPI_differential_close_Method' => 'applications/conduit/method/differential/close',
'ConduitAPI_differential_createcomment_Method' => 'applications/conduit/method/differential/createcomment',
2011-01-24 20:01:53 +01:00
'ConduitAPI_differential_creatediff_Method' => 'applications/conduit/method/differential/creatediff',
'ConduitAPI_differential_createrevision_Method' => 'applications/conduit/method/differential/createrevision',
'ConduitAPI_differential_find_Method' => 'applications/conduit/method/differential/find',
'ConduitAPI_differential_getalldiffs_Method' => 'applications/conduit/method/differential/getalldiffs',
'ConduitAPI_differential_getcommitmessage_Method' => 'applications/conduit/method/differential/getcommitmessage',
'ConduitAPI_differential_getcommitpaths_Method' => 'applications/conduit/method/differential/getcommitpaths',
'ConduitAPI_differential_getdiff_Method' => 'applications/conduit/method/differential/getdiff',
'ConduitAPI_differential_getrevision_Method' => 'applications/conduit/method/differential/getrevision',
'ConduitAPI_differential_getrevisioncomments_Method' => 'applications/conduit/method/differential/getrevisioncomments',
'ConduitAPI_differential_getrevisionfeedback_Method' => 'applications/conduit/method/differential/getrevisionfeedback',
'ConduitAPI_differential_markcommitted_Method' => 'applications/conduit/method/differential/markcommitted',
'ConduitAPI_differential_parsecommitmessage_Method' => 'applications/conduit/method/differential/parsecommitmessage',
'ConduitAPI_differential_query_Method' => 'applications/conduit/method/differential/query',
2011-01-24 21:07:34 +01:00
'ConduitAPI_differential_setdiffproperty_Method' => 'applications/conduit/method/differential/setdiffproperty',
'ConduitAPI_differential_updaterevision_Method' => 'applications/conduit/method/differential/updaterevision',
'ConduitAPI_differential_updatetaskrevisionassoc_Method' => 'applications/conduit/method/differential/updatetaskrevisionassoc',
'ConduitAPI_differential_updateunitresults_Method' => 'applications/conduit/method/differential/updateunitresults',
'ConduitAPI_diffusion_findsymbols_Method' => 'applications/conduit/method/diffusion/findsymbols',
'ConduitAPI_diffusion_getcommits_Method' => 'applications/conduit/method/diffusion/getcommits',
'ConduitAPI_diffusion_getrecentcommitsbypath_Method' => 'applications/conduit/method/diffusion/getrecentcommitsbypath',
'ConduitAPI_feed_publish_Method' => 'applications/conduit/method/feed/publish',
'ConduitAPI_feed_query_Method' => 'applications/conduit/method/feed/query',
'ConduitAPI_file_download_Method' => 'applications/conduit/method/file/download',
'ConduitAPI_file_info_Method' => 'applications/conduit/method/file/info',
2011-01-24 18:00:29 +01:00
'ConduitAPI_file_upload_Method' => 'applications/conduit/method/file/upload',
'ConduitAPI_flag_Method' => 'applications/conduit/method/flag/base',
'ConduitAPI_flag_query_Method' => 'applications/conduit/method/flag/query',
'ConduitAPI_macro_Method' => 'applications/conduit/method/macro/base',
'ConduitAPI_macro_query_Method' => 'applications/conduit/method/macro/query',
'ConduitAPI_maniphest_Method' => 'applications/conduit/method/maniphest/base',
'ConduitAPI_maniphest_createtask_Method' => 'applications/conduit/method/maniphest/createtask',
'ConduitAPI_maniphest_find_Method' => 'applications/conduit/method/maniphest/find',
'ConduitAPI_maniphest_gettasktransactions_Method' => 'applications/conduit/method/maniphest/gettasktransactions',
'ConduitAPI_maniphest_info_Method' => 'applications/conduit/method/maniphest/info',
'ConduitAPI_maniphest_update_Method' => 'applications/conduit/method/maniphest/update',
'ConduitAPI_paste_Method' => 'applications/conduit/method/paste/base',
'ConduitAPI_paste_create_Method' => 'applications/conduit/method/paste/create',
'ConduitAPI_paste_info_Method' => 'applications/conduit/method/paste/info',
'ConduitAPI_path_getowners_Method' => 'applications/conduit/method/path/getowners',
'ConduitAPI_phid_Method' => 'applications/conduit/method/phid/base',
'ConduitAPI_phid_info_Method' => 'applications/conduit/method/phid/info',
'ConduitAPI_phid_query_Method' => 'applications/conduit/method/phid/query',
'ConduitAPI_phriction_Method' => 'applications/conduit/method/phriction/base',
'ConduitAPI_phriction_edit_Method' => 'applications/conduit/method/phriction/edit',
'ConduitAPI_phriction_history_Method' => 'applications/conduit/method/phriction/history',
'ConduitAPI_phriction_info_Method' => 'applications/conduit/method/phriction/info',
'ConduitAPI_project_Method' => 'applications/conduit/method/project/base',
'ConduitAPI_project_query_Method' => 'applications/conduit/method/project/query',
'ConduitAPI_remarkup_process_Method' => 'applications/conduit/method/remarkup/process',
'ConduitAPI_repository_Method' => 'applications/conduit/method/repository/base',
'ConduitAPI_repository_create_Method' => 'applications/conduit/method/repository/create',
'ConduitAPI_repository_query_Method' => 'applications/conduit/method/repository/query',
'ConduitAPI_slowvote_info_Method' => 'applications/conduit/method/slowvote/info',
'ConduitAPI_user_Method' => 'applications/conduit/method/user/base',
'ConduitAPI_user_addstatus_Method' => 'applications/conduit/method/user/addstatus',
'ConduitAPI_user_removestatus_Method' => 'applications/conduit/method/user/removestatus',
2011-01-24 20:36:53 +01:00
'ConduitAPI_user_find_Method' => 'applications/conduit/method/user/find',
'ConduitAPI_user_info_Method' => 'applications/conduit/method/user/info',
'ConduitAPI_user_whoami_Method' => 'applications/conduit/method/user/whoami',
2011-01-24 18:00:29 +01:00
'ConduitException' => 'applications/conduit/protocol/exception',
'DarkConsoleConfigPlugin' => 'aphront/console/plugin/config',
2011-02-02 22:48:52 +01:00
'DarkConsoleController' => 'aphront/console/controller',
'DarkConsoleCore' => 'aphront/console/core',
'DarkConsoleErrorLogPlugin' => 'aphront/console/plugin/errorlog',
2011-02-03 07:38:42 +01:00
'DarkConsoleErrorLogPluginAPI' => 'aphront/console/plugin/errorlog/api',
'DarkConsoleEventPlugin' => 'aphront/console/plugin/event',
'DarkConsoleEventPluginAPI' => 'aphront/console/plugin/event/api',
2011-02-02 22:48:52 +01:00
'DarkConsolePlugin' => 'aphront/console/plugin/base',
'DarkConsoleRequestPlugin' => 'aphront/console/plugin/request',
'DarkConsoleServicesPlugin' => 'aphront/console/plugin/services',
'DarkConsoleXHProfPlugin' => 'aphront/console/plugin/xhprof',
'DarkConsoleXHProfPluginAPI' => 'aphront/console/plugin/xhprof/api',
'DatabaseConfigurationProvider' => 'applications/base/storage/configuration/base',
'DefaultDatabaseConfigurationProvider' => 'applications/base/storage/configuration/default',
2011-01-24 03:10:20 +01:00
'DifferentialAction' => 'applications/differential/constants/action',
'DifferentialActionHasNoEffectException' => 'applications/differential/exception/noeffect',
2011-01-30 20:02:22 +01:00
'DifferentialAddCommentView' => 'applications/differential/view/addcomment',
'DifferentialAffectedPath' => 'applications/differential/storage/affectedpath',
'DifferentialApplyPatchFieldSpecification' => 'applications/differential/field/specification/applypatch',
'DifferentialArcanistProjectFieldSpecification' => 'applications/differential/field/specification/arcanistproject',
'DifferentialAuditorsFieldSpecification' => 'applications/differential/field/specification/auditors',
'DifferentialAuthorFieldSpecification' => 'applications/differential/field/specification/author',
'DifferentialAuxiliaryField' => 'applications/differential/storage/auxiliaryfield',
'DifferentialBlameRevisionFieldSpecification' => 'applications/differential/field/specification/blamerev',
'DifferentialBranchFieldSpecification' => 'applications/differential/field/specification/branch',
2011-01-26 02:17:19 +01:00
'DifferentialCCWelcomeMail' => 'applications/differential/mail/ccwelcome',
'DifferentialCCsFieldSpecification' => 'applications/differential/field/specification/ccs',
2011-01-24 03:10:20 +01:00
'DifferentialChangeType' => 'applications/differential/constants/changetype',
2011-01-24 20:01:53 +01:00
'DifferentialChangeset' => 'applications/differential/storage/changeset',
2011-01-24 22:18:41 +01:00
'DifferentialChangesetDetailView' => 'applications/differential/view/changesetdetailview',
2011-01-25 20:57:47 +01:00
'DifferentialChangesetListView' => 'applications/differential/view/changesetlistview',
2011-01-25 00:52:35 +01:00
'DifferentialChangesetParser' => 'applications/differential/parser/changeset',
'DifferentialChangesetViewController' => 'applications/differential/controller/changesetview',
'DifferentialComment' => 'applications/differential/storage/comment',
'DifferentialCommentEditor' => 'applications/differential/editor/comment',
'DifferentialCommentMail' => 'applications/differential/mail/comment',
2011-02-01 03:05:20 +01:00
'DifferentialCommentPreviewController' => 'applications/differential/controller/commentpreview',
'DifferentialCommentSaveController' => 'applications/differential/controller/commentsave',
'DifferentialCommitsFieldSpecification' => 'applications/differential/field/specification/commits',
2011-01-24 22:18:41 +01:00
'DifferentialController' => 'applications/differential/controller/base',
2011-01-24 20:01:53 +01:00
'DifferentialDAO' => 'applications/differential/storage/base',
'DifferentialDateCreatedFieldSpecification' => 'applications/differential/field/specification/datecreated',
'DifferentialDateModifiedFieldSpecification' => 'applications/differential/field/specification/datemodified',
'DifferentialDefaultFieldSelector' => 'applications/differential/field/selector/default',
'DifferentialDependenciesFieldSpecification' => 'applications/differential/field/specification/dependencies',
2011-01-24 20:01:53 +01:00
'DifferentialDiff' => 'applications/differential/storage/diff',
2011-01-26 02:17:19 +01:00
'DifferentialDiffContentMail' => 'applications/differential/mail/diffcontent',
'DifferentialDiffCreateController' => 'applications/differential/controller/diffcreate',
2011-01-24 21:07:34 +01:00
'DifferentialDiffProperty' => 'applications/differential/storage/diffproperty',
2011-01-24 22:18:41 +01:00
'DifferentialDiffTableOfContentsView' => 'applications/differential/view/difftableofcontents',
'DifferentialDiffViewController' => 'applications/differential/controller/diffview',
'DifferentialException' => 'applications/differential/exception/base',
'DifferentialExceptionMail' => 'applications/differential/mail/exception',
'DifferentialExportPatchFieldSpecification' => 'applications/differential/field/specification/exportpatch',
'DifferentialFieldDataNotAvailableException' => 'applications/differential/field/exception/notavailable',
'DifferentialFieldParseException' => 'applications/differential/field/exception/parse',
'DifferentialFieldSelector' => 'applications/differential/field/selector/base',
'DifferentialFieldSpecification' => 'applications/differential/field/specification/base',
'DifferentialFieldSpecificationIncompleteException' => 'applications/differential/field/exception/incomplete',
'DifferentialFieldValidationException' => 'applications/differential/field/exception/validation',
'DifferentialGitSVNIDFieldSpecification' => 'applications/differential/field/specification/gitsvnid',
'DifferentialHostFieldSpecification' => 'applications/differential/field/specification/host',
2011-01-24 20:01:53 +01:00
'DifferentialHunk' => 'applications/differential/storage/hunk',
'DifferentialInlineComment' => 'applications/differential/storage/inlinecomment',
2011-02-02 01:42:36 +01:00
'DifferentialInlineCommentEditController' => 'applications/differential/controller/inlinecommentedit',
'DifferentialInlineCommentEditView' => 'applications/differential/view/inlinecommentedit',
2011-02-03 04:38:43 +01:00
'DifferentialInlineCommentPreviewController' => 'applications/differential/controller/inlinecommentpreview',
2011-02-02 01:42:36 +01:00
'DifferentialInlineCommentView' => 'applications/differential/view/inlinecomment',
'DifferentialLinesFieldSpecification' => 'applications/differential/field/specification/lines',
'DifferentialLintFieldSpecification' => 'applications/differential/field/specification/lint',
2011-01-24 03:10:20 +01:00
'DifferentialLintStatus' => 'applications/differential/constants/lintstatus',
'DifferentialLocalCommitsView' => 'applications/differential/view/localcommits',
2011-01-26 02:17:19 +01:00
'DifferentialMail' => 'applications/differential/mail/base',
'DifferentialManiphestTasksFieldSpecification' => 'applications/differential/field/specification/maniphesttasks',
2011-01-26 02:17:19 +01:00
'DifferentialNewDiffMail' => 'applications/differential/mail/newdiff',
'DifferentialPathFieldSpecification' => 'applications/differential/field/specification/path',
'DifferentialPrimaryPaneView' => 'applications/differential/view/primarypane',
'DifferentialReplyHandler' => 'applications/differential/replyhandler',
'DifferentialResultsTableView' => 'applications/differential/view/resultstableview',
'DifferentialRevertPlanFieldSpecification' => 'applications/differential/field/specification/revertplan',
2011-01-26 02:17:19 +01:00
'DifferentialReviewRequestMail' => 'applications/differential/mail/reviewrequest',
'DifferentialReviewedByFieldSpecification' => 'applications/differential/field/specification/reviewedby',
'DifferentialReviewersFieldSpecification' => 'applications/differential/field/specification/reviewers',
2011-01-24 20:01:53 +01:00
'DifferentialRevision' => 'applications/differential/storage/revision',
'DifferentialRevisionCommentListView' => 'applications/differential/view/revisioncommentlist',
'DifferentialRevisionCommentView' => 'applications/differential/view/revisioncomment',
2011-01-24 20:01:53 +01:00
'DifferentialRevisionControlSystem' => 'applications/differential/constants/revisioncontrolsystem',
'DifferentialRevisionDetailRenderer' => 'applications/differential/controller/customrenderer',
2011-01-27 23:55:52 +01:00
'DifferentialRevisionDetailView' => 'applications/differential/view/revisiondetail',
2011-01-25 22:26:09 +01:00
'DifferentialRevisionEditController' => 'applications/differential/controller/revisionedit',
2011-01-26 02:17:19 +01:00
'DifferentialRevisionEditor' => 'applications/differential/editor/revision',
'DifferentialRevisionIDFieldParserTestCase' => 'applications/differential/field/specification/revisionid/__tests__',
'DifferentialRevisionIDFieldSpecification' => 'applications/differential/field/specification/revisionid',
2011-01-26 00:19:06 +01:00
'DifferentialRevisionListController' => 'applications/differential/controller/revisionlist',
2011-01-27 20:35:04 +01:00
'DifferentialRevisionListData' => 'applications/differential/data/revisionlist',
'DifferentialRevisionListView' => 'applications/differential/view/revisionlist',
'DifferentialRevisionQuery' => 'applications/differential/query/revision',
'DifferentialRevisionStatsController' => 'applications/differential/controller/revisionstats',
'DifferentialRevisionStatsView' => 'applications/differential/view/revisionstats',
'DifferentialRevisionStatusFieldSpecification' => 'applications/differential/field/specification/revisionstatus',
2011-01-27 23:55:52 +01:00
'DifferentialRevisionUpdateHistoryView' => 'applications/differential/view/revisionupdatehistory',
'DifferentialRevisionViewController' => 'applications/differential/controller/revisionview',
'DifferentialSubscribeController' => 'applications/differential/controller/subscribe',
'DifferentialSummaryFieldSpecification' => 'applications/differential/field/specification/summary',
'DifferentialTasksAttacher' => 'applications/differential/tasks',
'DifferentialTestPlanFieldSpecification' => 'applications/differential/field/specification/testplan',
'DifferentialTitleFieldSpecification' => 'applications/differential/field/specification/title',
'DifferentialUnitFieldSpecification' => 'applications/differential/field/specification/unit',
2011-01-24 03:10:20 +01:00
'DifferentialUnitStatus' => 'applications/differential/constants/unitstatus',
'DifferentialUnitTestResult' => 'applications/differential/constants/unittestresult',
'DiffusionBranchInformation' => 'applications/diffusion/data/branch',
'DiffusionBranchQuery' => 'applications/diffusion/query/branch/base',
'DiffusionBranchTableView' => 'applications/diffusion/view/branchtable',
'DiffusionBrowseController' => 'applications/diffusion/controller/browse',
'DiffusionBrowseFileController' => 'applications/diffusion/controller/file',
'DiffusionBrowseQuery' => 'applications/diffusion/query/browse/base',
'DiffusionBrowseTableView' => 'applications/diffusion/view/browsetable',
2011-03-14 06:03:30 +01:00
'DiffusionChangeController' => 'applications/diffusion/controller/change',
'DiffusionCommentListView' => 'applications/diffusion/view/commentlist',
'DiffusionCommentView' => 'applications/diffusion/view/comment',
'DiffusionCommitChangeTableView' => 'applications/diffusion/view/commitchangetable',
'DiffusionCommitController' => 'applications/diffusion/controller/commit',
'DiffusionCommitParentsQuery' => 'applications/diffusion/query/parents/base',
'DiffusionCommitTagsQuery' => 'applications/diffusion/query/committags/base',
'DiffusionContainsQuery' => 'applications/diffusion/query/contains/base',
'DiffusionController' => 'applications/diffusion/controller/base',
2011-03-31 02:36:16 +02:00
'DiffusionDiffController' => 'applications/diffusion/controller/diff',
'DiffusionDiffQuery' => 'applications/diffusion/query/diff/base',
'DiffusionEmptyResultView' => 'applications/diffusion/view/emptyresult',
'DiffusionExternalController' => 'applications/diffusion/controller/external',
'DiffusionFileContent' => 'applications/diffusion/data/filecontent',
'DiffusionFileContentQuery' => 'applications/diffusion/query/filecontent/base',
'DiffusionGitBranchQuery' => 'applications/diffusion/query/branch/git',
'DiffusionGitBranchQueryTestCase' => 'applications/diffusion/query/branch/git/__tests__',
'DiffusionGitBrowseQuery' => 'applications/diffusion/query/browse/git',
'DiffusionGitCommitParentsQuery' => 'applications/diffusion/query/parents/git',
'DiffusionGitCommitTagsQuery' => 'applications/diffusion/query/committags/git',
'DiffusionGitContainsQuery' => 'applications/diffusion/query/contains/git',
2011-03-31 03:17:36 +02:00
'DiffusionGitDiffQuery' => 'applications/diffusion/query/diff/git',
'DiffusionGitFileContentQuery' => 'applications/diffusion/query/filecontent/git',
'DiffusionGitHistoryQuery' => 'applications/diffusion/query/history/git',
'DiffusionGitLastModifiedQuery' => 'applications/diffusion/query/lastmodified/git',
'DiffusionGitMergedCommitsQuery' => 'applications/diffusion/query/mergedcommits/git',
'DiffusionGitRawDiffQuery' => 'applications/diffusion/query/rawdiff/git',
'DiffusionGitRenameHistoryQuery' => 'applications/diffusion/query/renamehistory/git',
'DiffusionGitRequest' => 'applications/diffusion/request/git',
'DiffusionGitTagListQuery' => 'applications/diffusion/query/taglist/git',
'DiffusionHistoryController' => 'applications/diffusion/controller/history',
'DiffusionHistoryQuery' => 'applications/diffusion/query/history/base',
'DiffusionHistoryTableView' => 'applications/diffusion/view/historytable',
'DiffusionHomeController' => 'applications/diffusion/controller/home',
'DiffusionInlineCommentController' => 'applications/diffusion/controller/inline',
'DiffusionLastModifiedController' => 'applications/diffusion/controller/lastmodified',
'DiffusionLastModifiedQuery' => 'applications/diffusion/query/lastmodified/base',
'DiffusionMercurialBranchQuery' => 'applications/diffusion/query/branch/mercurial',
'DiffusionMercurialBrowseQuery' => 'applications/diffusion/query/browse/mercurial',
'DiffusionMercurialCommitParentsQuery' => 'applications/diffusion/query/parents/mercurial',
'DiffusionMercurialCommitTagsQuery' => 'applications/diffusion/query/committags/mercurial',
'DiffusionMercurialContainsQuery' => 'applications/diffusion/query/contains/mercurial',
'DiffusionMercurialDiffQuery' => 'applications/diffusion/query/diff/mercurial',
'DiffusionMercurialFileContentQuery' => 'applications/diffusion/query/filecontent/mercurial',
'DiffusionMercurialHistoryQuery' => 'applications/diffusion/query/history/mercurial',
'DiffusionMercurialLastModifiedQuery' => 'applications/diffusion/query/lastmodified/mercurial',
'DiffusionMercurialMergedCommitsQuery' => 'applications/diffusion/query/mergedcommits/mercurial',
'DiffusionMercurialRawDiffQuery' => 'applications/diffusion/query/rawdiff/mercurial',
'DiffusionMercurialRenameHistoryQuery' => 'applications/diffusion/query/renamehistory/mercurial',
'DiffusionMercurialRequest' => 'applications/diffusion/request/mercurial',
'DiffusionMercurialTagListQuery' => 'applications/diffusion/query/taglist/mercurial',
'DiffusionMergedCommitsQuery' => 'applications/diffusion/query/mergedcommits/base',
'DiffusionPathChange' => 'applications/diffusion/data/pathchange',
2011-03-14 00:19:39 +01:00
'DiffusionPathChangeQuery' => 'applications/diffusion/query/pathchange/base',
2011-04-04 04:20:47 +02:00
'DiffusionPathCompleteController' => 'applications/diffusion/controller/pathcomplete',
'DiffusionPathIDQuery' => 'applications/diffusion/query/pathid/base',
'DiffusionPathQuery' => 'applications/diffusion/query/path',
'DiffusionPathQueryTestCase' => 'applications/diffusion/query/pathid/base/__tests__',
2011-04-04 04:20:47 +02:00
'DiffusionPathValidateController' => 'applications/diffusion/controller/pathvalidate',
'DiffusionQuery' => 'applications/diffusion/query/base',
'DiffusionRawDiffQuery' => 'applications/diffusion/query/rawdiff/base',
'DiffusionRenameHistoryQuery' => 'applications/diffusion/query/renamehistory/base',
'DiffusionRepositoryController' => 'applications/diffusion/controller/repository',
'DiffusionRepositoryPath' => 'applications/diffusion/data/repositorypath',
'DiffusionRepositoryTag' => 'applications/diffusion/tag',
'DiffusionRequest' => 'applications/diffusion/request/base',
'DiffusionSvnBrowseQuery' => 'applications/diffusion/query/browse/svn',
'DiffusionSvnCommitParentsQuery' => 'applications/diffusion/query/parents/svn',
'DiffusionSvnCommitTagsQuery' => 'applications/diffusion/query/committags/svn',
2012-03-24 20:52:14 +01:00
'DiffusionSvnContainsQuery' => 'applications/diffusion/query/contains/svn',
2011-03-31 02:36:16 +02:00
'DiffusionSvnDiffQuery' => 'applications/diffusion/query/diff/svn',
2011-03-14 06:03:30 +01:00
'DiffusionSvnFileContentQuery' => 'applications/diffusion/query/filecontent/svn',
'DiffusionSvnHistoryQuery' => 'applications/diffusion/query/history/svn',
'DiffusionSvnLastModifiedQuery' => 'applications/diffusion/query/lastmodified/svn',
'DiffusionSvnMergedCommitsQuery' => 'applications/diffusion/query/mergedcommits/svn',
'DiffusionSvnRawDiffQuery' => 'applications/diffusion/query/rawdiff/svn',
'DiffusionSvnRenameHistoryQuery' => 'applications/diffusion/query/renamehistory/svn',
'DiffusionSvnRequest' => 'applications/diffusion/request/svn',
'DiffusionSvnTagListQuery' => 'applications/diffusion/query/taglist/svn',
'DiffusionSymbolController' => 'applications/diffusion/controller/symbol',
'DiffusionSymbolQuery' => 'applications/diffusion/query/symbol',
'DiffusionTagListController' => 'applications/diffusion/controller/taglist',
'DiffusionTagListQuery' => 'applications/diffusion/query/taglist/base',
'DiffusionTagListView' => 'applications/diffusion/view/taglist',
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' => 'applications/diffusion/request/base/__tests__',
'DiffusionView' => 'applications/diffusion/view/base',
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
'DrydockAllocator' => 'applications/drydock/allocator/resource',
'DrydockAllocatorWorker' => 'applications/drydock/allocator/worker',
'DrydockApacheWebrootBlueprint' => 'applications/drydock/blueprint/webroot/apache',
'DrydockApacheWebrootInterface' => 'applications/drydock/interface/webroot/apache',
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
'DrydockBlueprint' => 'applications/drydock/blueprint/base',
'DrydockCommandInterface' => 'applications/drydock/interface/command/base',
'DrydockConstants' => 'applications/drydock/constants/base',
'DrydockController' => 'applications/drydock/controller/base',
'DrydockDAO' => 'applications/drydock/storage/base',
'DrydockEC2HostBlueprint' => 'applications/drydock/blueprint/ec2host',
'DrydockInterface' => 'applications/drydock/interface/base',
'DrydockLease' => 'applications/drydock/storage/lease',
'DrydockLeaseListController' => 'applications/drydock/controller/leaselist',
'DrydockLeaseStatus' => 'applications/drydock/constants/leasestatus',
'DrydockLocalCommandInterface' => 'applications/drydock/interface/command/local',
'DrydockLocalHostBlueprint' => 'applications/drydock/blueprint/localhost',
'DrydockLog' => 'applications/drydock/storage/log',
'DrydockLogController' => 'applications/drydock/controller/log',
'DrydockLogQuery' => 'applications/drydock/query/log',
'DrydockPhabricatorApplicationBlueprint' => 'applications/drydock/blueprint/application/phabricator',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockRemoteHostBlueprint' => 'applications/drydock/blueprint/remotehost',
'DrydockResource' => 'applications/drydock/storage/resource',
'DrydockResourceAllocateController' => 'applications/drydock/controller/resourceallocate',
'DrydockResourceListController' => 'applications/drydock/controller/resourcelist',
'DrydockResourceStatus' => 'applications/drydock/constants/resourcestatus',
'DrydockSSHCommandInterface' => 'applications/drydock/interface/command/ssh',
'DrydockWebrootInterface' => 'applications/drydock/interface/webroot/base',
2011-03-22 21:22:40 +01:00
'HeraldAction' => 'applications/herald/storage/action',
'HeraldActionConfig' => 'applications/herald/config/action',
'HeraldApplyTranscript' => 'applications/herald/storage/transcript/apply',
'HeraldCommitAdapter' => 'applications/herald/adapter/commit',
2011-03-22 21:22:40 +01:00
'HeraldCondition' => 'applications/herald/storage/condition',
'HeraldConditionConfig' => 'applications/herald/config/condition',
'HeraldConditionTranscript' => 'applications/herald/storage/transcript/condition',
'HeraldContentTypeConfig' => 'applications/herald/config/contenttype',
2011-03-22 21:49:46 +01:00
'HeraldController' => 'applications/herald/controller/base',
2011-03-22 21:22:40 +01:00
'HeraldDAO' => 'applications/herald/storage/base',
2011-03-24 19:07:36 +01:00
'HeraldDeleteController' => 'applications/herald/controller/delete',
'HeraldDifferentialRevisionAdapter' => 'applications/herald/adapter/differential',
2011-03-24 21:49:21 +01:00
'HeraldDryRunAdapter' => 'applications/herald/adapter/dryrun',
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' => 'applications/herald/query/log',
2011-03-22 21:22:40 +01:00
'HeraldEffect' => 'applications/herald/engine/effect',
'HeraldEngine' => 'applications/herald/engine/engine',
'HeraldFieldConfig' => 'applications/herald/config/field',
2011-03-22 21:49:46 +01:00
'HeraldHomeController' => 'applications/herald/controller/home',
2011-03-22 21:22:40 +01:00
'HeraldInvalidConditionException' => 'applications/herald/engine/engine/exception',
'HeraldInvalidFieldException' => 'applications/herald/engine/engine/exception',
2011-03-22 22:34:38 +01:00
'HeraldNewController' => 'applications/herald/controller/new',
2011-03-24 21:49:21 +01:00
'HeraldObjectAdapter' => 'applications/herald/adapter/base',
2011-03-22 21:22:40 +01:00
'HeraldObjectTranscript' => 'applications/herald/storage/transcript/object',
'HeraldRecursiveConditionsException' => 'applications/herald/engine/engine/exception',
'HeraldRepetitionPolicyConfig' => 'applications/herald/config/repetitionpolicy',
2011-03-22 21:22:40 +01:00
'HeraldRule' => 'applications/herald/storage/rule',
'HeraldRuleController' => 'applications/herald/controller/rule',
'HeraldRuleEdit' => 'applications/herald/storage/edithistory',
'HeraldRuleEditHistoryController' => 'applications/herald/controller/edithistory',
'HeraldRuleEditHistoryView' => 'applications/herald/view/edithistory',
'HeraldRuleListView' => 'applications/herald/view/rulelist',
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' => 'applications/herald/query/rule',
2011-03-22 21:22:40 +01:00
'HeraldRuleTranscript' => 'applications/herald/storage/transcript/rule',
'HeraldRuleTypeConfig' => 'applications/herald/config/ruletype',
2011-03-24 21:49:21 +01:00
'HeraldTestConsoleController' => 'applications/herald/controller/test',
2011-03-22 21:22:40 +01:00
'HeraldTranscript' => 'applications/herald/storage/transcript/base',
'HeraldTranscriptController' => 'applications/herald/controller/transcript',
'HeraldTranscriptListController' => 'applications/herald/controller/transcriptlist',
2011-03-22 21:22:40 +01:00
'HeraldValueTypeConfig' => 'applications/herald/config/valuetype',
'Javelin' => 'infrastructure/javelin/api',
'JavelinReactorExample' => 'applications/uiexample/examples/reactor',
'JavelinViewExample' => 'applications/uiexample/examples/client',
'JavelinViewExampleServerView' => 'applications/uiexample/examples/client',
'LiskDAO' => 'storage/lisk/dao',
'LiskEphemeralObjectException' => 'storage/lisk/dao',
'LiskFixtureTestCase' => 'storage/lisk/dao/__tests__',
'LiskIsolationTestCase' => 'storage/lisk/dao/__tests__',
'LiskIsolationTestDAO' => 'storage/lisk/dao/__tests__',
'LiskIsolationTestDAOException' => 'storage/lisk/dao/__tests__',
'ManiphestAction' => 'applications/maniphest/constants/action',
'ManiphestAuxiliaryFieldDefaultSpecification' => 'applications/maniphest/auxiliaryfield/default',
'ManiphestAuxiliaryFieldSpecification' => 'applications/maniphest/auxiliaryfield/base',
'ManiphestAuxiliaryFieldTypeException' => 'applications/maniphest/auxiliaryfield/typeexception',
'ManiphestAuxiliaryFieldValidationException' => 'applications/maniphest/auxiliaryfield/validationexception',
'ManiphestBatchEditController' => 'applications/maniphest/controller/batch',
'ManiphestConstants' => 'applications/maniphest/constants/base',
'ManiphestController' => 'applications/maniphest/controller/base',
'ManiphestDAO' => 'applications/maniphest/storage/base',
'ManiphestDefaultTaskExtensions' => 'applications/maniphest/extensions/task',
'ManiphestExportController' => 'applications/maniphest/controller/export',
'ManiphestReplyHandler' => 'applications/maniphest/replyhandler',
'ManiphestReportController' => 'applications/maniphest/controller/report',
'ManiphestSavedQuery' => 'applications/maniphest/storage/savedquery',
'ManiphestSavedQueryDeleteController' => 'applications/maniphest/controller/savedquerydelete',
'ManiphestSavedQueryEditController' => 'applications/maniphest/controller/savedqueryedit',
'ManiphestSavedQueryListController' => 'applications/maniphest/controller/savedquerylist',
'ManiphestSubpriorityController' => 'applications/maniphest/controller/subpriority',
'ManiphestTask' => 'applications/maniphest/storage/task',
'ManiphestTaskAuxiliaryStorage' => 'applications/maniphest/storage/auxiliary',
'ManiphestTaskDescriptionChangeController' => 'applications/maniphest/controller/descriptionchange',
'ManiphestTaskDescriptionPreviewController' => 'applications/maniphest/controller/descriptionpreview',
'ManiphestTaskDetailController' => 'applications/maniphest/controller/taskdetail',
'ManiphestTaskEditController' => 'applications/maniphest/controller/taskedit',
'ManiphestTaskExtensions' => 'applications/maniphest/extensions/base',
'ManiphestTaskListController' => 'applications/maniphest/controller/tasklist',
'ManiphestTaskListView' => 'applications/maniphest/view/tasklist',
'ManiphestTaskOwner' => 'applications/maniphest/constants/owner',
'ManiphestTaskPriority' => 'applications/maniphest/constants/priority',
'ManiphestTaskProject' => 'applications/maniphest/storage/taskproject',
'ManiphestTaskProjectsView' => 'applications/maniphest/view/taskprojects',
'ManiphestTaskQuery' => 'applications/maniphest/query',
'ManiphestTaskStatus' => 'applications/maniphest/constants/status',
'ManiphestTaskSubscriber' => 'applications/maniphest/storage/subscriber',
'ManiphestTaskSummaryView' => 'applications/maniphest/view/tasksummary',
'ManiphestTransaction' => 'applications/maniphest/storage/transaction',
'ManiphestTransactionDetailView' => 'applications/maniphest/view/transactiondetail',
'ManiphestTransactionEditor' => 'applications/maniphest/editor/transaction',
'ManiphestTransactionListView' => 'applications/maniphest/view/transactionlist',
'ManiphestTransactionPreviewController' => 'applications/maniphest/controller/transactionpreview',
'ManiphestTransactionSaveController' => 'applications/maniphest/controller/transactionsave',
'ManiphestTransactionType' => 'applications/maniphest/constants/transactiontype',
'ManiphestView' => 'applications/maniphest/view/base',
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
'MetaMTAConstants' => 'applications/metamta/constants/base',
'MetaMTANotificationType' => 'applications/metamta/constants/notificationtype',
2011-01-30 01:16:09 +01:00
'Phabricator404Controller' => 'applications/base/controller/404',
Allow Phabricator to write an access log using PhutilDeferredLog Summary: Provide a configurable access log. Test Plan: Got a sensible-looking log including logged-in, logged-out, conduit, 404, etc: [Mon, 23 Apr 2012 20:08:12 -0700] 32599 orbital - epriestley DifferentialCommentPreviewController - /differential/comment/preview/42/ http://local.aphront.com:8080/D42 200 65406 [Mon, 23 Apr 2012 20:08:12 -0700] 32881 orbital - epriestley DifferentialChangesetViewController - /differential/changeset/ http://local.aphront.com:8080/D42 200 72669 [Mon, 23 Apr 2012 20:08:39 -0700] 32882 orbital 127.0.0.1 epriestley DifferentialRevisionListController - /differential/ http://local.aphront.com:8080/D42 200 106444 [Mon, 23 Apr 2012 20:08:54 -0700] 32867 orbital 127.0.0.1 epriestley DifferentialRevisionListController - /differential/ http://local.aphront.com:8080/differential/ 200 112229 [Mon, 23 Apr 2012 20:09:05 -0700] 32530 orbital 127.0.0.1 epriestley PhabricatorDirectoryMainController - / http://local.aphront.com:8080/differential/ 200 141350 [Mon, 23 Apr 2012 20:09:10 -0700] 32598 orbital 127.0.0.1 epriestley PhabricatorDirectoryCategoryViewController - /directory/6/ http://local.aphront.com:8080/ 200 43474 [Mon, 23 Apr 2012 20:09:12 -0700] 32880 orbital 127.0.0.1 epriestley PhabricatorConduitConsoleController - /conduit/ http://local.aphront.com:8080/directory/6/ 200 139340 [Mon, 23 Apr 2012 20:09:15 -0700] 32868 orbital 127.0.0.1 epriestley PhabricatorConduitAPIController arcanist.projectinfo /api/arcanist.projectinfo http://local.aphront.com:8080/conduit/ 200 128774 [Mon, 23 Apr 2012 20:10:04 -0700] 32599 orbital 127.0.0.1 epriestley Phabricator404Controller - /asdbmabdmbsm - 404 38782 [Mon, 23 Apr 2012 20:10:04 -0700] 32881 orbital 127.0.0.1 - CelerityResourceController - /res/c9a43002/rsrc/css/aphront/request-failure-view.css http://local.aphront.com:8080/asdbmabdmbsm 200 25160 [Mon, 23 Apr 2012 20:10:57 -0700] 32882 orbital 127.0.0.1 epriestley PhabricatorLogoutController - /logout/ http://local.aphront.com:8080/asdbmabdmbsm 200 40810 [Mon, 23 Apr 2012 20:10:57 -0700] 32867 orbital 127.0.0.1 - PhabricatorLoginController - /login/ http://local.aphront.com:8080/asdbmabdmbsm 200 42526 [Mon, 23 Apr 2012 20:10:59 -0700] 32919 orbital 127.0.0.1 - PhabricatorLoginController - /login/ http://local.aphront.com:8080/asdbmabdmbsm 200 49052 [Mon, 23 Apr 2012 20:10:59 -0700] 32880 orbital 127.0.0.1 - CelerityResourceController - /res/c80156c4/rsrc/js/application/core/behavior-dark-console.js http://local.aphront.com:8080/login/ 200 33166 [Mon, 23 Apr 2012 20:10:59 -0700] 32868 orbital 127.0.0.1 - CelerityResourceController - /res/4965d970/rsrc/css/aphront/dark-console.css http://local.aphront.com:8080/login/ 200 38078 [Mon, 23 Apr 2012 20:10:59 -0700] 32599 orbital 127.0.0.1 - CelerityResourceController - /res/pkg/8a5de8a3/javelin.pkg.js http://local.aphront.com:8080/login/ 200 40534 [Mon, 23 Apr 2012 20:10:59 -0700] 32882 orbital 127.0.0.1 - CelerityResourceController - /res/pkg/9c4e265b/core.pkg.css http://local.aphront.com:8080/login/ 200 41262 [Mon, 23 Apr 2012 20:10:59 -0700] 32881 orbital 127.0.0.1 - CelerityResourceController - /res/pkg/0c96375e/core.pkg.js http://local.aphront.com:8080/login/ 200 43720 [Mon, 23 Apr 2012 20:10:59 -0700] 32921 orbital 127.0.0.1 - CelerityResourceController - /res/caa86a45/rsrc/js/javelin/core/init.js http://local.aphront.com:8080/login/ 200 47566 [Mon, 23 Apr 2012 20:10:59 -0700] 32867 orbital 127.0.0.1 - CelerityResourceController - /res/f46289e9/rsrc/js/application/core/behavior-error-log.js http://local.aphront.com:8080/login/ 200 29328 [Mon, 23 Apr 2012 20:10:59 -0700] 32919 orbital 127.0.0.1 - CelerityResourceController - /res/7e62ff40/rsrc/image/phabricator_logo.png http://local.aphront.com:8080/login/ 200 25583 [Mon, 23 Apr 2012 20:10:59 -0700] 32880 orbital 127.0.0.1 - CelerityResourceController - /res/8c6200d3/rsrc/image/sprite.png http://local.aphront.com:8080/login/ 200 29829 [Mon, 23 Apr 2012 20:11:01 -0700] 32868 orbital 127.0.0.1 - PhabricatorOAuthLoginController - /oauth/facebook/login/ http://local.aphront.com:8080/login/ 200 855931 [Mon, 23 Apr 2012 20:11:02 -0700] 32882 orbital 127.0.0.1 epriestley789 PhabricatorLoginValidateController - /login/validate/ http://local.aphront.com:8080/login/ 200 29793 [Mon, 23 Apr 2012 20:11:02 -0700] 32881 orbital 127.0.0.1 epriestley789 PhabricatorDirectoryMainController - / http://local.aphront.com:8080/login/ 200 91638 Reviewers: jungejason, btrahan, vrana Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2310
2012-04-25 16:24:08 +02:00
'PhabricatorAccessLog' => 'infrastructure/accesslog',
'PhabricatorAphlictTestPageController' => 'applications/notifications/controller/test',
'PhabricatorAuditActionConstants' => 'applications/audit/constants/action',
'PhabricatorAuditAddCommentController' => 'applications/audit/controller/addcomment',
'PhabricatorAuditComment' => 'applications/audit/storage/auditcomment',
'PhabricatorAuditCommentEditor' => 'applications/audit/editor/comment',
'PhabricatorAuditCommitListView' => 'applications/audit/view/commitlist',
'PhabricatorAuditCommitQuery' => 'applications/audit/query/commit',
'PhabricatorAuditCommitStatusConstants' => 'applications/audit/constants/commitstatus',
'PhabricatorAuditController' => 'applications/audit/controller/base',
'PhabricatorAuditDAO' => 'applications/audit/storage/base',
'PhabricatorAuditInlineComment' => 'applications/audit/storage/inlinecommment',
'PhabricatorAuditListController' => 'applications/audit/controller/list',
'PhabricatorAuditListView' => 'applications/audit/view/list',
'PhabricatorAuditPreviewController' => 'applications/audit/controller/preview',
'PhabricatorAuditQuery' => 'applications/audit/query/audit',
'PhabricatorAuditReplyHandler' => 'applications/audit/replyhandler',
'PhabricatorAuditStatusConstants' => 'applications/audit/constants/status',
2011-01-31 06:28:45 +01:00
'PhabricatorAuthController' => 'applications/auth/controller/base',
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' => 'infrastructure/setup/sql/phabricator',
'PhabricatorCalendarBrowseController' => 'applications/calendar/controller/browse',
'PhabricatorCalendarController' => 'applications/calendar/controller/base',
'PhabricatorCalendarDAO' => 'applications/calendar/storage/base',
'PhabricatorCalendarHoliday' => 'applications/calendar/storage/holiday',
'PhabricatorCalendarHolidayTestCase' => 'applications/calendar/storage/holiday/__tests__',
'PhabricatorChangesetResponse' => 'infrastructure/diff/response',
'PhabricatorChatLogChannelListController' => 'applications/chatlog/controller/channellist',
'PhabricatorChatLogChannelLogController' => 'applications/chatlog/controller/channellog',
'PhabricatorChatLogConstants' => 'applications/chatlog/constants/base',
'PhabricatorChatLogController' => 'applications/chatlog/controller/base',
'PhabricatorChatLogDAO' => 'applications/chatlog/storage/base',
'PhabricatorChatLogEvent' => 'applications/chatlog/storage/event',
'PhabricatorChatLogEventType' => 'applications/chatlog/constants/eventtype',
'PhabricatorChatLogQuery' => 'applications/chatlog/query',
2011-01-24 18:00:29 +01:00
'PhabricatorConduitAPIController' => 'applications/conduit/controller/api',
'PhabricatorConduitCertificateToken' => 'applications/conduit/storage/token',
2011-01-24 18:00:29 +01:00
'PhabricatorConduitConnectionLog' => 'applications/conduit/storage/connectionlog',
'PhabricatorConduitConsoleController' => 'applications/conduit/controller/console',
'PhabricatorConduitController' => 'applications/conduit/controller/base',
'PhabricatorConduitDAO' => 'applications/conduit/storage/base',
'PhabricatorConduitListController' => 'applications/conduit/controller/list',
2011-01-24 18:00:29 +01:00
'PhabricatorConduitLogController' => 'applications/conduit/controller/log',
'PhabricatorConduitMethodCallLog' => 'applications/conduit/storage/methodcalllog',
'PhabricatorConduitTokenController' => 'applications/conduit/controller/token',
'PhabricatorContentSource' => 'applications/metamta/contentsource/source',
'PhabricatorContentSourceView' => 'applications/metamta/contentsource/view',
2011-01-23 02:48:55 +01:00
'PhabricatorController' => 'applications/base/controller/base',
'PhabricatorCountdownController' => 'applications/countdown/controller/base',
'PhabricatorCountdownDAO' => 'applications/countdown/storage/base',
'PhabricatorCountdownDeleteController' => 'applications/countdown/controller/delete',
'PhabricatorCountdownEditController' => 'applications/countdown/controller/edit',
'PhabricatorCountdownListController' => 'applications/countdown/controller/list',
'PhabricatorCountdownViewController' => 'applications/countdown/controller/view',
'PhabricatorDaemon' => 'infrastructure/daemon/base',
'PhabricatorDaemonCombinedLogController' => 'applications/daemon/controller/combined',
'PhabricatorDaemonConsoleController' => 'applications/daemon/controller/console',
2011-03-14 23:43:56 +01:00
'PhabricatorDaemonControl' => 'infrastructure/daemon/control',
'PhabricatorDaemonController' => 'applications/daemon/controller/base',
2011-03-15 21:38:14 +01:00
'PhabricatorDaemonDAO' => 'infrastructure/daemon/storage/base',
'PhabricatorDaemonLog' => 'infrastructure/daemon/storage/log',
'PhabricatorDaemonLogEvent' => 'infrastructure/daemon/storage/event',
'PhabricatorDaemonLogEventsView' => 'applications/daemon/view/daemonlogevents',
'PhabricatorDaemonLogListController' => 'applications/daemon/controller/loglist',
'PhabricatorDaemonLogListView' => 'applications/daemon/view/daemonloglist',
2011-03-15 21:38:14 +01:00
'PhabricatorDaemonLogViewController' => 'applications/daemon/controller/logview',
2011-03-14 23:43:56 +01:00
'PhabricatorDaemonReference' => 'infrastructure/daemon/control/reference',
'PhabricatorDaemonTimelineConsoleController' => 'applications/daemon/controller/timeline',
'PhabricatorDaemonTimelineEventController' => 'applications/daemon/controller/timelineevent',
'PhabricatorDefaultFileStorageEngineSelector' => 'applications/files/engineselector/default',
'PhabricatorDefaultSearchEngineSelector' => 'applications/search/selector/default',
'PhabricatorDifferenceEngine' => 'infrastructure/diff/engine',
2011-01-23 02:48:55 +01:00
'PhabricatorDirectoryController' => 'applications/directory/controller/base',
'PhabricatorDirectoryMainController' => 'applications/directory/controller/main',
'PhabricatorDisabledUserController' => 'applications/auth/controller/disabled',
2011-02-06 01:57:21 +01:00
'PhabricatorDraft' => 'applications/draft/storage/draft',
'PhabricatorDraftDAO' => 'applications/draft/storage/base',
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' => 'infrastructure/edges/constants/config',
'PhabricatorEdgeConstants' => 'infrastructure/edges/constants/base',
'PhabricatorEdgeEditor' => 'infrastructure/edges/editor/edge',
'PhabricatorEdgeQuery' => 'infrastructure/edges/query/edge',
'PhabricatorEmailLoginController' => 'applications/auth/controller/email',
'PhabricatorEmailTokenController' => 'applications/auth/controller/emailtoken',
'PhabricatorEnv' => 'infrastructure/env',
'PhabricatorEnvTestCase' => 'infrastructure/env/__tests__',
'PhabricatorErrorExample' => 'applications/uiexample/examples/error',
'PhabricatorEvent' => 'infrastructure/events/event',
'PhabricatorEventEngine' => 'infrastructure/events/engine',
'PhabricatorEventType' => 'infrastructure/events/constant/type',
'PhabricatorFeedBuilder' => 'applications/feed/builder/feed',
'PhabricatorFeedConstants' => 'applications/feed/constants/base',
'PhabricatorFeedController' => 'applications/feed/controller/base',
'PhabricatorFeedDAO' => 'applications/feed/storage/base',
'PhabricatorFeedPublicStreamController' => 'applications/feed/controller/publicstream',
'PhabricatorFeedQuery' => 'applications/feed/query',
'PhabricatorFeedStory' => 'applications/feed/story/base',
'PhabricatorFeedStoryAudit' => 'applications/feed/story/audit',
'PhabricatorFeedStoryData' => 'applications/feed/storage/story',
'PhabricatorFeedStoryDifferential' => 'applications/feed/story/differential',
'PhabricatorFeedStoryManiphest' => 'applications/feed/story/maniphest',
'PhabricatorFeedStoryPhriction' => 'applications/feed/story/phriction',
'PhabricatorFeedStoryProject' => 'applications/feed/story/project',
'PhabricatorFeedStoryPublisher' => 'applications/feed/publisher',
'PhabricatorFeedStoryReference' => 'applications/feed/storage/storyreference',
'PhabricatorFeedStoryStatus' => 'applications/feed/story/status',
'PhabricatorFeedStoryTypeConstants' => 'applications/feed/constants/story',
'PhabricatorFeedStoryUnknown' => 'applications/feed/story/unknown',
'PhabricatorFeedStoryView' => 'applications/feed/view/story',
'PhabricatorFeedView' => 'applications/feed/view/base',
2011-01-23 03:33:00 +01:00
'PhabricatorFile' => 'applications/files/storage/file',
'PhabricatorFileController' => 'applications/files/controller/base',
'PhabricatorFileDAO' => 'applications/files/storage/base',
'PhabricatorFileDataController' => 'applications/files/controller/data',
'PhabricatorFileDeleteController' => 'applications/files/controller/delete',
'PhabricatorFileDropUploadController' => 'applications/files/controller/dropupload',
'PhabricatorFileImageMacro' => 'applications/files/storage/imagemacro',
'PhabricatorFileInfoController' => 'applications/files/controller/info',
2011-01-23 03:33:00 +01:00
'PhabricatorFileListController' => 'applications/files/controller/list',
'PhabricatorFileMacroDeleteController' => 'applications/files/controller/macrodelete',
'PhabricatorFileMacroEditController' => 'applications/files/controller/macroedit',
'PhabricatorFileMacroListController' => 'applications/files/controller/macrolist',
'PhabricatorFileProxyController' => 'applications/files/controller/proxy',
'PhabricatorFileProxyImage' => 'applications/files/storage/proxyimage',
'PhabricatorFileShortcutController' => 'applications/files/controller/shortcut',
'PhabricatorFileSideNavView' => 'applications/files/view/sidenav',
2011-01-23 03:33:00 +01:00
'PhabricatorFileStorageBlob' => 'applications/files/storage/storageblob',
'PhabricatorFileStorageConfigurationException' => 'applications/files/exception/configuration',
'PhabricatorFileStorageEngine' => 'applications/files/engine/base',
'PhabricatorFileStorageEngineSelector' => 'applications/files/engineselector/base',
'PhabricatorFileTransformController' => 'applications/files/controller/transform',
2011-01-23 03:33:00 +01:00
'PhabricatorFileUploadController' => 'applications/files/controller/upload',
'PhabricatorFileUploadException' => 'applications/files/exception/upload',
'PhabricatorFileUploadView' => 'applications/files/view/upload',
'PhabricatorFlag' => 'applications/flag/storage/flag',
'PhabricatorFlagColor' => 'applications/flag/constants/color',
'PhabricatorFlagConstants' => 'applications/flag/constants/base',
'PhabricatorFlagController' => 'applications/flag/controller/base',
'PhabricatorFlagDAO' => 'applications/flag/storage/base',
'PhabricatorFlagDeleteController' => 'applications/flag/controller/delete',
'PhabricatorFlagEditController' => 'applications/flag/controller/edit',
'PhabricatorFlagListController' => 'applications/flag/controller/list',
'PhabricatorFlagListView' => 'applications/flag/view/list',
'PhabricatorFlagQuery' => 'applications/flag/query/flag',
'PhabricatorFormExample' => 'applications/uiexample/examples/form',
'PhabricatorGarbageCollectorDaemon' => 'infrastructure/daemon/garbagecollector',
'PhabricatorGoodForNothingWorker' => 'infrastructure/daemon/workers/worker/goodfornothing',
'PhabricatorHandleObjectSelectorDataView' => 'applications/phid/handle/view/selector',
'PhabricatorHash' => 'infrastructure/util/hash',
'PhabricatorHelpController' => 'applications/help/controller/base',
'PhabricatorHelpKeyboardShortcutController' => 'applications/help/controller/keyboardshortcut',
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
'PhabricatorIDPagedPolicyQuery' => 'infrastructure/query/policy/idpaged',
'PhabricatorIRCBot' => 'infrastructure/daemon/irc/bot',
'PhabricatorIRCDifferentialNotificationHandler' => 'infrastructure/daemon/irc/handler/differentialnotification',
'PhabricatorIRCHandler' => 'infrastructure/daemon/irc/handler/base',
'PhabricatorIRCLogHandler' => 'infrastructure/daemon/irc/handler/log',
'PhabricatorIRCMacroHandler' => 'infrastructure/daemon/irc/handler/macro',
'PhabricatorIRCMessage' => 'infrastructure/daemon/irc/message',
'PhabricatorIRCObjectNameHandler' => 'infrastructure/daemon/irc/handler/objectname',
'PhabricatorIRCProtocolHandler' => 'infrastructure/daemon/irc/handler/protocol',
'PhabricatorIRCWhatsNewHandler' => 'infrastructure/daemon/irc/handler/whatsnew',
'PhabricatorImageTransformer' => 'applications/files/transform',
'PhabricatorInfrastructureTestCase' => 'infrastructure/__tests__',
'PhabricatorInlineCommentController' => 'infrastructure/diff/controller',
'PhabricatorInlineCommentInterface' => 'infrastructure/diff/interface/inline',
'PhabricatorInlineSummaryView' => 'infrastructure/diff/view/inline',
'PhabricatorJavelinLinter' => 'infrastructure/lint/linter/javelin',
'PhabricatorJumpNavHandler' => 'applications/search/engine/jumpnav',
'PhabricatorLintEngine' => 'infrastructure/lint/engine',
2011-01-23 02:48:55 +01:00
'PhabricatorLiskDAO' => 'applications/base/storage/lisk',
'PhabricatorLocalDiskFileStorageEngine' => 'applications/files/engine/localdisk',
'PhabricatorLocalTimeTestCase' => 'view/utils/__tests__',
2011-01-31 06:28:45 +01:00
'PhabricatorLoginController' => 'applications/auth/controller/login',
'PhabricatorLoginValidateController' => 'applications/auth/controller/validate',
2011-01-31 06:28:45 +01:00
'PhabricatorLogoutController' => 'applications/auth/controller/logout',
2011-01-26 18:33:31 +01:00
'PhabricatorMailImplementationAdapter' => 'applications/metamta/adapter/base',
'PhabricatorMailImplementationAmazonSESAdapter' => 'applications/metamta/adapter/amazonses',
2011-01-26 18:33:31 +01:00
'PhabricatorMailImplementationPHPMailerLiteAdapter' => 'applications/metamta/adapter/phpmailerlite',
'PhabricatorMailImplementationSendGridAdapter' => 'applications/metamta/adapter/sendgrid',
'PhabricatorMailImplementationTestAdapter' => 'applications/metamta/adapter/test',
'PhabricatorMailReplyHandler' => 'applications/metamta/replyhandler/base',
'PhabricatorMarkupEngine' => 'applications/markup/engine',
'PhabricatorMetaMTAAttachment' => 'applications/metamta/storage/mail',
2011-01-26 02:40:21 +01:00
'PhabricatorMetaMTAController' => 'applications/metamta/controller/base',
'PhabricatorMetaMTADAO' => 'applications/metamta/storage/base',
'PhabricatorMetaMTAEmailBodyParser' => 'applications/metamta/parser',
'PhabricatorMetaMTAEmailBodyParserTestCase' => 'applications/metamta/parser/__tests__',
2011-01-26 02:40:21 +01:00
'PhabricatorMetaMTAListController' => 'applications/metamta/controller/list',
'PhabricatorMetaMTAMail' => 'applications/metamta/storage/mail',
'PhabricatorMetaMTAMailTestCase' => 'applications/metamta/storage/mail/__tests__',
2011-01-26 19:40:38 +01:00
'PhabricatorMetaMTAMailingList' => 'applications/metamta/storage/mailinglist',
'PhabricatorMetaMTAMailingListEditController' => 'applications/metamta/controller/mailinglistedit',
'PhabricatorMetaMTAMailingListsController' => 'applications/metamta/controller/mailinglists',
'PhabricatorMetaMTAReceiveController' => 'applications/metamta/controller/receive',
'PhabricatorMetaMTAReceivedListController' => 'applications/metamta/controller/receivedlist',
'PhabricatorMetaMTAReceivedMail' => 'applications/metamta/storage/receivedmail',
2011-01-26 02:40:21 +01:00
'PhabricatorMetaMTASendController' => 'applications/metamta/controller/send',
'PhabricatorMetaMTASendGridReceiveController' => 'applications/metamta/controller/sendgridreceive',
2011-01-26 18:08:26 +01:00
'PhabricatorMetaMTAViewController' => 'applications/metamta/controller/view',
'PhabricatorMetaMTAWorker' => 'applications/metamta/worker',
'PhabricatorMySQLFileStorageEngine' => 'applications/files/engine/mysql',
'PhabricatorNotificationsController' => 'applications/notifications/controller/base',
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' => 'applications/oauthserver/storage/clientauthorization',
'PhabricatorOAuthClientAuthorizationBaseController' => 'applications/oauthserver/controller/clientauthorization/base',
'PhabricatorOAuthClientAuthorizationDeleteController' => 'applications/oauthserver/controller/clientauthorization/delete',
'PhabricatorOAuthClientAuthorizationEditController' => 'applications/oauthserver/controller/clientauthorization/edit',
'PhabricatorOAuthClientAuthorizationListController' => 'applications/oauthserver/controller/clientauthorization/list',
'PhabricatorOAuthClientAuthorizationQuery' => 'applications/oauthserver/query/clientauthorization',
'PhabricatorOAuthClientBaseController' => 'applications/oauthserver/controller/client/base',
'PhabricatorOAuthClientDeleteController' => 'applications/oauthserver/controller/client/delete',
'PhabricatorOAuthClientEditController' => 'applications/oauthserver/controller/client/edit',
'PhabricatorOAuthClientListController' => 'applications/oauthserver/controller/client/list',
'PhabricatorOAuthClientViewController' => 'applications/oauthserver/controller/client/view',
2011-02-28 04:47:22 +01:00
'PhabricatorOAuthDefaultRegistrationController' => 'applications/auth/controller/oauthregistration/default',
'PhabricatorOAuthDiagnosticsController' => 'applications/auth/controller/oauthdiagnostics',
'PhabricatorOAuthFailureView' => 'applications/auth/view/oauthfailure',
'PhabricatorOAuthLoginController' => 'applications/auth/controller/oauth',
'PhabricatorOAuthProvider' => 'applications/auth/oauth/provider/base',
'PhabricatorOAuthProviderException' => 'applications/auth/oauth/provider/exception',
'PhabricatorOAuthProviderFacebook' => 'applications/auth/oauth/provider/facebook',
'PhabricatorOAuthProviderGitHub' => 'applications/auth/oauth/provider/github',
'PhabricatorOAuthProviderGoogle' => 'applications/auth/oauth/provider/google',
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' => 'applications/auth/oauth/provider/phabricator',
2011-02-28 04:47:22 +01:00
'PhabricatorOAuthRegistrationController' => 'applications/auth/controller/oauthregistration/base',
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' => 'applications/oauthserver/response',
'PhabricatorOAuthServer' => 'applications/oauthserver/server',
'PhabricatorOAuthServerAccessToken' => 'applications/oauthserver/storage/accesstoken',
'PhabricatorOAuthServerAuthController' => 'applications/oauthserver/controller/auth',
'PhabricatorOAuthServerAuthorizationCode' => 'applications/oauthserver/storage/authorizationcode',
'PhabricatorOAuthServerClient' => 'applications/oauthserver/storage/client',
'PhabricatorOAuthServerClientQuery' => 'applications/oauthserver/query/client',
'PhabricatorOAuthServerController' => 'applications/oauthserver/controller/base',
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' => 'applications/oauthserver/storage/base',
OAuth Server enhancements -- more complete access token response and groundwork for scope Summary: this patch makes the access token response "complete" relative to spec by returning when it expires AND that the token_type is in fact 'Bearer'. This patch also lays the groundwork for scope by fixing the underlying data model and adding the first scope checks for "offline_access" relative to expires and the "whoami" method. Further, conduit is augmented to open up individual methods for access via OAuth generally to enable "whoami" access. There's also a tidy little scope class to keep track of all the various scopes we plan to have as well as strings for display (T849 - work undone) Somewhat of a hack but Conduit methods by default have SCOPE_NOT_ACCESSIBLE. We then don't even bother with the OAuth stuff within conduit if we're not supposed to be accessing the method via Conduit. Felt relatively clean to me in terms of additional code complexity, etc. Next up ends up being T848 (scope in OAuth) and T849 (let user's authorize clients for specific scopes which kinds of needs T850). There's also a bunch of work that needs to be done to return the appropriate, well-formatted error codes. All in due time...! Test Plan: verified that an access_token with no scope doesn't let me see anything anymore. :( verified that access_tokens made awhile ago expire. :( Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T888, T848 Differential Revision: https://secure.phabricator.com/D1657
2012-02-21 23:28:05 +01:00
'PhabricatorOAuthServerScope' => 'applications/oauthserver/scope',
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' => 'applications/oauthserver/server/__tests__',
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
'PhabricatorOAuthServerTestController' => 'applications/oauthserver/controller/test',
'PhabricatorOAuthServerTokenController' => 'applications/oauthserver/controller/token',
'PhabricatorOAuthUnlinkController' => 'applications/auth/controller/unlink',
'PhabricatorObjectAttachmentEditor' => 'applications/search/editor/attach',
'PhabricatorObjectGraph' => 'applications/phid/graph',
2011-01-26 18:02:09 +01:00
'PhabricatorObjectHandle' => 'applications/phid/handle',
'PhabricatorObjectHandleConstants' => 'applications/phid/handle/const/base',
2011-01-26 18:02:09 +01:00
'PhabricatorObjectHandleData' => 'applications/phid/handle/data',
'PhabricatorObjectHandleStatus' => 'applications/phid/handle/const/status',
'PhabricatorObjectSelectorDialog' => 'view/control/objectselector',
'PhabricatorOffsetPagedQuery' => 'infrastructure/query/offsetpaged',
'PhabricatorOwnerPathQuery' => 'applications/owners/query/path',
2011-04-03 23:48:36 +02:00
'PhabricatorOwnersController' => 'applications/owners/controller/base',
'PhabricatorOwnersDAO' => 'applications/owners/storage/base',
2011-04-04 07:03:27 +02:00
'PhabricatorOwnersDeleteController' => 'applications/owners/controller/delete',
2011-04-03 23:48:36 +02:00
'PhabricatorOwnersDetailController' => 'applications/owners/controller/detail',
2011-04-04 07:03:27 +02:00
'PhabricatorOwnersEditController' => 'applications/owners/controller/edit',
2011-04-03 23:48:36 +02:00
'PhabricatorOwnersListController' => 'applications/owners/controller/list',
'PhabricatorOwnersOwner' => 'applications/owners/storage/owner',
'PhabricatorOwnersPackage' => 'applications/owners/storage/package',
'PhabricatorOwnersPath' => 'applications/owners/storage/path',
2011-01-23 06:09:13 +01:00
'PhabricatorPHID' => 'applications/phid/storage/phid',
'PhabricatorPHIDConstants' => 'applications/phid/constants',
2011-01-23 06:09:13 +01:00
'PhabricatorPHIDController' => 'applications/phid/controller/base',
'PhabricatorPHIDDAO' => 'applications/phid/storage/base',
2011-01-26 18:02:09 +01:00
'PhabricatorPHIDLookupController' => 'applications/phid/controller/lookup',
'PhabricatorPaste' => 'applications/paste/storage/paste',
'PhabricatorPasteController' => 'applications/paste/controller/base',
'PhabricatorPasteDAO' => 'applications/paste/storage/base',
'PhabricatorPasteListController' => 'applications/paste/controller/list',
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
'PhabricatorPasteQuery' => 'applications/paste/query/paste',
'PhabricatorPasteViewController' => 'applications/paste/controller/view',
2011-01-24 03:09:16 +01:00
'PhabricatorPeopleController' => 'applications/people/controller/base',
'PhabricatorPeopleEditController' => 'applications/people/controller/edit',
'PhabricatorPeopleListController' => 'applications/people/controller/list',
'PhabricatorPeopleLogsController' => 'applications/people/controller/logs',
2011-01-24 03:09:16 +01:00
'PhabricatorPeopleProfileController' => 'applications/people/controller/profile',
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' => 'applications/policy/constants/policy',
'PhabricatorPolicyCapability' => 'applications/policy/constants/capability',
'PhabricatorPolicyConstants' => 'applications/policy/constants/base',
'PhabricatorPolicyException' => 'applications/policy/exception/base',
'PhabricatorPolicyFilter' => 'applications/policy/filter/policy',
'PhabricatorPolicyInterface' => 'applications/policy/interface/policy',
'PhabricatorPolicyQuery' => 'infrastructure/query/policy/base',
'PhabricatorPolicyTestCase' => 'applications/policy/__tests__',
'PhabricatorPolicyTestObject' => 'applications/policy/__tests__',
'PhabricatorPolicyTestQuery' => 'applications/policy/__tests__',
'PhabricatorProfileHeaderView' => 'view/layout/profileheader',
'PhabricatorProject' => 'applications/project/storage/project',
'PhabricatorProjectAffiliation' => 'applications/project/storage/affiliation',
'PhabricatorProjectConstants' => 'applications/project/constants/base',
'PhabricatorProjectController' => 'applications/project/controller/base',
'PhabricatorProjectCreateController' => 'applications/project/controller/create',
'PhabricatorProjectDAO' => 'applications/project/storage/base',
'PhabricatorProjectEditor' => 'applications/project/editor/project',
'PhabricatorProjectListController' => 'applications/project/controller/list',
'PhabricatorProjectNameCollisionException' => 'applications/project/exception/namecollison',
'PhabricatorProjectProfile' => 'applications/project/storage/profile',
'PhabricatorProjectProfileController' => 'applications/project/controller/profile',
'PhabricatorProjectProfileEditController' => 'applications/project/controller/profileedit',
'PhabricatorProjectQuery' => 'applications/project/query/project',
'PhabricatorProjectStatus' => 'applications/project/constants/status',
'PhabricatorProjectSubproject' => 'applications/project/storage/subproject',
'PhabricatorProjectTransaction' => 'applications/project/storage/transaction',
'PhabricatorProjectTransactionType' => 'applications/project/constants/transaction',
'PhabricatorProjectUpdateController' => 'applications/project/controller/update',
'PhabricatorQuery' => 'infrastructure/query/base',
'PhabricatorRedirectController' => 'applications/base/controller/redirect',
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' => 'applications/auth/controller/refresh',
'PhabricatorRemarkupRuleDifferential' => 'infrastructure/markup/remarkup/markuprule/differential',
'PhabricatorRemarkupRuleDifferentialHandle' => 'infrastructure/markup/remarkup/markuprule/handle/differential',
2011-04-11 12:02:19 +02:00
'PhabricatorRemarkupRuleDiffusion' => 'infrastructure/markup/remarkup/markuprule/diffusion',
'PhabricatorRemarkupRuleEmbedFile' => 'infrastructure/markup/remarkup/markuprule/embedobject',
'PhabricatorRemarkupRuleImageMacro' => 'infrastructure/markup/remarkup/markuprule/imagemacro',
'PhabricatorRemarkupRuleManiphest' => 'infrastructure/markup/remarkup/markuprule/maniphest',
'PhabricatorRemarkupRuleManiphestHandle' => 'infrastructure/markup/remarkup/markuprule/handle/maniphest',
'PhabricatorRemarkupRuleMention' => 'infrastructure/markup/remarkup/markuprule/mention',
'PhabricatorRemarkupRuleObjectHandle' => 'infrastructure/markup/remarkup/markuprule/handle',
'PhabricatorRemarkupRuleObjectName' => 'infrastructure/markup/remarkup/markuprule/objectname',
'PhabricatorRemarkupRulePaste' => 'infrastructure/markup/remarkup/markuprule/paste',
'PhabricatorRemarkupRulePhriction' => 'infrastructure/markup/remarkup/markuprule/phriction',
'PhabricatorRemarkupRuleProxyImage' => 'infrastructure/markup/remarkup/markuprule/proxyimage',
'PhabricatorRemarkupRuleYoutube' => 'infrastructure/markup/remarkup/markuprule/youtube',
'PhabricatorRepository' => 'applications/repository/storage/repository',
'PhabricatorRepositoryArcanistProject' => 'applications/repository/storage/arcanistproject',
'PhabricatorRepositoryArcanistProjectEditController' => 'applications/repository/controller/arcansistprojectedit',
'PhabricatorRepositoryAuditRequest' => 'applications/repository/storage/auditrequest',
'PhabricatorRepositoryCommit' => 'applications/repository/storage/commit',
'PhabricatorRepositoryCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/base',
'PhabricatorRepositoryCommitData' => 'applications/repository/storage/commitdata',
'PhabricatorRepositoryCommitDiscoveryDaemon' => 'applications/repository/daemon/commitdiscovery/base',
'PhabricatorRepositoryCommitHeraldWorker' => 'applications/repository/worker/herald',
2011-04-02 02:11:05 +02:00
'PhabricatorRepositoryCommitMessageDetailParser' => 'applications/repository/parser/base',
'PhabricatorRepositoryCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/base',
'PhabricatorRepositoryCommitOwnersWorker' => 'applications/repository/worker/owner',
'PhabricatorRepositoryCommitParserWorker' => 'applications/repository/worker/base',
'PhabricatorRepositoryCommitTaskDaemon' => 'applications/repository/daemon/committask',
'PhabricatorRepositoryController' => 'applications/repository/controller/base',
'PhabricatorRepositoryCreateController' => 'applications/repository/controller/create',
'PhabricatorRepositoryDAO' => 'applications/repository/storage/base',
'PhabricatorRepositoryDaemon' => 'applications/repository/daemon/base',
2011-04-02 02:11:05 +02:00
'PhabricatorRepositoryDefaultCommitMessageDetailParser' => 'applications/repository/parser/default',
'PhabricatorRepositoryDeleteController' => 'applications/repository/controller/delete',
'PhabricatorRepositoryEditController' => 'applications/repository/controller/edit',
'PhabricatorRepositoryGitCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/git',
'PhabricatorRepositoryGitCommitDiscoveryDaemon' => 'applications/repository/daemon/commitdiscovery/git',
'PhabricatorRepositoryGitCommitDiscoveryDaemonTestCase' => 'applications/repository/daemon/commitdiscovery/git/__tests__',
'PhabricatorRepositoryGitCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/git',
2011-03-21 01:46:02 +01:00
'PhabricatorRepositoryGitFetchDaemon' => 'applications/repository/daemon/gitfetch',
'PhabricatorRepositoryListController' => 'applications/repository/controller/list',
'PhabricatorRepositoryMercurialCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/mercurial',
Add a Mercurial commit discovery daemon Summary: Repository import has three major steps: - Commit discovery (serial) - Message parsing (parallel, mostly VCS independent) - Change parsing (parallel, highly VCS dependent) This implements commit discovery for Mercurial, similar to git's parsing: - List the heads of all the branches. - If we haven't already discovered them, follow them back to their roots (or the first commit we have discovered). - Import all the newly discovered commits, oldest first. This is a little complicated but it ensures we discover commits in depth order, so the discovery process is robust against interruption/failure. If we just inserted commits as we went, we might read the tip, insert it, and then crash. When we ran again, we'd think we had already discovered commits older than HEAD. This also allows later stages to rely on being able to find Phabricator commit IDs which correspond to parent commits. NOTE: This importer is fairly slow because "hg" has a large startup time (compare "hg --version" to "git --version" and "svn --version"; on my machine, hg has 60ms of overhead for any command) and we need to run many commands (see the whole "hg id" mess). You can expect something like 10,000 per hour, which means you may need to run overnight to discover a large repository (IIRC, the svn/git discovery processes are both about an order of magnitude faster). We could improve this with batching, but I want to keep it as simple as possible for now. Test Plan: Discovered all the commits in the main Mercurial repository, http://selenic.com/repo/hg. Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran Reviewed By: Makinde CC: aran, Makinde Differential Revision: 943
2011-09-16 12:56:23 +02:00
'PhabricatorRepositoryMercurialCommitDiscoveryDaemon' => 'applications/repository/daemon/commitdiscovery/mercurial',
'PhabricatorRepositoryMercurialCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/mercurial',
'PhabricatorRepositoryMercurialPullDaemon' => 'applications/repository/daemon/mercurialpull',
'PhabricatorRepositoryPullLocalDaemon' => 'applications/repository/daemon/pulllocal',
'PhabricatorRepositoryShortcut' => 'applications/repository/storage/shortcut',
'PhabricatorRepositorySvnCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/svn',
'PhabricatorRepositorySvnCommitDiscoveryDaemon' => 'applications/repository/daemon/commitdiscovery/svn',
'PhabricatorRepositorySvnCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/svn',
'PhabricatorRepositorySymbol' => 'applications/repository/storage/symbol',
'PhabricatorRepositoryTestCase' => 'applications/repository/storage/repository/__tests__',
'PhabricatorRepositoryType' => 'applications/repository/constants/repositorytype',
'PhabricatorS3FileStorageEngine' => 'applications/files/engine/s3',
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
'PhabricatorSQLPatchList' => 'infrastructure/setup/sql/base',
'PhabricatorScopedEnv' => 'infrastructure/env',
'PhabricatorSearchAbstractDocument' => 'applications/search/index/abstractdocument',
'PhabricatorSearchAttachController' => 'applications/search/controller/attach',
'PhabricatorSearchBaseController' => 'applications/search/controller/base',
'PhabricatorSearchCommitIndexer' => 'applications/search/index/indexer/repository',
'PhabricatorSearchController' => 'applications/search/controller/search',
'PhabricatorSearchDAO' => 'applications/search/storage/base',
'PhabricatorSearchDifferentialIndexer' => 'applications/search/index/indexer/differential',
'PhabricatorSearchDocument' => 'applications/search/storage/document/document',
'PhabricatorSearchDocumentField' => 'applications/search/storage/document/field',
'PhabricatorSearchDocumentIndexer' => 'applications/search/index/indexer/base',
'PhabricatorSearchDocumentRelationship' => 'applications/search/storage/document/relationship',
'PhabricatorSearchEngine' => 'applications/search/engine/base',
'PhabricatorSearchEngineElastic' => 'applications/search/engine/elastic',
'PhabricatorSearchEngineMySQL' => 'applications/search/engine/mysql',
'PhabricatorSearchEngineSelector' => 'applications/search/selector/base',
'PhabricatorSearchField' => 'applications/search/constants/field',
'PhabricatorSearchIndexController' => 'applications/search/controller/index',
'PhabricatorSearchManiphestIndexer' => 'applications/search/index/indexer/maniphest',
'PhabricatorSearchPhrictionIndexer' => 'applications/search/index/indexer/phriction',
'PhabricatorSearchQuery' => 'applications/search/storage/query',
'PhabricatorSearchRelationship' => 'applications/search/constants/relationship',
'PhabricatorSearchResultView' => 'applications/search/view/searchresult',
'PhabricatorSearchScope' => 'applications/search/constants/scope',
'PhabricatorSearchSelectController' => 'applications/search/controller/select',
'PhabricatorSearchUserIndexer' => 'applications/search/index/indexer/user',
'PhabricatorSetup' => 'infrastructure/setup',
'PhabricatorSlowvoteChoice' => 'applications/slowvote/storage/choice',
'PhabricatorSlowvoteComment' => 'applications/slowvote/storage/comment',
'PhabricatorSlowvoteController' => 'applications/slowvote/controller/base',
'PhabricatorSlowvoteCreateController' => 'applications/slowvote/controller/create',
'PhabricatorSlowvoteDAO' => 'applications/slowvote/storage/base',
'PhabricatorSlowvoteListController' => 'applications/slowvote/controller/list',
'PhabricatorSlowvoteOption' => 'applications/slowvote/storage/option',
'PhabricatorSlowvotePoll' => 'applications/slowvote/storage/poll',
'PhabricatorSlowvotePollController' => 'applications/slowvote/controller/poll',
'PhabricatorSlug' => 'infrastructure/util/slug',
'PhabricatorSlugTestCase' => 'infrastructure/util/slug/__tests__',
'PhabricatorSortTableExample' => 'applications/uiexample/examples/sorttable',
2011-01-23 02:48:55 +01:00
'PhabricatorStandardPageView' => 'view/page/standard',
2011-04-08 20:13:29 +02:00
'PhabricatorStatusController' => 'applications/status/base',
'PhabricatorStorageFixtureScopeGuard' => 'infrastructure/testing/fixture/storage',
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
'PhabricatorStorageManagementAPI' => 'infrastructure/setup/storage/management',
'PhabricatorStorageManagementDatabasesWorkflow' => 'infrastructure/setup/storage/workflow/databases',
'PhabricatorStorageManagementDestroyWorkflow' => 'infrastructure/setup/storage/workflow/destroy',
'PhabricatorStorageManagementDumpWorkflow' => 'infrastructure/setup/storage/workflow/dump',
'PhabricatorStorageManagementStatusWorkflow' => 'infrastructure/setup/storage/workflow/status',
'PhabricatorStorageManagementUpgradeWorkflow' => 'infrastructure/setup/storage/workflow/upgrade',
'PhabricatorStorageManagementWorkflow' => 'infrastructure/setup/storage/workflow/base',
'PhabricatorStoragePatch' => 'infrastructure/setup/storage/patch',
'PhabricatorSymbolNameLinter' => 'infrastructure/lint/hook/xhpastsymbolname',
'PhabricatorSyntaxHighlighter' => 'applications/markup/syntax',
'PhabricatorTaskmasterDaemon' => 'infrastructure/daemon/workers/taskmaster',
'PhabricatorTestCase' => 'infrastructure/testing/testcase',
'PhabricatorTimelineCursor' => 'infrastructure/daemon/timeline/storage/cursor',
'PhabricatorTimelineDAO' => 'infrastructure/daemon/timeline/storage/base',
'PhabricatorTimelineEvent' => 'infrastructure/daemon/timeline/storage/event',
'PhabricatorTimelineEventData' => 'infrastructure/daemon/timeline/storage/eventdata',
'PhabricatorTimelineIterator' => 'infrastructure/daemon/timeline/cursor/iterator',
'PhabricatorTimer' => 'applications/countdown/storage/timer',
'PhabricatorTransactionView' => 'view/layout/transaction',
'PhabricatorTransformedFile' => 'applications/files/storage/transformed',
'PhabricatorTrivialTestCase' => 'infrastructure/testing/testcase/__tests__',
2011-01-25 22:48:05 +01:00
'PhabricatorTypeaheadCommonDatasourceController' => 'applications/typeahead/controller/common',
'PhabricatorTypeaheadDatasourceController' => 'applications/typeahead/controller/base',
2011-04-01 02:06:33 +02:00
'PhabricatorUIExample' => 'applications/uiexample/examples/base',
'PhabricatorUIExampleController' => 'applications/uiexample/controller/base',
'PhabricatorUIExampleRenderController' => 'applications/uiexample/controller/render',
'PhabricatorUIListFilterExample' => 'applications/uiexample/examples/listfilter',
2011-04-01 02:06:33 +02:00
'PhabricatorUIPagerExample' => 'applications/uiexample/examples/pager',
'PhabricatorUITooltipExample' => 'applications/uiexample/examples/tooltip',
'PhabricatorUnitsTestCase' => 'view/utils/__tests__',
2011-01-24 03:09:16 +01:00
'PhabricatorUser' => 'applications/people/storage/user',
'PhabricatorUserAccountSettingsPanelController' => 'applications/people/controller/settings/panels/account',
'PhabricatorUserConduitSettingsPanelController' => 'applications/people/controller/settings/panels/conduit',
2011-01-24 03:09:16 +01:00
'PhabricatorUserDAO' => 'applications/people/storage/base',
'PhabricatorUserEmailPreferenceSettingsPanelController' => 'applications/people/controller/settings/panels/emailpref',
'PhabricatorUserEmailSettingsPanelController' => 'applications/people/controller/settings/panels/email',
'PhabricatorUserLog' => 'applications/people/storage/log',
'PhabricatorUserOAuthInfo' => 'applications/people/storage/useroauthinfo',
'PhabricatorUserOAuthSettingsPanelController' => 'applications/people/controller/settings/panels/oauth',
'PhabricatorUserPasswordSettingsPanelController' => 'applications/people/controller/settings/panels/password',
'PhabricatorUserPreferenceSettingsPanelController' => 'applications/people/controller/settings/panels/preferences',
'PhabricatorUserPreferences' => 'applications/people/storage/preferences',
'PhabricatorUserProfile' => 'applications/people/storage/profile',
'PhabricatorUserProfileSettingsPanelController' => 'applications/people/controller/settings/panels/profile',
'PhabricatorUserSSHKey' => 'applications/people/storage/usersshkey',
'PhabricatorUserSSHKeysSettingsPanelController' => 'applications/people/controller/settings/panels/sshkeys',
'PhabricatorUserSearchSettingsPanelController' => 'applications/people/controller/settings/panels/search',
2011-02-06 07:36:21 +01:00
'PhabricatorUserSettingsController' => 'applications/people/controller/settings',
'PhabricatorUserSettingsPanelController' => 'applications/people/controller/settings/panels/base',
'PhabricatorUserStatus' => 'applications/people/storage/userstatus',
'PhabricatorUserTestCase' => 'applications/people/storage/user/__tests__',
'PhabricatorWorker' => 'infrastructure/daemon/workers/worker',
'PhabricatorWorkerDAO' => 'infrastructure/daemon/workers/storage/base',
'PhabricatorWorkerTask' => 'infrastructure/daemon/workers/storage/task',
'PhabricatorWorkerTaskData' => 'infrastructure/daemon/workers/storage/taskdata',
2011-03-27 07:55:18 +02:00
'PhabricatorWorkerTaskDetailController' => 'applications/daemon/controller/workertaskdetail',
'PhabricatorWorkerTaskUpdateController' => 'applications/daemon/controller/workertaskupdate',
2011-04-07 04:17:05 +02:00
'PhabricatorXHPASTViewController' => 'applications/xhpastview/controller/base',
'PhabricatorXHPASTViewDAO' => 'applications/xhpastview/storage/base',
'PhabricatorXHPASTViewFrameController' => 'applications/xhpastview/controller/viewframe',
'PhabricatorXHPASTViewFramesetController' => 'applications/xhpastview/controller/viewframeset',
'PhabricatorXHPASTViewInputController' => 'applications/xhpastview/controller/viewinput',
'PhabricatorXHPASTViewPanelController' => 'applications/xhpastview/controller/viewpanel',
'PhabricatorXHPASTViewParseTree' => 'applications/xhpastview/storage/parsetree',
'PhabricatorXHPASTViewRunController' => 'applications/xhpastview/controller/run',
'PhabricatorXHPASTViewStreamController' => 'applications/xhpastview/controller/viewstream',
'PhabricatorXHPASTViewTreeController' => 'applications/xhpastview/controller/viewtree',
2011-02-02 22:48:52 +01:00
'PhabricatorXHProfController' => 'applications/xhprof/controller/base',
'PhabricatorXHProfProfileController' => 'applications/xhprof/controller/profile',
'PhabricatorXHProfProfileSymbolView' => 'applications/xhprof/view/symbol',
'PhabricatorXHProfProfileTopLevelView' => 'applications/xhprof/view/toplevel',
'PhabricatorXHProfProfileView' => 'applications/xhprof/view/base',
'PhameController' => 'applications/phame/controller/base',
'PhameDAO' => 'applications/phame/storage/base',
'PhameDraftListController' => 'applications/phame/controller/post/list/drafts',
'PhamePost' => 'applications/phame/storage/post',
'PhamePostDeleteController' => 'applications/phame/controller/post/delete',
'PhamePostDetailView' => 'applications/phame/view/postdetail',
'PhamePostEditController' => 'applications/phame/controller/post/edit',
'PhamePostListBaseController' => 'applications/phame/controller/post/list/base',
'PhamePostListController' => 'applications/phame/controller/post/list/posts',
'PhamePostListView' => 'applications/phame/view/postlist',
'PhamePostPreviewController' => 'applications/phame/controller/post/preview',
'PhamePostQuery' => 'applications/phame/query/post',
'PhamePostViewController' => 'applications/phame/controller/post/view',
'PhortuneMonthYearExpiryControl' => 'applications/phortune/control/monthyearexpiry',
'PhortuneStripeBaseController' => 'applications/phortune/stripe/controller/base',
'PhortuneStripePaymentFormView' => 'applications/phortune/stripe/view/paymentform',
'PhortuneStripeTestPaymentFormController' => 'applications/phortune/stripe/controller/testpaymentform',
'PhrictionActionConstants' => 'applications/phriction/constants/action',
'PhrictionChangeType' => 'applications/phriction/constants/changetype',
'PhrictionConstants' => 'applications/phriction/constants/base',
'PhrictionContent' => 'applications/phriction/storage/content',
'PhrictionController' => 'applications/phriction/controller/base',
'PhrictionDAO' => 'applications/phriction/storage/base',
'PhrictionDeleteController' => 'applications/phriction/controller/delete',
'PhrictionDiffController' => 'applications/phriction/controller/diff',
'PhrictionDocument' => 'applications/phriction/storage/document',
'PhrictionDocumentController' => 'applications/phriction/controller/document',
'PhrictionDocumentEditor' => 'applications/phriction/editor/document',
'PhrictionDocumentPreviewController' => 'applications/phriction/controller/documentpreview',
'PhrictionDocumentStatus' => 'applications/phriction/constants/documentstatus',
'PhrictionDocumentTestCase' => 'applications/phriction/storage/document/__tests__',
'PhrictionEditController' => 'applications/phriction/controller/edit',
'PhrictionHistoryController' => 'applications/phriction/controller/history',
'PhrictionListController' => 'applications/phriction/controller/list',
'QueryFormattingTestCase' => 'storage/qsprintf/__tests__',
),
'function' =>
array(
'_phabricator_date_format' => 'view/utils',
'_qsprintf_check_scalar_type' => 'storage/qsprintf',
'_qsprintf_check_type' => 'storage/qsprintf',
'celerity_generate_unique_node_id' => 'infrastructure/celerity/api',
'celerity_get_resource_uri' => 'infrastructure/celerity/api',
'celerity_register_resource_map' => 'infrastructure/celerity/map',
'javelin_render_tag' => 'infrastructure/javelin/markup',
'phabricator_date' => 'view/utils',
'phabricator_datetime' => 'view/utils',
'phabricator_format_bytes' => 'view/utils',
'phabricator_format_local_time' => 'view/utils',
2011-01-31 03:24:57 +01:00
'phabricator_format_relative_time' => 'view/utils',
'phabricator_format_units_generic' => 'view/utils',
'phabricator_on_relative_date' => 'view/utils',
'phabricator_parse_bytes' => 'view/utils',
'phabricator_relative_date' => 'view/utils',
'phabricator_render_form' => 'infrastructure/javelin/markup',
'phabricator_time' => 'view/utils',
'phid_get_type' => 'applications/phid/utils',
'phid_group_by_type' => 'applications/phid/utils',
'qsprintf' => 'storage/qsprintf',
'queryfx' => 'storage/queryfx',
'queryfx_all' => 'storage/queryfx',
'queryfx_one' => 'storage/queryfx',
'require_celerity_resource' => 'infrastructure/celerity/api',
'vqsprintf' => 'storage/qsprintf',
'vqueryfx' => 'storage/queryfx',
2011-01-27 20:35:04 +01:00
'vqueryfx_all' => 'storage/queryfx',
'xsprintf_query' => 'storage/qsprintf',
),
'requires_class' =>
array(
'Aphront304Response' => 'AphrontResponse',
'Aphront400Response' => 'AphrontResponse',
'Aphront403Response' => 'AphrontWebpageResponse',
'Aphront404Response' => 'AphrontWebpageResponse',
2011-01-25 20:57:47 +01:00
'AphrontAjaxResponse' => 'AphrontResponse',
'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',
'AphrontCalendarMonthView' => 'AphrontView',
'AphrontContextBarView' => 'AphrontView',
'AphrontCrumbsView' => 'AphrontView',
'AphrontDefaultApplicationConfiguration' => 'AphrontApplicationConfiguration',
'AphrontDialogResponse' => 'AphrontResponse',
'AphrontDialogView' => 'AphrontView',
'AphrontErrorView' => 'AphrontView',
'AphrontFilePreviewView' => 'AphrontView',
2011-01-23 03:33:00 +01:00
'AphrontFileResponse' => 'AphrontResponse',
2011-01-26 02:40:21 +01:00
'AphrontFormCheckboxControl' => 'AphrontFormControl',
'AphrontFormControl' => 'AphrontView',
'AphrontFormDateControl' => 'AphrontFormControl',
'AphrontFormDividerControl' => 'AphrontFormControl',
'AphrontFormDragAndDropUploadControl' => 'AphrontFormControl',
2011-01-23 03:33:00 +01:00
'AphrontFormFileControl' => 'AphrontFormControl',
'AphrontFormInsetView' => 'AphrontView',
'AphrontFormLayoutView' => 'AphrontView',
2011-01-24 20:36:53 +01:00
'AphrontFormMarkupControl' => 'AphrontFormControl',
'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',
'AphrontFormRadioButtonControl' => 'AphrontFormControl',
'AphrontFormRecaptchaControl' => 'AphrontFormControl',
'AphrontFormSelectControl' => 'AphrontFormControl',
2011-01-23 03:33:00 +01:00
'AphrontFormStaticControl' => 'AphrontFormControl',
'AphrontFormSubmitControl' => 'AphrontFormControl',
'AphrontFormTextAreaControl' => 'AphrontFormControl',
'AphrontFormTextControl' => 'AphrontFormControl',
'AphrontFormToggleButtonsControl' => 'AphrontFormControl',
2011-01-25 22:48:05 +01:00
'AphrontFormTokenizerControl' => 'AphrontFormControl',
'AphrontFormView' => 'AphrontView',
'AphrontHTTPSinkTestCase' => 'PhabricatorTestCase',
'AphrontHeadsupActionListView' => 'AphrontView',
'AphrontHeadsupActionView' => 'AphrontView',
'AphrontHeadsupView' => '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
'AphrontIDPagerView' => 'AphrontView',
'AphrontIsolatedDatabaseConnection' => 'AphrontDatabaseConnection',
'AphrontIsolatedDatabaseConnectionTestCase' => 'PhabricatorTestCase',
'AphrontIsolatedHTTPSink' => 'AphrontHTTPSink',
'AphrontJSONResponse' => 'AphrontResponse',
'AphrontJavelinView' => 'AphrontView',
'AphrontKeyboardShortcutsAvailableView' => 'AphrontView',
'AphrontListFilterView' => 'AphrontView',
'AphrontMiniPanelView' => 'AphrontView',
'AphrontMySQLDatabaseConnection' => 'AphrontMySQLDatabaseConnectionBase',
'AphrontMySQLDatabaseConnectionBase' => 'AphrontDatabaseConnection',
'AphrontMySQLDatabaseConnectionTestCase' => 'PhabricatorTestCase',
'AphrontMySQLiDatabaseConnection' => 'AphrontMySQLDatabaseConnectionBase',
'AphrontNullView' => 'AphrontView',
'AphrontPHPHTTPSink' => 'AphrontHTTPSink',
'AphrontPageView' => 'AphrontView',
2011-04-01 02:06:33 +02:00
'AphrontPagerView' => 'AphrontView',
'AphrontPanelView' => 'AphrontView',
'AphrontPlainTextResponse' => 'AphrontResponse',
'AphrontProxyResponse' => 'AphrontResponse',
'AphrontQueryAccessDeniedException' => 'AphrontQueryRecoverableException',
'AphrontQueryConnectionException' => 'AphrontQueryException',
'AphrontQueryConnectionLostException' => 'AphrontQueryRecoverableException',
'AphrontQueryCountException' => 'AphrontQueryException',
2011-01-31 06:28:45 +01:00
'AphrontQueryDuplicateKeyException' => 'AphrontQueryException',
'AphrontQueryObjectMissingException' => 'AphrontQueryException',
'AphrontQueryParameterException' => 'AphrontQueryException',
'AphrontQueryRecoverableException' => 'AphrontQueryException',
'AphrontQuerySchemaException' => 'AphrontQueryException',
2011-01-26 22:21:12 +01:00
'AphrontRedirectException' => 'AphrontException',
'AphrontRedirectResponse' => 'AphrontResponse',
'AphrontReloadResponse' => 'AphrontRedirectResponse',
2011-01-30 18:15:01 +01:00
'AphrontRequestFailureView' => 'AphrontView',
'AphrontRequestTestCase' => 'PhabricatorTestCase',
'AphrontSideNavFilterView' => 'AphrontView',
2011-01-24 18:00:29 +01:00
'AphrontSideNavView' => 'AphrontView',
'AphrontTableView' => 'AphrontView',
2011-03-23 04:41:02 +01:00
'AphrontTokenizerTemplateView' => 'AphrontView',
2011-04-04 04:20:47 +02:00
'AphrontTypeaheadTemplateView' => 'AphrontView',
'AphrontUsageException' => 'AphrontException',
'AphrontWebpageResponse' => 'AphrontResponse',
'CelerityResourceController' => 'AphrontController',
'CelerityResourceGraph' => 'AbstractDirectedGraph',
'CelerityResourceTransformerTestCase' => 'PhabricatorTestCase',
'ConduitAPI_arcanist_Method' => 'ConduitAPIMethod',
'ConduitAPI_arcanist_projectinfo_Method' => 'ConduitAPI_arcanist_Method',
'ConduitAPI_audit_Method' => 'ConduitAPIMethod',
'ConduitAPI_audit_query_Method' => 'ConduitAPI_audit_Method',
'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',
'ConduitAPI_conduit_getcertificate_Method' => 'ConduitAPIMethod',
'ConduitAPI_conduit_ping_Method' => 'ConduitAPIMethod',
2011-03-15 21:38:14 +01:00
'ConduitAPI_daemon_launched_Method' => 'ConduitAPIMethod',
'ConduitAPI_daemon_log_Method' => 'ConduitAPIMethod',
'ConduitAPI_differential_close_Method' => 'ConduitAPIMethod',
'ConduitAPI_differential_createcomment_Method' => 'ConduitAPIMethod',
2011-01-24 20:01:53 +01:00
'ConduitAPI_differential_creatediff_Method' => 'ConduitAPIMethod',
'ConduitAPI_differential_createrevision_Method' => 'ConduitAPIMethod',
'ConduitAPI_differential_find_Method' => 'ConduitAPIMethod',
'ConduitAPI_differential_getalldiffs_Method' => 'ConduitAPIMethod',
'ConduitAPI_differential_getcommitmessage_Method' => 'ConduitAPIMethod',
'ConduitAPI_differential_getcommitpaths_Method' => 'ConduitAPIMethod',
'ConduitAPI_differential_getdiff_Method' => 'ConduitAPIMethod',
'ConduitAPI_differential_getrevision_Method' => 'ConduitAPIMethod',
'ConduitAPI_differential_getrevisioncomments_Method' => 'ConduitAPIMethod',
'ConduitAPI_differential_getrevisionfeedback_Method' => 'ConduitAPIMethod',
'ConduitAPI_differential_markcommitted_Method' => 'ConduitAPIMethod',
'ConduitAPI_differential_parsecommitmessage_Method' => 'ConduitAPIMethod',
'ConduitAPI_differential_query_Method' => 'ConduitAPIMethod',
2011-01-24 21:07:34 +01:00
'ConduitAPI_differential_setdiffproperty_Method' => 'ConduitAPIMethod',
'ConduitAPI_differential_updaterevision_Method' => 'ConduitAPIMethod',
'ConduitAPI_differential_updatetaskrevisionassoc_Method' => 'ConduitAPIMethod',
'ConduitAPI_differential_updateunitresults_Method' => 'ConduitAPIMethod',
'ConduitAPI_diffusion_findsymbols_Method' => 'ConduitAPIMethod',
'ConduitAPI_diffusion_getcommits_Method' => 'ConduitAPIMethod',
'ConduitAPI_diffusion_getrecentcommitsbypath_Method' => 'ConduitAPIMethod',
'ConduitAPI_feed_publish_Method' => 'ConduitAPIMethod',
'ConduitAPI_feed_query_Method' => 'ConduitAPIMethod',
'ConduitAPI_file_download_Method' => 'ConduitAPIMethod',
'ConduitAPI_file_info_Method' => 'ConduitAPIMethod',
2011-01-24 18:00:29 +01:00
'ConduitAPI_file_upload_Method' => 'ConduitAPIMethod',
'ConduitAPI_flag_Method' => 'ConduitAPIMethod',
'ConduitAPI_flag_query_Method' => 'ConduitAPI_flag_Method',
'ConduitAPI_macro_Method' => 'ConduitAPIMethod',
'ConduitAPI_macro_query_Method' => 'ConduitAPI_macro_Method',
'ConduitAPI_maniphest_Method' => 'ConduitAPIMethod',
'ConduitAPI_maniphest_createtask_Method' => 'ConduitAPI_maniphest_Method',
'ConduitAPI_maniphest_find_Method' => 'ConduitAPI_maniphest_Method',
'ConduitAPI_maniphest_gettasktransactions_Method' => 'ConduitAPI_maniphest_Method',
'ConduitAPI_maniphest_info_Method' => 'ConduitAPI_maniphest_Method',
'ConduitAPI_maniphest_update_Method' => 'ConduitAPI_maniphest_Method',
'ConduitAPI_paste_Method' => 'ConduitAPIMethod',
'ConduitAPI_paste_create_Method' => 'ConduitAPI_paste_Method',
'ConduitAPI_paste_info_Method' => 'ConduitAPI_paste_Method',
'ConduitAPI_path_getowners_Method' => 'ConduitAPIMethod',
'ConduitAPI_phid_Method' => 'ConduitAPIMethod',
'ConduitAPI_phid_info_Method' => 'ConduitAPI_phid_Method',
'ConduitAPI_phid_query_Method' => 'ConduitAPI_phid_Method',
'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',
'ConduitAPI_project_Method' => 'ConduitAPIMethod',
'ConduitAPI_project_query_Method' => 'ConduitAPI_project_Method',
'ConduitAPI_remarkup_process_Method' => 'ConduitAPIMethod',
'ConduitAPI_repository_Method' => 'ConduitAPIMethod',
'ConduitAPI_repository_create_Method' => 'ConduitAPI_repository_Method',
'ConduitAPI_repository_query_Method' => 'ConduitAPI_repository_Method',
'ConduitAPI_slowvote_info_Method' => 'ConduitAPIMethod',
'ConduitAPI_user_Method' => 'ConduitAPIMethod',
'ConduitAPI_user_addstatus_Method' => 'ConduitAPI_user_Method',
'ConduitAPI_user_removestatus_Method' => 'ConduitAPI_user_Method',
'ConduitAPI_user_find_Method' => 'ConduitAPI_user_Method',
'ConduitAPI_user_info_Method' => 'ConduitAPI_user_Method',
'ConduitAPI_user_whoami_Method' => 'ConduitAPI_user_Method',
'DarkConsoleConfigPlugin' => 'DarkConsolePlugin',
2011-02-03 07:38:42 +01:00
'DarkConsoleController' => 'PhabricatorController',
2011-02-02 22:48:52 +01:00
'DarkConsoleErrorLogPlugin' => 'DarkConsolePlugin',
'DarkConsoleEventPlugin' => 'DarkConsolePlugin',
'DarkConsoleEventPluginAPI' => 'PhutilEventListener',
2011-02-02 22:48:52 +01:00
'DarkConsoleRequestPlugin' => 'DarkConsolePlugin',
'DarkConsoleServicesPlugin' => 'DarkConsolePlugin',
'DarkConsoleXHProfPlugin' => 'DarkConsolePlugin',
'DifferentialActionHasNoEffectException' => 'DifferentialException',
2011-01-30 20:02:22 +01:00
'DifferentialAddCommentView' => 'AphrontView',
'DifferentialAffectedPath' => 'DifferentialDAO',
'DifferentialApplyPatchFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialArcanistProjectFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialAuditorsFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialAuthorFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialAuxiliaryField' => 'DifferentialDAO',
'DifferentialBlameRevisionFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialBranchFieldSpecification' => 'DifferentialFieldSpecification',
2011-01-26 02:17:19 +01:00
'DifferentialCCWelcomeMail' => 'DifferentialReviewRequestMail',
'DifferentialCCsFieldSpecification' => 'DifferentialFieldSpecification',
2011-01-24 20:01:53 +01:00
'DifferentialChangeset' => 'DifferentialDAO',
2011-01-24 22:18:41 +01:00
'DifferentialChangesetDetailView' => 'AphrontView',
2011-01-25 20:57:47 +01:00
'DifferentialChangesetListView' => 'AphrontView',
2011-01-25 00:52:35 +01:00
'DifferentialChangesetViewController' => 'DifferentialController',
'DifferentialComment' => 'DifferentialDAO',
'DifferentialCommentMail' => 'DifferentialMail',
2011-02-01 03:05:20 +01:00
'DifferentialCommentPreviewController' => 'DifferentialController',
'DifferentialCommentSaveController' => 'DifferentialController',
'DifferentialCommitsFieldSpecification' => 'DifferentialFieldSpecification',
2011-01-24 22:18:41 +01:00
'DifferentialController' => 'PhabricatorController',
2011-01-24 20:01:53 +01:00
'DifferentialDAO' => 'PhabricatorLiskDAO',
'DifferentialDateCreatedFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialDateModifiedFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialDefaultFieldSelector' => 'DifferentialFieldSelector',
'DifferentialDependenciesFieldSpecification' => 'DifferentialFieldSpecification',
2011-01-24 20:01:53 +01:00
'DifferentialDiff' => 'DifferentialDAO',
2011-01-26 02:17:19 +01:00
'DifferentialDiffContentMail' => 'DifferentialMail',
'DifferentialDiffCreateController' => 'DifferentialController',
2011-01-24 21:07:34 +01:00
'DifferentialDiffProperty' => 'DifferentialDAO',
2011-01-24 22:18:41 +01:00
'DifferentialDiffTableOfContentsView' => 'AphrontView',
'DifferentialDiffViewController' => 'DifferentialController',
'DifferentialExceptionMail' => 'DifferentialMail',
'DifferentialExportPatchFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialGitSVNIDFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialHostFieldSpecification' => 'DifferentialFieldSpecification',
2011-01-24 20:01:53 +01:00
'DifferentialHunk' => 'DifferentialDAO',
'DifferentialInlineComment' => 'DifferentialDAO',
'DifferentialInlineCommentEditController' => 'PhabricatorInlineCommentController',
'DifferentialInlineCommentEditView' => 'AphrontView',
2011-02-03 04:38:43 +01:00
'DifferentialInlineCommentPreviewController' => 'DifferentialController',
2011-02-02 01:42:36 +01:00
'DifferentialInlineCommentView' => 'AphrontView',
'DifferentialLinesFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialLintFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialLocalCommitsView' => 'AphrontView',
'DifferentialManiphestTasksFieldSpecification' => 'DifferentialFieldSpecification',
2011-01-26 02:17:19 +01:00
'DifferentialNewDiffMail' => 'DifferentialReviewRequestMail',
'DifferentialPathFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialPrimaryPaneView' => 'AphrontView',
'DifferentialReplyHandler' => 'PhabricatorMailReplyHandler',
'DifferentialResultsTableView' => 'AphrontView',
'DifferentialRevertPlanFieldSpecification' => 'DifferentialFieldSpecification',
2011-01-26 02:17:19 +01:00
'DifferentialReviewRequestMail' => 'DifferentialMail',
'DifferentialReviewedByFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialReviewersFieldSpecification' => 'DifferentialFieldSpecification',
2011-01-24 20:01:53 +01:00
'DifferentialRevision' => 'DifferentialDAO',
'DifferentialRevisionCommentListView' => 'AphrontView',
'DifferentialRevisionCommentView' => 'AphrontView',
2011-01-27 23:55:52 +01:00
'DifferentialRevisionDetailView' => 'AphrontView',
2011-01-25 22:26:09 +01:00
'DifferentialRevisionEditController' => 'DifferentialController',
'DifferentialRevisionIDFieldParserTestCase' => 'PhabricatorTestCase',
'DifferentialRevisionIDFieldSpecification' => 'DifferentialFieldSpecification',
2011-01-26 00:19:06 +01:00
'DifferentialRevisionListController' => 'DifferentialController',
'DifferentialRevisionListView' => 'AphrontView',
'DifferentialRevisionStatsController' => 'DifferentialController',
'DifferentialRevisionStatsView' => 'AphrontView',
'DifferentialRevisionStatusFieldSpecification' => 'DifferentialFieldSpecification',
2011-01-27 23:55:52 +01:00
'DifferentialRevisionUpdateHistoryView' => 'AphrontView',
'DifferentialRevisionViewController' => 'DifferentialController',
'DifferentialSubscribeController' => 'DifferentialController',
'DifferentialSummaryFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialTestPlanFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialTitleFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialUnitFieldSpecification' => 'DifferentialFieldSpecification',
'DiffusionBranchTableView' => 'DiffusionView',
'DiffusionBrowseController' => 'DiffusionController',
'DiffusionBrowseFileController' => 'DiffusionController',
'DiffusionBrowseTableView' => 'DiffusionView',
2011-03-14 06:03:30 +01:00
'DiffusionChangeController' => 'DiffusionController',
'DiffusionCommentListView' => 'AphrontView',
'DiffusionCommentView' => 'AphrontView',
'DiffusionCommitChangeTableView' => 'DiffusionView',
'DiffusionCommitController' => 'DiffusionController',
'DiffusionCommitParentsQuery' => 'DiffusionQuery',
'DiffusionCommitTagsQuery' => 'DiffusionQuery',
'DiffusionContainsQuery' => 'DiffusionQuery',
'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',
'DiffusionEmptyResultView' => 'DiffusionView',
'DiffusionExternalController' => 'DiffusionController',
'DiffusionFileContentQuery' => 'DiffusionQuery',
'DiffusionGitBranchQuery' => 'DiffusionBranchQuery',
'DiffusionGitBranchQueryTestCase' => 'PhabricatorTestCase',
'DiffusionGitBrowseQuery' => 'DiffusionBrowseQuery',
'DiffusionGitCommitParentsQuery' => 'DiffusionCommitParentsQuery',
'DiffusionGitCommitTagsQuery' => 'DiffusionCommitTagsQuery',
'DiffusionGitContainsQuery' => 'DiffusionContainsQuery',
2011-03-31 03:17:36 +02:00
'DiffusionGitDiffQuery' => 'DiffusionDiffQuery',
'DiffusionGitFileContentQuery' => 'DiffusionFileContentQuery',
'DiffusionGitHistoryQuery' => 'DiffusionHistoryQuery',
'DiffusionGitLastModifiedQuery' => 'DiffusionLastModifiedQuery',
'DiffusionGitMergedCommitsQuery' => 'DiffusionMergedCommitsQuery',
'DiffusionGitRawDiffQuery' => 'DiffusionRawDiffQuery',
'DiffusionGitRenameHistoryQuery' => 'DiffusionRenameHistoryQuery',
'DiffusionGitRequest' => 'DiffusionRequest',
'DiffusionGitTagListQuery' => 'DiffusionTagListQuery',
'DiffusionHistoryController' => 'DiffusionController',
'DiffusionHistoryQuery' => 'DiffusionQuery',
'DiffusionHistoryTableView' => 'DiffusionView',
'DiffusionHomeController' => 'DiffusionController',
'DiffusionInlineCommentController' => 'PhabricatorInlineCommentController',
'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',
'DiffusionMercurialBranchQuery' => 'DiffusionBranchQuery',
'DiffusionMercurialBrowseQuery' => 'DiffusionBrowseQuery',
'DiffusionMercurialCommitParentsQuery' => 'DiffusionCommitParentsQuery',
'DiffusionMercurialCommitTagsQuery' => 'DiffusionCommitTagsQuery',
'DiffusionMercurialContainsQuery' => 'DiffusionContainsQuery',
'DiffusionMercurialDiffQuery' => 'DiffusionDiffQuery',
'DiffusionMercurialFileContentQuery' => 'DiffusionFileContentQuery',
'DiffusionMercurialHistoryQuery' => 'DiffusionHistoryQuery',
'DiffusionMercurialLastModifiedQuery' => 'DiffusionLastModifiedQuery',
'DiffusionMercurialMergedCommitsQuery' => 'DiffusionMergedCommitsQuery',
'DiffusionMercurialRawDiffQuery' => 'DiffusionRawDiffQuery',
'DiffusionMercurialRenameHistoryQuery' => 'DiffusionRenameHistoryQuery',
'DiffusionMercurialRequest' => 'DiffusionRequest',
'DiffusionMercurialTagListQuery' => 'DiffusionTagListQuery',
'DiffusionMergedCommitsQuery' => 'DiffusionQuery',
2011-04-04 04:20:47 +02:00
'DiffusionPathCompleteController' => 'DiffusionController',
'DiffusionPathQueryTestCase' => 'PhabricatorTestCase',
2011-04-04 04:20:47 +02:00
'DiffusionPathValidateController' => 'DiffusionController',
'DiffusionRawDiffQuery' => 'DiffusionQuery',
'DiffusionRenameHistoryQuery' => 'DiffusionQuery',
'DiffusionRepositoryController' => 'DiffusionController',
'DiffusionSvnBrowseQuery' => 'DiffusionBrowseQuery',
'DiffusionSvnCommitParentsQuery' => 'DiffusionCommitParentsQuery',
'DiffusionSvnCommitTagsQuery' => 'DiffusionCommitTagsQuery',
2012-03-24 20:52:14 +01:00
'DiffusionSvnContainsQuery' => 'DiffusionContainsQuery',
2011-03-31 02:36:16 +02:00
'DiffusionSvnDiffQuery' => 'DiffusionDiffQuery',
2011-03-14 06:03:30 +01:00
'DiffusionSvnFileContentQuery' => 'DiffusionFileContentQuery',
'DiffusionSvnHistoryQuery' => 'DiffusionHistoryQuery',
'DiffusionSvnLastModifiedQuery' => 'DiffusionLastModifiedQuery',
'DiffusionSvnMergedCommitsQuery' => 'DiffusionMergedCommitsQuery',
'DiffusionSvnRawDiffQuery' => 'DiffusionRawDiffQuery',
'DiffusionSvnRenameHistoryQuery' => 'DiffusionRenameHistoryQuery',
'DiffusionSvnRequest' => 'DiffusionRequest',
'DiffusionSvnTagListQuery' => 'DiffusionTagListQuery',
'DiffusionSymbolController' => 'DiffusionController',
'DiffusionTagListController' => 'DiffusionController',
'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',
'DiffusionView' => 'AphrontView',
'DrydockAllocatorWorker' => 'PhabricatorWorker',
'DrydockApacheWebrootBlueprint' => 'DrydockBlueprint',
'DrydockApacheWebrootInterface' => 'DrydockWebrootInterface',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockCommandInterface' => 'DrydockInterface',
'DrydockController' => 'PhabricatorController',
'DrydockDAO' => 'PhabricatorLiskDAO',
'DrydockEC2HostBlueprint' => 'DrydockRemoteHostBlueprint',
'DrydockLease' => 'DrydockDAO',
'DrydockLeaseListController' => 'DrydockController',
'DrydockLeaseStatus' => 'DrydockConstants',
'DrydockLocalCommandInterface' => 'DrydockCommandInterface',
'DrydockLocalHostBlueprint' => 'DrydockBlueprint',
'DrydockLog' => 'DrydockDAO',
'DrydockLogController' => 'DrydockController',
'DrydockLogQuery' => 'PhabricatorOffsetPagedQuery',
'DrydockPhabricatorApplicationBlueprint' => 'DrydockBlueprint',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockRemoteHostBlueprint' => 'DrydockBlueprint',
'DrydockResource' => 'DrydockDAO',
'DrydockResourceAllocateController' => 'DrydockController',
'DrydockResourceListController' => 'DrydockController',
'DrydockResourceStatus' => 'DrydockConstants',
'DrydockSSHCommandInterface' => 'DrydockCommandInterface',
'DrydockWebrootInterface' => 'DrydockInterface',
2011-03-22 21:22:40 +01:00
'HeraldAction' => 'HeraldDAO',
'HeraldApplyTranscript' => 'HeraldDAO',
'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',
'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',
2011-03-22 22:34:38 +01:00
'HeraldNewController' => 'HeraldController',
2011-03-22 21:22:40 +01:00
'HeraldRule' => 'HeraldDAO',
'HeraldRuleController' => 'HeraldController',
'HeraldRuleEdit' => 'HeraldDAO',
'HeraldRuleEditHistoryController' => 'HeraldController',
'HeraldRuleEditHistoryView' => 'AphrontView',
'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',
'HeraldTranscriptController' => 'HeraldController',
'HeraldTranscriptListController' => 'HeraldController',
'JavelinReactorExample' => 'PhabricatorUIExample',
'JavelinViewExample' => 'PhabricatorUIExample',
'JavelinViewExampleServerView' => 'AphrontView',
'LiskFixtureTestCase' => 'PhabricatorTestCase',
'LiskIsolationTestCase' => 'PhabricatorTestCase',
'LiskIsolationTestDAO' => 'LiskDAO',
'ManiphestAction' => 'PhrictionConstants',
'ManiphestAuxiliaryFieldDefaultSpecification' => 'ManiphestAuxiliaryFieldSpecification',
'ManiphestBatchEditController' => 'ManiphestController',
'ManiphestController' => 'PhabricatorController',
'ManiphestDAO' => 'PhabricatorLiskDAO',
'ManiphestDefaultTaskExtensions' => 'ManiphestTaskExtensions',
'ManiphestExportController' => 'ManiphestController',
'ManiphestReplyHandler' => 'PhabricatorMailReplyHandler',
'ManiphestReportController' => 'ManiphestController',
'ManiphestSavedQuery' => 'ManiphestDAO',
'ManiphestSavedQueryDeleteController' => 'ManiphestController',
'ManiphestSavedQueryEditController' => 'ManiphestController',
'ManiphestSavedQueryListController' => 'ManiphestController',
'ManiphestSubpriorityController' => 'ManiphestController',
'ManiphestTask' => 'ManiphestDAO',
'ManiphestTaskAuxiliaryStorage' => 'ManiphestDAO',
'ManiphestTaskDescriptionChangeController' => 'ManiphestController',
'ManiphestTaskDescriptionPreviewController' => 'ManiphestController',
'ManiphestTaskDetailController' => 'ManiphestController',
'ManiphestTaskEditController' => 'ManiphestController',
'ManiphestTaskListController' => 'ManiphestController',
'ManiphestTaskListView' => 'ManiphestView',
'ManiphestTaskOwner' => 'ManiphestConstants',
'ManiphestTaskPriority' => 'ManiphestConstants',
'ManiphestTaskProject' => 'ManiphestDAO',
'ManiphestTaskProjectsView' => 'ManiphestView',
'ManiphestTaskStatus' => 'ManiphestConstants',
'ManiphestTaskSubscriber' => 'ManiphestDAO',
'ManiphestTaskSummaryView' => 'ManiphestView',
'ManiphestTransaction' => 'ManiphestDAO',
'ManiphestTransactionDetailView' => 'ManiphestView',
'ManiphestTransactionListView' => 'ManiphestView',
'ManiphestTransactionPreviewController' => 'ManiphestController',
'ManiphestTransactionSaveController' => 'ManiphestController',
'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',
2011-01-30 01:16:09 +01:00
'Phabricator404Controller' => 'PhabricatorController',
'PhabricatorAphlictTestPageController' => 'PhabricatorNotificationsController',
'PhabricatorAuditAddCommentController' => 'PhabricatorAuditController',
'PhabricatorAuditComment' => 'PhabricatorAuditDAO',
'PhabricatorAuditCommitListView' => 'AphrontView',
'PhabricatorAuditController' => 'PhabricatorController',
'PhabricatorAuditDAO' => 'PhabricatorLiskDAO',
'PhabricatorAuditInlineComment' => 'PhabricatorAuditDAO',
'PhabricatorAuditListController' => 'PhabricatorAuditController',
'PhabricatorAuditListView' => 'AphrontView',
'PhabricatorAuditPreviewController' => 'PhabricatorAuditController',
'PhabricatorAuditReplyHandler' => 'PhabricatorMailReplyHandler',
2011-01-26 22:21:12 +01:00
'PhabricatorAuthController' => '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
'PhabricatorBuiltinPatchList' => 'PhabricatorSQLPatchList',
'PhabricatorCalendarBrowseController' => 'PhabricatorCalendarController',
'PhabricatorCalendarController' => 'PhabricatorController',
'PhabricatorCalendarDAO' => 'PhabricatorLiskDAO',
'PhabricatorCalendarHoliday' => 'PhabricatorCalendarDAO',
'PhabricatorCalendarHolidayTestCase' => 'PhabricatorTestCase',
'PhabricatorChangesetResponse' => 'AphrontProxyResponse',
'PhabricatorChatLogChannelListController' => 'PhabricatorChatLogController',
'PhabricatorChatLogChannelLogController' => 'PhabricatorChatLogController',
'PhabricatorChatLogController' => 'PhabricatorController',
'PhabricatorChatLogDAO' => 'PhabricatorLiskDAO',
'PhabricatorChatLogEvent' => 'PhabricatorChatLogDAO',
'PhabricatorChatLogEventType' => 'PhabricatorChatLogConstants',
'PhabricatorChatLogQuery' => 'PhabricatorOffsetPagedQuery',
2011-01-24 18:00:29 +01:00
'PhabricatorConduitAPIController' => 'PhabricatorConduitController',
'PhabricatorConduitCertificateToken' => 'PhabricatorConduitDAO',
2011-01-24 18:00:29 +01:00
'PhabricatorConduitConnectionLog' => 'PhabricatorConduitDAO',
'PhabricatorConduitConsoleController' => 'PhabricatorConduitController',
'PhabricatorConduitController' => 'PhabricatorController',
'PhabricatorConduitDAO' => 'PhabricatorLiskDAO',
'PhabricatorConduitListController' => 'PhabricatorConduitController',
2011-01-24 18:00:29 +01:00
'PhabricatorConduitLogController' => 'PhabricatorConduitController',
'PhabricatorConduitMethodCallLog' => 'PhabricatorConduitDAO',
'PhabricatorConduitTokenController' => 'PhabricatorConduitController',
'PhabricatorContentSourceView' => 'AphrontView',
2011-01-23 02:48:55 +01:00
'PhabricatorController' => 'AphrontController',
'PhabricatorCountdownController' => 'PhabricatorController',
'PhabricatorCountdownDAO' => 'PhabricatorLiskDAO',
'PhabricatorCountdownDeleteController' => 'PhabricatorCountdownController',
'PhabricatorCountdownEditController' => 'PhabricatorCountdownController',
'PhabricatorCountdownListController' => 'PhabricatorCountdownController',
'PhabricatorCountdownViewController' => 'PhabricatorCountdownController',
'PhabricatorDaemon' => 'PhutilDaemon',
'PhabricatorDaemonCombinedLogController' => 'PhabricatorDaemonController',
'PhabricatorDaemonConsoleController' => 'PhabricatorDaemonController',
'PhabricatorDaemonController' => 'PhabricatorController',
2011-03-15 21:38:14 +01:00
'PhabricatorDaemonDAO' => 'PhabricatorLiskDAO',
'PhabricatorDaemonLog' => 'PhabricatorDaemonDAO',
'PhabricatorDaemonLogEvent' => 'PhabricatorDaemonDAO',
'PhabricatorDaemonLogEventsView' => 'AphrontView',
'PhabricatorDaemonLogListController' => 'PhabricatorDaemonController',
'PhabricatorDaemonLogListView' => 'AphrontView',
2011-03-15 21:38:14 +01:00
'PhabricatorDaemonLogViewController' => 'PhabricatorDaemonController',
'PhabricatorDaemonTimelineConsoleController' => 'PhabricatorDaemonController',
'PhabricatorDaemonTimelineEventController' => 'PhabricatorDaemonController',
'PhabricatorDefaultFileStorageEngineSelector' => 'PhabricatorFileStorageEngineSelector',
'PhabricatorDefaultSearchEngineSelector' => 'PhabricatorSearchEngineSelector',
2011-01-23 02:48:55 +01:00
'PhabricatorDirectoryController' => 'PhabricatorController',
'PhabricatorDirectoryMainController' => 'PhabricatorDirectoryController',
'PhabricatorDisabledUserController' => 'PhabricatorAuthController',
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',
'PhabricatorEdgeQuery' => 'PhabricatorQuery',
'PhabricatorEmailLoginController' => 'PhabricatorAuthController',
'PhabricatorEmailTokenController' => 'PhabricatorAuthController',
'PhabricatorEnvTestCase' => 'PhabricatorTestCase',
'PhabricatorErrorExample' => 'PhabricatorUIExample',
'PhabricatorEvent' => 'PhutilEvent',
'PhabricatorEventType' => 'PhutilEventType',
'PhabricatorFeedController' => 'PhabricatorController',
'PhabricatorFeedDAO' => 'PhabricatorLiskDAO',
'PhabricatorFeedPublicStreamController' => 'PhabricatorFeedController',
'PhabricatorFeedStoryAudit' => 'PhabricatorFeedStory',
'PhabricatorFeedStoryData' => 'PhabricatorFeedDAO',
'PhabricatorFeedStoryDifferential' => 'PhabricatorFeedStory',
'PhabricatorFeedStoryManiphest' => 'PhabricatorFeedStory',
'PhabricatorFeedStoryPhriction' => 'PhabricatorFeedStory',
'PhabricatorFeedStoryProject' => 'PhabricatorFeedStory',
'PhabricatorFeedStoryReference' => 'PhabricatorFeedDAO',
'PhabricatorFeedStoryStatus' => 'PhabricatorFeedStory',
'PhabricatorFeedStoryTypeConstants' => 'PhabricatorFeedConstants',
'PhabricatorFeedStoryUnknown' => 'PhabricatorFeedStory',
'PhabricatorFeedStoryView' => 'PhabricatorFeedView',
'PhabricatorFeedView' => 'AphrontView',
2011-01-23 03:33:00 +01:00
'PhabricatorFile' => 'PhabricatorFileDAO',
'PhabricatorFileController' => 'PhabricatorController',
'PhabricatorFileDAO' => 'PhabricatorLiskDAO',
'PhabricatorFileDataController' => 'PhabricatorFileController',
'PhabricatorFileDeleteController' => 'PhabricatorFileController',
'PhabricatorFileDropUploadController' => 'PhabricatorFileController',
'PhabricatorFileImageMacro' => 'PhabricatorFileDAO',
'PhabricatorFileInfoController' => 'PhabricatorFileController',
2011-01-23 03:33:00 +01:00
'PhabricatorFileListController' => 'PhabricatorFileController',
'PhabricatorFileMacroDeleteController' => 'PhabricatorFileController',
'PhabricatorFileMacroEditController' => 'PhabricatorFileController',
'PhabricatorFileMacroListController' => 'PhabricatorFileController',
'PhabricatorFileProxyController' => 'PhabricatorFileController',
'PhabricatorFileProxyImage' => 'PhabricatorFileDAO',
'PhabricatorFileShortcutController' => 'PhabricatorFileController',
'PhabricatorFileSideNavView' => 'AphrontView',
2011-01-23 03:33:00 +01:00
'PhabricatorFileStorageBlob' => 'PhabricatorFileDAO',
'PhabricatorFileTransformController' => 'PhabricatorFileController',
2011-01-23 03:33:00 +01:00
'PhabricatorFileUploadController' => 'PhabricatorFileController',
'PhabricatorFileUploadView' => 'AphrontView',
'PhabricatorFlag' => 'PhabricatorFlagDAO',
'PhabricatorFlagColor' => 'PhabricatorFlagConstants',
'PhabricatorFlagController' => 'PhabricatorController',
'PhabricatorFlagDAO' => 'PhabricatorLiskDAO',
'PhabricatorFlagDeleteController' => 'PhabricatorFlagController',
'PhabricatorFlagEditController' => 'PhabricatorFlagController',
'PhabricatorFlagListController' => 'PhabricatorFlagController',
'PhabricatorFlagListView' => 'AphrontView',
'PhabricatorFormExample' => 'PhabricatorUIExample',
'PhabricatorGarbageCollectorDaemon' => 'PhabricatorDaemon',
'PhabricatorGoodForNothingWorker' => 'PhabricatorWorker',
'PhabricatorHelpController' => 'PhabricatorController',
'PhabricatorHelpKeyboardShortcutController' => 'PhabricatorHelpController',
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
'PhabricatorIDPagedPolicyQuery' => 'PhabricatorPolicyQuery',
'PhabricatorIRCBot' => 'PhabricatorDaemon',
'PhabricatorIRCDifferentialNotificationHandler' => 'PhabricatorIRCHandler',
'PhabricatorIRCLogHandler' => 'PhabricatorIRCHandler',
'PhabricatorIRCMacroHandler' => 'PhabricatorIRCHandler',
'PhabricatorIRCObjectNameHandler' => 'PhabricatorIRCHandler',
'PhabricatorIRCProtocolHandler' => 'PhabricatorIRCHandler',
'PhabricatorIRCWhatsNewHandler' => 'PhabricatorIRCHandler',
'PhabricatorInfrastructureTestCase' => 'PhabricatorTestCase',
'PhabricatorInlineCommentController' => 'PhabricatorController',
'PhabricatorInlineSummaryView' => 'AphrontView',
'PhabricatorJavelinLinter' => 'ArcanistLinter',
'PhabricatorLintEngine' => 'PhutilLintEngine',
2011-01-23 02:48:55 +01:00
'PhabricatorLiskDAO' => 'LiskDAO',
'PhabricatorLocalDiskFileStorageEngine' => 'PhabricatorFileStorageEngine',
'PhabricatorLocalTimeTestCase' => 'PhabricatorTestCase',
2011-01-26 22:21:12 +01:00
'PhabricatorLoginController' => 'PhabricatorAuthController',
'PhabricatorLoginValidateController' => 'PhabricatorAuthController',
2011-01-31 03:52:29 +01:00
'PhabricatorLogoutController' => 'PhabricatorAuthController',
'PhabricatorMailImplementationAmazonSESAdapter' => 'PhabricatorMailImplementationPHPMailerLiteAdapter',
2011-01-26 18:33:31 +01:00
'PhabricatorMailImplementationPHPMailerLiteAdapter' => 'PhabricatorMailImplementationAdapter',
'PhabricatorMailImplementationSendGridAdapter' => 'PhabricatorMailImplementationAdapter',
'PhabricatorMailImplementationTestAdapter' => 'PhabricatorMailImplementationAdapter',
2011-01-26 02:40:21 +01:00
'PhabricatorMetaMTAController' => 'PhabricatorController',
'PhabricatorMetaMTADAO' => 'PhabricatorLiskDAO',
'PhabricatorMetaMTAEmailBodyParserTestCase' => 'PhabricatorTestCase',
2011-01-26 02:40:21 +01:00
'PhabricatorMetaMTAListController' => 'PhabricatorMetaMTAController',
'PhabricatorMetaMTAMail' => 'PhabricatorMetaMTADAO',
'PhabricatorMetaMTAMailTestCase' => 'PhabricatorTestCase',
2011-01-26 19:40:38 +01:00
'PhabricatorMetaMTAMailingList' => 'PhabricatorMetaMTADAO',
'PhabricatorMetaMTAMailingListEditController' => 'PhabricatorMetaMTAController',
'PhabricatorMetaMTAMailingListsController' => 'PhabricatorMetaMTAController',
'PhabricatorMetaMTAReceiveController' => 'PhabricatorMetaMTAController',
'PhabricatorMetaMTAReceivedListController' => 'PhabricatorMetaMTAController',
'PhabricatorMetaMTAReceivedMail' => 'PhabricatorMetaMTADAO',
2011-01-26 02:40:21 +01:00
'PhabricatorMetaMTASendController' => 'PhabricatorMetaMTAController',
'PhabricatorMetaMTASendGridReceiveController' => 'PhabricatorMetaMTAController',
2011-01-26 18:08:26 +01:00
'PhabricatorMetaMTAViewController' => 'PhabricatorMetaMTAController',
'PhabricatorMetaMTAWorker' => 'PhabricatorWorker',
'PhabricatorMySQLFileStorageEngine' => 'PhabricatorFileStorageEngine',
'PhabricatorNotificationsController' => '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
'PhabricatorOAuthClientAuthorization' => 'PhabricatorOAuthServerDAO',
'PhabricatorOAuthClientAuthorizationBaseController' => 'PhabricatorOAuthServerController',
'PhabricatorOAuthClientAuthorizationDeleteController' => 'PhabricatorOAuthClientAuthorizationBaseController',
'PhabricatorOAuthClientAuthorizationEditController' => 'PhabricatorOAuthClientAuthorizationBaseController',
'PhabricatorOAuthClientAuthorizationListController' => 'PhabricatorOAuthClientAuthorizationBaseController',
'PhabricatorOAuthClientAuthorizationQuery' => 'PhabricatorOffsetPagedQuery',
'PhabricatorOAuthClientBaseController' => 'PhabricatorOAuthServerController',
'PhabricatorOAuthClientDeleteController' => 'PhabricatorOAuthClientBaseController',
'PhabricatorOAuthClientEditController' => 'PhabricatorOAuthClientBaseController',
'PhabricatorOAuthClientListController' => 'PhabricatorOAuthClientBaseController',
'PhabricatorOAuthClientViewController' => 'PhabricatorOAuthClientBaseController',
2011-02-28 04:47:22 +01:00
'PhabricatorOAuthDefaultRegistrationController' => 'PhabricatorOAuthRegistrationController',
'PhabricatorOAuthDiagnosticsController' => 'PhabricatorAuthController',
'PhabricatorOAuthFailureView' => 'AphrontView',
'PhabricatorOAuthLoginController' => 'PhabricatorAuthController',
'PhabricatorOAuthProviderFacebook' => 'PhabricatorOAuthProvider',
'PhabricatorOAuthProviderGitHub' => 'PhabricatorOAuthProvider',
'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',
'PhabricatorOAuthServerClientQuery' => 'PhabricatorOffsetPagedQuery',
'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',
'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',
'PhabricatorOAuthUnlinkController' => 'PhabricatorAuthController',
'PhabricatorObjectGraph' => 'AbstractDirectedGraph',
'PhabricatorObjectHandleStatus' => 'PhabricatorObjectHandleConstants',
'PhabricatorOffsetPagedQuery' => 'PhabricatorQuery',
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',
'PhabricatorOwnersPackage' => 'PhabricatorOwnersDAO',
'PhabricatorOwnersPath' => 'PhabricatorOwnersDAO',
2011-01-23 06:09:13 +01:00
'PhabricatorPHID' => 'PhabricatorPHIDDAO',
'PhabricatorPHIDController' => 'PhabricatorController',
'PhabricatorPHIDDAO' => 'PhabricatorLiskDAO',
2011-01-26 18:02:09 +01:00
'PhabricatorPHIDLookupController' => 'PhabricatorPHIDController',
'PhabricatorPaste' => 'PhabricatorPasteDAO',
'PhabricatorPasteController' => 'PhabricatorController',
'PhabricatorPasteDAO' => 'PhabricatorLiskDAO',
'PhabricatorPasteListController' => 'PhabricatorPasteController',
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
'PhabricatorPasteQuery' => 'PhabricatorIDPagedPolicyQuery',
'PhabricatorPasteViewController' => 'PhabricatorPasteController',
2011-01-24 03:09:16 +01:00
'PhabricatorPeopleController' => 'PhabricatorController',
'PhabricatorPeopleEditController' => 'PhabricatorPeopleController',
'PhabricatorPeopleListController' => 'PhabricatorPeopleController',
'PhabricatorPeopleLogsController' => 'PhabricatorPeopleController',
2011-01-24 03:09:16 +01:00
'PhabricatorPeopleProfileController' => 'PhabricatorPeopleController',
Add basic per-object privacy policies Summary: Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change. Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request. The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens. We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can. Test Plan: Unit tests, played around in the UI with various policy settings. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
'PhabricatorPolicies' => 'PhabricatorPolicyConstants',
'PhabricatorPolicyCapability' => 'PhabricatorPolicyConstants',
'PhabricatorPolicyQuery' => 'PhabricatorQuery',
'PhabricatorPolicyTestCase' => 'PhabricatorTestCase',
'PhabricatorPolicyTestQuery' => 'PhabricatorPolicyQuery',
'PhabricatorProfileHeaderView' => 'AphrontView',
'PhabricatorProject' => 'PhabricatorProjectDAO',
'PhabricatorProjectAffiliation' => 'PhabricatorProjectDAO',
'PhabricatorProjectController' => 'PhabricatorController',
'PhabricatorProjectCreateController' => 'PhabricatorProjectController',
'PhabricatorProjectDAO' => 'PhabricatorLiskDAO',
'PhabricatorProjectListController' => 'PhabricatorProjectController',
'PhabricatorProjectProfile' => 'PhabricatorProjectDAO',
'PhabricatorProjectProfileController' => 'PhabricatorProjectController',
'PhabricatorProjectProfileEditController' => 'PhabricatorProjectController',
'PhabricatorProjectSubproject' => 'PhabricatorProjectDAO',
'PhabricatorProjectTransaction' => 'PhabricatorProjectDAO',
'PhabricatorProjectTransactionType' => 'PhabricatorProjectConstants',
'PhabricatorProjectUpdateController' => 'PhabricatorProjectController',
'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',
'PhabricatorRemarkupRuleDifferential' => 'PhabricatorRemarkupRuleObjectName',
'PhabricatorRemarkupRuleDifferentialHandle' => 'PhabricatorRemarkupRuleObjectHandle',
2011-04-11 12:02:19 +02:00
'PhabricatorRemarkupRuleDiffusion' => 'PhutilRemarkupRule',
'PhabricatorRemarkupRuleEmbedFile' => 'PhutilRemarkupRule',
'PhabricatorRemarkupRuleImageMacro' => 'PhutilRemarkupRule',
'PhabricatorRemarkupRuleManiphest' => 'PhabricatorRemarkupRuleObjectName',
'PhabricatorRemarkupRuleManiphestHandle' => 'PhabricatorRemarkupRuleObjectHandle',
'PhabricatorRemarkupRuleMention' => 'PhutilRemarkupRule',
'PhabricatorRemarkupRuleObjectHandle' => 'PhutilRemarkupRule',
'PhabricatorRemarkupRuleObjectName' => 'PhutilRemarkupRule',
'PhabricatorRemarkupRulePaste' => 'PhabricatorRemarkupRuleObjectName',
'PhabricatorRemarkupRulePhriction' => 'PhutilRemarkupRule',
'PhabricatorRemarkupRuleProxyImage' => 'PhutilRemarkupRule',
'PhabricatorRemarkupRuleYoutube' => 'PhutilRemarkupRule',
'PhabricatorRepository' => 'PhabricatorRepositoryDAO',
'PhabricatorRepositoryArcanistProject' => 'PhabricatorRepositoryDAO',
'PhabricatorRepositoryArcanistProjectEditController' => 'PhabricatorRepositoryController',
'PhabricatorRepositoryAuditRequest' => 'PhabricatorRepositoryDAO',
'PhabricatorRepositoryCommit' => 'PhabricatorRepositoryDAO',
'PhabricatorRepositoryCommitChangeParserWorker' => 'PhabricatorRepositoryCommitParserWorker',
'PhabricatorRepositoryCommitData' => 'PhabricatorRepositoryDAO',
'PhabricatorRepositoryCommitDiscoveryDaemon' => 'PhabricatorRepositoryDaemon',
'PhabricatorRepositoryCommitHeraldWorker' => 'PhabricatorRepositoryCommitParserWorker',
'PhabricatorRepositoryCommitMessageParserWorker' => 'PhabricatorRepositoryCommitParserWorker',
'PhabricatorRepositoryCommitOwnersWorker' => 'PhabricatorRepositoryCommitParserWorker',
'PhabricatorRepositoryCommitParserWorker' => 'PhabricatorWorker',
'PhabricatorRepositoryCommitTaskDaemon' => 'PhabricatorRepositoryDaemon',
'PhabricatorRepositoryController' => 'PhabricatorController',
'PhabricatorRepositoryCreateController' => 'PhabricatorRepositoryController',
'PhabricatorRepositoryDAO' => 'PhabricatorLiskDAO',
'PhabricatorRepositoryDaemon' => 'PhabricatorDaemon',
2011-04-02 02:11:05 +02:00
'PhabricatorRepositoryDefaultCommitMessageDetailParser' => 'PhabricatorRepositoryCommitMessageDetailParser',
'PhabricatorRepositoryDeleteController' => 'PhabricatorRepositoryController',
'PhabricatorRepositoryEditController' => 'PhabricatorRepositoryController',
'PhabricatorRepositoryGitCommitChangeParserWorker' => 'PhabricatorRepositoryCommitChangeParserWorker',
'PhabricatorRepositoryGitCommitDiscoveryDaemon' => 'PhabricatorRepositoryCommitDiscoveryDaemon',
'PhabricatorRepositoryGitCommitDiscoveryDaemonTestCase' => 'PhabricatorTestCase',
'PhabricatorRepositoryGitCommitMessageParserWorker' => 'PhabricatorRepositoryCommitMessageParserWorker',
'PhabricatorRepositoryGitFetchDaemon' => 'PhabricatorRepositoryPullLocalDaemon',
'PhabricatorRepositoryListController' => 'PhabricatorRepositoryController',
'PhabricatorRepositoryMercurialCommitChangeParserWorker' => 'PhabricatorRepositoryCommitChangeParserWorker',
Add a Mercurial commit discovery daemon Summary: Repository import has three major steps: - Commit discovery (serial) - Message parsing (parallel, mostly VCS independent) - Change parsing (parallel, highly VCS dependent) This implements commit discovery for Mercurial, similar to git's parsing: - List the heads of all the branches. - If we haven't already discovered them, follow them back to their roots (or the first commit we have discovered). - Import all the newly discovered commits, oldest first. This is a little complicated but it ensures we discover commits in depth order, so the discovery process is robust against interruption/failure. If we just inserted commits as we went, we might read the tip, insert it, and then crash. When we ran again, we'd think we had already discovered commits older than HEAD. This also allows later stages to rely on being able to find Phabricator commit IDs which correspond to parent commits. NOTE: This importer is fairly slow because "hg" has a large startup time (compare "hg --version" to "git --version" and "svn --version"; on my machine, hg has 60ms of overhead for any command) and we need to run many commands (see the whole "hg id" mess). You can expect something like 10,000 per hour, which means you may need to run overnight to discover a large repository (IIRC, the svn/git discovery processes are both about an order of magnitude faster). We could improve this with batching, but I want to keep it as simple as possible for now. Test Plan: Discovered all the commits in the main Mercurial repository, http://selenic.com/repo/hg. Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran Reviewed By: Makinde CC: aran, Makinde Differential Revision: 943
2011-09-16 12:56:23 +02:00
'PhabricatorRepositoryMercurialCommitDiscoveryDaemon' => 'PhabricatorRepositoryCommitDiscoveryDaemon',
'PhabricatorRepositoryMercurialCommitMessageParserWorker' => 'PhabricatorRepositoryCommitMessageParserWorker',
'PhabricatorRepositoryMercurialPullDaemon' => 'PhabricatorRepositoryPullLocalDaemon',
'PhabricatorRepositoryPullLocalDaemon' => 'PhabricatorRepositoryDaemon',
'PhabricatorRepositoryShortcut' => 'PhabricatorRepositoryDAO',
'PhabricatorRepositorySvnCommitChangeParserWorker' => 'PhabricatorRepositoryCommitChangeParserWorker',
'PhabricatorRepositorySvnCommitDiscoveryDaemon' => 'PhabricatorRepositoryCommitDiscoveryDaemon',
'PhabricatorRepositorySvnCommitMessageParserWorker' => 'PhabricatorRepositoryCommitMessageParserWorker',
'PhabricatorRepositorySymbol' => 'PhabricatorRepositoryDAO',
'PhabricatorRepositoryTestCase' => 'PhabricatorTestCase',
'PhabricatorS3FileStorageEngine' => 'PhabricatorFileStorageEngine',
'PhabricatorSearchAttachController' => 'PhabricatorSearchBaseController',
'PhabricatorSearchBaseController' => 'PhabricatorController',
'PhabricatorSearchCommitIndexer' => 'PhabricatorSearchDocumentIndexer',
'PhabricatorSearchController' => 'PhabricatorSearchBaseController',
'PhabricatorSearchDAO' => 'PhabricatorLiskDAO',
'PhabricatorSearchDifferentialIndexer' => 'PhabricatorSearchDocumentIndexer',
'PhabricatorSearchDocument' => 'PhabricatorSearchDAO',
'PhabricatorSearchDocumentField' => 'PhabricatorSearchDAO',
'PhabricatorSearchDocumentRelationship' => 'PhabricatorSearchDAO',
'PhabricatorSearchEngineElastic' => 'PhabricatorSearchEngine',
'PhabricatorSearchEngineMySQL' => 'PhabricatorSearchEngine',
'PhabricatorSearchIndexController' => 'PhabricatorSearchBaseController',
'PhabricatorSearchManiphestIndexer' => 'PhabricatorSearchDocumentIndexer',
'PhabricatorSearchPhrictionIndexer' => 'PhabricatorSearchDocumentIndexer',
'PhabricatorSearchQuery' => 'PhabricatorSearchDAO',
'PhabricatorSearchResultView' => 'AphrontView',
'PhabricatorSearchSelectController' => 'PhabricatorSearchBaseController',
'PhabricatorSearchUserIndexer' => 'PhabricatorSearchDocumentIndexer',
'PhabricatorSlowvoteChoice' => 'PhabricatorSlowvoteDAO',
'PhabricatorSlowvoteComment' => 'PhabricatorSlowvoteDAO',
'PhabricatorSlowvoteController' => 'PhabricatorController',
'PhabricatorSlowvoteCreateController' => 'PhabricatorSlowvoteController',
'PhabricatorSlowvoteDAO' => 'PhabricatorLiskDAO',
'PhabricatorSlowvoteListController' => 'PhabricatorSlowvoteController',
'PhabricatorSlowvoteOption' => 'PhabricatorSlowvoteDAO',
'PhabricatorSlowvotePoll' => 'PhabricatorSlowvoteDAO',
'PhabricatorSlowvotePollController' => 'PhabricatorSlowvoteController',
'PhabricatorSlugTestCase' => 'PhabricatorTestCase',
'PhabricatorSortTableExample' => 'PhabricatorUIExample',
2011-01-23 02:48:55 +01:00
'PhabricatorStandardPageView' => 'AphrontPageView',
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',
'PhabricatorSymbolNameLinter' => 'ArcanistXHPASTLintNamingHook',
'PhabricatorTaskmasterDaemon' => 'PhabricatorDaemon',
'PhabricatorTestCase' => 'ArcanistPhutilTestCase',
'PhabricatorTimelineCursor' => 'PhabricatorTimelineDAO',
'PhabricatorTimelineDAO' => 'PhabricatorLiskDAO',
'PhabricatorTimelineEvent' => 'PhabricatorTimelineDAO',
'PhabricatorTimelineEventData' => 'PhabricatorTimelineDAO',
'PhabricatorTimer' => 'PhabricatorCountdownDAO',
'PhabricatorTransactionView' => 'AphrontView',
'PhabricatorTransformedFile' => 'PhabricatorFileDAO',
'PhabricatorTrivialTestCase' => 'PhabricatorTestCase',
2011-01-25 22:48:05 +01:00
'PhabricatorTypeaheadCommonDatasourceController' => 'PhabricatorTypeaheadDatasourceController',
'PhabricatorTypeaheadDatasourceController' => 'PhabricatorController',
2011-04-01 02:06:33 +02:00
'PhabricatorUIExampleController' => 'PhabricatorController',
'PhabricatorUIExampleRenderController' => 'PhabricatorUIExampleController',
'PhabricatorUIListFilterExample' => 'PhabricatorUIExample',
2011-04-01 02:06:33 +02:00
'PhabricatorUIPagerExample' => 'PhabricatorUIExample',
'PhabricatorUITooltipExample' => 'PhabricatorUIExample',
'PhabricatorUnitsTestCase' => 'PhabricatorTestCase',
2011-01-24 03:09:16 +01:00
'PhabricatorUser' => 'PhabricatorUserDAO',
'PhabricatorUserAccountSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
'PhabricatorUserConduitSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
2011-01-24 03:09:16 +01:00
'PhabricatorUserDAO' => 'PhabricatorLiskDAO',
'PhabricatorUserEmailPreferenceSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
'PhabricatorUserEmailSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
'PhabricatorUserLog' => 'PhabricatorUserDAO',
'PhabricatorUserOAuthInfo' => 'PhabricatorUserDAO',
'PhabricatorUserOAuthSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
'PhabricatorUserPasswordSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
'PhabricatorUserPreferenceSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
'PhabricatorUserPreferences' => 'PhabricatorUserDAO',
'PhabricatorUserProfile' => 'PhabricatorUserDAO',
'PhabricatorUserProfileSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
'PhabricatorUserSSHKey' => 'PhabricatorUserDAO',
'PhabricatorUserSSHKeysSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
'PhabricatorUserSearchSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
2011-02-06 07:36:21 +01:00
'PhabricatorUserSettingsController' => 'PhabricatorPeopleController',
'PhabricatorUserSettingsPanelController' => 'PhabricatorPeopleController',
'PhabricatorUserStatus' => 'PhabricatorUserDAO',
'PhabricatorUserTestCase' => 'PhabricatorTestCase',
'PhabricatorWorkerDAO' => 'PhabricatorLiskDAO',
'PhabricatorWorkerTask' => 'PhabricatorWorkerDAO',
'PhabricatorWorkerTaskData' => 'PhabricatorWorkerDAO',
2011-03-27 07:55:18 +02:00
'PhabricatorWorkerTaskDetailController' => 'PhabricatorDaemonController',
'PhabricatorWorkerTaskUpdateController' => 'PhabricatorDaemonController',
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',
'PhabricatorXHProfProfileController' => 'PhabricatorXHProfController',
'PhabricatorXHProfProfileSymbolView' => 'PhabricatorXHProfProfileView',
'PhabricatorXHProfProfileTopLevelView' => 'PhabricatorXHProfProfileView',
'PhabricatorXHProfProfileView' => 'AphrontView',
'PhameController' => 'PhabricatorController',
'PhameDAO' => 'PhabricatorLiskDAO',
'PhameDraftListController' => 'PhamePostListBaseController',
'PhamePost' => 'PhameDAO',
'PhamePostDeleteController' => 'PhameController',
'PhamePostDetailView' => 'AphrontView',
'PhamePostEditController' => 'PhameController',
'PhamePostListBaseController' => 'PhameController',
'PhamePostListController' => 'PhamePostListBaseController',
'PhamePostListView' => 'AphrontView',
'PhamePostPreviewController' => 'PhameController',
'PhamePostQuery' => 'PhabricatorOffsetPagedQuery',
'PhamePostViewController' => 'PhameController',
'PhortuneMonthYearExpiryControl' => 'AphrontFormControl',
'PhortuneStripeBaseController' => 'PhabricatorController',
'PhortuneStripePaymentFormView' => 'AphrontView',
'PhortuneStripeTestPaymentFormController' => 'PhortuneStripeBaseController',
'PhrictionActionConstants' => 'PhrictionConstants',
'PhrictionChangeType' => 'PhrictionConstants',
'PhrictionContent' => 'PhrictionDAO',
'PhrictionController' => 'PhabricatorController',
'PhrictionDAO' => 'PhabricatorLiskDAO',
'PhrictionDeleteController' => 'PhrictionController',
'PhrictionDiffController' => 'PhrictionController',
'PhrictionDocument' => 'PhrictionDAO',
'PhrictionDocumentController' => 'PhrictionController',
'PhrictionDocumentPreviewController' => 'PhrictionController',
'PhrictionDocumentStatus' => 'PhrictionConstants',
'PhrictionDocumentTestCase' => 'PhabricatorTestCase',
'PhrictionEditController' => 'PhrictionController',
'PhrictionHistoryController' => 'PhrictionController',
'PhrictionListController' => 'PhrictionController',
'QueryFormattingTestCase' => 'PhabricatorTestCase',
),
'requires_interface' =>
array(
'DefaultDatabaseConfigurationProvider' =>
array(
0 => 'DatabaseConfigurationProvider',
),
'DifferentialInlineComment' =>
array(
0 => 'PhabricatorInlineCommentInterface',
),
'PhabricatorAuditInlineComment' =>
array(
0 => 'PhabricatorInlineCommentInterface',
),
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
'PhabricatorPaste' =>
array(
0 => 'PhabricatorPolicyInterface',
),
'PhabricatorPolicyTestObject' =>
array(
0 => 'PhabricatorPolicyInterface',
),
),
));