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

3797 lines
300 KiB
PHP
Raw Normal View History

Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
<?php
/**
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
* This file is automatically generated. Use 'arc liberate' to rebuild it.
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
* @generated
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
* @phutil-library-version 2
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
*/
phutil_register_library_map(array(
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'__library_version__' => 2,
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'class' =>
array(
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'Aphront304Response' => 'aphront/response/Aphront304Response.php',
'Aphront400Response' => 'aphront/response/Aphront400Response.php',
'Aphront403Response' => 'aphront/response/Aphront403Response.php',
'Aphront404Response' => 'aphront/response/Aphront404Response.php',
'AphrontAjaxResponse' => 'aphront/response/AphrontAjaxResponse.php',
Move some aprhont/ stuff around a little bit Summary: "configuration/default" moved to "default". Rename it to "configuration" and put config stuff back there. Put writeguard into writeguard/. Test Plan: tools Reviewers: vrana Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2639
2012-06-01 21:46:28 +02:00
'AphrontApplicationConfiguration' => 'aphront/configuration/AphrontApplicationConfiguration.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontAttachedFileView' => 'view/control/AphrontAttachedFileView.php',
AphrontBars Summary: Aphront widgets that render the either a discrete or continuous value as a horizontal shape. Like a progress bar, or a five-star rating bar. Test Plan: `/uiexample/view/PhabricatorAphrontBarExample/` ...which shows this, amongst other things: {F33898} Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5122
2013-03-05 17:46:09 +01:00
'AphrontBarView' => 'view/widget/bars/AphrontBarView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontCSRFException' => 'aphront/exception/AphrontCSRFException.php',
'AphrontCalendarEventView' => 'applications/calendar/view/AphrontCalendarEventView.php',
'AphrontCalendarMonthView' => 'applications/calendar/view/AphrontCalendarMonthView.php',
'AphrontContextBarView' => 'view/layout/AphrontContextBarView.php',
'AphrontController' => 'aphront/AphrontController.php',
Rename "IDPaged" to "CursorPaged", "executeWithPager" to "executeWith[Cursor|Offset]Pager" Summary: I'm trying to make progress on the policy/visibility stuff since it's a blocker for Wikimedia. First, I want to improve Projects so they can serve as policy groups (e.g., an object can have a visibility policy like "Visible to: members of project 'security'"). However, doing this without breaking anything or snowballing into a bigger change is a bit awkward because Projects are name-ordered and we have a Conduit API which does offset paging. Rather than breaking or rewriting this stuff, I want to just continue offset paging them for now. So I'm going to make PhabricatorPolicyQuery extend PhabricatorOffsetPagedQuery, but can't currently since the `executeWithPager` methods would clash. These methods do different things anyway and are probably better with different names. This also generally improves the names of these classes, since cursors are not necessarily IDs (in the feed case, they're "chronlogicalKeys", for example). I did leave some of the interals as "ID" since calling them "Cursor"s (e.g., `setAfterCursor()`) seemed a little wrong -- it should maybe be `setAfterCursorPosition()`. These APIs have very limited use and can easily be made more consistent later. Test Plan: Browsed around various affected tools; any issues here should throw/fail in a loud/obvious way. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3177
2012-08-07 20:54:06 +02:00
'AphrontCursorPagerView' => 'view/control/AphrontCursorPagerView.php',
Move some aprhont/ stuff around a little bit Summary: "configuration/default" moved to "default". Rename it to "configuration" and put config stuff back there. Put writeguard into writeguard/. Test Plan: tools Reviewers: vrana Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2639
2012-06-01 21:46:28 +02:00
'AphrontDefaultApplicationConfiguration' => 'aphront/configuration/AphrontDefaultApplicationConfiguration.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontDialogResponse' => 'aphront/response/AphrontDialogResponse.php',
'AphrontDialogView' => 'view/AphrontDialogView.php',
'AphrontErrorView' => 'view/form/AphrontErrorView.php',
'AphrontException' => 'aphront/exception/AphrontException.php',
'AphrontFileResponse' => 'aphront/response/AphrontFileResponse.php',
'AphrontFormCheckboxControl' => 'view/form/control/AphrontFormCheckboxControl.php',
'AphrontFormControl' => 'view/form/control/AphrontFormControl.php',
AphrontFormCountedToggleButtonsControl Summary: Like AphrontFormToggleButtonsControl, but with mouseover counters. These counters let you know how many of each thing there are in each category, which is useful when using this control for filtering a list of things in multiple dimensions. Test Plan: `/uiexample/view/PhabricatorCountedToggleButtonsExample/` Reviewers: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5118
2013-02-26 17:20:14 +01:00
'AphrontFormCountedToggleButtonsControl' => 'view/form/control/AphrontFormCountedToggleButtonsControl.php',
Conpherence - add crop Summary: mainly, this adds the image cropper - yay! - also removes the file image from the handle stuff I added in V1. now we do all this crazy photo stuff. Test Plan: - uploaded a photo by dragging to header and noted 120 x 80 showed up on reload - uploaded a photo by dragging to edit dialogue spot and noted 120 x 80 showed up on reload - cropped a photo - noted it cropped right - cropped a photo again and again and again - seems like it crops okay Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2418, T2399 Differential Revision: https://secure.phabricator.com/D4790
2013-02-06 23:03:52 +01:00
'AphrontFormCropControl' => 'view/form/control/AphrontFormCropControl.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontFormDateControl' => 'view/form/control/AphrontFormDateControl.php',
'AphrontFormDividerControl' => 'view/form/control/AphrontFormDividerControl.php',
'AphrontFormDragAndDropUploadControl' => 'view/form/control/AphrontFormDragAndDropUploadControl.php',
'AphrontFormFileControl' => 'view/form/control/AphrontFormFileControl.php',
Robustify profile image controls ever so slightly Summary: show project profile image on pertinent edit page. also add a "Use Default Image" checkbox for both project and user profiles. Also added a function for projects to get the profile picture to prevent some copy + paste action. Test Plan: set my user profile and project profile image. clicked "Use Default Image" and got the default image back. Reviewers: epriestley, floatinglomas Reviewed By: floatinglomas CC: aran, Korvin Maniphest Tasks: T1307 Differential Revision: https://secure.phabricator.com/D2852
2012-06-26 17:14:15 +02:00
'AphrontFormImageControl' => 'view/form/control/AphrontFormImageControl.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontFormInsetView' => 'view/form/AphrontFormInsetView.php',
'AphrontFormLayoutView' => 'view/form/AphrontFormLayoutView.php',
'AphrontFormMarkupControl' => 'view/form/control/AphrontFormMarkupControl.php',
'AphrontFormPasswordControl' => 'view/form/control/AphrontFormPasswordControl.php',
'AphrontFormPolicyControl' => 'view/form/control/AphrontFormPolicyControl.php',
'AphrontFormRadioButtonControl' => 'view/form/control/AphrontFormRadioButtonControl.php',
'AphrontFormRecaptchaControl' => 'view/form/control/AphrontFormRecaptchaControl.php',
'AphrontFormSelectControl' => 'view/form/control/AphrontFormSelectControl.php',
'AphrontFormStaticControl' => 'view/form/control/AphrontFormStaticControl.php',
'AphrontFormSubmitControl' => 'view/form/control/AphrontFormSubmitControl.php',
'AphrontFormTextAreaControl' => 'view/form/control/AphrontFormTextAreaControl.php',
'AphrontFormTextControl' => 'view/form/control/AphrontFormTextControl.php',
'AphrontFormToggleButtonsControl' => 'view/form/control/AphrontFormToggleButtonsControl.php',
'AphrontFormTokenizerControl' => 'view/form/control/AphrontFormTokenizerControl.php',
'AphrontFormView' => 'view/form/AphrontFormView.php',
AphrontBars Summary: Aphront widgets that render the either a discrete or continuous value as a horizontal shape. Like a progress bar, or a five-star rating bar. Test Plan: `/uiexample/view/PhabricatorAphrontBarExample/` ...which shows this, amongst other things: {F33898} Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5122
2013-03-05 17:46:09 +01:00
'AphrontGlyphBarView' => 'view/widget/bars/AphrontGlyphBarView.php',
Make webpage response final
2012-11-29 08:57:13 +01:00
'AphrontHTMLResponse' => 'aphront/response/AphrontHTMLResponse.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontHTTPSink' => 'aphront/sink/AphrontHTTPSink.php',
'AphrontHTTPSinkTestCase' => 'aphront/sink/__tests__/AphrontHTTPSinkTestCase.php',
Move qsprintf() test cases from libphutil to Phabricator Summary: Also move the other tests up so they'll trigger when this stuff is touched. Test Plan: liberate Reviewers: nh, btrahan, vrana Reviewed By: nh CC: aran Maniphest Tasks: T1283 Differential Revision: https://secure.phabricator.com/D3074
2012-07-26 21:01:47 +02:00
'AphrontIsolatedDatabaseConnectionTestCase' => 'infrastructure/storage/__tests__/AphrontIsolatedDatabaseConnectionTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontIsolatedHTTPSink' => 'aphront/sink/AphrontIsolatedHTTPSink.php',
'AphrontJSONResponse' => 'aphront/response/AphrontJSONResponse.php',
'AphrontJavelinView' => 'view/AphrontJavelinView.php',
'AphrontKeyboardShortcutsAvailableView' => 'view/widget/AphrontKeyboardShortcutsAvailableView.php',
'AphrontListFilterView' => 'view/layout/AphrontListFilterView.php',
'AphrontMiniPanelView' => 'view/layout/AphrontMiniPanelView.php',
'AphrontMoreView' => 'view/layout/AphrontMoreView.php',
Build an AphrontMultiColumnView, use on workboards. Summary: Abstract out the multi-column code from workboards and have it be available separately. I feel like there will be some benefit here especially for custom developers in how they present infromation (like releeph). It also scales back to tablet and mobile fairly well, so they get those things for free. Test Plan: Tested mobile, tablet and chrome layouts. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5529
2013-04-02 20:23:24 +02:00
'AphrontMultiColumnView' => 'view/layout/AphrontMultiColumnView.php',
Move qsprintf() test cases from libphutil to Phabricator Summary: Also move the other tests up so they'll trigger when this stuff is touched. Test Plan: liberate Reviewers: nh, btrahan, vrana Reviewed By: nh CC: aran Maniphest Tasks: T1283 Differential Revision: https://secure.phabricator.com/D3074
2012-07-26 21:01:47 +02:00
'AphrontMySQLDatabaseConnectionTestCase' => 'infrastructure/storage/__tests__/AphrontMySQLDatabaseConnectionTestCase.php',
Implement Maniphest auxiliary field 'default' key Summary: Fixes T404. Ref T2575. Allows default to be set for any field. Date defaults are interpreted by `strtotime()`. Other defaults are interpreted as expected. Test Plan: - Created a string custom field with default value "Orange". - Created a date custom field with a fixed default value (my birthday). - Created a date custom field with a relative default value ("today 4:59 PM"). - Created/edited tasks with these fields, verified everything behaved sensibly. Reviewers: hach-que, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T404, T2575 Differential Revision: https://secure.phabricator.com/D5282
2013-03-08 02:23:30 +01:00
'AphrontNoteView' => 'view/widget/AphrontNoteView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontNullView' => 'view/AphrontNullView.php',
'AphrontPHPHTTPSink' => 'aphront/sink/AphrontPHPHTTPSink.php',
'AphrontPageView' => 'view/page/AphrontPageView.php',
'AphrontPagerView' => 'view/control/AphrontPagerView.php',
'AphrontPanelView' => 'view/layout/AphrontPanelView.php',
'AphrontPlainTextResponse' => 'aphront/response/AphrontPlainTextResponse.php',
AphrontBars Summary: Aphront widgets that render the either a discrete or continuous value as a horizontal shape. Like a progress bar, or a five-star rating bar. Test Plan: `/uiexample/view/PhabricatorAphrontBarExample/` ...which shows this, amongst other things: {F33898} Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5122
2013-03-05 17:46:09 +01:00
'AphrontProgressBarView' => 'view/widget/bars/AphrontProgressBarView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontProxyResponse' => 'aphront/response/AphrontProxyResponse.php',
'AphrontRedirectException' => 'aphront/exception/AphrontRedirectException.php',
'AphrontRedirectResponse' => 'aphront/response/AphrontRedirectResponse.php',
'AphrontReloadResponse' => 'aphront/response/AphrontReloadResponse.php',
'AphrontRequest' => 'aphront/AphrontRequest.php',
'AphrontRequestFailureView' => 'view/page/AphrontRequestFailureView.php',
'AphrontRequestTestCase' => 'aphront/__tests__/AphrontRequestTestCase.php',
'AphrontResponse' => 'aphront/response/AphrontResponse.php',
'AphrontSideNavFilterView' => 'view/layout/AphrontSideNavFilterView.php',
'AphrontTableView' => 'view/control/AphrontTableView.php',
Genericize implementing views which expose common attributes Summary: Some views expose some/most/all of the basics (id, class, sigil, metadata, etc); let them extend a dedicated view to get it for free. Test Plan: Viewed home page, paste, mobile dropdown, etc. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D4440
2013-01-16 19:50:41 +01:00
'AphrontTagView' => 'view/AphrontTagView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontTokenizerTemplateView' => 'view/control/AphrontTokenizerTemplateView.php',
Apront Two Column View Summary: Wanted to pull this out in case we don't use it in Maniphest, still useful perhaps in the future. Creates a sidebar that wraps when on mobile. Test Plan: Tested UIExample Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5321
2013-03-11 03:20:01 +01:00
'AphrontTwoColumnView' => 'view/layout/AphrontTwoColumnView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontTypeaheadTemplateView' => 'view/control/AphrontTypeaheadTemplateView.php',
'AphrontURIMapper' => 'aphront/AphrontURIMapper.php',
'AphrontUsageException' => 'aphront/exception/AphrontUsageException.php',
'AphrontView' => 'view/AphrontView.php',
'AphrontWebpageResponse' => 'aphront/response/AphrontWebpageResponse.php',
Update PeopleMenu to only show integration with applications if they are installed Summary: do so via event engine. note different order now... Test Plan: toggled "show beta applications" to off and noted that Conpherence disappeared. Otherwise noted that links showed. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2424 Differential Revision: https://secure.phabricator.com/D4708
2013-02-05 22:46:02 +01:00
'AuditPeopleMenuEventListener' => 'applications/audit/events/AuditPeopleMenuEventListener.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'CelerityAPI' => 'infrastructure/celerity/CelerityAPI.php',
Allow blog resources to be served without Celerity Summary: Allow skins to serve arbitrary resources without needing to be mapped, so we can have a vibrant community of amateur skinners. For "basic" skins, just put all the "css/" on the page always. Includes an image to prove that works. @vrana, pretty sure this has no impact outside of Phame but it does change Celerity so it might be to blame if there's any weirdness with static resources. Test Plan: {F21341} {F21340} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3719
2012-10-17 17:37:05 +02:00
'CelerityPhabricatorResourceController' => 'infrastructure/celerity/CelerityPhabricatorResourceController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'CelerityResourceController' => 'infrastructure/celerity/CelerityResourceController.php',
'CelerityResourceGraph' => 'infrastructure/celerity/CelerityResourceGraph.php',
'CelerityResourceMap' => 'infrastructure/celerity/CelerityResourceMap.php',
'CelerityResourceTransformer' => 'infrastructure/celerity/CelerityResourceTransformer.php',
'CelerityResourceTransformerTestCase' => 'infrastructure/celerity/__tests__/CelerityResourceTransformerTestCase.php',
Move sprite sources from webroot/ to resources/ Summary: - Since we'll never serve these directly, move them to resources/. This makes generating the Celerity map faster and reduces the size of the result map, since we don't need to analyze resources we'll never serve. - Also Rename the 2x `subscribe-remove` to `subscribe-delete` since they were named inconsistently. Everything else is in good shape. Test Plan: Generated sprites as per D4025 Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2013 Differential Revision: https://secure.phabricator.com/D4026
2012-11-24 01:19:06 +01:00
'CeleritySpriteGenerator' => 'infrastructure/celerity/CeleritySpriteGenerator.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'CelerityStaticResourceResponse' => 'infrastructure/celerity/CelerityStaticResourceResponse.php',
'ConduitAPIMethod' => 'applications/conduit/method/ConduitAPIMethod.php',
'ConduitAPIRequest' => 'applications/conduit/protocol/ConduitAPIRequest.php',
'ConduitAPIResponse' => 'applications/conduit/protocol/ConduitAPIResponse.php',
Move Conduit methods inside applications Test Plan: /conduit/ /conduit/method/arcanist.projectinfo/ Call method $ echo '{}' | arc call-conduit user.whoami Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4268
2012-12-21 21:12:26 +01:00
'ConduitAPI_arcanist_Method' => 'applications/arcanist/conduit/ConduitAPI_arcanist_Method.php',
'ConduitAPI_arcanist_projectinfo_Method' => 'applications/arcanist/conduit/ConduitAPI_arcanist_projectinfo_Method.php',
'ConduitAPI_audit_Method' => 'applications/audit/conduit/ConduitAPI_audit_Method.php',
'ConduitAPI_audit_query_Method' => 'applications/audit/conduit/ConduitAPI_audit_query_Method.php',
'ConduitAPI_chatlog_Method' => 'applications/chatlog/conduit/ConduitAPI_chatlog_Method.php',
'ConduitAPI_chatlog_query_Method' => 'applications/chatlog/conduit/ConduitAPI_chatlog_query_Method.php',
'ConduitAPI_chatlog_record_Method' => 'applications/chatlog/conduit/ConduitAPI_chatlog_record_Method.php',
'ConduitAPI_conduit_connect_Method' => 'applications/conduit/method/ConduitAPI_conduit_connect_Method.php',
'ConduitAPI_conduit_getcertificate_Method' => 'applications/conduit/method/ConduitAPI_conduit_getcertificate_Method.php',
'ConduitAPI_conduit_ping_Method' => 'applications/conduit/method/ConduitAPI_conduit_ping_Method.php',
Adding the Conduit query method. Summary: T2154 Adding the Conduit query method implementation, and metadata to the phutil register library. Test Plan: Choose conduit.query on the web UI to see information about the method. Then, click the "Call Method" button and observe the method result. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4550
2013-01-20 01:37:06 +01:00
'ConduitAPI_conduit_query_Method' => 'applications/conduit/method/ConduitAPI_conduit_query_Method.php',
Conpherence - add createthread method Summary: Ref T3166. I moved the create logic into a static method in the editor class to keep things tidy. Test Plan: created a conpherence from UI. purdy. tried errors and got UI to show "required". for conduit, created a thread with all the bells and whistles and it worked. verified i got proper exceptions with bum conduit calls Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3166 Differential Revision: https://secure.phabricator.com/D6083
2013-05-31 01:37:51 +02:00
'ConduitAPI_conpherence_Method' => 'applications/conpherence/conduit/ConduitAPI_conpherence_Method.php',
'ConduitAPI_conpherence_createthread_Method' => 'applications/conpherence/conduit/ConduitAPI_conpherence_createthread_Method.php',
Conpherence - add querythead conduit method Summary: nice title. also adds a description to the create thread method which I forgot to add... Ref T3166. Test Plan: queried threads by ids, by phids, and by offset / limit tweakage. Got the right stuff! Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3166 Differential Revision: https://secure.phabricator.com/D6096
2013-05-31 19:43:46 +02:00
'ConduitAPI_conpherence_querythread_Method' => 'applications/conpherence/conduit/ConduitAPI_conpherence_querythread_Method.php',
Conpherence - add querytransaction method Summary: Ref T3166. Returned all the data I could think of, though notable "metadata" isn't used in conpherence (yet afaik) AND its somewhat silly to return the conpherence id / phid you specified, but seems handy. Test Plan: played with conduit console. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3166 Differential Revision: https://secure.phabricator.com/D6098
2013-05-31 20:27:49 +02:00
'ConduitAPI_conpherence_querytransaction_Method' => 'applications/conpherence/conduit/ConduitAPI_conpherence_querytransaction_Method.php',
Conpherence - add an updatethread conduit method Summary: Last of the methods. Fixes T3166. Test Plan: updated a thread in all the various ways except remove and it worked. removed myself and it worked! tried to remove someone else and it yelled at me. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3166 Differential Revision: https://secure.phabricator.com/D6103
2013-05-31 23:58:02 +02:00
'ConduitAPI_conpherence_updatethread_Method' => 'applications/conpherence/conduit/ConduitAPI_conpherence_updatethread_Method.php',
Move Conduit methods inside applications Test Plan: /conduit/ /conduit/method/arcanist.projectinfo/ Call method $ echo '{}' | arc call-conduit user.whoami Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4268
2012-12-21 21:12:26 +01:00
'ConduitAPI_daemon_launched_Method' => 'applications/daemon/conduit/ConduitAPI_daemon_launched_Method.php',
'ConduitAPI_daemon_log_Method' => 'applications/daemon/conduit/ConduitAPI_daemon_log_Method.php',
'ConduitAPI_daemon_setstatus_Method' => 'applications/daemon/conduit/ConduitAPI_daemon_setstatus_Method.php',
'ConduitAPI_differential_Method' => 'applications/differential/conduit/ConduitAPI_differential_Method.php',
'ConduitAPI_differential_close_Method' => 'applications/differential/conduit/ConduitAPI_differential_close_Method.php',
'ConduitAPI_differential_createcomment_Method' => 'applications/differential/conduit/ConduitAPI_differential_createcomment_Method.php',
'ConduitAPI_differential_creatediff_Method' => 'applications/differential/conduit/ConduitAPI_differential_creatediff_Method.php',
'ConduitAPI_differential_createinline_Method' => 'applications/differential/conduit/ConduitAPI_differential_createinline_Method.php',
'ConduitAPI_differential_createrawdiff_Method' => 'applications/differential/conduit/ConduitAPI_differential_createrawdiff_Method.php',
'ConduitAPI_differential_createrevision_Method' => 'applications/differential/conduit/ConduitAPI_differential_createrevision_Method.php',
'ConduitAPI_differential_find_Method' => 'applications/differential/conduit/ConduitAPI_differential_find_Method.php',
'ConduitAPI_differential_finishpostponedlinters_Method' => 'applications/differential/conduit/ConduitAPI_differential_finishpostponedlinters_Method.php',
'ConduitAPI_differential_getalldiffs_Method' => 'applications/differential/conduit/ConduitAPI_differential_getalldiffs_Method.php',
'ConduitAPI_differential_getcommitmessage_Method' => 'applications/differential/conduit/ConduitAPI_differential_getcommitmessage_Method.php',
'ConduitAPI_differential_getcommitpaths_Method' => 'applications/differential/conduit/ConduitAPI_differential_getcommitpaths_Method.php',
'ConduitAPI_differential_getdiff_Method' => 'applications/differential/conduit/ConduitAPI_differential_getdiff_Method.php',
'ConduitAPI_differential_getrevision_Method' => 'applications/differential/conduit/ConduitAPI_differential_getrevision_Method.php',
'ConduitAPI_differential_getrevisioncomments_Method' => 'applications/differential/conduit/ConduitAPI_differential_getrevisioncomments_Method.php',
'ConduitAPI_differential_getrevisionfeedback_Method' => 'applications/differential/conduit/ConduitAPI_differential_getrevisionfeedback_Method.php',
'ConduitAPI_differential_markcommitted_Method' => 'applications/differential/conduit/ConduitAPI_differential_markcommitted_Method.php',
'ConduitAPI_differential_parsecommitmessage_Method' => 'applications/differential/conduit/ConduitAPI_differential_parsecommitmessage_Method.php',
'ConduitAPI_differential_query_Method' => 'applications/differential/conduit/ConduitAPI_differential_query_Method.php',
'ConduitAPI_differential_setdiffproperty_Method' => 'applications/differential/conduit/ConduitAPI_differential_setdiffproperty_Method.php',
'ConduitAPI_differential_updaterevision_Method' => 'applications/differential/conduit/ConduitAPI_differential_updaterevision_Method.php',
'ConduitAPI_differential_updateunitresults_Method' => 'applications/differential/conduit/ConduitAPI_differential_updateunitresults_Method.php',
Uninstall Conduit calls when uninstalling applications Summary: Fixes T2698. When applications are installed, their Conduit calls should drop out. This will also let us land Releeph without exposing Conduit calls. Test Plan: - Viewed Conduit console; uninstalled some applications and verified their calls dropped out. - Tried to make an uninstalled call; got an appropriate error. Reviewers: edward, btrahan Reviewed By: edward CC: aran Maniphest Tasks: T2698 Differential Revision: https://secure.phabricator.com/D5302
2013-03-13 15:09:05 +01:00
'ConduitAPI_diffusion_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_Method.php',
Diffusion - move DiffusionExistsQuery to work over conduit Summary: le title. However, this also "is the first" conversion so sets the precedence for how this will all work. See comments in the code. I think this helps us keep the new code we're writing to a minimum. Wondering if the conduit end point could be more generic, and rather than have a switch statement on VCS type, one can just implement the "handleSubversion" version and have that called? Ref T2784 Test Plan: slapped an "or true" in the conditional protecting this code path. verified it worked on all 3 vcs systems, including typing in garbage and getting a 404 Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5803
2013-05-01 23:44:28 +02:00
'ConduitAPI_diffusion_abstractquery_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_abstractquery_Method.php',
DiffusionBranchQuery => Conduit Summary: ref T2784. This one had a few fun spots where I had to move data around. Also, is there some common object (or should I add it?) that can do this toDictionary newFromConduit stuff? Also, this assumes D5803 is largely correct at the time of this diff. Test Plan: browsed mercurial and git repository page. saw the branches i expected. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5810
2013-05-01 23:56:36 +02:00
'ConduitAPI_diffusion_branchquery_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_branchquery_Method.php',
Diffusion - move DiffusionBrowseQuery => Conduit Summary: see title. Ref T2784. Test Plan: In diffusion, for each of SVN, Mercurial, and Git, I loaded up /diffusion/CALLSIGN/. I verified the README was displayed and things looked good. Next I clicked on "browse" on the top-most commit and verified things looked correct. Also clicked through to a file for a good measure and things looked good. In owners, for each of SVN, Mercurial, and Git, I played around with the path typeahead / validator. It worked correctly! Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5883
2013-05-10 20:02:58 +02:00
'ConduitAPI_diffusion_browsequery_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_browsequery_Method.php',
Diffusion - move commit branches query to conduit Summary: Ref T2784. Test Plan: loaded up a mercurial and a git commit. verified branches showed up correctly in object detail panel Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5958
2013-05-18 01:54:10 +02:00
'ConduitAPI_diffusion_commitbranchesquery_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_commitbranchesquery_Method.php',
Diffusion - move commit parents query to conduit Summary: Ref T2784. Relatively complicated one as this bad boy is used in a repository daemon. While testing, I noticed bugs in the expandshortname query stuff. Those variables are private to the parent class so they need some setX love. Also, was unable to find links to the "before" stuff, but made them by hand by looking at some of these T2784 diffs, browsing a file at a specific revision, then hacking the "before" variable to be some known commit that also touched the file. This produced sensical results. On the process of doing that I upgraded a query to use the proper policy query. Test Plan: In git, mercurial, svn, verified on a commit page the "parents" showed up correctly. played around with ?before parameter on specific file browse page, with commits known to have interesting history and stuff looked good Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5988
2013-05-22 01:22:49 +02:00
'ConduitAPI_diffusion_commitparentsquery_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_commitparentsquery_Method.php',
Diffusion - move DiffQuery to Conduit Summary: title does not say it all; also added conduit wrappers for rawdiffquery and lastmodifiedquery. These get the wrapper treatment since they are used in daemons. Ref T2784. Test Plan: for each of the 3 VCS, did the following: 1) loaded up CALLSIGN and verified 'Modified' column data showed up correctly in Browse Repository box. 2) loaded up the "change" view for a specific file and verified content showed up correctly. 3) loaded up a specific commit and noted the changes ajax loaded A-OK Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5896
2013-05-14 22:53:32 +02:00
'ConduitAPI_diffusion_diffquery_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_diffquery_Method.php',
Diffusion - move DiffusionExistsQuery to work over conduit Summary: le title. However, this also "is the first" conversion so sets the precedence for how this will all work. See comments in the code. I think this helps us keep the new code we're writing to a minimum. Wondering if the conduit end point could be more generic, and rather than have a switch statement on VCS type, one can just implement the "handleSubversion" version and have that called? Ref T2784 Test Plan: slapped an "or true" in the conditional protecting this code path. verified it worked on all 3 vcs systems, including typing in garbage and getting a 404 Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5803
2013-05-01 23:44:28 +02:00
'ConduitAPI_diffusion_existsquery_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_existsquery_Method.php',
Diffusion - move some DiffusionRequest queries to occur over Conduit Summary: Ref T2784. This one was a wee bit complicated. Had to add PhabricatorUser and concept of initFromConduit (or not) to DiffusionRequest. Test Plan: foreach repo, visited CALLSIGN and clicked a commit and verified they laoded correctly. Hacked code to hit NOT via Conduit and repeated tests to great success. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5928
2013-05-15 00:32:19 +02:00
'ConduitAPI_diffusion_expandshortcommitquery_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_expandshortcommitquery_Method.php',
DiffusionFileContentQuery => Conduit Summary: Ref T2784. This is probably pretty good except the fancy lint error saver now issue serial queries via Conduit. Test Plan: reparsed commits on 3 repos - yay. viewed readme from diffusion UI on 3 repos - yay. viewed file content from diffusion UI on 3 repos - yay. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5824
2013-05-07 23:57:08 +02:00
'ConduitAPI_diffusion_filecontentquery_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_filecontentquery_Method.php',
Move Conduit methods inside applications Test Plan: /conduit/ /conduit/method/arcanist.projectinfo/ Call method $ echo '{}' | arc call-conduit user.whoami Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4268
2012-12-21 21:12:26 +01:00
'ConduitAPI_diffusion_findsymbols_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_findsymbols_Method.php',
'ConduitAPI_diffusion_getcommits_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_getcommits_Method.php',
'ConduitAPI_diffusion_getlintmessages_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_getlintmessages_Method.php',
'ConduitAPI_diffusion_getrecentcommitsbypath_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_getrecentcommitsbypath_Method.php',
Diffusion - move history query to conduit Summary: Ref T2784 Test Plan: for each flavor of VCS, I loaded up the repository home page. verified I saw some parent action where appropos. next, clicked through to 'view history' and verified it loaded up A-OK. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5960
2013-05-20 21:45:34 +02:00
'ConduitAPI_diffusion_historyquery_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_historyquery_Method.php',
Diffusion - move DiffQuery to Conduit Summary: title does not say it all; also added conduit wrappers for rawdiffquery and lastmodifiedquery. These get the wrapper treatment since they are used in daemons. Ref T2784. Test Plan: for each of the 3 VCS, did the following: 1) loaded up CALLSIGN and verified 'Modified' column data showed up correctly in Browse Repository box. 2) loaded up the "change" view for a specific file and verified content showed up correctly. 3) loaded up a specific commit and noted the changes ajax loaded A-OK Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5896
2013-05-14 22:53:32 +02:00
'ConduitAPI_diffusion_lastmodifiedquery_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_lastmodifiedquery_Method.php',
Diffusion - move merged commits query to happen over conduit. Summary: Ref T2784. Also sneaks in a fix for branch query -- forgot to catch the unsupported VCS exception. One strange thing is I have test Phabricator repositories and the mercurial one is showing different data than git for the same commit. The data shown is consistent pre and post this diff though so its an existing issue. Also note the mercurial is an import of git so maybe its busted-ish? Test Plan: viewed commits in mercurial, svn, and git that were merge commits. saw the right stuff in mercurial and git. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5985
2013-05-21 02:04:51 +02:00
'ConduitAPI_diffusion_mergedcommitsquery_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_mergedcommitsquery_Method.php',
Diffusion - move DiffQuery to Conduit Summary: title does not say it all; also added conduit wrappers for rawdiffquery and lastmodifiedquery. These get the wrapper treatment since they are used in daemons. Ref T2784. Test Plan: for each of the 3 VCS, did the following: 1) loaded up CALLSIGN and verified 'Modified' column data showed up correctly in Browse Repository box. 2) loaded up the "change" view for a specific file and verified content showed up correctly. 3) loaded up a specific commit and noted the changes ajax loaded A-OK Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5896
2013-05-14 22:53:32 +02:00
'ConduitAPI_diffusion_rawdiffquery_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_rawdiffquery_Method.php',
Diffusion - break out readme query all on its own Summary: nice title. Ref T2784. Fixes T3171. Test Plan: For all 3 VCS types, viewed phabricator repository and saw readme. browsed said repository and saw readme. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784, T3171 Differential Revision: https://secure.phabricator.com/D5993
2013-05-21 22:47:06 +02:00
'ConduitAPI_diffusion_readmequery_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_readmequery_Method.php',
Diffusion - move build refs to occur over Conduit Summary: Ref T2784. Test Plan: loaded up a git commit with refs and they showed up! loaded up a git commit without revs and nothing showed up. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5957
2013-05-17 23:13:48 +02:00
'ConduitAPI_diffusion_refsquery_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_refsquery_Method.php',
Diffusion - move search (grep) system commands to happen over Conduit Summary: Ref T2784. Test Plan: loaded up my git and mercurial copies of Phabricator. Searched for "diff". Observed many results and pagination working correctly. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5955
2013-05-17 23:11:20 +02:00
'ConduitAPI_diffusion_searchquery_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_searchquery_Method.php',
Diffusion - move querying for stable commit name to occur over conduit Summary: Ref T2784. This is a lower-level one from drequest so it gets the conditional initialization treatment. Consolidated SVN as well even though SVN is issuing database queries; I felt better about the code de-duplication despite the small performance hit when we could just query the DB directly in the SVN case. Test Plan: browsed around my Phabricator repositories in Mercurial, Git, and SVN flavors. Looked good. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5956
2013-05-17 23:12:46 +02:00
'ConduitAPI_diffusion_stablecommitnamequery_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_stablecommitnamequery_Method.php',
Diffusion - tag queries => conduit Summary: title. Ref T2784. Test Plan: foreach of SVN, Mercurial, and Git, loaded up a repository. Verified that only git had a tags box and it showed up correctly. Went to CALLSIGN/tags and verified that only git had a tags box and it showed up correctly. Went to various commits across vcs and verified it said "none" unless it was a git commit that also was tagged. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5894
2013-05-11 00:22:35 +02:00
'ConduitAPI_diffusion_tagsquery_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_tagsquery_Method.php',
Uninstall Conduit calls when uninstalling applications Summary: Fixes T2698. When applications are installed, their Conduit calls should drop out. This will also let us land Releeph without exposing Conduit calls. Test Plan: - Viewed Conduit console; uninstalled some applications and verified their calls dropped out. - Tried to make an uninstalled call; got an appropriate error. Reviewers: edward, btrahan Reviewed By: edward CC: aran Maniphest Tasks: T2698 Differential Revision: https://secure.phabricator.com/D5302
2013-03-13 15:09:05 +01:00
'ConduitAPI_feed_Method' => 'applications/feed/conduit/ConduitAPI_feed_Method.php',
Move Conduit methods inside applications Test Plan: /conduit/ /conduit/method/arcanist.projectinfo/ Call method $ echo '{}' | arc call-conduit user.whoami Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4268
2012-12-21 21:12:26 +01:00
'ConduitAPI_feed_publish_Method' => 'applications/feed/conduit/ConduitAPI_feed_publish_Method.php',
'ConduitAPI_feed_query_Method' => 'applications/feed/conduit/ConduitAPI_feed_query_Method.php',
Uninstall Conduit calls when uninstalling applications Summary: Fixes T2698. When applications are installed, their Conduit calls should drop out. This will also let us land Releeph without exposing Conduit calls. Test Plan: - Viewed Conduit console; uninstalled some applications and verified their calls dropped out. - Tried to make an uninstalled call; got an appropriate error. Reviewers: edward, btrahan Reviewed By: edward CC: aran Maniphest Tasks: T2698 Differential Revision: https://secure.phabricator.com/D5302
2013-03-13 15:09:05 +01:00
'ConduitAPI_file_Method' => 'applications/files/conduit/ConduitAPI_file_Method.php',
Move Conduit methods inside applications Test Plan: /conduit/ /conduit/method/arcanist.projectinfo/ Call method $ echo '{}' | arc call-conduit user.whoami Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4268
2012-12-21 21:12:26 +01:00
'ConduitAPI_file_download_Method' => 'applications/files/conduit/ConduitAPI_file_download_Method.php',
'ConduitAPI_file_info_Method' => 'applications/files/conduit/ConduitAPI_file_info_Method.php',
'ConduitAPI_file_upload_Method' => 'applications/files/conduit/ConduitAPI_file_upload_Method.php',
Conduit file upload method that takes in the files content hash and name. Returns the file phid if successful. Updates to phutil library map. Summary: Conduit method to upload a a new file using a hash Test Plan: Try uploading a file using its content hash Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4899
2013-02-11 15:30:02 +01:00
'ConduitAPI_file_uploadhash_Method' => 'applications/files/conduit/ConduitAPI_file_uploadhash_Method.php',
Move Conduit methods inside applications Test Plan: /conduit/ /conduit/method/arcanist.projectinfo/ Call method $ echo '{}' | arc call-conduit user.whoami Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4268
2012-12-21 21:12:26 +01:00
'ConduitAPI_flag_Method' => 'applications/flag/conduit/ConduitAPI_flag_Method.php',
'ConduitAPI_flag_delete_Method' => 'applications/flag/conduit/ConduitAPI_flag_delete_Method.php',
'ConduitAPI_flag_edit_Method' => 'applications/flag/conduit/ConduitAPI_flag_edit_Method.php',
'ConduitAPI_flag_query_Method' => 'applications/flag/conduit/ConduitAPI_flag_query_Method.php',
'ConduitAPI_macro_Method' => 'applications/macro/conduit/ConduitAPI_macro_Method.php',
'ConduitAPI_macro_query_Method' => 'applications/macro/conduit/ConduitAPI_macro_query_Method.php',
'ConduitAPI_maniphest_Method' => 'applications/maniphest/conduit/ConduitAPI_maniphest_Method.php',
'ConduitAPI_maniphest_createtask_Method' => 'applications/maniphest/conduit/ConduitAPI_maniphest_createtask_Method.php',
'ConduitAPI_maniphest_find_Method' => 'applications/maniphest/conduit/ConduitAPI_maniphest_find_Method.php',
'ConduitAPI_maniphest_gettasktransactions_Method' => 'applications/maniphest/conduit/ConduitAPI_maniphest_gettasktransactions_Method.php',
'ConduitAPI_maniphest_info_Method' => 'applications/maniphest/conduit/ConduitAPI_maniphest_info_Method.php',
'ConduitAPI_maniphest_query_Method' => 'applications/maniphest/conduit/ConduitAPI_maniphest_query_Method.php',
'ConduitAPI_maniphest_update_Method' => 'applications/maniphest/conduit/ConduitAPI_maniphest_update_Method.php',
Uninstall Conduit calls when uninstalling applications Summary: Fixes T2698. When applications are installed, their Conduit calls should drop out. This will also let us land Releeph without exposing Conduit calls. Test Plan: - Viewed Conduit console; uninstalled some applications and verified their calls dropped out. - Tried to make an uninstalled call; got an appropriate error. Reviewers: edward, btrahan Reviewed By: edward CC: aran Maniphest Tasks: T2698 Differential Revision: https://secure.phabricator.com/D5302
2013-03-13 15:09:05 +01:00
'ConduitAPI_owners_Method' => 'applications/owners/conduit/ConduitAPI_owners_Method.php',
Move Conduit methods inside applications Test Plan: /conduit/ /conduit/method/arcanist.projectinfo/ Call method $ echo '{}' | arc call-conduit user.whoami Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4268
2012-12-21 21:12:26 +01:00
'ConduitAPI_owners_query_Method' => 'applications/owners/conduit/ConduitAPI_owners_query_Method.php',
Add 'paste.query' conduit method and deprecate 'paste.info' Summary: - Modernize the Paste Conduit API. - Deprecate 'paste.info'. - Make queries policy-aware. - Move methods into the application to support greater modularity. Test Plan: Made `paste.query`, `paste.info`, `paste.create` calls. Browsed Paste interfaces. Forked a paste. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3379
2012-08-24 22:20:20 +02:00
'ConduitAPI_paste_Method' => 'applications/paste/conduit/ConduitAPI_paste_Method.php',
'ConduitAPI_paste_create_Method' => 'applications/paste/conduit/ConduitAPI_paste_create_Method.php',
'ConduitAPI_paste_info_Method' => 'applications/paste/conduit/ConduitAPI_paste_info_Method.php',
'ConduitAPI_paste_query_Method' => 'applications/paste/conduit/ConduitAPI_paste_query_Method.php',
Move Conduit methods inside applications Test Plan: /conduit/ /conduit/method/arcanist.projectinfo/ Call method $ echo '{}' | arc call-conduit user.whoami Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4268
2012-12-21 21:12:26 +01:00
'ConduitAPI_phid_Method' => 'applications/phid/conduit/ConduitAPI_phid_Method.php',
'ConduitAPI_phid_info_Method' => 'applications/phid/conduit/ConduitAPI_phid_info_Method.php',
'ConduitAPI_phid_lookup_Method' => 'applications/phid/conduit/ConduitAPI_phid_lookup_Method.php',
'ConduitAPI_phid_query_Method' => 'applications/phid/conduit/ConduitAPI_phid_query_Method.php',
Uninstall Conduit calls when uninstalling applications Summary: Fixes T2698. When applications are installed, their Conduit calls should drop out. This will also let us land Releeph without exposing Conduit calls. Test Plan: - Viewed Conduit console; uninstalled some applications and verified their calls dropped out. - Tried to make an uninstalled call; got an appropriate error. Reviewers: edward, btrahan Reviewed By: edward CC: aran Maniphest Tasks: T2698 Differential Revision: https://secure.phabricator.com/D5302
2013-03-13 15:09:05 +01:00
'ConduitAPI_phpast_Method' => 'applications/phpast/conduit/ConduitAPI_phpast_Method.php',
Move Conduit methods inside applications Test Plan: /conduit/ /conduit/method/arcanist.projectinfo/ Call method $ echo '{}' | arc call-conduit user.whoami Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4268
2012-12-21 21:12:26 +01:00
'ConduitAPI_phpast_getast_Method' => 'applications/phpast/conduit/ConduitAPI_phpast_getast_Method.php',
'ConduitAPI_phpast_version_Method' => 'applications/phpast/conduit/ConduitAPI_phpast_version_Method.php',
'ConduitAPI_phriction_Method' => 'applications/phriction/conduit/ConduitAPI_phriction_Method.php',
'ConduitAPI_phriction_edit_Method' => 'applications/phriction/conduit/ConduitAPI_phriction_edit_Method.php',
'ConduitAPI_phriction_history_Method' => 'applications/phriction/conduit/ConduitAPI_phriction_history_Method.php',
'ConduitAPI_phriction_info_Method' => 'applications/phriction/conduit/ConduitAPI_phriction_info_Method.php',
'ConduitAPI_project_Method' => 'applications/project/conduit/ConduitAPI_project_Method.php',
'ConduitAPI_project_query_Method' => 'applications/project/conduit/ConduitAPI_project_query_Method.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ConduitAPI_releeph_Method' => 'applications/releeph/conduit/ConduitAPI_releeph_Method.php',
'ConduitAPI_releeph_getbranches_Method' => 'applications/releeph/conduit/ConduitAPI_releeph_getbranches_Method.php',
'ConduitAPI_releeph_projectinfo_Method' => 'applications/releeph/conduit/ConduitAPI_releeph_projectinfo_Method.php',
Add get Releeph Requests conduit method Summary: Added "getrequests" conduit method Test Plan: Open /conduit/method/differential.getrequests/ and try different inputs. Reviewers: edward, epriestley Reviewed By: edward CC: aran, epriestley, Korvin Maniphest Tasks: T3057 Differential Revision: https://secure.phabricator.com/D5788
2013-04-26 18:07:38 +02:00
'ConduitAPI_releeph_queryrequests_Method' => 'applications/releeph/conduit/ConduitAPI_releeph_queryrequests_Method.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ConduitAPI_releeph_request_Method' => 'applications/releeph/conduit/ConduitAPI_releeph_request_Method.php',
'ConduitAPI_releephwork_canpush_Method' => 'applications/releeph/conduit/work/ConduitAPI_releephwork_canpush_Method.php',
'ConduitAPI_releephwork_getauthorinfo_Method' => 'applications/releeph/conduit/work/ConduitAPI_releephwork_getauthorinfo_Method.php',
'ConduitAPI_releephwork_getbranch_Method' => 'applications/releeph/conduit/work/ConduitAPI_releephwork_getbranch_Method.php',
'ConduitAPI_releephwork_getbranchcommitmessage_Method' => 'applications/releeph/conduit/work/ConduitAPI_releephwork_getbranchcommitmessage_Method.php',
'ConduitAPI_releephwork_getcommitmessage_Method' => 'applications/releeph/conduit/work/ConduitAPI_releephwork_getcommitmessage_Method.php',
'ConduitAPI_releephwork_getorigcommitmessage_Method' => 'applications/releeph/conduit/work/ConduitAPI_releephwork_getorigcommitmessage_Method.php',
'ConduitAPI_releephwork_nextrequest_Method' => 'applications/releeph/conduit/work/ConduitAPI_releephwork_nextrequest_Method.php',
'ConduitAPI_releephwork_record_Method' => 'applications/releeph/conduit/work/ConduitAPI_releephwork_record_Method.php',
'ConduitAPI_releephwork_recordpickstatus_Method' => 'applications/releeph/conduit/work/ConduitAPI_releephwork_recordpickstatus_Method.php',
Move Conduit methods inside applications Test Plan: /conduit/ /conduit/method/arcanist.projectinfo/ Call method $ echo '{}' | arc call-conduit user.whoami Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4268
2012-12-21 21:12:26 +01:00
'ConduitAPI_remarkup_process_Method' => 'applications/remarkup/conduit/ConduitAPI_remarkup_process_Method.php',
'ConduitAPI_repository_Method' => 'applications/repository/conduit/ConduitAPI_repository_Method.php',
'ConduitAPI_repository_create_Method' => 'applications/repository/conduit/ConduitAPI_repository_create_Method.php',
'ConduitAPI_repository_query_Method' => 'applications/repository/conduit/ConduitAPI_repository_query_Method.php',
Uninstall Conduit calls when uninstalling applications Summary: Fixes T2698. When applications are installed, their Conduit calls should drop out. This will also let us land Releeph without exposing Conduit calls. Test Plan: - Viewed Conduit console; uninstalled some applications and verified their calls dropped out. - Tried to make an uninstalled call; got an appropriate error. Reviewers: edward, btrahan Reviewed By: edward CC: aran Maniphest Tasks: T2698 Differential Revision: https://secure.phabricator.com/D5302
2013-03-13 15:09:05 +01:00
'ConduitAPI_slowvote_Method' => 'applications/slowvote/conduit/ConduitAPI_slowvote_Method.php',
Move Conduit methods inside applications Test Plan: /conduit/ /conduit/method/arcanist.projectinfo/ Call method $ echo '{}' | arc call-conduit user.whoami Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4268
2012-12-21 21:12:26 +01:00
'ConduitAPI_slowvote_info_Method' => 'applications/slowvote/conduit/ConduitAPI_slowvote_info_Method.php',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'ConduitAPI_token_Method' => 'applications/tokens/conduit/ConduitAPI_token_Method.php',
'ConduitAPI_token_give_Method' => 'applications/tokens/conduit/ConduitAPI_token_give_Method.php',
'ConduitAPI_token_given_Method' => 'applications/tokens/conduit/ConduitAPI_token_given_Method.php',
'ConduitAPI_token_query_Method' => 'applications/tokens/conduit/ConduitAPI_token_query_Method.php',
Move Conduit methods inside applications Test Plan: /conduit/ /conduit/method/arcanist.projectinfo/ Call method $ echo '{}' | arc call-conduit user.whoami Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4268
2012-12-21 21:12:26 +01:00
'ConduitAPI_user_Method' => 'applications/people/conduit/ConduitAPI_user_Method.php',
'ConduitAPI_user_addstatus_Method' => 'applications/people/conduit/ConduitAPI_user_addstatus_Method.php',
'ConduitAPI_user_disable_Method' => 'applications/people/conduit/ConduitAPI_user_disable_Method.php',
'ConduitAPI_user_enable_Method' => 'applications/people/conduit/ConduitAPI_user_enable_Method.php',
'ConduitAPI_user_find_Method' => 'applications/people/conduit/ConduitAPI_user_find_Method.php',
'ConduitAPI_user_info_Method' => 'applications/people/conduit/ConduitAPI_user_info_Method.php',
'ConduitAPI_user_query_Method' => 'applications/people/conduit/ConduitAPI_user_query_Method.php',
'ConduitAPI_user_removestatus_Method' => 'applications/people/conduit/ConduitAPI_user_removestatus_Method.php',
'ConduitAPI_user_whoami_Method' => 'applications/people/conduit/ConduitAPI_user_whoami_Method.php',
Allow applications to call Conduit directly Summary: Sorry this took so long, had a bunch of stuff going on today. Separate the actual core part of making conduit calls from the controller, so the application can make conduit calls without needing to invoke HTTP or redo auth. Generally, this lets us build more parts of the application on top of Conduit, as appropriate. This diff can be simplified, but I wanted to unblock you guys first. I'll followup with a cleanup patch once I have a chance. Test Plan: Ran unit tests, ran calls from the conduit API console, and ran calls over arc. Reviewers: nodren, 20after4, btrahan, vrana Reviewed By: 20after4 CC: aran, svemir Maniphest Tasks: T945 Differential Revision: https://secure.phabricator.com/D2718
2012-06-17 17:47:09 +02:00
'ConduitCall' => 'applications/conduit/call/ConduitCall.php',
'ConduitCallTestCase' => 'applications/conduit/call/__tests__/ConduitCallTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ConduitException' => 'applications/conduit/protocol/ConduitException.php',
Implement SSHD glue and Conduit SSH endpoint Summary: - Build "sshd-auth" (for authentication) and "sshd-exec" (for command execution) binaries. These are callable by "sshd-vcs", located [[https://github.com/epriestley/sshd-vcs | in my account on GitHub]]. They are based on precursors [[https://github.com/epriestley/sshd-vcs-glue | here on GitHub]] which I deployed for TenXer about a year ago, so I have some confidence they at least basically work. - The problem this solves is that normally every user would need an account on a machine to connect to it, and/or their public keys would all need to be listed in `~/.authorized_keys`. This is a big pain in most installs. Software like Gitosis/Gitolite solve this problem by giving you an easy way to add public keys to `~/.authorized_keys`, but this is pretty gross. - Roughly, instead of looking in `~/.authorized_keys` when a user connects, the patched sshd instead runs `echo <public key> | sshd-auth`. The `sshd-auth` script looks up the public key and authorizes the matching user, if they exist. It also forces sshd to run `sshd-exec` instead of a normal shell. - `sshd-exec` receives the authenticated user and any command which was passed to ssh (like `git receive-pack`) and can route them appropriately. - Overall, this permits a single account to be set up on a server which all Phabricator users can connect to without any extra work, and which can safely execute commands and apply appropriate permissions, and disable users when they are disabled in Phabricator and all that stuff. - Build out "sshd-exec" to do more thorough checks and setup, and delegate command execution to Workflows (they now exist, and did not when I originally built this stuff). - Convert @btrahan's conduit API script into a workflow and slightly simplify it (ConduitCall did not exist at the time it was written). The next steps here on the Repository side are to implement Workflows for Git, SVN and HG wire protocols. These will mostly just proxy the protocols, but also need to enforce permissions. So the approach will basically be: - Implement workflows for stuff like `git receive-pack`. - These workflows will implement enough of the underlying protocol to determine what resource the user is trying to access, and whether they want to read or write it. - They'll then do a permissons check, and kick the user out if they don't have permission to do whatever they are trying to do. - If the user does have permission, we just proxy the rest of the transaction. Next steps on the Conduit side are more simple: - Make ConduitClient understand "ssh://" URLs. Test Plan: Ran `sshd-exec --phabricator-ssh-user epriestley conduit differential.query`, etc. This will get a more comprehensive test once I set up sshd-vcs. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T550 Differential Revision: https://secure.phabricator.com/D4229
2012-12-19 20:08:07 +01:00
'ConduitSSHWorkflow' => 'applications/conduit/ssh/ConduitSSHWorkflow.php',
Conpherence - reply handler integration Summary: Added a reply handler. A few problems -- first, I can't seem to get this to actually send me email so I haven't been able to reply (which I would have done by generating a reply, then copying the raw email into scripts/mail_handler.php). Second, the subject is often terrible on these emails -- unless the conpherence is named its something gross like "E4:" Third, on create I am noticing an error on array_combine() which I think is related to the need to write array_combine_not_broken or what have you I saw go by... (PhabricatorTransactionEditor does array_combine(xaction->getOldValue(), xaction->getOldValue()) and complains that the arrays are empty) Test Plan: noted that /mail/ said mails were being sent Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2399 Differential Revision: https://secure.phabricator.com/D4656
2013-01-26 01:03:54 +01:00
'ConpherenceConfigOptions' => 'applications/conpherence/config/ConpherenceConfigOptions.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceConstants' => 'applications/conpherence/constants/ConpherenceConstants.php',
'ConpherenceController' => 'applications/conpherence/controller/ConpherenceController.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ConpherenceCreateThreadMailReceiver' => 'applications/conpherence/mail/ConpherenceCreateThreadMailReceiver.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceDAO' => 'applications/conpherence/storage/ConpherenceDAO.php',
'ConpherenceEditor' => 'applications/conpherence/editor/ConpherenceEditor.php',
Conpherence - Make the files widget more useful and ajaxify some more stuff Summary: files widget updates as new files are added. made basically all edits "ajax" except for when you change the conpherence image which just does a reload. I will fix this in a future diff but it was starting to spiral out of control a bit. Test Plan: commented on a task with files and noted the updated file widget. updated header image via drag and drop and dialogue -- noted a full reload. cropped image and re-titled conpherence - ajax updated as expected. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2530 Differential Revision: https://secure.phabricator.com/D5288
2013-03-08 19:40:06 +01:00
'ConpherenceFileWidgetView' => 'applications/conpherence/view/ConpherenceFileWidgetView.php',
Adding hovercard event listeners for Users, Revisions, Conpherence and Commits Summary: Refs T1048 Adding Differential Hovercard EventListener Adding People Hovercard EventListener Adding basic Diffusion hovercard Adding Conpherence Hovercard EventListener Test Plan: Used in a combo with working hovercards. So beautiful. Also visited test page. Works alright. awesometown Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1048 Differential Revision: https://secure.phabricator.com/D5576
2013-04-06 02:01:54 +02:00
'ConpherenceHovercardEventListener' => 'applications/conpherence/events/ConpherenceHovercardEventListener.php',
Consolidate Conpherence frame rendering Summary: Conpherence frame rendering is spread out a bit across ConpherenceController, ConpherenceListController, and previously ConpherenceNewController. I want to let the Thread and Widget controllers render the frame for mobile. Ref T2421. Test Plan: Viewed conpherences, switched between conpherences. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2421 Differential Revision: https://secure.phabricator.com/D5501
2013-04-01 21:43:07 +02:00
'ConpherenceLayoutView' => 'applications/conpherence/view/ConpherenceLayoutView.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceListController' => 'applications/conpherence/controller/ConpherenceListController.php',
'ConpherenceMenuItemView' => 'applications/conpherence/view/ConpherenceMenuItemView.php',
'ConpherenceNewController' => 'applications/conpherence/controller/ConpherenceNewController.php',
'ConpherenceParticipant' => 'applications/conpherence/storage/ConpherenceParticipant.php',
Conpherence - paginate thread list Summary: this is D5750 but just the conpherence part. fixes a few random conpherence bugs / quirks as well. Also messes with ApplicationTransactionEditor to expose the xactions so Conpherence doesn't over-update participation rows. Fixes T2429. Test Plan: set LIMIT to 3. verified I could scroll down all conpherences. next, picked a conpherence "in the middle" to load. verified I could page up and down. next, picked a conpherence in the middle then had another user update that conpherence. verified as I paged up the conpherence re-loaded properly selected Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin, vrana Maniphest Tasks: T2429 Differential Revision: https://secure.phabricator.com/D5783
2013-04-26 19:30:41 +02:00
'ConpherenceParticipantCountQuery' => 'applications/conpherence/query/ConpherenceParticipantCountQuery.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceParticipantQuery' => 'applications/conpherence/query/ConpherenceParticipantQuery.php',
'ConpherenceParticipationStatus' => 'applications/conpherence/constants/ConpherenceParticipationStatus.php',
Update PeopleMenu to only show integration with applications if they are installed Summary: do so via event engine. note different order now... Test Plan: toggled "show beta applications" to off and noted that Conpherence disappeared. Otherwise noted that links showed. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2424 Differential Revision: https://secure.phabricator.com/D4708
2013-02-05 22:46:02 +01:00
'ConpherencePeopleMenuEventListener' => 'applications/conpherence/events/ConpherencePeopleMenuEventListener.php',
Conpherence - people widget Summary: adds ye olde people widget. Features include - handle-based display, so we get status for free. (Note less pretty than M14 would have it!) - can add a person - can remove a person - can see the people already in the conpherence Test Plan: added and removed people and noted they joined / re-added as appropriate. Tried to add someone already in the conpherence and got a "transaction has no effect" message Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2399 Differential Revision: https://secure.phabricator.com/D5466
2013-04-02 18:32:40 +02:00
'ConpherencePeopleWidgetView' => 'applications/conpherence/view/ConpherencePeopleWidgetView.php',
Conpherence - reply handler integration Summary: Added a reply handler. A few problems -- first, I can't seem to get this to actually send me email so I haven't been able to reply (which I would have done by generating a reply, then copying the raw email into scripts/mail_handler.php). Second, the subject is often terrible on these emails -- unless the conpherence is named its something gross like "E4:" Third, on create I am noticing an error on array_combine() which I think is related to the need to write array_combine_not_broken or what have you I saw go by... (PhabricatorTransactionEditor does array_combine(xaction->getOldValue(), xaction->getOldValue()) and complains that the arrays are empty) Test Plan: noted that /mail/ said mails were being sent Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2399 Differential Revision: https://secure.phabricator.com/D4656
2013-01-26 01:03:54 +01:00
'ConpherenceReplyHandler' => 'applications/conpherence/mail/ConpherenceReplyHandler.php',
Conpherence - add per thread notification setting Summary: Introduces a new settings panel for Conpherence specific settings. Test Plan: started a thread with a test user, thus two participants total. Replied to conpherence, toggling notification settings in between. Verified 1 or 2 emails were sent as appropos to the current toggle. Toggled global setting and verified setting was updated in conpherences where nothing was specified. Verified setting conpherence setting overrides global setting. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2521 Differential Revision: https://secure.phabricator.com/D5391
2013-03-26 21:30:35 +01:00
'ConpherenceSettings' => 'applications/conpherence/constants/ConpherenceSettings.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceThread' => 'applications/conpherence/storage/ConpherenceThread.php',
Render Conpherence threads as a separate menu inside the layout, not a side nav Summary: Currently, the thread list is in a standard side nav, but that makes it awkward to render (rendering logic needs to live in the base controller) and gives it some bad beahviors (like autohiding on mobile). Instead, move it into its own view and make it a little more custom. Ref T2421. Test Plan: {F38098} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T2421 Differential Revision: https://secure.phabricator.com/D5504
2013-04-01 21:50:39 +02:00
'ConpherenceThreadListView' => 'applications/conpherence/view/ConpherenceThreadListView.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ConpherenceThreadMailReceiver' => 'applications/conpherence/mail/ConpherenceThreadMailReceiver.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceThreadQuery' => 'applications/conpherence/query/ConpherenceThreadQuery.php',
Conpherence - implement epoch creation slightly differently Summary: D6114 fixed some bugs but on production it shows up as a new bug where Saturday is the first day? stop messing with the DateTime object so much and do some old school epoch manipulation. This works correctly on my laptop and my still fail in production, but it will rule out DateTime suckage. Test Plan: still works on laptop Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6115
2013-06-04 00:40:00 +02:00
'ConpherenceTimeUtil' => 'applications/conpherence/util/ConpherenceTimeUtil.php',
'ConpherenceTimeUtilTestCase' => 'applications/conpherence/__tests__/ConpherenceTimeUtilTestCase.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceTransaction' => 'applications/conpherence/storage/ConpherenceTransaction.php',
'ConpherenceTransactionComment' => 'applications/conpherence/storage/ConpherenceTransactionComment.php',
'ConpherenceTransactionQuery' => 'applications/conpherence/query/ConpherenceTransactionQuery.php',
'ConpherenceTransactionType' => 'applications/conpherence/constants/ConpherenceTransactionType.php',
'ConpherenceTransactionView' => 'applications/conpherence/view/ConpherenceTransactionView.php',
Conpherence - continue the load less quest Summary: basically makes it so we only really load what we need from the server for any particular update action. the javascript thus then has some things deleted from it. made a spot or two ready for when the pertinent UI won't be there as well. also added a feature in javascript -- updating the document title to the current conpherence title. Ref T2867 T2399 Test Plan: played with conpherence for quite a bit. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2867 Differential Revision: https://secure.phabricator.com/D5625
2013-04-10 20:37:04 +02:00
'ConpherenceUpdateActions' => 'applications/conpherence/constants/ConpherenceUpdateActions.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceUpdateController' => 'applications/conpherence/controller/ConpherenceUpdateController.php',
'ConpherenceViewController' => 'applications/conpherence/controller/ConpherenceViewController.php',
Renders the last 100 conpherence transactions only Summary: Fixed T2428 a little bit Test Plan: On trial, only the last n transactions loaded as hardcoded in ConpherenceViewController.php. Button was rendered. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2428 Differential Revision: https://secure.phabricator.com/D4898
2013-02-15 23:01:27 +01:00
'ConpherenceWidgetController' => 'applications/conpherence/controller/ConpherenceWidgetController.php',
Conpherence - people widget Summary: adds ye olde people widget. Features include - handle-based display, so we get status for free. (Note less pretty than M14 would have it!) - can add a person - can remove a person - can see the people already in the conpherence Test Plan: added and removed people and noted they joined / re-added as appropriate. Tried to add someone already in the conpherence and got a "transaction has no effect" message Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2399 Differential Revision: https://secure.phabricator.com/D5466
2013-04-02 18:32:40 +02:00
'ConpherenceWidgetView' => 'applications/conpherence/view/ConpherenceWidgetView.php',
Countdown revamp 2 Summary: Now has policy support (not really) Now uses CountdownQuery Now has handles Now uses common way for remarkup Remarkup still looks terrible Test Plan: Added countdowns, edited countdowns. Did even embed some. Couldn't break it Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2624 Differential Revision: https://secure.phabricator.com/D6012
2013-05-23 15:47:54 +02:00
'CountdownQuery' => 'applications/countdown/query/CountdownQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DarkConsoleController' => 'aphront/console/DarkConsoleController.php',
'DarkConsoleCore' => 'aphront/console/DarkConsoleCore.php',
DarkConsole: fix rendering, move request log, load over ajax Summary: This accomplishes three major goals: # Fixes phutil_render_tag -> phutil_tag callsites in DarkConsole. # Moves the Ajax request log to a new panel on the left. This panel (and the tabs panel) get scrollbars when they get large, instead of making the page constantly scroll down. # Loads the panel content over ajax, instead of dumping it into the page body / ajax response body. I've been planning to do this for about 3 years, which is why the plugins are architected the way they are. This should make debugging easier by making response bodies not be 50%+ darkconsole stuff. Additionally, load the plugins dynamically (the old method predates library maps and PhutilSymbolLoader). Test Plan: {F30675} - Switched between requests and tabs, reloaded page, saw same tab. - Used "analyze queries", "profile page", triggered errors. - Verified page does not load anything by default if dark console is closed with Charles. - Generally banged on it a bit. Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2432 Differential Revision: https://secure.phabricator.com/D4692
2013-01-29 03:45:32 +01:00
'DarkConsoleDataController' => 'aphront/console/DarkConsoleDataController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DarkConsoleErrorLogPlugin' => 'aphront/console/plugin/DarkConsoleErrorLogPlugin.php',
'DarkConsoleErrorLogPluginAPI' => 'aphront/console/plugin/errorlog/DarkConsoleErrorLogPluginAPI.php',
'DarkConsoleEventPlugin' => 'aphront/console/plugin/DarkConsoleEventPlugin.php',
'DarkConsoleEventPluginAPI' => 'aphront/console/plugin/event/DarkConsoleEventPluginAPI.php',
'DarkConsolePlugin' => 'aphront/console/plugin/DarkConsolePlugin.php',
'DarkConsoleRequestPlugin' => 'aphront/console/plugin/DarkConsoleRequestPlugin.php',
'DarkConsoleServicesPlugin' => 'aphront/console/plugin/DarkConsoleServicesPlugin.php',
'DarkConsoleXHProfPlugin' => 'aphront/console/plugin/DarkConsoleXHProfPlugin.php',
'DarkConsoleXHProfPluginAPI' => 'aphront/console/plugin/xhprof/DarkConsoleXHProfPluginAPI.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'DatabaseConfigurationProvider' => 'infrastructure/storage/configuration/DatabaseConfigurationProvider.php',
'DefaultDatabaseConfigurationProvider' => 'infrastructure/storage/configuration/DefaultDatabaseConfigurationProvider.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialAction' => 'applications/differential/constants/DifferentialAction.php',
'DifferentialActionHasNoEffectException' => 'applications/differential/exception/DifferentialActionHasNoEffectException.php',
'DifferentialAddCommentView' => 'applications/differential/view/DifferentialAddCommentView.php',
'DifferentialAffectedPath' => 'applications/differential/storage/DifferentialAffectedPath.php',
'DifferentialApplyPatchFieldSpecification' => 'applications/differential/field/specification/DifferentialApplyPatchFieldSpecification.php',
'DifferentialArcanistProjectFieldSpecification' => 'applications/differential/field/specification/DifferentialArcanistProjectFieldSpecification.php',
'DifferentialAuditorsFieldSpecification' => 'applications/differential/field/specification/DifferentialAuditorsFieldSpecification.php',
'DifferentialAuthorFieldSpecification' => 'applications/differential/field/specification/DifferentialAuthorFieldSpecification.php',
'DifferentialAuxiliaryField' => 'applications/differential/storage/DifferentialAuxiliaryField.php',
'DifferentialBlameRevisionFieldSpecification' => 'applications/differential/field/specification/DifferentialBlameRevisionFieldSpecification.php',
'DifferentialBranchFieldSpecification' => 'applications/differential/field/specification/DifferentialBranchFieldSpecification.php',
'DifferentialCCWelcomeMail' => 'applications/differential/mail/DifferentialCCWelcomeMail.php',
'DifferentialCCsFieldSpecification' => 'applications/differential/field/specification/DifferentialCCsFieldSpecification.php',
'DifferentialChangeType' => 'applications/differential/constants/DifferentialChangeType.php',
'DifferentialChangeset' => 'applications/differential/storage/DifferentialChangeset.php',
'DifferentialChangesetDetailView' => 'applications/differential/view/DifferentialChangesetDetailView.php',
upgrade diffusion to use modern header UI and fix a few quirks Summary: upgrades are CrumbsView, HeaderView, PropertyListView, and ActionListView. I had to modify CrumbsView stuff a bit to handle the "advanced" diffusion crumbs. Quirks fixed include making file tree view show up in diffusion, the page not have extra space when the file tree is hidden, links no longer breaking once you visit files (since without the change the files always got "/" appended and thus 404'd), and a differential quirk where it read "next step:" and that colon is a no no, Test Plan: played around in diffusion and differential Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2048, T2178 Differential Revision: https://secure.phabricator.com/D4169
2012-12-13 02:50:42 +01:00
'DifferentialChangesetFileTreeSideNavBuilder' => 'applications/differential/view/DifferentialChangesetFileTreeSideNavBuilder.php',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialChangesetHTMLRenderer' => 'applications/differential/render/DifferentialChangesetHTMLRenderer.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialChangesetListView' => 'applications/differential/view/DifferentialChangesetListView.php',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialChangesetOneUpRenderer' => 'applications/differential/render/DifferentialChangesetOneUpRenderer.php',
'DifferentialChangesetOneUpTestRenderer' => 'applications/differential/render/DifferentialChangesetOneUpTestRenderer.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialChangesetParser' => 'applications/differential/parser/DifferentialChangesetParser.php',
Unhighlight lines modified in rebase Summary: Diff of diffs display changes between new versions of file. This is bad after rebase because there can be many unrelated changes so it is hard to spot the real change. This diff unhighlights the lines that were added or removed in rebase. The changes are still visible (they can be sometimes relevant) but very subtle. Test Plan: # Add, change and delete line. Display diff. # Add and change some lines in parent. Rebase. Display diff. Display diff of diff. # Change and add some lines. Display diff. Display diff to first diff. Display diff to second diff. Reviewers: epriestley, jungejason Reviewed By: jungejason CC: jungejason, aran, Korvin Differential Revision: https://secure.phabricator.com/D2761
2012-06-15 09:53:26 +02:00
'DifferentialChangesetParserTestCase' => 'applications/differential/parser/__tests__/DifferentialChangesetParserTestCase.php',
Refactor DifferentialChangesetParser -- pass 1 of N Summary: basically did my darnedest to pull out a TwoUp rendering view. Made a base class for the rendering views with "old" and "new" terminology rather than "left" and "right. Future revisions will finish cleaning up the terminology within the DifferentialChangesetParser itself and more of the ideas within T2009. Test Plan: been playing with differential all day Reviewers: epriestley Reviewed By: epriestley CC: vrana, chad, aran, Korvin Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4117
2012-12-08 01:19:57 +01:00
'DifferentialChangesetRenderer' => 'applications/differential/render/DifferentialChangesetRenderer.php',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialChangesetTestRenderer' => 'applications/differential/render/DifferentialChangesetTestRenderer.php',
Refactor DifferentialChangesetParser -- pass 1 of N Summary: basically did my darnedest to pull out a TwoUp rendering view. Made a base class for the rendering views with "old" and "new" terminology rather than "left" and "right. Future revisions will finish cleaning up the terminology within the DifferentialChangesetParser itself and more of the ideas within T2009. Test Plan: been playing with differential all day Reviewers: epriestley Reviewed By: epriestley CC: vrana, chad, aran, Korvin Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4117
2012-12-08 01:19:57 +01:00
'DifferentialChangesetTwoUpRenderer' => 'applications/differential/render/DifferentialChangesetTwoUpRenderer.php',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialChangesetTwoUpTestRenderer' => 'applications/differential/render/DifferentialChangesetTwoUpTestRenderer.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialChangesetViewController' => 'applications/differential/controller/DifferentialChangesetViewController.php',
'DifferentialComment' => 'applications/differential/storage/DifferentialComment.php',
'DifferentialCommentEditor' => 'applications/differential/editor/DifferentialCommentEditor.php',
'DifferentialCommentMail' => 'applications/differential/mail/DifferentialCommentMail.php',
'DifferentialCommentPreviewController' => 'applications/differential/controller/DifferentialCommentPreviewController.php',
'DifferentialCommentSaveController' => 'applications/differential/controller/DifferentialCommentSaveController.php',
'DifferentialCommitsFieldSpecification' => 'applications/differential/field/specification/DifferentialCommitsFieldSpecification.php',
Parse Conflicts field in commit message Summary: Git adds it automatically. I don't like this solution much because there could be other unknown fields appended to the end of the commit message which will break parsing. Test Plan: Reparsed commit ending with: > Differential Revision: ... > Conflicts: ... Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4157
2012-12-12 01:34:08 +01:00
'DifferentialConflictsFieldSpecification' => 'applications/differential/field/specification/DifferentialConflictsFieldSpecification.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialController' => 'applications/differential/controller/DifferentialController.php',
'DifferentialDAO' => 'applications/differential/storage/DifferentialDAO.php',
'DifferentialDateCreatedFieldSpecification' => 'applications/differential/field/specification/DifferentialDateCreatedFieldSpecification.php',
'DifferentialDateModifiedFieldSpecification' => 'applications/differential/field/specification/DifferentialDateModifiedFieldSpecification.php',
'DifferentialDefaultFieldSelector' => 'applications/differential/field/selector/DifferentialDefaultFieldSelector.php',
'DifferentialDependenciesFieldSpecification' => 'applications/differential/field/specification/DifferentialDependenciesFieldSpecification.php',
Display dependent revisions in revision detail Summary: I have a chain of revisions sometimes. I want to see also revisions depending on me. Test Plan: Displayed revision in the middle of chain. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3399
2012-08-29 00:24:01 +02:00
'DifferentialDependsOnFieldSpecification' => 'applications/differential/field/specification/DifferentialDependsOnFieldSpecification.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialDiff' => 'applications/differential/storage/DifferentialDiff.php',
'DifferentialDiffContentMail' => 'applications/differential/mail/DifferentialDiffContentMail.php',
'DifferentialDiffCreateController' => 'applications/differential/controller/DifferentialDiffCreateController.php',
'DifferentialDiffProperty' => 'applications/differential/storage/DifferentialDiffProperty.php',
'DifferentialDiffTableOfContentsView' => 'applications/differential/view/DifferentialDiffTableOfContentsView.php',
Don't skip even lines in copied code detector Summary: PHP 3 basics: `each()` advances internal pointer so calling `next()` is wrong. Test Plan: New test. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4011
2012-11-21 21:30:38 +01:00
'DifferentialDiffTestCase' => 'applications/differential/storage/__tests__/DifferentialDiffTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialDiffViewController' => 'applications/differential/controller/DifferentialDiffViewController.php',
'DifferentialException' => 'applications/differential/exception/DifferentialException.php',
'DifferentialExceptionMail' => 'applications/differential/mail/DifferentialExceptionMail.php',
'DifferentialExportPatchFieldSpecification' => 'applications/differential/field/specification/DifferentialExportPatchFieldSpecification.php',
'DifferentialFieldDataNotAvailableException' => 'applications/differential/field/exception/DifferentialFieldDataNotAvailableException.php',
'DifferentialFieldParseException' => 'applications/differential/field/exception/DifferentialFieldParseException.php',
'DifferentialFieldSelector' => 'applications/differential/field/selector/DifferentialFieldSelector.php',
'DifferentialFieldSpecification' => 'applications/differential/field/specification/DifferentialFieldSpecification.php',
'DifferentialFieldSpecificationIncompleteException' => 'applications/differential/field/exception/DifferentialFieldSpecificationIncompleteException.php',
'DifferentialFieldValidationException' => 'applications/differential/field/exception/DifferentialFieldValidationException.php',
Detect tasks referenced in commit messages and either link or update the mentioned tasks. Refs T945 Summary: This takes the place of D2721 which I am going to abandon. Test Plan: * Make a commit with "Closes T###" in the summary field. See that the mentioned task gets closed. * Make a commit with "refs T###" in the summary. See that it gets added as a related commit via edges. Reviewers: 20after4 Reviewed By: epriestley CC: aran, Korvin, champo Maniphest Tasks: T945 Differential Revision: https://secure.phabricator.com/D3466
2012-09-11 19:37:30 +02:00
'DifferentialFreeformFieldSpecification' => 'applications/differential/field/specification/DifferentialFreeformFieldSpecification.php',
Parse VCS revert langauge in commit messages Summary: Ref T1751. When commit messages include language like "reverts X", parse it. This change doesn't do anything with the commits yet. I attempted to cover all "natural" VCS messages and all reasonable human variations of these messages. Test Plan: Added unit tests. Added `var_dump()` and used `scripts/repository/reparse.php --message X` to reparse some commit messages, with expected results. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1751 Differential Revision: https://secure.phabricator.com/D5840
2013-05-06 21:33:37 +02:00
'DifferentialFreeformFieldTestCase' => 'applications/differential/field/specification/__tests__/DifferentialFreeformFieldTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialGitSVNIDFieldSpecification' => 'applications/differential/field/specification/DifferentialGitSVNIDFieldSpecification.php',
'DifferentialHostFieldSpecification' => 'applications/differential/field/specification/DifferentialHostFieldSpecification.php',
Adding hovercard event listeners for Users, Revisions, Conpherence and Commits Summary: Refs T1048 Adding Differential Hovercard EventListener Adding People Hovercard EventListener Adding basic Diffusion hovercard Adding Conpherence Hovercard EventListener Test Plan: Used in a combo with working hovercards. So beautiful. Also visited test page. Works alright. awesometown Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1048 Differential Revision: https://secure.phabricator.com/D5576
2013-04-06 02:01:54 +02:00
'DifferentialHovercardEventListener' => 'applications/differential/events/DifferentialHovercardEventListener.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialHunk' => 'applications/differential/storage/DifferentialHunk.php',
re-factor DifferentialChangesetParser pass 3 / N Summary: introducing a new friend called DifferentialHunkParser. Sort of like the DifferentialChangesetParser but works with hunks only. tried to grab hunk parsing type things from across the code base and move them into this new class. Test Plan: unit tests and played around in Differential a bit. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4351
2013-01-09 22:11:17 +01:00
'DifferentialHunkParser' => 'applications/differential/parser/DifferentialHunkParser.php',
'DifferentialHunkParserTestCase' => 'applications/differential/parser/__tests__/DifferentialHunkParserTestCase.php',
Simplify DifferentialHunk::getAddedLines() Summary: I will also need `getRemovedLines()` so refactor this first. Test Plan: New test case. Viewed uncached diff. Verified that the only callsite of `getAddedLines()` trims lines. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D2875
2012-06-27 19:44:29 +02:00
'DifferentialHunkTestCase' => 'applications/differential/storage/__tests__/DifferentialHunkTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialInlineComment' => 'applications/differential/storage/DifferentialInlineComment.php',
'DifferentialInlineCommentEditController' => 'applications/differential/controller/DifferentialInlineCommentEditController.php',
'DifferentialInlineCommentEditView' => 'applications/differential/view/DifferentialInlineCommentEditView.php',
'DifferentialInlineCommentPreviewController' => 'applications/differential/controller/DifferentialInlineCommentPreviewController.php',
'DifferentialInlineCommentView' => 'applications/differential/view/DifferentialInlineCommentView.php',
'DifferentialLinesFieldSpecification' => 'applications/differential/field/specification/DifferentialLinesFieldSpecification.php',
'DifferentialLintFieldSpecification' => 'applications/differential/field/specification/DifferentialLintFieldSpecification.php',
'DifferentialLintStatus' => 'applications/differential/constants/DifferentialLintStatus.php',
'DifferentialLocalCommitsView' => 'applications/differential/view/DifferentialLocalCommitsView.php',
'DifferentialMail' => 'applications/differential/mail/DifferentialMail.php',
Drive Differential review request e-mail message by field specification Summary: This also changes some stuff: - Reviewers used to be at top, now they are under comments. - Primary reviewer is now rendered as first. Test Plan: Added `renderValueForMail()` to a custom field, created diff, commented on it and verified e-mails. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D2664
2012-06-06 19:52:17 +02:00
'DifferentialMailPhase' => 'applications/differential/constants/DifferentialMailPhase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialManiphestTasksFieldSpecification' => 'applications/differential/field/specification/DifferentialManiphestTasksFieldSpecification.php',
'DifferentialNewDiffMail' => 'applications/differential/mail/DifferentialNewDiffMail.php',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialParseRenderTestCase' => 'applications/differential/__tests__/DifferentialParseRenderTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialPathFieldSpecification' => 'applications/differential/field/specification/DifferentialPathFieldSpecification.php',
Update PeopleMenu to only show integration with applications if they are installed Summary: do so via event engine. note different order now... Test Plan: toggled "show beta applications" to off and noted that Conpherence disappeared. Otherwise noted that links showed. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2424 Differential Revision: https://secure.phabricator.com/D4708
2013-02-05 22:46:02 +01:00
'DifferentialPeopleMenuEventListener' => 'applications/differential/events/DifferentialPeopleMenuEventListener.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialPrimaryPaneView' => 'applications/differential/view/DifferentialPrimaryPaneView.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'DifferentialReleephRequestFieldSpecification' => 'applications/releeph/differential/DifferentialReleephRequestFieldSpecification.php',
Pre-prepare for hovercards Summary: D5120 and followups refactor and generalize object references in Remarkup -- notably, they move remarkup rules from a central location to the implementing applications. Preserve blame by doing moves/renames only first. This change moves application remarkup rules into those applications, and renames the ones D5120 modifies. Test Plan: Typed some preview text into a textarea, got a valid Remarkup render. Reviewers: vrana, chad Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5123
2013-02-26 23:57:41 +01:00
'DifferentialRemarkupRule' => 'applications/differential/remarkup/DifferentialRemarkupRule.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'DifferentialReplyHandler' => 'applications/differential/mail/DifferentialReplyHandler.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialResultsTableView' => 'applications/differential/view/DifferentialResultsTableView.php',
'DifferentialRevertPlanFieldSpecification' => 'applications/differential/field/specification/DifferentialRevertPlanFieldSpecification.php',
'DifferentialReviewRequestMail' => 'applications/differential/mail/DifferentialReviewRequestMail.php',
'DifferentialReviewedByFieldSpecification' => 'applications/differential/field/specification/DifferentialReviewedByFieldSpecification.php',
Compute reviewer stats Summary: The final goal is to display reviewers response time on homepage. This is a building block for it. The algorithm is quite strict - it doesn't count simple comment as response because reviewers would be able to cheat with comments like "I'm overwhelmed right now and will review next week". We are more liberate in Phabricator where reviewers response with comments without changing the status quite often but I'm not trying to improve response times in Phabricator so this is irrelevant. Reviewers in Facebook changes status more often (to clean their queue) so I follow this approach. There is currently no way to track reviewers silently added and removed in Edit Revision but it's not a big deal. The algorithm doesn't track commandeered revision, there's a TODO for it. Response times are put in two buckets: `$reviewed` and `$not_reviewed`. `$reviewed` contains reviewers who took action, `$not_reviewed` contains reviewers who didn't respond on time. I will probably compute average time from `$reviewed` and raise it for those `$not_reviewed` that are higher than this average. The idea is to not favor reviewers who were only lucky for being in a group with someone fast. Test Plan: Passed test. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3062
2012-07-25 02:58:33 +02:00
'DifferentialReviewerStats' => 'applications/differential/stats/DifferentialReviewerStats.php',
'DifferentialReviewerStatsTestCase' => 'applications/differential/stats/__tests__/DifferentialReviewerStatsTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialReviewersFieldSpecification' => 'applications/differential/field/specification/DifferentialReviewersFieldSpecification.php',
'DifferentialRevision' => 'applications/differential/storage/DifferentialRevision.php',
'DifferentialRevisionCommentListView' => 'applications/differential/view/DifferentialRevisionCommentListView.php',
'DifferentialRevisionCommentView' => 'applications/differential/view/DifferentialRevisionCommentView.php',
'DifferentialRevisionControlSystem' => 'applications/differential/constants/DifferentialRevisionControlSystem.php',
'DifferentialRevisionDetailRenderer' => 'applications/differential/controller/DifferentialRevisionDetailRenderer.php',
'DifferentialRevisionDetailView' => 'applications/differential/view/DifferentialRevisionDetailView.php',
'DifferentialRevisionEditController' => 'applications/differential/controller/DifferentialRevisionEditController.php',
'DifferentialRevisionEditor' => 'applications/differential/editor/DifferentialRevisionEditor.php',
'DifferentialRevisionIDFieldParserTestCase' => 'applications/differential/field/specification/__tests__/DifferentialRevisionIDFieldParserTestCase.php',
'DifferentialRevisionIDFieldSpecification' => 'applications/differential/field/specification/DifferentialRevisionIDFieldSpecification.php',
'DifferentialRevisionListController' => 'applications/differential/controller/DifferentialRevisionListController.php',
'DifferentialRevisionListData' => 'applications/differential/data/DifferentialRevisionListData.php',
'DifferentialRevisionListView' => 'applications/differential/view/DifferentialRevisionListView.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'DifferentialRevisionMailReceiver' => 'applications/differential/mail/DifferentialRevisionMailReceiver.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialRevisionQuery' => 'applications/differential/query/DifferentialRevisionQuery.php',
'DifferentialRevisionStatsController' => 'applications/differential/controller/DifferentialRevisionStatsController.php',
'DifferentialRevisionStatsView' => 'applications/differential/view/DifferentialRevisionStatsView.php',
change DifferentialRevisionDetailView to use newer fangled UI abstractions Summary: actions are still a bit messy - unsatisfactory icons (T2013 will help!) Test Plan: viewed diffs - they look good Reviewers: epriestley, vrana Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2007 Differential Revision: https://secure.phabricator.com/D3904
2012-12-11 23:59:27 +01:00
'DifferentialRevisionStatus' => 'applications/differential/constants/DifferentialRevisionStatus.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialRevisionStatusFieldSpecification' => 'applications/differential/field/specification/DifferentialRevisionStatusFieldSpecification.php',
'DifferentialRevisionUpdateHistoryView' => 'applications/differential/view/DifferentialRevisionUpdateHistoryView.php',
'DifferentialRevisionViewController' => 'applications/differential/controller/DifferentialRevisionViewController.php',
Improve Search architecture Summary: The search indexing API has several problems right now: - Always runs in-process. - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it. - Being able to use the task queue will also make rebuilding indexes faster. - Instead, make the API phid-oriented. - No uniform indexing API. - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird. - Instead, provide a uniform API. - No uniform CLI. - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers. - Instead, let indexers expose documents for indexing. - Not application-oriented. - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world. - Instead, move indexers to applications and load them with SymbolLoader. Test Plan: - `bin/search index` - Indexed one revision, one task. - Indexed `--type TASK`, `--type DREV`, etc., for all types. - Indexed `--all`. - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it. - Creating users is a pain; searched for a user after indexing. - Creating commits is a pain; searched for a commit after indexing. - Mocks aren't currently loadable in the result view, so their indexing is moot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: 20after4, aran Maniphest Tasks: T1991, T2104 Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
'DifferentialSearchIndexer' => 'applications/differential/search/DifferentialSearchIndexer.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialSubscribeController' => 'applications/differential/controller/DifferentialSubscribeController.php',
'DifferentialSummaryFieldSpecification' => 'applications/differential/field/specification/DifferentialSummaryFieldSpecification.php',
'DifferentialTasksAttacher' => 'applications/differential/DifferentialTasksAttacher.php',
'DifferentialTestPlanFieldSpecification' => 'applications/differential/field/specification/DifferentialTestPlanFieldSpecification.php',
'DifferentialTitleFieldSpecification' => 'applications/differential/field/specification/DifferentialTitleFieldSpecification.php',
'DifferentialUnitFieldSpecification' => 'applications/differential/field/specification/DifferentialUnitFieldSpecification.php',
'DifferentialUnitStatus' => 'applications/differential/constants/DifferentialUnitStatus.php',
'DifferentialUnitTestResult' => 'applications/differential/constants/DifferentialUnitTestResult.php',
'DiffusionBranchInformation' => 'applications/diffusion/data/DiffusionBranchInformation.php',
'DiffusionBranchTableController' => 'applications/diffusion/controller/DiffusionBranchTableController.php',
'DiffusionBranchTableView' => 'applications/diffusion/view/DiffusionBranchTableView.php',
'DiffusionBrowseController' => 'applications/diffusion/controller/DiffusionBrowseController.php',
'DiffusionBrowseFileController' => 'applications/diffusion/controller/DiffusionBrowseFileController.php',
Diffusion - move DiffusionBrowseQuery => Conduit Summary: see title. Ref T2784. Test Plan: In diffusion, for each of SVN, Mercurial, and Git, I loaded up /diffusion/CALLSIGN/. I verified the README was displayed and things looked good. Next I clicked on "browse" on the top-most commit and verified things looked correct. Also clicked through to a file for a good measure and things looked good. In owners, for each of SVN, Mercurial, and Git, I played around with the path typeahead / validator. It worked correctly! Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5883
2013-05-10 20:02:58 +02:00
'DiffusionBrowseResultSet' => 'applications/diffusion/data/DiffusionBrowseResultSet.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionBrowseTableView' => 'applications/diffusion/view/DiffusionBrowseTableView.php',
'DiffusionChangeController' => 'applications/diffusion/controller/DiffusionChangeController.php',
'DiffusionCommentListView' => 'applications/diffusion/view/DiffusionCommentListView.php',
'DiffusionCommentView' => 'applications/diffusion/view/DiffusionCommentView.php',
Load commit branches and tags by AJAX Summary: Each query takes over 2 seconds in FBCODE. I didn't find a way how to speed them up. There's also no easy way how to parallelize them at least. So AJAX is the last instance. Test Plan: Loaded commit with one branch and no tag. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3112
2012-08-01 01:27:48 +02:00
'DiffusionCommitBranchesController' => 'applications/diffusion/controller/DiffusionCommitBranchesController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionCommitChangeTableView' => 'applications/diffusion/view/DiffusionCommitChangeTableView.php',
'DiffusionCommitController' => 'applications/diffusion/controller/DiffusionCommitController.php',
Allow commits to be associated with projects and associated goodies Summary: - Commit detail view - List of projects - "edit" action which takes the user to a simple form where they can only add / remove projects. - Integrated the project relationship into the commit search indexer - fixed a bug from D790; it seems you must select the column if you're going to join against it later. Without this change searching for author or projectfails 100% for me. Test Plan: added and removed projects. verified appropriate projects showed up in detail and edit view. searched for commits by project and found the ones I was supposed to...! Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1614 Differential Revision: https://secure.phabricator.com/D3189
2012-08-08 19:03:41 +02:00
'DiffusionCommitEditController' => 'applications/diffusion/controller/DiffusionCommitEditController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionCommitParentsQuery' => 'applications/diffusion/query/parents/DiffusionCommitParentsQuery.php',
Prepare Diffusion for hovercards Summary: Move Diffusion to be hovercard-ready, and expand our ability to resolve commit references. - Link unqualified hashes of 7 characters or more which match a commit. - Link qualified hashes of 5 characters or more which match a commit. - Support `{...}` syntax. Test Plan: {F33896} Reviewers: chad, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5121
2013-02-27 17:04:54 +01:00
'DiffusionCommitQuery' => 'applications/diffusion/query/DiffusionCommitQuery.php',
Load commit branches and tags by AJAX Summary: Each query takes over 2 seconds in FBCODE. I didn't find a way how to speed them up. There's also no easy way how to parallelize them at least. So AJAX is the last instance. Test Plan: Loaded commit with one branch and no tag. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3112
2012-08-01 01:27:48 +02:00
'DiffusionCommitTagsController' => 'applications/diffusion/controller/DiffusionCommitTagsController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionController' => 'applications/diffusion/controller/DiffusionController.php',
'DiffusionDiffController' => 'applications/diffusion/controller/DiffusionDiffController.php',
'DiffusionEmptyResultView' => 'applications/diffusion/view/DiffusionEmptyResultView.php',
Diffusion - move some DiffusionRequest queries to occur over Conduit Summary: Ref T2784. This one was a wee bit complicated. Had to add PhabricatorUser and concept of initFromConduit (or not) to DiffusionRequest. Test Plan: foreach repo, visited CALLSIGN and clicked a commit and verified they laoded correctly. Hacked code to hit NOT via Conduit and repeated tests to great success. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5928
2013-05-15 00:32:19 +02:00
'DiffusionExpandCommitQueryException' => 'applications/diffusion/exception/DiffusionExpandCommitQueryException.php',
'DiffusionExpandShortNameQuery' => 'applications/diffusion/query/expandshortname/DiffusionExpandShortNameQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionExternalController' => 'applications/diffusion/controller/DiffusionExternalController.php',
'DiffusionFileContent' => 'applications/diffusion/data/DiffusionFileContent.php',
'DiffusionFileContentQuery' => 'applications/diffusion/query/filecontent/DiffusionFileContentQuery.php',
DiffusionBranchQuery => Conduit Summary: ref T2784. This one had a few fun spots where I had to move data around. Also, is there some common object (or should I add it?) that can do this toDictionary newFromConduit stuff? Also, this assumes D5803 is largely correct at the time of this diff. Test Plan: browsed mercurial and git repository page. saw the branches i expected. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5810
2013-05-01 23:56:36 +02:00
'DiffusionGitBranch' => 'applications/diffusion/data/DiffusionGitBranch.php',
'DiffusionGitBranchTestCase' => 'applications/diffusion/data/__tests__/DiffusionGitBranchTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionGitCommitParentsQuery' => 'applications/diffusion/query/parents/DiffusionGitCommitParentsQuery.php',
Diffusion - move some DiffusionRequest queries to occur over Conduit Summary: Ref T2784. This one was a wee bit complicated. Had to add PhabricatorUser and concept of initFromConduit (or not) to DiffusionRequest. Test Plan: foreach repo, visited CALLSIGN and clicked a commit and verified they laoded correctly. Hacked code to hit NOT via Conduit and repeated tests to great success. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5928
2013-05-15 00:32:19 +02:00
'DiffusionGitExpandShortNameQuery' => 'applications/diffusion/query/expandshortname/DiffusionGitExpandShortNameQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionGitFileContentQuery' => 'applications/diffusion/query/filecontent/DiffusionGitFileContentQuery.php',
'DiffusionGitRawDiffQuery' => 'applications/diffusion/query/rawdiff/DiffusionGitRawDiffQuery.php',
'DiffusionGitRequest' => 'applications/diffusion/request/DiffusionGitRequest.php',
Diffusion - move querying for stable commit name to occur over conduit Summary: Ref T2784. This is a lower-level one from drequest so it gets the conditional initialization treatment. Consolidated SVN as well even though SVN is issuing database queries; I felt better about the code de-duplication despite the small performance hit when we could just query the DB directly in the SVN case. Test Plan: browsed around my Phabricator repositories in Mercurial, Git, and SVN flavors. Looked good. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5956
2013-05-17 23:12:46 +02:00
'DiffusionGitStableCommitNameQuery' => 'applications/diffusion/query/stablecommitname/DiffusionGitStableCommitNameQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionHistoryController' => 'applications/diffusion/controller/DiffusionHistoryController.php',
'DiffusionHistoryTableView' => 'applications/diffusion/view/DiffusionHistoryTableView.php',
'DiffusionHomeController' => 'applications/diffusion/controller/DiffusionHomeController.php',
Adding hovercard event listeners for Users, Revisions, Conpherence and Commits Summary: Refs T1048 Adding Differential Hovercard EventListener Adding People Hovercard EventListener Adding basic Diffusion hovercard Adding Conpherence Hovercard EventListener Test Plan: Used in a combo with working hovercards. So beautiful. Also visited test page. Works alright. awesometown Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1048 Differential Revision: https://secure.phabricator.com/D5576
2013-04-06 02:01:54 +02:00
'DiffusionHovercardEventListener' => 'applications/diffusion/events/DiffusionHovercardEventListener.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionInlineCommentController' => 'applications/diffusion/controller/DiffusionInlineCommentController.php',
Make inline comment preview work in Diffusion Summary: created a PhabricatorInlineCommentPreviewController so controllers in Diffusion and Differential respectively just have to handle the URI mapping and data loading like good little controllers. Test Plan: left inline comments on commits, deleted inline commits, submitted inline comments -- all worked well did the same on some diffs Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1176 Differential Revision: https://secure.phabricator.com/D3034
2012-07-23 20:01:28 +02:00
'DiffusionInlineCommentPreviewController' => 'applications/diffusion/controller/DiffusionInlineCommentPreviewController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionLastModifiedController' => 'applications/diffusion/controller/DiffusionLastModifiedController.php',
Display lint overview in Diffusion Summary: I will add links from /diffusion/ARC/lint/ in future diff. Test Plan: /diffusion/ - clicked on lint messages link. /diffusion/ARC/ - clicked on lint messages link. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3926
2012-11-08 20:11:44 +01:00
'DiffusionLintController' => 'applications/diffusion/controller/DiffusionLintController.php',
Display list of lint problems in Diffusion Test Plan: /diffusion/ARC/lint/master/, saw links. /diffusion/ARC/lint/master/?lint=SPELL0, saw two links. /diffusion/ARC/lint/master/src/lint/linter/ArcanistFilenameLinter.php?lint=SPELL0, saw link. Clicked on everything. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2038 Differential Revision: https://secure.phabricator.com/D3931
2012-11-09 01:13:21 +01:00
'DiffusionLintDetailsController' => 'applications/diffusion/controller/DiffusionLintDetailsController.php',
Simplify and optimize save_lint.php Test Plan: Ran it. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2038 Differential Revision: https://secure.phabricator.com/D3933
2012-11-09 03:37:15 +01:00
'DiffusionLintSaveRunner' => 'applications/diffusion/DiffusionLintSaveRunner.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionMercurialCommitParentsQuery' => 'applications/diffusion/query/parents/DiffusionMercurialCommitParentsQuery.php',
Diffusion - move some DiffusionRequest queries to occur over Conduit Summary: Ref T2784. This one was a wee bit complicated. Had to add PhabricatorUser and concept of initFromConduit (or not) to DiffusionRequest. Test Plan: foreach repo, visited CALLSIGN and clicked a commit and verified they laoded correctly. Hacked code to hit NOT via Conduit and repeated tests to great success. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5928
2013-05-15 00:32:19 +02:00
'DiffusionMercurialExpandShortNameQuery' => 'applications/diffusion/query/expandshortname/DiffusionMercurialExpandShortNameQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionMercurialFileContentQuery' => 'applications/diffusion/query/filecontent/DiffusionMercurialFileContentQuery.php',
'DiffusionMercurialRawDiffQuery' => 'applications/diffusion/query/rawdiff/DiffusionMercurialRawDiffQuery.php',
'DiffusionMercurialRequest' => 'applications/diffusion/request/DiffusionMercurialRequest.php',
Diffusion - move querying for stable commit name to occur over conduit Summary: Ref T2784. This is a lower-level one from drequest so it gets the conditional initialization treatment. Consolidated SVN as well even though SVN is issuing database queries; I felt better about the code de-duplication despite the small performance hit when we could just query the DB directly in the SVN case. Test Plan: browsed around my Phabricator repositories in Mercurial, Git, and SVN flavors. Looked good. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5956
2013-05-17 23:12:46 +02:00
'DiffusionMercurialStableCommitNameQuery' => 'applications/diffusion/query/stablecommitname/DiffusionMercurialStableCommitNameQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionPathChange' => 'applications/diffusion/data/DiffusionPathChange.php',
'DiffusionPathChangeQuery' => 'applications/diffusion/query/pathchange/DiffusionPathChangeQuery.php',
'DiffusionPathCompleteController' => 'applications/diffusion/controller/DiffusionPathCompleteController.php',
'DiffusionPathIDQuery' => 'applications/diffusion/query/pathid/DiffusionPathIDQuery.php',
'DiffusionPathQuery' => 'applications/diffusion/query/DiffusionPathQuery.php',
'DiffusionPathQueryTestCase' => 'applications/diffusion/query/pathid/__tests__/DiffusionPathQueryTestCase.php',
'DiffusionPathValidateController' => 'applications/diffusion/controller/DiffusionPathValidateController.php',
Update PeopleMenu to only show integration with applications if they are installed Summary: do so via event engine. note different order now... Test Plan: toggled "show beta applications" to off and noted that Conpherence disappeared. Otherwise noted that links showed. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2424 Differential Revision: https://secure.phabricator.com/D4708
2013-02-05 22:46:02 +01:00
'DiffusionPeopleMenuEventListener' => 'applications/diffusion/events/DiffusionPeopleMenuEventListener.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionQuery' => 'applications/diffusion/query/DiffusionQuery.php',
'DiffusionRawDiffQuery' => 'applications/diffusion/query/rawdiff/DiffusionRawDiffQuery.php',
Pre-prepare for hovercards Summary: D5120 and followups refactor and generalize object references in Remarkup -- notably, they move remarkup rules from a central location to the implementing applications. Preserve blame by doing moves/renames only first. This change moves application remarkup rules into those applications, and renames the ones D5120 modifies. Test Plan: Typed some preview text into a textarea, got a valid Remarkup render. Reviewers: vrana, chad Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5123
2013-02-26 23:57:41 +01:00
'DiffusionRemarkupRule' => 'applications/diffusion/remarkup/DiffusionRemarkupRule.php',
Read rename information from DB instead of repository Summary: We already have this information for all VCSes, there's no point in parsing it again. We currently support it only for Git and I remember there were some bugs in it. It should also be faster. Test Plan: Blamed previous revision of a file which was moved in SVN. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3564
2012-09-28 23:36:47 +02:00
'DiffusionRenameHistoryQuery' => 'applications/diffusion/query/DiffusionRenameHistoryQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionRepositoryController' => 'applications/diffusion/controller/DiffusionRepositoryController.php',
Begin transacitonalizing repository edits and provide a more sensible edit interface Summary: Ref T2231, T603. Plan of attack here is pretty much: - Built out a new (currently not linked in the UI) edit interface in Diffusion which is transaction-based and has a sensible layout. - Build out a new create interface based on PagedForm which dumps into the new edit interface. - Throw the old stuff away. - Everyone lives happily ever after. Test Plan: {F44163} {F44164} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D6029
2013-05-24 21:37:42 +02:00
'DiffusionRepositoryEditBasicController' => 'applications/diffusion/controller/DiffusionRepositoryEditBasicController.php',
'DiffusionRepositoryEditController' => 'applications/diffusion/controller/DiffusionRepositoryEditController.php',
Provide transaction-based edits of repository encoding Summary: Adds support for the "encoding" field to the new transactional interface. Test Plan: {F44189} {F44190} Some of the encodings in the second screen are from testing, and can no longer be set. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6035
2013-05-25 15:30:38 +02:00
'DiffusionRepositoryEditEncodingController' => 'applications/diffusion/controller/DiffusionRepositoryEditEncodingController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionRepositoryPath' => 'applications/diffusion/data/DiffusionRepositoryPath.php',
DiffusionBranchQuery => Conduit Summary: ref T2784. This one had a few fun spots where I had to move data around. Also, is there some common object (or should I add it?) that can do this toDictionary newFromConduit stuff? Also, this assumes D5803 is largely correct at the time of this diff. Test Plan: browsed mercurial and git repository page. saw the branches i expected. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5810
2013-05-01 23:56:36 +02:00
'DiffusionRepositoryTag' => 'applications/diffusion/data/DiffusionRepositoryTag.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionRequest' => 'applications/diffusion/request/DiffusionRequest.php',
'DiffusionSetupException' => 'applications/diffusion/exception/DiffusionSetupException.php',
Diffusion - move querying for stable commit name to occur over conduit Summary: Ref T2784. This is a lower-level one from drequest so it gets the conditional initialization treatment. Consolidated SVN as well even though SVN is issuing database queries; I felt better about the code de-duplication despite the small performance hit when we could just query the DB directly in the SVN case. Test Plan: browsed around my Phabricator repositories in Mercurial, Git, and SVN flavors. Looked good. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5956
2013-05-17 23:12:46 +02:00
'DiffusionStableCommitNameQuery' => 'applications/diffusion/query/stablecommitname/DiffusionStableCommitNameQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionSvnCommitParentsQuery' => 'applications/diffusion/query/parents/DiffusionSvnCommitParentsQuery.php',
'DiffusionSvnFileContentQuery' => 'applications/diffusion/query/filecontent/DiffusionSvnFileContentQuery.php',
'DiffusionSvnRawDiffQuery' => 'applications/diffusion/query/rawdiff/DiffusionSvnRawDiffQuery.php',
'DiffusionSvnRequest' => 'applications/diffusion/request/DiffusionSvnRequest.php',
Diffusion - move querying for stable commit name to occur over conduit Summary: Ref T2784. This is a lower-level one from drequest so it gets the conditional initialization treatment. Consolidated SVN as well even though SVN is issuing database queries; I felt better about the code de-duplication despite the small performance hit when we could just query the DB directly in the SVN case. Test Plan: browsed around my Phabricator repositories in Mercurial, Git, and SVN flavors. Looked good. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5956
2013-05-17 23:12:46 +02:00
'DiffusionSvnStableCommitNameQuery' => 'applications/diffusion/query/stablecommitname/DiffusionSvnStableCommitNameQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionSymbolController' => 'applications/diffusion/controller/DiffusionSymbolController.php',
'DiffusionSymbolQuery' => 'applications/diffusion/query/DiffusionSymbolQuery.php',
'DiffusionTagListController' => 'applications/diffusion/controller/DiffusionTagListController.php',
'DiffusionTagListView' => 'applications/diffusion/view/DiffusionTagListView.php',
'DiffusionURITestCase' => 'applications/diffusion/request/__tests__/DiffusionURITestCase.php',
'DiffusionView' => 'applications/diffusion/view/DiffusionView.php',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerArticleAtomizer' => 'applications/diviner/atomizer/DivinerArticleAtomizer.php',
'DivinerAtom' => 'applications/diviner/atom/DivinerAtom.php',
'DivinerAtomCache' => 'applications/diviner/cache/DivinerAtomCache.php',
Add an Atom controller to Diviner Summary: Ref T988. Lots of rough edges still, but this pulls the right data and dumps it into a reasonable-looking shell. Test Plan: {F44883} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6104
2013-06-01 00:14:39 +02:00
'DivinerAtomController' => 'applications/diviner/controller/DivinerAtomController.php',
Use ApplicationSearch in Diviner Summary: Ref T988. Ref T2625. Rough cut of ApplicationSearch in Diviner, for detailed Atom queries. This isn't useful yet, and isn't linked in the UI. Test Plan: {F44836} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T2625 Differential Revision: https://secure.phabricator.com/D6094
2013-05-31 19:52:25 +02:00
'DivinerAtomListController' => 'applications/diviner/controller/DivinerAtomListController.php',
'DivinerAtomQuery' => 'applications/diviner/query/DivinerAtomQuery.php',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerAtomRef' => 'applications/diviner/atom/DivinerAtomRef.php',
Use ApplicationSearch in Diviner Summary: Ref T988. Ref T2625. Rough cut of ApplicationSearch in Diviner, for detailed Atom queries. This isn't useful yet, and isn't linked in the UI. Test Plan: {F44836} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T2625 Differential Revision: https://secure.phabricator.com/D6094
2013-05-31 19:52:25 +02:00
'DivinerAtomSearchEngine' => 'applications/diviner/query/DivinerAtomSearchEngine.php',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerAtomizeWorkflow' => 'applications/diviner/workflow/DivinerAtomizeWorkflow.php',
'DivinerAtomizer' => 'applications/diviner/atomizer/DivinerAtomizer.php',
Add a book controller and various amenities to Diviner's live view Summary: Ref T988. Mostly backend changes, with a very rough frontend on top of them. See Conpherence discussion. Test Plan: {F45010} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6113
2013-06-04 20:15:34 +02:00
'DivinerBookController' => 'applications/diviner/controller/DivinerBookController.php',
Use ApplicationSearch in Diviner Summary: Ref T988. Ref T2625. Rough cut of ApplicationSearch in Diviner, for detailed Atom queries. This isn't useful yet, and isn't linked in the UI. Test Plan: {F44836} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T2625 Differential Revision: https://secure.phabricator.com/D6094
2013-05-31 19:52:25 +02:00
'DivinerBookQuery' => 'applications/diviner/query/DivinerBookQuery.php',
'DivinerController' => 'applications/diviner/controller/DivinerController.php',
Add "live" publisher and storage to Diviner Summary: Ref T988. This adds basics for the non-static publishing target: - Storage (called "Live", e.g. `DivinerLiveAtom` to distinguish it from shared classes like `DivinerAtom`). - Mostly populate the storage. - Some minor fixes and improvements. Test Plan: Generated docs, looked at DB, saw mostly-sensible output. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D5973
2013-05-20 19:18:26 +02:00
'DivinerDAO' => 'applications/diviner/storage/DivinerDAO.php',
Move Diviner further toward usability Summary: - Complete the "project" -> "book" stuff. This is cleaner conceptually and keeps us from having yet another meaning for the word "project". - Normalize symbols during atomization. This simplifies publishing a great deal, and allows static documentation to link to dynamic documentation and vice versa, because the canonical names of symbols are agreed upon (we can tweak the actual algorithm). - Give articles a specifiable name distinct from the title, and default to something like "support" instead of "Get Help! Get Support!" so URIs end up more readable (not "Get_Help!_Get_Support!"). - Have the atomizers set book information on atoms. - Implement very basic publishers. Publishers are basically glue code between the atomization process and the rendering process -- the two we'll have initially are "static" (publish to files on disk) and "phabricator" (or similar -- publish into the database). - Handle duplicate symbol definitions in the atomize and publish pipelines. This fixes the issue where a project defines two functions named "idx()" and we currently tell them not to do that and break. Realistically, this is common in the real world and we should just roll our eyes and do the legwork to generate documentation as best we can. - Particularly, dirty all atoms with the same name as a dirty atom (e.g., if 'function f()' is updated, regnerate the documentation for all functions named f() in the book). - When publishing, we publish these at "function/f/@1", "function/f/@2". The base page will offer to disambiguate ("There are 8 functions named 'f' in this codebase, which one do you want?"). - Implement a very very basic renderer. This generates the actual HTML (or text, or XML, or whatever else) for the documentation, which the publisher dumps onto disk or into a database or whatever. - The atomize workflow actually needs to depend on books, at least sort of, so make it load config and use it properly. - Propagate multilevel dirties through the graph. If "C extends B" and "B extends A", we should regenerate C when A changes. Prior to this diff, we would regnerate B only. Test Plan: Generated some documentation. Named two articles "feedback", generated docs, saw "article/feedback/@1/" and "article/feedback/@2/" created. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4896
2013-02-18 00:39:36 +01:00
'DivinerDefaultRenderer' => 'applications/diviner/renderer/DivinerDefaultRenderer.php',
Add a publish cache for the Diviner static publisher Summary: Keep track of what we've written to disk, and regenerate only new documents. Test Plan: Changed a small number of files, saw that number of files get regenerated. Ran with "--clean" and saw everything regenerate. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4897
2013-02-18 00:40:00 +01:00
'DivinerDiskCache' => 'applications/diviner/cache/DivinerDiskCache.php',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerFileAtomizer' => 'applications/diviner/atomizer/DivinerFileAtomizer.php',
'DivinerGenerateWorkflow' => 'applications/diviner/workflow/DivinerGenerateWorkflow.php',
Use ApplicationSearch in Diviner Summary: Ref T988. Ref T2625. Rough cut of ApplicationSearch in Diviner, for detailed Atom queries. This isn't useful yet, and isn't linked in the UI. Test Plan: {F44836} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T2625 Differential Revision: https://secure.phabricator.com/D6094
2013-05-31 19:52:25 +02:00
'DivinerLegacyController' => 'applications/diviner/controller/DivinerLegacyController.php',
Add "live" publisher and storage to Diviner Summary: Ref T988. This adds basics for the non-static publishing target: - Storage (called "Live", e.g. `DivinerLiveAtom` to distinguish it from shared classes like `DivinerAtom`). - Mostly populate the storage. - Some minor fixes and improvements. Test Plan: Generated docs, looked at DB, saw mostly-sensible output. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D5973
2013-05-20 19:18:26 +02:00
'DivinerLiveAtom' => 'applications/diviner/storage/DivinerLiveAtom.php',
'DivinerLiveBook' => 'applications/diviner/storage/DivinerLiveBook.php',
'DivinerLivePublisher' => 'applications/diviner/publisher/DivinerLivePublisher.php',
'DivinerLiveSymbol' => 'applications/diviner/storage/DivinerLiveSymbol.php',
Add a publish cache for the Diviner static publisher Summary: Keep track of what we've written to disk, and regenerate only new documents. Test Plan: Changed a small number of files, saw that number of files get regenerated. Ran with "--clean" and saw everything regenerate. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4897
2013-02-18 00:40:00 +01:00
'DivinerPublishCache' => 'applications/diviner/cache/DivinerPublishCache.php',
Move Diviner further toward usability Summary: - Complete the "project" -> "book" stuff. This is cleaner conceptually and keeps us from having yet another meaning for the word "project". - Normalize symbols during atomization. This simplifies publishing a great deal, and allows static documentation to link to dynamic documentation and vice versa, because the canonical names of symbols are agreed upon (we can tweak the actual algorithm). - Give articles a specifiable name distinct from the title, and default to something like "support" instead of "Get Help! Get Support!" so URIs end up more readable (not "Get_Help!_Get_Support!"). - Have the atomizers set book information on atoms. - Implement very basic publishers. Publishers are basically glue code between the atomization process and the rendering process -- the two we'll have initially are "static" (publish to files on disk) and "phabricator" (or similar -- publish into the database). - Handle duplicate symbol definitions in the atomize and publish pipelines. This fixes the issue where a project defines two functions named "idx()" and we currently tell them not to do that and break. Realistically, this is common in the real world and we should just roll our eyes and do the legwork to generate documentation as best we can. - Particularly, dirty all atoms with the same name as a dirty atom (e.g., if 'function f()' is updated, regnerate the documentation for all functions named f() in the book). - When publishing, we publish these at "function/f/@1", "function/f/@2". The base page will offer to disambiguate ("There are 8 functions named 'f' in this codebase, which one do you want?"). - Implement a very very basic renderer. This generates the actual HTML (or text, or XML, or whatever else) for the documentation, which the publisher dumps onto disk or into a database or whatever. - The atomize workflow actually needs to depend on books, at least sort of, so make it load config and use it properly. - Propagate multilevel dirties through the graph. If "C extends B" and "B extends A", we should regenerate C when A changes. Prior to this diff, we would regnerate B only. Test Plan: Generated some documentation. Named two articles "feedback", generated docs, saw "article/feedback/@1/" and "article/feedback/@2/" created. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4896
2013-02-18 00:39:36 +01:00
'DivinerPublisher' => 'applications/diviner/publisher/DivinerPublisher.php',
Improve Diviner handling of paths and remarkup Summary: - Currently, the atomizers don't emit atoms with the right file in all cases. Make them always emit it correctly. - Currently, we use absolute paths in some cases and relative paths in other cases. Use them consistently: relative when storing/presenting, absolute when accessing data. - Don't preserve linebreaks when marking up documentation (documentation is generally wrapped at 80col, but should not be wrapped in this way when displayed). - Markup Diviner link rules (albeit uselesly). Test Plan: Before: {F33044} After: {F33045} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4992
2013-02-18 00:40:44 +01:00
'DivinerRemarkupRuleSymbol' => 'applications/diviner/markup/DivinerRemarkupRuleSymbol.php',
Move Diviner further toward usability Summary: - Complete the "project" -> "book" stuff. This is cleaner conceptually and keeps us from having yet another meaning for the word "project". - Normalize symbols during atomization. This simplifies publishing a great deal, and allows static documentation to link to dynamic documentation and vice versa, because the canonical names of symbols are agreed upon (we can tweak the actual algorithm). - Give articles a specifiable name distinct from the title, and default to something like "support" instead of "Get Help! Get Support!" so URIs end up more readable (not "Get_Help!_Get_Support!"). - Have the atomizers set book information on atoms. - Implement very basic publishers. Publishers are basically glue code between the atomization process and the rendering process -- the two we'll have initially are "static" (publish to files on disk) and "phabricator" (or similar -- publish into the database). - Handle duplicate symbol definitions in the atomize and publish pipelines. This fixes the issue where a project defines two functions named "idx()" and we currently tell them not to do that and break. Realistically, this is common in the real world and we should just roll our eyes and do the legwork to generate documentation as best we can. - Particularly, dirty all atoms with the same name as a dirty atom (e.g., if 'function f()' is updated, regnerate the documentation for all functions named f() in the book). - When publishing, we publish these at "function/f/@1", "function/f/@2". The base page will offer to disambiguate ("There are 8 functions named 'f' in this codebase, which one do you want?"). - Implement a very very basic renderer. This generates the actual HTML (or text, or XML, or whatever else) for the documentation, which the publisher dumps onto disk or into a database or whatever. - The atomize workflow actually needs to depend on books, at least sort of, so make it load config and use it properly. - Propagate multilevel dirties through the graph. If "C extends B" and "B extends A", we should regenerate C when A changes. Prior to this diff, we would regnerate B only. Test Plan: Generated some documentation. Named two articles "feedback", generated docs, saw "article/feedback/@1/" and "article/feedback/@2/" created. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4896
2013-02-18 00:39:36 +01:00
'DivinerRenderer' => 'applications/diviner/renderer/DivinerRenderer.php',
'DivinerStaticPublisher' => 'applications/diviner/publisher/DivinerStaticPublisher.php',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerWorkflow' => 'applications/diviner/workflow/DivinerWorkflow.php',
Make various Drydock improvements Summary: Tightens up a bunch of stuff: - In `drydock lease`, pull and print logs so the user can see what's happening. - Remove `DrydockAllocator`, which was a dumb class that did nothing. Move the tiny amount of logic it held directly to `DrydockLease`. - Move `resourceType` from worker task metadata directly to `DrydockLease`. Other things (like the web UI) can be more informative with this information available. - Pass leases to `allocateResource()`. We always allocate in response to a lease activation request, and the lease often has vital information. This also allows us to associate logs with leases correctly. Test Plan: Ran `drydock lease --type host` and saw it perform a host allocation in EC2. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3870
2012-11-02 00:53:17 +01:00
'DrydockAllocatorWorker' => 'applications/drydock/worker/DrydockAllocatorWorker.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockApacheWebrootInterface' => 'applications/drydock/interface/webroot/DrydockApacheWebrootInterface.php',
'DrydockBlueprint' => 'applications/drydock/blueprint/DrydockBlueprint.php',
Improve Drydock's ability to allocate leases correctly Summary: Right now, Drydock gives out multiple leases to the same working copy and gives out leases to working copies with repository "P" in them when the user requested some other repository. Add two callbacks: - `canAllocateLease()` - allows a blueprint to reject a lease on a resource because of a fundamental incompatibility, like "it's a working copy with Phabricator in it, but the lease wants a working copy with Javelin in it". - `shouldAllocateLease()` - allows a blueprint to reject a lease on a resource because of resource limits, like "only one active lease can own a working copy at a time". Also cleaned up various other things. Test Plan: After implementing the callbacks, Drydock has the correct behavior: - It gives multiple leases on `localhost`, but only one lease per working-copy resource. - It does not grant leases on resources with repository X to requests for repository Y. Ran `bin/drydock lease --type working-copy --repositoryID 12` and similar repeatedly and verified results in the web console. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D4166
2012-12-13 03:42:12 +01:00
'DrydockBlueprintScopeGuard' => 'applications/drydock/util/DrydockBlueprintScopeGuard.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockCommandInterface' => 'applications/drydock/interface/command/DrydockCommandInterface.php',
'DrydockConstants' => 'applications/drydock/constants/DrydockConstants.php',
'DrydockController' => 'applications/drydock/controller/DrydockController.php',
'DrydockDAO' => 'applications/drydock/storage/DrydockDAO.php',
'DrydockInterface' => 'applications/drydock/interface/DrydockInterface.php',
'DrydockLease' => 'applications/drydock/storage/DrydockLease.php',
'DrydockLeaseListController' => 'applications/drydock/controller/DrydockLeaseListController.php',
Show Drydock resource leases, add DrydockLeaseQuery, allow reuse of working copies Summary: Minor updates to Drydock things to make them work better. In particular, after this patch working copies are correctly allocated or reused. Test Plan: Ran "reparse.php --harbormaster <derp derp>", saw reuse of working copies when unleased resources were avilable. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D4216
2012-12-17 22:53:32 +01:00
'DrydockLeaseQuery' => 'applications/drydock/query/DrydockLeaseQuery.php',
Allow leases to be explicitly released via web or CLI Summary: Permit the forcible release of Drydock leases. The implementation isn't very exciting for now. Test Plan: Released leases via web and CLI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D4181
2012-12-15 00:42:58 +01:00
'DrydockLeaseReleaseController' => 'applications/drydock/controller/DrydockLeaseReleaseController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockLeaseStatus' => 'applications/drydock/constants/DrydockLeaseStatus.php',
Make minor improvements to Drydock web interface Summary: Consolidate some code and start on lease detail pages. Test Plan: {F22783} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3901
2012-11-07 00:28:33 +01:00
'DrydockLeaseViewController' => 'applications/drydock/controller/DrydockLeaseViewController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockLocalCommandInterface' => 'applications/drydock/interface/command/DrydockLocalCommandInterface.php',
'DrydockLocalHostBlueprint' => 'applications/drydock/blueprint/DrydockLocalHostBlueprint.php',
'DrydockLog' => 'applications/drydock/storage/DrydockLog.php',
'DrydockLogController' => 'applications/drydock/controller/DrydockLogController.php',
'DrydockLogQuery' => 'applications/drydock/query/DrydockLogQuery.php',
Add a "close" action to Drydock resources Summary: This does nothing fancy, just closes the resource and releases/breaks leases. They'll get cleaned up in some to-be-written GC process. Test Plan: Closed resources from web UI and CLI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3998
2012-11-27 21:48:03 +01:00
'DrydockManagementCloseWorkflow' => 'applications/drydock/management/DrydockManagementCloseWorkflow.php',
Modernize the `drydock` script Summary: Add a bin/drydock symlink and break it into workflows. Nothing too special here. Test Plan: Ran `bin/drydock wait-for-lease`, `bin/drydock lease`, `bin/drydock help`, etc. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3867
2012-11-01 23:30:14 +01:00
'DrydockManagementLeaseWorkflow' => 'applications/drydock/management/DrydockManagementLeaseWorkflow.php',
Allow leases to be explicitly released via web or CLI Summary: Permit the forcible release of Drydock leases. The implementation isn't very exciting for now. Test Plan: Released leases via web and CLI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D4181
2012-12-15 00:42:58 +01:00
'DrydockManagementReleaseWorkflow' => 'applications/drydock/management/DrydockManagementReleaseWorkflow.php',
Modernize the `drydock` script Summary: Add a bin/drydock symlink and break it into workflows. Nothing too special here. Test Plan: Ran `bin/drydock wait-for-lease`, `bin/drydock lease`, `bin/drydock help`, etc. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3867
2012-11-01 23:30:14 +01:00
'DrydockManagementWaitForLeaseWorkflow' => 'applications/drydock/management/DrydockManagementWaitForLeaseWorkflow.php',
'DrydockManagementWorkflow' => 'applications/drydock/management/DrydockManagementWorkflow.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockResource' => 'applications/drydock/storage/DrydockResource.php',
Add a "close" action to Drydock resources Summary: This does nothing fancy, just closes the resource and releases/breaks leases. They'll get cleaned up in some to-be-written GC process. Test Plan: Closed resources from web UI and CLI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3998
2012-11-27 21:48:03 +01:00
'DrydockResourceCloseController' => 'applications/drydock/controller/DrydockResourceCloseController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockResourceListController' => 'applications/drydock/controller/DrydockResourceListController.php',
Make most Drydock web interfaces work with mobile Summary: The logs bits still need some work but add crumbs/lists to everything else. Also build a propery DrydockResourceQuery. Test Plan: Looked at lease list/detail; resource list/detail. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D4221
2012-12-17 23:47:21 +01:00
'DrydockResourceQuery' => 'applications/drydock/query/DrydockResourceQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockResourceStatus' => 'applications/drydock/constants/DrydockResourceStatus.php',
Add a detail view for resources in Drydock Summary: Nothing fancy here, just add a detail page. Test Plan: Looked at detail page. {F24808} Reviewers: btrahan Reviewed By: btrahan CC: aran, vrana Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3995
2012-11-20 22:25:22 +01:00
'DrydockResourceViewController' => 'applications/drydock/controller/DrydockResourceViewController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockSSHCommandInterface' => 'applications/drydock/interface/command/DrydockSSHCommandInterface.php',
'DrydockWebrootInterface' => 'applications/drydock/interface/webroot/DrydockWebrootInterface.php',
Allow Drydock to allocate (very basic) working copy resources Summary: This is missing a lot of features, but technically allows working copy allocation. Test Plan: Ran `drydock lease --type working-copy --attributes repositoryID=12`, got a working copy of Phabricator allocated on disk. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3999
2012-11-27 21:48:14 +01:00
'DrydockWorkingCopyBlueprint' => 'applications/drydock/blueprint/DrydockWorkingCopyBlueprint.php',
post feed stories to arbitrary uris via a new Worker Summary: so folks can write applications and whatnot. Test Plan: set feed.http-hooks to local dev instance (200) and localhost (500) in my conf. Verified succcess and retrying respectively. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T305 Differential Revision: https://secure.phabricator.com/D3874
2012-11-02 21:34:18 +01:00
'FeedPublisherWorker' => 'applications/feed/worker/FeedPublisherWorker.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HarbormasterDAO' => 'applications/harbormaster/storage/HarbormasterDAO.php',
Add a generic object for unit tests Summary: A later diff adds unit tests against edges, but we need real objects to connect with edges. Add some trivial objects to the Harbormaster database to compliment the similar HarbormasterScratchTable. On its own, this does nothing interesting. Test Plan: Built unit tests on this in a followup. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D2937
2012-07-09 19:39:14 +02:00
'HarbormasterObject' => 'applications/harbormaster/storage/HarbormasterObject.php',
Add HarbormasterRunnerWorker, for running CI tests Summary: This is very preliminary and doesn't actually do anything useful. In theory, it uses Drydock to check out a working copy and run tests. In practice, it's not actually capable of running any of our tests (because of complicated interdependency stuff), but does check out a working copy and //try// to run tests there. Adds various sorts of utility methods to various things as well. Test Plan: Ran `reparse.php --harbormaster --trace <commit>`, observed attempt to run tests via Drydock. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015, T1049 Differential Revision: https://secure.phabricator.com/D4215
2012-12-17 22:43:26 +01:00
'HarbormasterRunnerWorker' => 'applications/harbormaster/worker/HarbormasterRunnerWorker.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HarbormasterScratchTable' => 'applications/harbormaster/storage/HarbormasterScratchTable.php',
'HeraldAction' => 'applications/herald/storage/HeraldAction.php',
'HeraldActionConfig' => 'applications/herald/config/HeraldActionConfig.php',
'HeraldApplyTranscript' => 'applications/herald/storage/transcript/HeraldApplyTranscript.php',
'HeraldCommitAdapter' => 'applications/herald/adapter/HeraldCommitAdapter.php',
'HeraldCondition' => 'applications/herald/storage/HeraldCondition.php',
'HeraldConditionConfig' => 'applications/herald/config/HeraldConditionConfig.php',
'HeraldConditionTranscript' => 'applications/herald/storage/transcript/HeraldConditionTranscript.php',
'HeraldContentTypeConfig' => 'applications/herald/config/HeraldContentTypeConfig.php',
'HeraldController' => 'applications/herald/controller/HeraldController.php',
'HeraldDAO' => 'applications/herald/storage/HeraldDAO.php',
'HeraldDeleteController' => 'applications/herald/controller/HeraldDeleteController.php',
'HeraldDifferentialRevisionAdapter' => 'applications/herald/adapter/HeraldDifferentialRevisionAdapter.php',
'HeraldDryRunAdapter' => 'applications/herald/adapter/HeraldDryRunAdapter.php',
'HeraldEditLogQuery' => 'applications/herald/query/HeraldEditLogQuery.php',
'HeraldEffect' => 'applications/herald/engine/HeraldEffect.php',
'HeraldEngine' => 'applications/herald/engine/HeraldEngine.php',
'HeraldFieldConfig' => 'applications/herald/config/HeraldFieldConfig.php',
'HeraldHomeController' => 'applications/herald/controller/HeraldHomeController.php',
'HeraldInvalidConditionException' => 'applications/herald/engine/engine/HeraldInvalidConditionException.php',
'HeraldInvalidFieldException' => 'applications/herald/engine/engine/HeraldInvalidFieldException.php',
'HeraldNewController' => 'applications/herald/controller/HeraldNewController.php',
'HeraldObjectAdapter' => 'applications/herald/adapter/HeraldObjectAdapter.php',
'HeraldObjectTranscript' => 'applications/herald/storage/transcript/HeraldObjectTranscript.php',
'HeraldRecursiveConditionsException' => 'applications/herald/engine/engine/HeraldRecursiveConditionsException.php',
'HeraldRepetitionPolicyConfig' => 'applications/herald/config/HeraldRepetitionPolicyConfig.php',
'HeraldRule' => 'applications/herald/storage/HeraldRule.php',
'HeraldRuleController' => 'applications/herald/controller/HeraldRuleController.php',
'HeraldRuleEdit' => 'applications/herald/storage/HeraldRuleEdit.php',
'HeraldRuleEditHistoryController' => 'applications/herald/controller/HeraldRuleEditHistoryController.php',
'HeraldRuleEditHistoryView' => 'applications/herald/view/HeraldRuleEditHistoryView.php',
'HeraldRuleListView' => 'applications/herald/view/HeraldRuleListView.php',
'HeraldRuleQuery' => 'applications/herald/query/HeraldRuleQuery.php',
'HeraldRuleTranscript' => 'applications/herald/storage/transcript/HeraldRuleTranscript.php',
'HeraldRuleTypeConfig' => 'applications/herald/config/HeraldRuleTypeConfig.php',
'HeraldTestConsoleController' => 'applications/herald/controller/HeraldTestConsoleController.php',
'HeraldTranscript' => 'applications/herald/storage/transcript/HeraldTranscript.php',
'HeraldTranscriptController' => 'applications/herald/controller/HeraldTranscriptController.php',
'HeraldTranscriptListController' => 'applications/herald/controller/HeraldTranscriptListController.php',
'HeraldValueTypeConfig' => 'applications/herald/config/HeraldValueTypeConfig.php',
'Javelin' => 'infrastructure/javelin/Javelin.php',
'JavelinReactorExample' => 'applications/uiexample/examples/JavelinReactorExample.php',
Add support for placeholders Summary: Support placeholder text for inputs. We currently don't use this because it requires JS and doesn't degrade (no JS means you have zero idea what the input is for if it isn't separately labeled) but there are some cases where intent is obvious from context (for example, the search input in the menu bar, which is fairly obvious on its own and will soon have a magnifying glass icon) and in such cases it's much prettier and saves a bunch of space over an explicit label. Add a behavior so we can add placeholders where they make sense. This implementation is somewhat sanity-checked agianst the two jQuery placeholder implementations I was able to google: https://github.com/danielstocks/jQuery-Placeholder/ https://github.com/mathiasbynens/jquery-placeholder Since we don't currently have any uses cases, I haven't included support for making JS access to the `value` work, for password inputs, or for dynamically altering the placeholder. Test Plan: Played around with the placeholder in the UI example in various browsers and couldn't break it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3103
2012-07-31 01:08:10 +02:00
'JavelinUIExample' => 'applications/uiexample/examples/JavelinUIExample.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'JavelinViewExample' => 'applications/uiexample/examples/JavelinViewExample.php',
'JavelinViewExampleServerView' => 'applications/uiexample/examples/JavelinViewExampleServerView.php',
Implement a more compact, general database-backed key-value cache Summary: See discussion in D4204. Facebook currently has a 314MB remarkup cache with a 55MB index, which is slow to access. Under the theory that this is an index size/quality problem (the current index is on a potentially-384-byte field, with many keys sharing prefixes), provide a more general index with fancy new features: - It implements PhutilKeyValueCache, so it can be a component in cache stacks and supports TTL. - It has a 12-byte hash-based key. - It automatically compresses large blocks of data (most of what we store is highly-compressible HTML). Test Plan: - Basics: - Loaded /paste/, saw caches generate and save. - Reloaded /paste/, saw the page hit cache. - GC: - Ran GC daemon, saw nothing. - Set maximum lifetime to 1 second, ran GC daemon, saw it collect the entire cache. - Deflate: - Selected row formats from the database, saw a mixture of 'raw' and 'deflate' storage. - Used profiler to verify that 'deflate' is fast (12 calls @ 220us on my paste list). - Ran unit tests Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D4259
2012-12-21 23:17:56 +01:00
'LiskChunkTestCase' => 'infrastructure/storage/lisk/__tests__/LiskChunkTestCase.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'LiskDAO' => 'infrastructure/storage/lisk/LiskDAO.php',
'LiskDAOSet' => 'infrastructure/storage/lisk/LiskDAOSet.php',
Add regression test for LiskDAO::__call() Summary: D3606 Test Plan: Deleted `call()`, ran the test. Reviewers: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3814
2012-10-24 21:47:53 +02:00
'LiskDAOTestCase' => 'infrastructure/storage/lisk/__tests__/LiskDAOTestCase.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'LiskEphemeralObjectException' => 'infrastructure/storage/lisk/LiskEphemeralObjectException.php',
'LiskFixtureTestCase' => 'infrastructure/storage/lisk/__tests__/LiskFixtureTestCase.php',
'LiskIsolationTestCase' => 'infrastructure/storage/lisk/__tests__/LiskIsolationTestCase.php',
'LiskIsolationTestDAO' => 'infrastructure/storage/lisk/__tests__/LiskIsolationTestDAO.php',
'LiskIsolationTestDAOException' => 'infrastructure/storage/lisk/__tests__/LiskIsolationTestDAOException.php',
Add an iterator to make it easier to perform database migrations Summary: See D3006, D3007. Make it easier to do migrations like that without holding all results in memory. Test Plan: Ran this code with an artificially small page size (2): foreach (new LiskMigrationIterator(new DifferentialRevision()) as $rev) { echo "Revision ".$rev->getID()."\n"; } Verified each revision as loaded and processed. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D3008
2012-07-19 05:01:23 +02:00
'LiskMigrationIterator' => 'infrastructure/storage/lisk/LiskMigrationIterator.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestAction' => 'applications/maniphest/constants/ManiphestAction.php',
'ManiphestAuxiliaryFieldDefaultSpecification' => 'applications/maniphest/auxiliaryfield/ManiphestAuxiliaryFieldDefaultSpecification.php',
'ManiphestAuxiliaryFieldSpecification' => 'applications/maniphest/auxiliaryfield/ManiphestAuxiliaryFieldSpecification.php',
'ManiphestAuxiliaryFieldTypeException' => 'applications/maniphest/auxiliaryfield/ManiphestAuxiliaryFieldTypeException.php',
'ManiphestAuxiliaryFieldValidationException' => 'applications/maniphest/auxiliaryfield/ManiphestAuxiliaryFieldValidationException.php',
'ManiphestBatchEditController' => 'applications/maniphest/controller/ManiphestBatchEditController.php',
'ManiphestConstants' => 'applications/maniphest/constants/ManiphestConstants.php',
'ManiphestController' => 'applications/maniphest/controller/ManiphestController.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ManiphestCreateMailReceiver' => 'applications/maniphest/mail/ManiphestCreateMailReceiver.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestDAO' => 'applications/maniphest/storage/ManiphestDAO.php',
'ManiphestDefaultTaskExtensions' => 'applications/maniphest/extensions/ManiphestDefaultTaskExtensions.php',
Insert Maniphest transactions when edges are edited Summary: - See D2741. - When EdgeEditor performs edits, emit events. - Listen for Maniphest edge events and save the changes as transactions. - Do all this in a reasonably generic way that won't take too much rewriting as we use edges more generally. Test Plan: Attached and detached commits from tasks, saw reasonable-looking transactions spring into existence. Reviewers: btrahan, davidreuss Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2906
2012-07-03 00:42:06 +02:00
'ManiphestEdgeEventListener' => 'applications/maniphest/event/ManiphestEdgeEventListener.php',
Implemented support for different export formats. Summary: This adds support for different export formats to Excel via a drop-down on the Export page as per the discussion in D5443. Test Plan: Export some things from Maniphest. Do a simple implementation of ManiphestExcelFormat just for testing and make sure that it appears in the list after you run `arc liberate`. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2575 Differential Revision: https://secure.phabricator.com/D5642 Conflicts: src/applications/maniphest/controller/ManiphestExportController.php
2013-04-11 20:22:06 +02:00
'ManiphestExcelDefaultFormat' => 'applications/maniphest/export/ManiphestExcelDefaultFormat.php',
'ManiphestExcelFormat' => 'applications/maniphest/export/ManiphestExcelFormat.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestExportController' => 'applications/maniphest/controller/ManiphestExportController.php',
Add Maniphest Hovercard event listener Summary: Refs T1048 badassery Test Plan: Used in a future diff. Verified correct appearance of hovercard Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1048 Differential Revision: https://secure.phabricator.com/D5544
2013-04-03 19:05:48 +02:00
'ManiphestHovercardEventListener' => 'applications/maniphest/event/ManiphestHovercardEventListener.php',
Update PeopleMenu to only show integration with applications if they are installed Summary: do so via event engine. note different order now... Test Plan: toggled "show beta applications" to off and noted that Conpherence disappeared. Otherwise noted that links showed. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2424 Differential Revision: https://secure.phabricator.com/D4708
2013-02-05 22:46:02 +01:00
'ManiphestPeopleMenuEventListener' => 'applications/maniphest/event/ManiphestPeopleMenuEventListener.php',
Pre-prepare for hovercards Summary: D5120 and followups refactor and generalize object references in Remarkup -- notably, they move remarkup rules from a central location to the implementing applications. Preserve blame by doing moves/renames only first. This change moves application remarkup rules into those applications, and renames the ones D5120 modifies. Test Plan: Typed some preview text into a textarea, got a valid Remarkup render. Reviewers: vrana, chad Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5123
2013-02-26 23:57:41 +01:00
'ManiphestRemarkupRule' => 'applications/maniphest/remarkup/ManiphestRemarkupRule.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ManiphestReplyHandler' => 'applications/maniphest/mail/ManiphestReplyHandler.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestReportController' => 'applications/maniphest/controller/ManiphestReportController.php',
'ManiphestSavedQuery' => 'applications/maniphest/storage/ManiphestSavedQuery.php',
'ManiphestSavedQueryDeleteController' => 'applications/maniphest/controller/ManiphestSavedQueryDeleteController.php',
'ManiphestSavedQueryEditController' => 'applications/maniphest/controller/ManiphestSavedQueryEditController.php',
'ManiphestSavedQueryListController' => 'applications/maniphest/controller/ManiphestSavedQueryListController.php',
Improve Search architecture Summary: The search indexing API has several problems right now: - Always runs in-process. - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it. - Being able to use the task queue will also make rebuilding indexes faster. - Instead, make the API phid-oriented. - No uniform indexing API. - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird. - Instead, provide a uniform API. - No uniform CLI. - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers. - Instead, let indexers expose documents for indexing. - Not application-oriented. - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world. - Instead, move indexers to applications and load them with SymbolLoader. Test Plan: - `bin/search index` - Indexed one revision, one task. - Indexed `--type TASK`, `--type DREV`, etc., for all types. - Indexed `--all`. - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it. - Creating users is a pain; searched for a user after indexing. - Creating commits is a pain; searched for a commit after indexing. - Mocks aren't currently loadable in the result view, so their indexing is moot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: 20after4, aran Maniphest Tasks: T1991, T2104 Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
'ManiphestSearchIndexer' => 'applications/maniphest/search/ManiphestSearchIndexer.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestSubpriorityController' => 'applications/maniphest/controller/ManiphestSubpriorityController.php',
Add Subscribe option to maniphest Summary: Same as //Subscribe//, //Unsubscribe// and //Automatically Subscribed// in differential. Manually updated library map as windows is fun! Test Plan: Subscribe, Unsubscribe! Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5809
2013-05-04 00:47:39 +02:00
'ManiphestSubscribeController' => 'applications/maniphest/controller/ManiphestSubscribeController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestTask' => 'applications/maniphest/storage/ManiphestTask.php',
'ManiphestTaskAuxiliaryStorage' => 'applications/maniphest/storage/ManiphestTaskAuxiliaryStorage.php',
'ManiphestTaskDescriptionChangeController' => 'applications/maniphest/controller/ManiphestTaskDescriptionChangeController.php',
'ManiphestTaskDescriptionPreviewController' => 'applications/maniphest/controller/ManiphestTaskDescriptionPreviewController.php',
'ManiphestTaskDetailController' => 'applications/maniphest/controller/ManiphestTaskDetailController.php',
'ManiphestTaskEditController' => 'applications/maniphest/controller/ManiphestTaskEditController.php',
'ManiphestTaskExtensions' => 'applications/maniphest/extensions/ManiphestTaskExtensions.php',
'ManiphestTaskListController' => 'applications/maniphest/controller/ManiphestTaskListController.php',
'ManiphestTaskListView' => 'applications/maniphest/view/ManiphestTaskListView.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ManiphestTaskMailReceiver' => 'applications/maniphest/mail/ManiphestTaskMailReceiver.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestTaskOwner' => 'applications/maniphest/constants/ManiphestTaskOwner.php',
'ManiphestTaskPriority' => 'applications/maniphest/constants/ManiphestTaskPriority.php',
'ManiphestTaskProject' => 'applications/maniphest/storage/ManiphestTaskProject.php',
'ManiphestTaskProjectsView' => 'applications/maniphest/view/ManiphestTaskProjectsView.php',
'ManiphestTaskQuery' => 'applications/maniphest/ManiphestTaskQuery.php',
'ManiphestTaskStatus' => 'applications/maniphest/constants/ManiphestTaskStatus.php',
'ManiphestTaskSubscriber' => 'applications/maniphest/storage/ManiphestTaskSubscriber.php',
'ManiphestTransaction' => 'applications/maniphest/storage/ManiphestTransaction.php',
'ManiphestTransactionDetailView' => 'applications/maniphest/view/ManiphestTransactionDetailView.php',
'ManiphestTransactionEditor' => 'applications/maniphest/editor/ManiphestTransactionEditor.php',
'ManiphestTransactionListView' => 'applications/maniphest/view/ManiphestTransactionListView.php',
'ManiphestTransactionPreviewController' => 'applications/maniphest/controller/ManiphestTransactionPreviewController.php',
'ManiphestTransactionSaveController' => 'applications/maniphest/controller/ManiphestTransactionSaveController.php',
'ManiphestTransactionType' => 'applications/maniphest/constants/ManiphestTransactionType.php',
'ManiphestView' => 'applications/maniphest/view/ManiphestView.php',
'MetaMTAConstants' => 'applications/metamta/constants/MetaMTAConstants.php',
'MetaMTANotificationType' => 'applications/metamta/constants/MetaMTANotificationType.php',
Begin improving the soundness of received mail Summary: We/I broke a couple of things here recently (see D5911) and are doing some work here in general (see D5912, etc.). Generally, this code is pretty oldschool and not especially well architected for modern application-oriented Phabricator. It hardcodes a lot of stuff which should be applications' responsibilites. Take the first steps toward making it more solid to reduce the risk here. In particular: - Factor out the "self mail" and "duplicate mail" checks and add unit tests. - Make Message-ID hash handling automatic. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5915
2013-05-14 01:32:19 +02:00
'MetaMTAReceivedMailStatus' => 'applications/metamta/constants/MetaMTAReceivedMailStatus.php',
Formalize phid.external-loaders Test Plan: /config/issue/ Reviewers: edward, codeblock, epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4516
2013-01-19 19:20:22 +01:00
'ObjectHandleLoader' => 'applications/phid/handle/ObjectHandleLoader.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'OwnersPackageReplyHandler' => 'applications/owners/mail/OwnersPackageReplyHandler.php',
PHUIBoxView Summary: Adds a basic div box that takes some styles. Not sure this is the best approach for the spacing, but overall hoping people can spend less time in CSS and just use this class. Test Plan: UIExamples Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin, AnhNhan Differential Revision: https://secure.phabricator.com/D5723
2013-04-18 20:34:02 +02:00
'PHUI' => 'view/phui/PHUI.php',
'PHUIBoxExample' => 'applications/uiexample/examples/PHUIBoxExample.php',
'PHUIBoxView' => 'view/phui/PHUIBoxView.php',
PHUIButtonView class Summary: Rough pass at a PHUIButtonView Class. Keeps phutil_tag intact and adds some image features if you use the class. Test Plan: UIExamples Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6192
2013-06-13 03:23:35 +02:00
'PHUIButtonExample' => 'applications/uiexample/examples/PHUIButtonExample.php',
'PHUIButtonView' => 'view/phui/PHUIButtonView.php',
PHUIList, PHUIDocument updates Summary: This diff covers a bit of ground. - PHUIDocumentExample has been added - PHUIDocument has been extended with new features - PhabricatorMenuView is now PHUIListView - PhabricatorMenuItemView is now PHUIItemListView Overall - I think I've gotten all the edges covered here. There is some derpi-ness that we can talk about, comments in the code. Responsive design is missing from the new features on PHUIDocument, will follow up later. Test Plan: Tested mobile and desktop menus, old phriction layout, new document views, new lists, and object lists. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6130
2013-06-05 17:41:43 +02:00
'PHUIDocumentExample' => 'applications/uiexample/examples/PHUIDocumentExample.php',
Separate Phriction style into PHUIDocumentView Summary: Ref T988. Fixes T3150. I want to use this element in Diviner, so separate it from Phriction. This makes no changes to the actual display except for fixing {T3150} by adding `overflow: hidden;`. Test Plan: Viewed Phriction documents in mobile and desktop views. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T3150 Differential Revision: https://secure.phabricator.com/D6101
2013-06-01 00:03:59 +02:00
'PHUIDocumentView' => 'view/phui/PHUIDocumentView.php',
Feed Story UI Examples. Summary: This provides some new display methods and examples to PHUIFeedStory. Test Plan: Tested UIExamples Page, mobile layouts, and existing Feed Pages (feed, profile, etc). I want to add a bit more but am stopping here since it's not a priority. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5749
2013-04-25 00:18:58 +02:00
'PHUIFeedStoryExample' => 'applications/uiexample/examples/PHUIFeedStoryExample.php',
PHUIFeedStoryView, Update Profile Summary: This moves Feed's rendering over to a PHUI class. I want to build it out and have it power Ponder, Phame, Feed, as well as Profiles and Projects in some fashion. It also provides some more data depth over ObjectItemView. Also updated Profile for mobile and fixed some other display issues there. Test Plan: Tested Feed, Profile. Used iOS and Chrome. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin, AnhNhan Differential Revision: https://secure.phabricator.com/D5687
2013-04-15 04:32:26 +02:00
'PHUIFeedStoryView' => 'view/phui/PHUIFeedStoryView.php',
Add instructions about READMEs to new Diffusion basic editor Summary: Provide contextual, in-app documentation about README files. Test Plan: {F44181} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6033
2013-05-24 21:38:27 +02:00
'PHUIFormDividerControl' => 'view/form/control/PHUIFormDividerControl.php',
Add a date range query to Macros Summary: Ref T1163. Ref T2625. This could probably use some tweaks, but I kept things mostly-generic. I added a new control for freeform dates so we can have it render help or whatever later on. Test Plan: See screenshots. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625, T1163 Differential Revision: https://secure.phabricator.com/D6084
2013-05-31 02:32:12 +02:00
'PHUIFormFreeformDateControl' => 'view/form/control/PHUIFormFreeformDateControl.php',
Add a basic multipage form Summary: Ref T2232. Very busy day on IRC so I feel like I've made 20 minutes of progress in 1-minute spurts here, but this adds the basics for a form that can have multiple pages and automatically handle pagination and reading to/from the request, objects and responses. The UIExample is reasonably instructive. Basically, you make a form, add pages to the form, and add controls to the pages. The core flow control looks like this: if ($request->isFormPost()) { $form->readFromRequest($request); // (1) if ($form->isComplete()) { // (2) $response = $form->writeToResponse($response); // (3) // Process result here. // (4) } } else { $form->readFromObject($object); // (5) } The key parts are: # This reads the form state from the request, including reading all the inactive pages. # This tests if all pages are valid and the user just clicked "Done" on the last page. # This produces a "response", which might be writing to an object (for simpler forms) or creating a transaction record (for more complex forms). # Here, we would save the object or apply the transactions. # When the user views the form for the first time, we preload all the values from some object (which might just be empty). Ultimate goal here is to fix repository creation to not be a terrible pit of awfulness. There are probably a lot of rough edges and missing features still, but this seems to not be totally crazy. I'm using two submit buttons with different names which doesn't work on IE7 or something, but we can JS our way out of that if we need to. Test Plan: Paged forward and backward through the form. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2232 Differential Revision: https://secure.phabricator.com/D6003
2013-05-23 23:39:01 +02:00
'PHUIFormMultiSubmitControl' => 'view/form/control/PHUIFormMultiSubmitControl.php',
'PHUIFormPageView' => 'view/form/PHUIFormPageView.php',
PHUIIconView Summary: Adds a base class for displaying images and icons. Test Plan: Tested giving and taking tokens, viewed action headers, uiexamples for icons, workboards. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5736
2013-04-20 02:44:20 +02:00
'PHUIIconExample' => 'applications/uiexample/examples/PHUIIconExample.php',
'PHUIIconView' => 'view/phui/PHUIIconView.php',
PHUIListView Examples, CSS Summary: This adds examples and abstracts out CSS for common nav re-use. Test Plan: Tested DocumentExample and ListExample Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6138
2013-06-06 00:03:56 +02:00
'PHUIListExample' => 'applications/uiexample/examples/PHUIListExample.php',
PHUIList, PHUIDocument updates Summary: This diff covers a bit of ground. - PHUIDocumentExample has been added - PHUIDocument has been extended with new features - PhabricatorMenuView is now PHUIListView - PhabricatorMenuItemView is now PHUIItemListView Overall - I think I've gotten all the edges covered here. There is some derpi-ness that we can talk about, comments in the code. Responsive design is missing from the new features on PHUIDocument, will follow up later. Test Plan: Tested mobile and desktop menus, old phriction layout, new document views, new lists, and object lists. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6130
2013-06-05 17:41:43 +02:00
'PHUIListItemView' => 'view/phui/PHUIListItemView.php',
'PHUIListView' => 'view/phui/PHUIListView.php',
'PHUIListViewTestCase' => 'view/layout/__tests__/PHUIListViewTestCase.php',
Add a basic multipage form Summary: Ref T2232. Very busy day on IRC so I feel like I've made 20 minutes of progress in 1-minute spurts here, but this adds the basics for a form that can have multiple pages and automatically handle pagination and reading to/from the request, objects and responses. The UIExample is reasonably instructive. Basically, you make a form, add pages to the form, and add controls to the pages. The core flow control looks like this: if ($request->isFormPost()) { $form->readFromRequest($request); // (1) if ($form->isComplete()) { // (2) $response = $form->writeToResponse($response); // (3) // Process result here. // (4) } } else { $form->readFromObject($object); // (5) } The key parts are: # This reads the form state from the request, including reading all the inactive pages. # This tests if all pages are valid and the user just clicked "Done" on the last page. # This produces a "response", which might be writing to an object (for simpler forms) or creating a transaction record (for more complex forms). # Here, we would save the object or apply the transactions. # When the user views the form for the first time, we preload all the values from some object (which might just be empty). Ultimate goal here is to fix repository creation to not be a terrible pit of awfulness. There are probably a lot of rough edges and missing features still, but this seems to not be totally crazy. I'm using two submit buttons with different names which doesn't work on IE7 or something, but we can JS our way out of that if we need to. Test Plan: Paged forward and backward through the form. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2232 Differential Revision: https://secure.phabricator.com/D6003
2013-05-23 23:39:01 +02:00
'PHUIPagedFormView' => 'view/form/PHUIPagedFormView.php',
PHUI Text View Summary: Adds basic colors and text styles for shorthand use. Test Plan: UIExamples Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5751
2013-04-22 23:28:23 +02:00
'PHUITextExample' => 'applications/uiexample/examples/PHUITextExample.php',
'PHUITextView' => 'view/phui/PHUITextView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PackageCreateMail' => 'applications/owners/mail/PackageCreateMail.php',
'PackageDeleteMail' => 'applications/owners/mail/PackageDeleteMail.php',
'PackageMail' => 'applications/owners/mail/PackageMail.php',
'PackageModifyMail' => 'applications/owners/mail/PackageModifyMail.php',
Paste embeds look super cool Summary: Make Paste embeds look super cool Test Plan: {F35387} Reviewers: epriestley CC: aran, Korvin, chad, btrahan, AnhNhan Maniphest Tasks: T1770 Differential Revision: https://secure.phabricator.com/D5323
2013-03-13 14:44:27 +01:00
'PasteEmbedView' => 'applications/paste/view/PasteEmbedView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'Phabricator404Controller' => 'applications/base/controller/Phabricator404Controller.php',
Add Disqus, Facebook, Google, GitHub auth config; AWS config Summary: Also improve behavior for the "unknown config" warning. Test Plan: Looked at configs, went through unknown config workflow. Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4310
2013-01-01 23:09:29 +01:00
'PhabricatorAWSConfigOptions' => 'applications/config/option/PhabricatorAWSConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorAccessLog' => 'infrastructure/PhabricatorAccessLog.php',
Add "Developer" and "Access Log" config option groups, some types Summary: - Add a "developer" option group. - Add an "access log" option group. - Render the types "bool", "int" and "string" in a more tailored way. - Add a config check for dead config. Right now this serves as a "TODO" list of things that need to be migrated. Test Plan: Looked at config options, setup issues. Edited bool, int, string options. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4308
2013-01-01 23:09:17 +01:00
'PhabricatorAccessLogConfigOptions' => 'applications/config/option/PhabricatorAccessLogConfigOptions.php',
PhabricatorActionHeaderView v0 Summary: Initial pass at an action header. The idea is to support current and future planned needs in 'headers' with various colors and icons. The overall goal here is to keep markup light and allow other classes to wrap and extend with more specific features. Test Plan: Tested UIExamples and Workboards. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin, AnhNhan Differential Revision: https://secure.phabricator.com/D5585
2013-04-05 16:40:27 +02:00
'PhabricatorActionHeaderExample' => 'applications/uiexample/examples/PhabricatorActionHeaderExample.php',
'PhabricatorActionHeaderView' => 'view/layout/PhabricatorActionHeaderView.php',
Allow action list items to render as forms Summary: In some cases, we want an action item (like "Subscribe") to effect a write that needs a CSRF check. Allow such items to render as forms so they gracefully degrade if JS is FUBAR'd. D3499 has a specific example. Test Plan: Loaded new UI example page, clicked all the actions. Reviewers: btrahan, vrana, avivey Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3596
2012-10-03 19:21:39 +02:00
'PhabricatorActionListExample' => 'applications/uiexample/examples/PhabricatorActionListExample.php',
Modernize Paste Summary: - Add a PhabricatorApplication. - Make most of the views work well on tablets / phones. The actual "Create" form doesn't, but everything else is good -- need to make device-friendly form layouts before I can do the form. Test Plan: Will attach screenshots. Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3293
2012-08-15 19:45:06 +02:00
'PhabricatorActionListView' => 'view/layout/PhabricatorActionListView.php',
'PhabricatorActionView' => 'view/layout/PhabricatorActionView.php',
Adds ALL CAPS language. Summary: Adds an ALL CAPs language, requires changes from libphutil as well. Test Plan: Turn on AC, get caps back. Turn it back to English, stuff went away. Reviewers: epriestley, btrahan, vrana Reviewed By: vrana CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4627
2013-01-25 01:11:30 +01:00
'PhabricatorAllCapsTranslation' => 'infrastructure/internationalization/PhabricatorAllCapsTranslation.php',
Add local navigation to Differential Summary: Adds a flexible navigation menu to diffs that shows you your current position in the diff. Anticipating some "this is the best thing ever" and some "this is the wosrt thing ever" on this, but let's see how much pushback we get? It seems pretty good to me. Test Plan: Will attach screenshots. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1633, T1591 Differential Revision: https://secure.phabricator.com/D3355
2012-08-22 00:01:20 +02:00
'PhabricatorAnchorView' => 'view/layout/PhabricatorAnchorView.php',
AphrontBars Summary: Aphront widgets that render the either a discrete or continuous value as a horizontal shape. Like a progress bar, or a five-star rating bar. Test Plan: `/uiexample/view/PhabricatorAphrontBarExample/` ...which shows this, amongst other things: {F33898} Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5122
2013-03-05 17:46:09 +01:00
'PhabricatorAphrontBarExample' => 'applications/uiexample/examples/PhabricatorAphrontBarExample.php',
Add FactCursors and application fact datasources Summary: - Add PhabricatorApplication. This is a general class that I have grand designs for, but used here to allow applications to provide objects for analysis by the facts appliction. - Add FactCursors, to keep track of where iterators are. - Make the daemon do something sort of useful. - Add `bin/fact cursors` for showing and managing objects and cursors. - Add some options to `bin/fact analyze`. Test Plan: - `bin/fact cursors`, `bin/fact cursors --reset DifferentialRevision`, `bin/fact cursors --reset X` - `bin/fact analyze`, `bin/fact analyze --all`, `bin/fact analyze --iterator DifferentialRevision --skip-aggregates` - `bin/phd debug fact` Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3098
2012-07-30 19:43:49 +02:00
'PhabricatorApplication' => 'applications/base/PhabricatorApplication.php',
Add a meta-application Summary: - Adds a new "Applications" application. - Builds an application list via application config instead of via hard-coding, so we can move toward better concepts of installing/uninstalling applications, etc. - Applications indicate that they need attention with notice counts and brief status messages rathern than 50 giant tables of all sorts of app data. I want to try replacing the home screen with this screen, pretty much. Not sure if this is totally crazy or not. What does everyone else think? Test Plan: Will add screenshots. Reviewers: btrahan, chad, vrana, alanh Reviewed By: vrana CC: aran, davidreuss, champo Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3129
2012-08-02 23:07:21 +02:00
'PhabricatorApplicationApplications' => 'applications/meta/application/PhabricatorApplicationApplications.php',
'PhabricatorApplicationAudit' => 'applications/audit/application/PhabricatorApplicationAudit.php',
Drive menu icons from Applications Summary: This makes no changes, it just moves the menu icons to the applications instead of hard-coded on the page. I'm going to try to address some of the angst in T1593 next... Test Plan: Loaded logged-in / logged out pages. Clicked menu items. Looked at /applications/. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1593, T1569 Differential Revision: https://secure.phabricator.com/D3146
2012-08-05 23:12:43 +02:00
'PhabricatorApplicationAuth' => 'applications/auth/application/PhabricatorApplicationAuth.php',
Create a status tool by giving /calendar/ some teeth Summary: you can now add, edit, and delete status events. also added a "description" to status events and surface it in the big calendar view on mouse hover. some refactoring changes as well to make validation logic centralized within the storage class. Test Plan: added, edited, deleted. yay. Reviewers: epriestley, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T407 Differential Revision: https://secure.phabricator.com/D3810
2012-10-24 22:22:24 +02:00
'PhabricatorApplicationCalendar' => 'applications/calendar/application/PhabricatorApplicationCalendar.php',
Created Chat log application class Summary: Created a chat log application which displays on the home page. Test Plan: Loaded the home page to see if the chat log application really shows up on the home page. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4930
2013-02-13 16:28:14 +01:00
'PhabricatorApplicationChatLog' => 'applications/chatlog/applications/PhabricatorApplicationChatLog.php',
Add Conduit and Herald applications Summary: See D3572. Adds applications for Conduit and Herald. Test Plan: Viewed `/applications/`, saw applications. Clicked buttons, got to applications. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D3578
2012-10-01 21:56:10 +02:00
'PhabricatorApplicationConduit' => 'applications/conduit/application/PhabricatorApplicationConduit.php',
Start of a config web interface. Summary: This is somewhat clowny, particularly in how it handles JSON encode/decode, but I've commented why I did things the way I did. The goal is to store minified JSON but show pretty-printed JSON where possible, to the user editing it. Test Plan: * Went to /config/ and saw a list of keys from the `default` config. * Clicked on one of them, submitted the default value successfully. * Changed the value to invalid JSON and got a decent error. * Changed the value to valid JSON and checked the DB to confirm it saved. * Confirmed the DB values were minified. * Confirmed the user-facing values were pretty-printed where they could be. * Confirmed that PHIDs were getting assigned properly and that isDeleted properly defaulted to false/0. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2246 Differential Revision: https://secure.phabricator.com/D4290
2012-12-28 00:20:09 +01:00
'PhabricatorApplicationConfig' => 'applications/config/application/PhabricatorApplicationConfig.php',
Begin moving Phabricator configuration into PHP Summary: Ref T2255. Ref T2221. Lay the groundwork to move configuration into PHP, so we can show descriptions in the web UI, do typechecking, disable application options when an application is uninstalled, etc. Test Plan: {F28421} {F28420} {F28422} Reviewers: codeblock, btrahan, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221, T2255 Differential Revision: https://secure.phabricator.com/D4306
2012-12-31 00:36:06 +01:00
'PhabricatorApplicationConfigOptions' => 'applications/config/option/PhabricatorApplicationConfigOptions.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'PhabricatorApplicationConpherence' => 'applications/conpherence/application/PhabricatorApplicationConpherence.php',
Add Slowvote and Countdown applications Summary: See D3572. Test Plan: Loaded /applications/, saw applications. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D3577
2012-10-01 21:56:02 +02:00
'PhabricatorApplicationCountdown' => 'applications/countdown/application/PhabricatorApplicationCountdown.php',
Modernize daemon application Summary: Make it possible to get to stuff that used to be in tabs. Test Plan: Clicked links and such. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3264
2012-08-14 00:27:45 +02:00
'PhabricatorApplicationDaemons' => 'applications/daemon/application/PhabricatorApplicationDaemons.php',
Application Detail View Summary: Added Applications Details View Applications Detail View Test Plan: In "Applications" application, clicked on each application to check whether the each application detail view is displayed. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4615
2013-01-24 21:13:31 +01:00
'PhabricatorApplicationDetailViewController' => 'applications/meta/controller/PhabricatorApplicationDetailViewController.php',
Add FactCursors and application fact datasources Summary: - Add PhabricatorApplication. This is a general class that I have grand designs for, but used here to allow applications to provide objects for analysis by the facts appliction. - Add FactCursors, to keep track of where iterators are. - Make the daemon do something sort of useful. - Add `bin/fact cursors` for showing and managing objects and cursors. - Add some options to `bin/fact analyze`. Test Plan: - `bin/fact cursors`, `bin/fact cursors --reset DifferentialRevision`, `bin/fact cursors --reset X` - `bin/fact analyze`, `bin/fact analyze --all`, `bin/fact analyze --iterator DifferentialRevision --skip-aggregates` - `bin/phd debug fact` Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3098
2012-07-30 19:43:49 +02:00
'PhabricatorApplicationDifferential' => 'applications/differential/application/PhabricatorApplicationDifferential.php',
Add a meta-application Summary: - Adds a new "Applications" application. - Builds an application list via application config instead of via hard-coding, so we can move toward better concepts of installing/uninstalling applications, etc. - Applications indicate that they need attention with notice counts and brief status messages rathern than 50 giant tables of all sorts of app data. I want to try replacing the home screen with this screen, pretty much. Not sure if this is totally crazy or not. What does everyone else think? Test Plan: Will add screenshots. Reviewers: btrahan, chad, vrana, alanh Reviewed By: vrana CC: aran, davidreuss, champo Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3129
2012-08-02 23:07:21 +02:00
'PhabricatorApplicationDiffusion' => 'applications/diffusion/application/PhabricatorApplicationDiffusion.php',
Remove all code referencing old tab navigation Summary: - Add getHelpURI() to PhabricatorApplication for application user guides. - Add a new "help" icon menu item and skeletal Diviner application. - Move help tabs to Applications where they exist, document the other ones that don't exist yet. - Grep for all tab-related stuff and delete it. Test Plan: Clicked "help" for some apps. Clicked around randomly in a bunch of other apps. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3267
2012-08-14 00:28:41 +02:00
'PhabricatorApplicationDiviner' => 'applications/diviner/application/PhabricatorApplicationDiviner.php',
Add Drydock Application Summary: Add an Application class for Drydock and move routing rules there. Test Plan: Looked at /applications/, clicked around drydock. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3847
2012-10-31 17:57:57 +01:00
'PhabricatorApplicationDrydock' => 'applications/drydock/application/PhabricatorApplicationDrydock.php',
Allow Fact app to draw charts Summary: For any count fact, allow a chart to be drawn. INCREDIBLY POWERFUL DATA ANALYSIS PLATFORM. Test Plan: Drew a chart of object counts. Drew the Maniphest burn chart. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3099
2012-07-30 19:44:08 +02:00
'PhabricatorApplicationFact' => 'applications/fact/application/PhabricatorApplicationFact.php',
Make feed its own application Summary: Fixes the two-level nav issue introduced by D4376. (My claim that this page is device ready in the code is something of a lie, but it's fairly close.) (@chad, this could use an icon at some point, or you can point me at which one you want and I can take a stab at slicing it.) Test Plan: Looked at feed; saw it not-broken. Also checked public feed (which should just merge at some point). Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D4381
2013-01-11 01:06:29 +01:00
'PhabricatorApplicationFeed' => 'applications/feed/application/PhabricatorApplicationFeed.php',
Add a PhabricatorApplication for files Summary: Basic step toward modernizing Files, makes it appear on /applications/ and in typeahead. Test Plan: Looked at /applications/. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D3575
2012-10-01 23:05:12 +02:00
'PhabricatorApplicationFiles' => 'applications/files/application/PhabricatorApplicationFiles.php',
Add a meta-application Summary: - Adds a new "Applications" application. - Builds an application list via application config instead of via hard-coding, so we can move toward better concepts of installing/uninstalling applications, etc. - Applications indicate that they need attention with notice counts and brief status messages rathern than 50 giant tables of all sorts of app data. I want to try replacing the home screen with this screen, pretty much. Not sure if this is totally crazy or not. What does everyone else think? Test Plan: Will add screenshots. Reviewers: btrahan, chad, vrana, alanh Reviewed By: vrana CC: aran, davidreuss, champo Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3129
2012-08-02 23:07:21 +02:00
'PhabricatorApplicationFlags' => 'applications/flag/application/PhabricatorApplicationFlags.php',
Add Conduit and Herald applications Summary: See D3572. Adds applications for Conduit and Herald. Test Plan: Viewed `/applications/`, saw applications. Clicked buttons, got to applications. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D3578
2012-10-01 21:56:10 +02:00
'PhabricatorApplicationHerald' => 'applications/herald/application/PhabricatorApplicationHerald.php',
Add a meta-application Summary: - Adds a new "Applications" application. - Builds an application list via application config instead of via hard-coding, so we can move toward better concepts of installing/uninstalling applications, etc. - Applications indicate that they need attention with notice counts and brief status messages rathern than 50 giant tables of all sorts of app data. I want to try replacing the home screen with this screen, pretty much. Not sure if this is totally crazy or not. What does everyone else think? Test Plan: Will add screenshots. Reviewers: btrahan, chad, vrana, alanh Reviewed By: vrana CC: aran, davidreuss, champo Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3129
2012-08-02 23:07:21 +02:00
'PhabricatorApplicationLaunchView' => 'applications/meta/view/PhabricatorApplicationLaunchView.php',
Move "Macros" to a first-class application Summary: This is mostly to unblock D3547. - Move "Macros" to a first-class application called "Macros". - After D3547, this application will also house "Memes" (macros with text on them). - This will also make them easier to find; the top navigational query I field is "where are image macros?" nowadays, since it's not intuitive they're part of files. - This makes some of the UI mobile-aware but doesn't set the `device` flag yet, since there are still some missing pieces. - I'll separate storage out and continue modernizing the UI as we unblock and integrate D3547. Test Plan: Created, edited and deleted macros. Viewed files. Reviewers: btrahan, vrana, teisenbe Reviewed By: vrana CC: aran Maniphest Tasks: T175 Differential Revision: https://secure.phabricator.com/D3572
2012-10-01 23:04:03 +02:00
'PhabricatorApplicationMacro' => 'applications/macro/application/PhabricatorApplicationMacro.php',
Move "Mailing Lists" to a separate application Summary: There's currently no way to get here from the UI since nav tabs don't exist anymore. It's also always been hard to find this feature even when we had the tabs, since it's surprising that it's inside "MetaMTA". - Move mailing lists to a separate application. - Add `buildApplicationPage()`, since we don't really need `buildStandardPageResponse()` any more -- we can infer all the information from `PhabricatorApplication`. This will let us get rid of a lot of the `PhabricatorXXXController` classes which just define application information. - Add `getApplicationURI()` to reduce code duplication, and in case we want to let you move applications around some day. Test Plan: Looked/edited/saved mailing lists. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T631 Differential Revision: https://secure.phabricator.com/D3248
2012-08-13 04:19:46 +02:00
'PhabricatorApplicationMailingLists' => 'applications/mailinglists/application/PhabricatorApplicationMailingLists.php',
Add FactCursors and application fact datasources Summary: - Add PhabricatorApplication. This is a general class that I have grand designs for, but used here to allow applications to provide objects for analysis by the facts appliction. - Add FactCursors, to keep track of where iterators are. - Make the daemon do something sort of useful. - Add `bin/fact cursors` for showing and managing objects and cursors. - Add some options to `bin/fact analyze`. Test Plan: - `bin/fact cursors`, `bin/fact cursors --reset DifferentialRevision`, `bin/fact cursors --reset X` - `bin/fact analyze`, `bin/fact analyze --all`, `bin/fact analyze --iterator DifferentialRevision --skip-aggregates` - `bin/phd debug fact` Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3098
2012-07-30 19:43:49 +02:00
'PhabricatorApplicationManiphest' => 'applications/maniphest/application/PhabricatorApplicationManiphest.php',
Modernize MetaMTA Summary: - Add an Application. - Move routes to the application. - Move nav out of tabs (which no longer exist). - Fix a couple of random things. Test Plan: Viewed sent/received mail logs. Performed send/receive tests. Viewed email details. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T631, T1569 Differential Revision: https://secure.phabricator.com/D3255
2012-08-13 21:37:06 +02:00
'PhabricatorApplicationMetaMTA' => 'applications/metamta/application/PhabricatorApplicationMetaMTA.php',
Add applications for Owners, Repositories, PHID manager, PHPAST Summary: See D3572. Test Plan: Viewed /applications/, saw all these applications. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3579
2012-10-01 21:56:33 +02:00
'PhabricatorApplicationOwners' => 'applications/owners/application/PhabricatorApplicationOwners.php',
'PhabricatorApplicationPHID' => 'applications/phid/application/PhabricatorApplicationPHID.php',
Move Conduit methods inside applications Test Plan: /conduit/ /conduit/method/arcanist.projectinfo/ Call method $ echo '{}' | arc call-conduit user.whoami Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4268
2012-12-21 21:12:26 +01:00
'PhabricatorApplicationPHPAST' => 'applications/phpast/application/PhabricatorApplicationPHPAST.php',
Modernize Paste Summary: - Add a PhabricatorApplication. - Make most of the views work well on tablets / phones. The actual "Create" form doesn't, but everything else is good -- need to make device-friendly form layouts before I can do the form. Test Plan: Will attach screenshots. Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3293
2012-08-15 19:45:06 +02:00
'PhabricatorApplicationPaste' => 'applications/paste/application/PhabricatorApplicationPaste.php',
Drive menu icons from Applications Summary: This makes no changes, it just moves the menu icons to the applications instead of hard-coded on the page. I'm going to try to address some of the angst in T1593 next... Test Plan: Loaded logged-in / logged out pages. Clicked menu items. Looked at /applications/. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1593, T1569 Differential Revision: https://secure.phabricator.com/D3146
2012-08-05 23:12:43 +02:00
'PhabricatorApplicationPeople' => 'applications/people/application/PhabricatorApplicationPeople.php',
Modernize phame and add concept of "blog style" to blog post list view Summary: "blog style" for now is just "true" to make this UI render better for the blog LATER it will be a string which will choose the larger template. this will also have to do some messing around with links; when viewing on a phabricator instance links need to be a bit dirtier to carry around the blog whereas when viewing offsite we can tell what blog it is based on the host domain. anyhoo, this is future diff work Test Plan: looked at blog - less ugly. resized blog to smaller sizes - became a "single list" of goodness for quality reading quite quickly. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3587
2012-10-02 00:37:02 +02:00
'PhabricatorApplicationPhame' => 'applications/phame/application/PhabricatorApplicationPhame.php',
Phlux v0 Summary: Yup, it's sitevars. No conduit or caching or fancy stuff yet. Ref T2793. Test Plan: {F36525} {F36526} {F36527} {F36528} {F36529} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2793 Differential Revision: https://secure.phabricator.com/D5397
2013-03-21 02:01:52 +01:00
'PhabricatorApplicationPhlux' => 'applications/phlux/application/PhabricatorApplicationPhlux.php',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PhabricatorApplicationPholio' => 'applications/pholio/application/PhabricatorApplicationPholio.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhabricatorApplicationPhortune' => 'applications/phortune/application/PhabricatorApplicationPhortune.php',
Implemented Phrequent time tracking functionality. Summary: This differential implements Phrequent's time tracking functionality for users and hooks it up to Maniphest. It also includes a basic "Time Tracked" list for the Phrequent application, where users can review what they've spent time working on. Test Plan: Apply the patch and track some things in Maniphest. They should appear in the "Time Tracked" view of Phrequent. There is also a `phrequent.show-prompt` option which toggles whether to display a prompt when tracking time. I'm unsure of whether the prompt is useful or is more likely to cause people to click "Track Time", go off and do the task and then come back to the prompt still waiting for them to confirm. A potential solution to the "accidentally clicking the button and recording 2 seconds of time" might be to show a prompt on stop if the total time is under 10 seconds, asking whether the user wants to keep or discard the tracked time. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2857 Differential Revision: https://secure.phabricator.com/D5479
2013-03-30 17:32:29 +01:00
'PhabricatorApplicationPhrequent' => 'applications/phrequent/application/PhabricatorApplicationPhrequent.php',
Add a meta-application Summary: - Adds a new "Applications" application. - Builds an application list via application config instead of via hard-coding, so we can move toward better concepts of installing/uninstalling applications, etc. - Applications indicate that they need attention with notice counts and brief status messages rathern than 50 giant tables of all sorts of app data. I want to try replacing the home screen with this screen, pretty much. Not sure if this is totally crazy or not. What does everyone else think? Test Plan: Will add screenshots. Reviewers: btrahan, chad, vrana, alanh Reviewed By: vrana CC: aran, davidreuss, champo Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3129
2012-08-02 23:07:21 +02:00
'PhabricatorApplicationPhriction' => 'applications/phriction/application/PhabricatorApplicationPhriction.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PhabricatorApplicationPonder' => 'applications/ponder/application/PhabricatorApplicationPonder.php',
Add a "Project" application Summary: Move routes into a formal application class. Test Plan: Checked /applications/, browsed various routes. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, floatinglomas Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3181
2012-08-07 20:54:49 +02:00
'PhabricatorApplicationProject' => 'applications/project/application/PhabricatorApplicationProject.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'PhabricatorApplicationReleeph' => 'applications/releeph/application/PhabricatorApplicationReleeph.php',
'PhabricatorApplicationReleephConfigOptions' => 'applications/releeph/config/PhabricatorApplicationReleephConfigOptions.php',
Add applications for Owners, Repositories, PHID manager, PHPAST Summary: See D3572. Test Plan: Viewed /applications/, saw all these applications. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3579
2012-10-01 21:56:33 +02:00
'PhabricatorApplicationRepositories' => 'applications/repository/application/PhabricatorApplicationRepositories.php',
Adding an own application for search Summary: Refs T2989 Renamed file Libery Test Plan: Nothing broken, that's always a good sign. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2989 Differential Revision: https://secure.phabricator.com/D5697 Conflicts: src/__phutil_library_map__.php
2013-04-15 15:43:39 +02:00
'PhabricatorApplicationSearch' => 'applications/search/application/PhabricatorApplicationSearch.php',
Use delegation to generalize application search controllers Summary: Ref T2625. Lifts almost all of the search logic out of Paste controllers and into Search. This uses controller delegation for generalization. We use this in a few places, but don't use it very much yet. I think it's pretty reasonable as-is, but I might be able to make even more stuff free. There are some slightly rough edges around routes, still, but I want to hit Phame and Differential (which both have multiple application search engines) before trying to generalize that. Test Plan: Executed, browsed and managed Paste searches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6073
2013-05-30 23:09:02 +02:00
'PhabricatorApplicationSearchController' => 'applications/search/controller/PhabricatorApplicationSearchController.php',
Move paste search to generic search. Summary: Begin implementing generic application search and refactoring paste search. Test Plan: See if the paste search still works. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5621
2013-04-14 15:53:20 +02:00
'PhabricatorApplicationSearchEngine' => 'applications/search/engine/PhabricatorApplicationSearchEngine.php',
Use delegation to generalize application search controllers Summary: Ref T2625. Lifts almost all of the search logic out of Paste controllers and into Search. This uses controller delegation for generalization. We use this in a few places, but don't use it very much yet. I think it's pretty reasonable as-is, but I might be able to make even more stuff free. There are some slightly rough edges around routes, still, but I want to hit Phame and Differential (which both have multiple application search engines) before trying to generalize that. Test Plan: Executed, browsed and managed Paste searches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6073
2013-05-30 23:09:02 +02:00
'PhabricatorApplicationSearchResultsControllerInterface' => 'applications/search/interface/PhabricatorApplicationSearchResultsControllerInterface.php',
Move Settings to a separate directory Summary: We currently have two relatively distinct applications, "People" and "Settings", living in /people/. Move settings to its own directory. This renames a couple of classes but makes no real code changes. Test Plan: Browsed /settings/, changed some settings. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569, T631 Differential Revision: https://secure.phabricator.com/D3256
2012-08-13 21:37:18 +02:00
'PhabricatorApplicationSettings' => 'applications/settings/application/PhabricatorApplicationSettings.php',
Add Slowvote and Countdown applications Summary: See D3572. Test Plan: Loaded /applications/, saw applications. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D3577
2012-10-01 21:56:02 +02:00
'PhabricatorApplicationSlowvote' => 'applications/slowvote/application/PhabricatorApplicationSlowvote.php',
Add a meta-application Summary: - Adds a new "Applications" application. - Builds an application list via application config instead of via hard-coding, so we can move toward better concepts of installing/uninstalling applications, etc. - Applications indicate that they need attention with notice counts and brief status messages rathern than 50 giant tables of all sorts of app data. I want to try replacing the home screen with this screen, pretty much. Not sure if this is totally crazy or not. What does everyone else think? Test Plan: Will add screenshots. Reviewers: btrahan, chad, vrana, alanh Reviewed By: vrana CC: aran, davidreuss, champo Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3129
2012-08-02 23:07:21 +02:00
'PhabricatorApplicationStatusView' => 'applications/meta/view/PhabricatorApplicationStatusView.php',
Add basic "Subscriptions" application Summary: Basic infrastructure for generalizing subscriptions/CCs for T1808, T1514 and T1663. - Implement `PhabricatorSubscribableInterface` and you'll get a subscribe/unsubscribe button for free. - If there are any auto-subscribed users (like the question author) you can specify them; this makes more sense for Tasks and Revisions than Ponder probably, but maybe the author should be auto-subscribed. - Subscriptions are either "explicit" (the user clicked 'subscribe') or "implicit" (the user did something which causes them to become subscribed naturally). If a user unsubscribes, they'll no longer be added by implicit subscriptions. This may or may not be relevant to Ponder but is an existing Herald feature in Differential. - Helper method on PhabricatorSubscribersQuery to load subscribers. - This doesn't handle actually sending email, etc. I think that's all so application-specific that it doesn't belong here. - Now seems to work. Test Plan: {F20552} {F20553} Reviewers: pieter, btrahan Reviewed By: pieter CC: aran Maniphest Tasks: T1663, T1514, T1808 Differential Revision: https://secure.phabricator.com/D3637
2012-10-05 22:18:05 +02:00
'PhabricatorApplicationSubscriptions' => 'applications/subscriptions/application/PhabricatorApplicationSubscriptions.php',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorApplicationTokens' => 'applications/tokens/application/PhabricatorApplicationTokens.php',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransaction' => 'applications/transactions/storage/PhabricatorApplicationTransaction.php',
'PhabricatorApplicationTransactionComment' => 'applications/transactions/storage/PhabricatorApplicationTransactionComment.php',
Allow ApplicationTransaction comments to be edited and deleted Summary: Allows you to edit or delete comments in appplications which support ApplicationTransactions. UI/UX stuff: - The dialogs are rough but I want to do a dialog design pass more generally, @chad has some mocks. - When you add new mentions via edit, they don't currently count as mentions. I'm not sure what I want to do about this. - When you edit or delete a comment, we do not publish any notifications about it. I think this is reasonable. - I didn't separate "delete" out versus "edit"; I assume it will be reasonably intuitive that deleting all the text deletes effectively deletes the comment. I also want to discourage deletion somewhat (we still show the transaction, just show that the comment has been deleted). Test Plan: Transaction view, note "Edit" and "Edited" links: {F26914} Edit view, has some design issues but I want to do a pass on dialogs in general: {F26915} History view: {F26913} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1082 Differential Revision: https://secure.phabricator.com/D4149
2012-12-11 23:01:51 +01:00
'PhabricatorApplicationTransactionCommentEditController' => 'applications/transactions/controller/PhabricatorApplicationTransactionCommentEditController.php',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionCommentEditor' => 'applications/transactions/editor/PhabricatorApplicationTransactionCommentEditor.php',
Allow ApplicationTransaction comments to be edited and deleted Summary: Allows you to edit or delete comments in appplications which support ApplicationTransactions. UI/UX stuff: - The dialogs are rough but I want to do a dialog design pass more generally, @chad has some mocks. - When you add new mentions via edit, they don't currently count as mentions. I'm not sure what I want to do about this. - When you edit or delete a comment, we do not publish any notifications about it. I think this is reasonable. - I didn't separate "delete" out versus "edit"; I assume it will be reasonably intuitive that deleting all the text deletes effectively deletes the comment. I also want to discourage deletion somewhat (we still show the transaction, just show that the comment has been deleted). Test Plan: Transaction view, note "Edit" and "Edited" links: {F26914} Edit view, has some design issues but I want to do a pass on dialogs in general: {F26915} History view: {F26913} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1082 Differential Revision: https://secure.phabricator.com/D4149
2012-12-11 23:01:51 +01:00
'PhabricatorApplicationTransactionCommentHistoryController' => 'applications/transactions/controller/PhabricatorApplicationTransactionCommentHistoryController.php',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionCommentQuery' => 'applications/transactions/query/PhabricatorApplicationTransactionCommentQuery.php',
Add previews to ApplicationTransaction Summary: Implements previews for Macros and Pholio. (Design is nonfinal -- kind of split the difference between `diff_full_view.png`, laziness, and space concerns. Next couple diffs will add more stuff here.) Test Plan: {F28055} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, vrana Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4246
2012-12-21 14:51:33 +01:00
'PhabricatorApplicationTransactionCommentView' => 'applications/transactions/view/PhabricatorApplicationTransactionCommentView.php',
Allow ApplicationTransaction comments to be edited and deleted Summary: Allows you to edit or delete comments in appplications which support ApplicationTransactions. UI/UX stuff: - The dialogs are rough but I want to do a dialog design pass more generally, @chad has some mocks. - When you add new mentions via edit, they don't currently count as mentions. I'm not sure what I want to do about this. - When you edit or delete a comment, we do not publish any notifications about it. I think this is reasonable. - I didn't separate "delete" out versus "edit"; I assume it will be reasonably intuitive that deleting all the text deletes effectively deletes the comment. I also want to discourage deletion somewhat (we still show the transaction, just show that the comment has been deleted). Test Plan: Transaction view, note "Edit" and "Edited" links: {F26914} Edit view, has some design issues but I want to do a pass on dialogs in general: {F26915} History view: {F26913} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1082 Differential Revision: https://secure.phabricator.com/D4149
2012-12-11 23:01:51 +01:00
'PhabricatorApplicationTransactionController' => 'applications/transactions/controller/PhabricatorApplicationTransactionController.php',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionEditor' => 'applications/transactions/editor/PhabricatorApplicationTransactionEditor.php',
Add feed integration to generic transactions Summary: Publish feed stories, including from Pholio. Actual stories are somewhat garbage but it's all display-time; I'm going to do a pass on feed in general. Test Plan: {F26832} Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4140
2012-12-11 23:00:21 +01:00
'PhabricatorApplicationTransactionFeedStory' => 'applications/transactions/feed/PhabricatorApplicationTransactionFeedStory.php',
Integrate subscriptions with ApplicationTransactions Summary: Fixes T2214. For objects which support ApplicationTransaction, use ApplicationTransactions to apply subscription action changes. Principally, this makes clicking "Subscribe" / "Unsubscribe" appear correctly in the transaction log. Test Plan: Clicked "Subscribe" and "Unsubscribe" a on Macros and Mocks. Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2214 Differential Revision: https://secure.phabricator.com/D4986
2013-02-17 15:37:09 +01:00
'PhabricatorApplicationTransactionInterface' => 'applications/transactions/interface/PhabricatorApplicationTransactionInterface.php',
Add ApplicationTransaction handling for transactions with no effect Summary: When a user submits an action with no effect (like an empty comment, an "abandon" on an already-accepted revision, or a "close, resolved" on a closed task) we want to alert them that their action isn't effective. These warnings fall into two general buckets: - User is submitting two or more actions, and some aren't effective but some are. Prompt them to apply the effective actions only. - A special case of this is where the only effective action is a comment. We provide tailored text ("Post Comment") in this case. - User is submitting one action, which isn't effective. Tell them they're out of luck. - A special case of this is an empty comment. We provide tailored text in this case. By default, the transaction editor throws when transactions have no effect. The caller can then deal with this, or use `PhabricatorApplicationTransactionNoEffectResponse` to provide a standard dialog that gives the user information as above. For cases where we expect transactions to have no effect (notably, "edit" forms) we just continue on no-effect unconditionally. Also fix an issue where new, combined or filtered transactions would not be represented properly in the Ajax response (i.e., return final transactions from `applyTransactions()`), and translate some strings. Test Plan: - Submitted empty and nonempy comments in Macro and Pholio. - Submitted comments with new and existing "@mentions". - Submitted edits in both applications. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T912, T2104 Differential Revision: https://secure.phabricator.com/D4160
2012-12-12 02:27:40 +01:00
'PhabricatorApplicationTransactionNoEffectException' => 'applications/transactions/exception/PhabricatorApplicationTransactionNoEffectException.php',
'PhabricatorApplicationTransactionNoEffectResponse' => 'applications/transactions/response/PhabricatorApplicationTransactionNoEffectResponse.php',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionQuery' => 'applications/transactions/query/PhabricatorApplicationTransactionQuery.php',
Render application transactions via Ajax Summary: When possible, render application transactions via Ajax. Instead of reloading the page when the response returns, append new transactions to the transaction view. Scroll the window to the new transactions, animate them in, and clear the form to make this interaction feel reasonable. When editing transactions, fade them in but do not scroll to them (i.e., don't disrupt the user's position). Test Plan: Edited and appended transactions via Ajax. Observed fade in animations and scroll behavior. Clicked anchors to verify proper anchor accounting. Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1960 Differential Revision: https://secure.phabricator.com/D4151
2012-12-11 23:02:29 +01:00
'PhabricatorApplicationTransactionResponse' => 'applications/transactions/response/PhabricatorApplicationTransactionResponse.php',
Implement basic transaction detail blocks Summary: Some transactions (like editing configuration values, task descriptions, or Conpherence images) can't be simply explained and need an additional larger element to show them fully (like a text diff). Support change details like this in ApplicationTransactions. Implements the element in Config, so you can see changes. Test Plan: {F32974} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2213 Differential Revision: https://secure.phabricator.com/D4984
2013-02-17 15:37:02 +01:00
'PhabricatorApplicationTransactionTextDiffDetailView' => 'applications/transactions/view/PhabricatorApplicationTransactionTextDiffDetailView.php',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorApplicationTransactionView' => 'applications/transactions/view/PhabricatorApplicationTransactionView.php',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactions' => 'applications/transactions/application/PhabricatorApplicationTransactions.php',
Modernize UIExamples Summary: - Get rid of an AphrontSideNavView callsite. - Modernize and simplify the application implementation. - Doesn't work perfectly on tablet/phone but that's because not all the UI examples work there yet. Test Plan: Looked at /applications/ and /uiexample/. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3431
2012-09-11 18:56:40 +02:00
'PhabricatorApplicationUIExamples' => 'applications/uiexample/application/PhabricatorApplicationUIExamples.php',
Installation & Uninstallion of Applications Summary: Created Applications application which allows uninstallation & installation of application. Test Plan: In "Applications" application, clicked on uninstalled the application by cliking Uninstall and chekcing whether they are really uninstalled(Disabling URI & in appearance in the side pane). Then Clicked on the install button of the uninstalled application to check whether they are installed. Reviewers: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4715
2013-01-29 18:14:03 +01:00
'PhabricatorApplicationUninstallController' => 'applications/meta/controller/PhabricatorApplicationUninstallController.php',
Fix XHProf index page Summary: Ref T2870. This resolves a few issues: - No proper Application. Define one. - Routes are in the default controller. Move them to the application. - UI doesn't work on mobile. - Overescaping in the link column. Test Plan: Old page: {F38444} New page: {F38445} Reviewers: btrahan, chad Reviewed By: chad CC: aran, AnhNhan, edward Maniphest Tasks: T2870 Differential Revision: https://secure.phabricator.com/D5531
2013-04-02 18:52:52 +02:00
'PhabricatorApplicationXHProf' => 'applications/xhprof/application/PhabricatorApplicationXHProf.php',
Initial Commint Summary: Created "Applications" application which lists all the installed applications in phabricator. Test Plan: Navigated to localphabricatorinstall.com/applications and check whether it actually shows the list of all installed applications. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2352 Differential Revision: https://secure.phabricator.com/D4548
2013-01-19 22:46:48 +01:00
'PhabricatorApplicationsController' => 'applications/meta/controller/PhabricatorApplicationsController.php',
'PhabricatorApplicationsListController' => 'applications/meta/controller/PhabricatorApplicationsListController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorAuditActionConstants' => 'applications/audit/constants/PhabricatorAuditActionConstants.php',
'PhabricatorAuditAddCommentController' => 'applications/audit/controller/PhabricatorAuditAddCommentController.php',
'PhabricatorAuditComment' => 'applications/audit/storage/PhabricatorAuditComment.php',
'PhabricatorAuditCommentEditor' => 'applications/audit/editor/PhabricatorAuditCommentEditor.php',
'PhabricatorAuditCommitListView' => 'applications/audit/view/PhabricatorAuditCommitListView.php',
'PhabricatorAuditCommitQuery' => 'applications/audit/query/PhabricatorAuditCommitQuery.php',
'PhabricatorAuditCommitStatusConstants' => 'applications/audit/constants/PhabricatorAuditCommitStatusConstants.php',
'PhabricatorAuditController' => 'applications/audit/controller/PhabricatorAuditController.php',
'PhabricatorAuditDAO' => 'applications/audit/storage/PhabricatorAuditDAO.php',
'PhabricatorAuditInlineComment' => 'applications/audit/storage/PhabricatorAuditInlineComment.php',
'PhabricatorAuditListController' => 'applications/audit/controller/PhabricatorAuditListController.php',
'PhabricatorAuditListView' => 'applications/audit/view/PhabricatorAuditListView.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorAuditMailReceiver' => 'applications/audit/mail/PhabricatorAuditMailReceiver.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorAuditPreviewController' => 'applications/audit/controller/PhabricatorAuditPreviewController.php',
'PhabricatorAuditQuery' => 'applications/audit/query/PhabricatorAuditQuery.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorAuditReplyHandler' => 'applications/audit/mail/PhabricatorAuditReplyHandler.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorAuditStatusConstants' => 'applications/audit/constants/PhabricatorAuditStatusConstants.php',
'PhabricatorAuthController' => 'applications/auth/controller/PhabricatorAuthController.php',
Generalize login flows for new registration Summary: Ref T1536. None of this code is reachable. `PhabricatorAuthLoginController` provides a completely generic login/link flow, similar to how D6155 provides a generic registration flow. `PhabricatorAuthProvider` wraps a `PhutilAuthAdapter` and glues the generic top-level flow to a concrete authentication provider. Test Plan: Static only, code isn't meaningfully reachable. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6159
2013-06-16 19:14:07 +02:00
'PhabricatorAuthLoginController' => 'applications/auth/controller/PhabricatorAuthLoginController.php',
'PhabricatorAuthProvider' => 'applications/auth/provider/PhabricatorAuthProvider.php',
Move LDAP to new registration flow Summary: Ref T1536. LDAP is very likely the worst thing in existence. This has some rough edges (error handling isn't perfect) but is already better than the current LDAP experience! durrr Test Plan: Registered and logged in using LDAP. Reviewers: btrahan Reviewed By: btrahan CC: aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6177
2013-06-16 19:18:34 +02:00
'PhabricatorAuthProviderLDAP' => 'applications/auth/provider/PhabricatorAuthProviderLDAP.php',
Provide start screen and full registration flow on the new auth stuff Summary: Ref T1536. Code is intentionally made unreachable (see PhabricatorAuthProviderOAuthFacebook->isEnabled()). This adds: - A provider-driven "start" screen (this has the list of ways you can login/register). - Registration actually works. - Facebook OAuth works. @chad, do you have any design ideas on the start screen? I think we poked at it before, but the big issue was that there were a limitless number of providers. Today, we have: - Password - LDAP - Facebook - GitHub - Phabricator - Disqus - Google We plan to add: - Asana - An arbitrary number of additional instances of Phabricator Users want to add: - OpenID - Custom providers And I'd like to have these at some point: - Stripe - WePay - Amazon - Bitbucket So basically any UI for this has to accommodate 300 zillion auth options. I don't think we need to solve any UX problems here (realistically, installs enable 1-2 auth options and users don't actually face an overwhelming number of choices) but making the login forms less ugly would be nice. No combination of prebuilt elements seems to look very good for this use case. Test Plan: Registered a new acount with Facebook. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6161
2013-06-16 19:15:16 +02:00
'PhabricatorAuthProviderOAuth' => 'applications/auth/provider/PhabricatorAuthProviderOAuth.php',
Add Disqus OAuth to new flows Summary: Ref T1536. Adds Disqus as a Provider. Test Plan: Registered and logged in with Disqus. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6165
2013-06-16 19:16:14 +02:00
'PhabricatorAuthProviderOAuthDisqus' => 'applications/auth/provider/PhabricatorAuthProviderOAuthDisqus.php',
Provide start screen and full registration flow on the new auth stuff Summary: Ref T1536. Code is intentionally made unreachable (see PhabricatorAuthProviderOAuthFacebook->isEnabled()). This adds: - A provider-driven "start" screen (this has the list of ways you can login/register). - Registration actually works. - Facebook OAuth works. @chad, do you have any design ideas on the start screen? I think we poked at it before, but the big issue was that there were a limitless number of providers. Today, we have: - Password - LDAP - Facebook - GitHub - Phabricator - Disqus - Google We plan to add: - Asana - An arbitrary number of additional instances of Phabricator Users want to add: - OpenID - Custom providers And I'd like to have these at some point: - Stripe - WePay - Amazon - Bitbucket So basically any UI for this has to accommodate 300 zillion auth options. I don't think we need to solve any UX problems here (realistically, installs enable 1-2 auth options and users don't actually face an overwhelming number of choices) but making the login forms less ugly would be nice. No combination of prebuilt elements seems to look very good for this use case. Test Plan: Registered a new acount with Facebook. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6161
2013-06-16 19:15:16 +02:00
'PhabricatorAuthProviderOAuthFacebook' => 'applications/auth/provider/PhabricatorAuthProviderOAuthFacebook.php',
Add GitHub auth to new flows Summary: Ref T1536. Support for GitHub on new flows. Test Plan: Registered and logged in with GitHub. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6166
2013-06-16 19:17:29 +02:00
'PhabricatorAuthProviderOAuthGitHub' => 'applications/auth/provider/PhabricatorAuthProviderOAuthGitHub.php',
Add Google support to new registration flow Summary: Ref T1536. Adds Google support. Test Plan: Registered and logged in with Google. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6167
2013-06-16 19:18:04 +02:00
'PhabricatorAuthProviderOAuthGoogle' => 'applications/auth/provider/PhabricatorAuthProviderOAuthGoogle.php',
Add password authentication and registration to new registration Summary: Ref T1536. Ref T1930. Code is not reachable. This provides password authentication and registration on the new provider/adapter framework. I sort of cheated a little bit and don't really route any password logic through the adapter (instead, this provider uses an empty adapter and just sets the type/domain on it). I think the right way to do this //conceptually// is to treat username/passwords as an external black box which the adapter communicates with. However, this creates a lot of practical implementation and UX problems: - There would basically be two steps -- in the first one, you interact with the "password black box", which behaves like an OAuth provider. This produces some ExternalAccount associated with the username/password pair, then we go into normal registration. - In normal registration, we'd proceed normally. This means: - The registration flow would be split into two parts, one where you select a username/password (interacting with the black box) and one where you actually register (interacting with the generic flow). This is unusual and probably confusing for users. - We would need to do a lot of re-hashing of passwords, since passwords currently depend on the username and user PHID, which won't exist yet during registration or the "black box" phase. This is a big mess I don't want to deal with. - We hit a weird condition where two users complete step 1 with the same username but don't complete step 2 yet. The box knows about two different copies of the username, with two different passwords. When we arrive at step 2 the second time we have a lot of bad choices about how to reoslve it, most of which create security problems. The most stragihtforward and "pure" way to resolve the issues is to put password-auth usernames in a separate space, but this would be incredibly confusuing to users (your login name might not be the same as your username, which is bizarre). - If we change this, we need to update all the other password-related code, which I don't want to bother with (at least for now). Instead, let registration know about a "default" registration controller (which is always password, if enabled), and let it require a password. This gives us a much simpler (albeit slightly less pure) implementation: - All the fields are on one form. - Password adapter is just a shell. - Password provider does the heavy lifting. We might make this more pure at some point, but I'm generally pretty satisfied with this. This doesn't implement the brute-force CAPTCHA protection, that will be coming soon. Test Plan: Registered with password only and logged in with a password. Hit various error conditions. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1536, T1930 Differential Revision: https://secure.phabricator.com/D6164
2013-06-16 19:15:49 +02:00
'PhabricatorAuthProviderPassword' => 'applications/auth/provider/PhabricatorAuthProviderPassword.php',
New Registration Workflow Summary: Currently, registration and authentication are pretty messy. Two concrete problems: - The `PhabricatorLDAPRegistrationController` and `PhabricatorOAuthDefaultRegistrationController` controllers are giant copy/pastes of one another. This is really bad. - We can't practically implement OpenID because we can't reissue the authentication request. Additionally, the OAuth registration controller can be replaced wholesale by config, which is a huge API surface area and a giant mess. Broadly, the problem right now is that registration does too much: we hand it some set of indirect credentials (like OAuth tokens) and expect it to take those the entire way to a registered user. Instead, break registration into smaller steps: - User authenticates with remote service. - Phabricator pulls information (remote account ID, username, email, real name, profile picture, etc) from the remote service and saves it as `PhabricatorUserCredentials`. - Phabricator hands the `PhabricatorUserCredentials` to the registration form, which is agnostic about where they originate from: it can process LDAP credentials, OAuth credentials, plain old email credentials, HTTP basic auth credentials, etc. This doesn't do anything yet -- there is no way to create credentials objects (and no storage patch), but I wanted to get any initial feedback, especially about the event call for T2394. In particular, I think the implementation would look something like this: $profile = $event->getValue('profile') $username = $profile->getDefaultUsername(); $is_employee = is_this_a_facebook_employee($username); if (!$is_employee) { throw new Exception("You are not employed at Facebook."); } $fbid = get_fbid_for_facebook_username($username); $profile->setDefaultEmail($fbid); $profile->setCanEditUsername(false); $profile->setCanEditEmail(false); $profile->setCanEditRealName(false); $profile->setShouldVerifyEmail(true); Seem reasonable? Test Plan: N/A yet, probably fatals. Reviewers: vrana, btrahan, codeblock, chad Reviewed By: btrahan CC: aran, asherkin, nh, wez Maniphest Tasks: T1536, T2394 Differential Revision: https://secure.phabricator.com/D4647
2013-06-16 19:13:49 +02:00
'PhabricatorAuthRegisterController' => 'applications/auth/controller/PhabricatorAuthRegisterController.php',
Provide start screen and full registration flow on the new auth stuff Summary: Ref T1536. Code is intentionally made unreachable (see PhabricatorAuthProviderOAuthFacebook->isEnabled()). This adds: - A provider-driven "start" screen (this has the list of ways you can login/register). - Registration actually works. - Facebook OAuth works. @chad, do you have any design ideas on the start screen? I think we poked at it before, but the big issue was that there were a limitless number of providers. Today, we have: - Password - LDAP - Facebook - GitHub - Phabricator - Disqus - Google We plan to add: - Asana - An arbitrary number of additional instances of Phabricator Users want to add: - OpenID - Custom providers And I'd like to have these at some point: - Stripe - WePay - Amazon - Bitbucket So basically any UI for this has to accommodate 300 zillion auth options. I don't think we need to solve any UX problems here (realistically, installs enable 1-2 auth options and users don't actually face an overwhelming number of choices) but making the login forms less ugly would be nice. No combination of prebuilt elements seems to look very good for this use case. Test Plan: Registered a new acount with Facebook. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6161
2013-06-16 19:15:16 +02:00
'PhabricatorAuthStartController' => 'applications/auth/controller/PhabricatorAuthStartController.php',
Implement new auth login flow and login validation controller Summary: Ref T1536. None of this code is reachable. Implements new-auth login (so you can actually login) and login validation (which checks that cookies were set correctly). Test Plan: Manually enabled FB auth, went through the auth flow to login/logout. Manually hit most of the validation errors. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6162
2013-06-16 19:15:33 +02:00
'PhabricatorAuthValidateController' => 'applications/auth/controller/PhabricatorAuthValidateController.php',
First go at Authentication config options. Test Plan: Looked at them in the web UI. Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4355
2013-01-07 21:48:39 +01:00
'PhabricatorAuthenticationConfigOptions' => 'applications/config/option/PhabricatorAuthenticationConfigOptions.php',
Separate "PhabricatorBarePageView" out of "PhabricatorStandardPageView" Summary: For Phame, we really want more than a chromeless page -- it shouldn't have Javelin or Phabricator styles on it. Pull the bare infrastructure out of StandardPageView and make it available as BarePageView. Test Plan: Viewed bare page in UIExamples, various non-bare pages. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3711
2012-10-16 19:33:47 +02:00
'PhabricatorBarePageExample' => 'applications/uiexample/examples/PhabricatorBarePageExample.php',
'PhabricatorBarePageView' => 'view/page/PhabricatorBarePageView.php',
Allow extending English translation Test Plan: Displayed home. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D2759
2012-06-15 04:01:57 +02:00
'PhabricatorBaseEnglishTranslation' => 'infrastructure/internationalization/PhabricatorBaseEnglishTranslation.php',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorBaseProtocolAdapter' => 'infrastructure/daemon/bot/adapter/PhabricatorBaseProtocolAdapter.php',
'PhabricatorBot' => 'infrastructure/daemon/bot/PhabricatorBot.php',
Added Flowdock protocol adapter for the bot. Refactored campfire bot into a base streaming protocol adapter for common functionality. Summary: First pass. Flowdock supports interesting message types (like replies to messages), but for now implementing a standard messaging interface. Test Plan: Ran both a Flowdock bot and a Campfire bot. Made sure both still connected and responded properly to the Object Handler. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4983
2013-02-16 05:24:23 +01:00
'PhabricatorBotBaseStreamingProtocolAdapter' => 'infrastructure/daemon/bot/adapter/PhabricatorBotBaseStreamingProtocolAdapter.php',
Formalize targets (users and channel) into objects Summary: Make users/channels/rooms into objects, so we can later sort out stuff like Campfire user IDs, Phabricator vs chat accounts, etc. The only change here is that I removed output buffering from the macro handler. We should move throttling/buffering to adapters instead and have it apply globally. Test Plan: Ran IRC and Campfire bots and interacted with them. Reviewers: indiefan Reviewed By: indiefan CC: aran Differential Revision: https://secure.phabricator.com/D4924
2013-02-14 14:13:38 +01:00
'PhabricatorBotChannel' => 'infrastructure/daemon/bot/target/PhabricatorBotChannel.php',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorBotDebugLogHandler' => 'infrastructure/daemon/bot/handler/PhabricatorBotDebugLogHandler.php',
'PhabricatorBotDifferentialNotificationHandler' => 'infrastructure/daemon/bot/handler/PhabricatorBotDifferentialNotificationHandler.php',
'PhabricatorBotFeedNotificationHandler' => 'infrastructure/daemon/bot/handler/PhabricatorBotFeedNotificationHandler.php',
Added Flowdock protocol adapter for the bot. Refactored campfire bot into a base streaming protocol adapter for common functionality. Summary: First pass. Flowdock supports interesting message types (like replies to messages), but for now implementing a standard messaging interface. Test Plan: Ran both a Flowdock bot and a Campfire bot. Made sure both still connected and responded properly to the Object Handler. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4983
2013-02-16 05:24:23 +01:00
'PhabricatorBotFlowdockProtocolAdapter' => 'infrastructure/daemon/bot/adapter/PhabricatorBotFlowdockProtocolAdapter.php',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorBotHandler' => 'infrastructure/daemon/bot/handler/PhabricatorBotHandler.php',
'PhabricatorBotLogHandler' => 'infrastructure/daemon/bot/handler/PhabricatorBotLogHandler.php',
'PhabricatorBotMacroHandler' => 'infrastructure/daemon/bot/handler/PhabricatorBotMacroHandler.php',
'PhabricatorBotMessage' => 'infrastructure/daemon/bot/PhabricatorBotMessage.php',
'PhabricatorBotObjectNameHandler' => 'infrastructure/daemon/bot/handler/PhabricatorBotObjectNameHandler.php',
'PhabricatorBotSymbolHandler' => 'infrastructure/daemon/bot/handler/PhabricatorBotSymbolHandler.php',
Formalize targets (users and channel) into objects Summary: Make users/channels/rooms into objects, so we can later sort out stuff like Campfire user IDs, Phabricator vs chat accounts, etc. The only change here is that I removed output buffering from the macro handler. We should move throttling/buffering to adapters instead and have it apply globally. Test Plan: Ran IRC and Campfire bots and interacted with them. Reviewers: indiefan Reviewed By: indiefan CC: aran Differential Revision: https://secure.phabricator.com/D4924
2013-02-14 14:13:38 +01:00
'PhabricatorBotTarget' => 'infrastructure/daemon/bot/target/PhabricatorBotTarget.php',
'PhabricatorBotUser' => 'infrastructure/daemon/bot/target/PhabricatorBotUser.php',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorBotWhatsNewHandler' => 'infrastructure/daemon/bot/handler/PhabricatorBotWhatsNewHandler.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'PhabricatorBuiltinPatchList' => 'infrastructure/storage/patch/PhabricatorBuiltinPatchList.php',
Add a generic multistep Markup cache Summary: The immediate issue this addresses is T1366, adding a rendering cache to Phriction. For wiki pages with code blocks especially, rerendering them each time is expensive. The broader issue is that out markup caches aren't very good right now. They have three major problems: **Problem 1: the data is stored in the wrong place.** We currently store remarkup caches on objects. This means we're always loading it and passing it around even when we don't need it, can't genericize cache management code (e.g., have one simple script to drop/GC caches), need to update authoritative rows to clear caches, and can't genericize rendering code since each object is different. To solve this, I created a dedicated cache database that I plan to move all markup caches to use. **Problem 2: time-variant rules break when cached.** Some rules like `**bold**` are time-invariant and always produce the same output, but some rules like `{Tnnn}` and `@username` are variant and may render differently (because a task was closed or a user is on vacation). Currently, we cache the raw output, so these time-variant rules get locked at whatever values they had when they were first rendered. This is the main reason Phriction doesn't have a cache right now -- I wanted `{Tnnn}` rules to reflect open/closed tasks. To solve this, I split markup into a "preprocessing" phase (which does all the parsing and evaluates all time-invariant rules) and a "postprocessing" phase (which evaluates time-variant rules only). The preprocessing phase is most of the expense (and, notably, includes syntax highlighting) so this is nearly as good as caching the final output. I did most of the work here in D737 / D738, but we never moved to use it in Phabricator -- we currently just do the two operations serially in all cases. This diff splits them apart and caches the output of preprocessing only, so we benefit from caching but also get accurate time-variant rendering. **Problem 3: cache access isn't batched/pipelined optimally.** When we're rendering a list of markup blocks, we should be able to batch datafetching better than we do. D738 helped with this (fetching is batched within a single hunk of markup) and this improves batching on cache access. We could still do better here, but this is at least a step forward. Also fixes a bug with generating a link in the Phriction history interface ($uri gets clobbered). I'm using PHP serialization instead of JSON serialization because Remarkup does some stuff with non-ascii characters that might not survive JSON. Test Plan: - Created a Phriction document and verified that previews don't go to cache (no rows appear in the cache table). - Verified that published documents come out of cache. - Verified that caches generate/regenerate correctly, time-variant rules render properly and old documents hit the right caches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1366 Differential Revision: https://secure.phabricator.com/D2945
2012-07-10 00:20:56 +02:00
'PhabricatorCacheDAO' => 'applications/cache/storage/PhabricatorCacheDAO.php',
Provide 'bin/cache', for managing caches Summary: See <https://github.com/facebook/phabricator/issues/323>. We have a very old cache management script which doesn't purge all the modern caches (and does purge some caches which are no longer in use). Update it so it purges all the modern caches (remarkup, general, changeset), no longer purges outdated caches, and is easier to use. Also delete a lot of "this script has moved" scripts from the last few rounds of similar cleanup, I believe all of these have been in master for at least several months, which should be enough time for users to get used to the new stuff. Test Plan: Ran `bin/cache` with various arguments. Verified caches were purged. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5978
2013-05-20 19:16:35 +02:00
'PhabricatorCacheManagementPurgeWorkflow' => 'applications/cache/management/PhabricatorCacheManagementPurgeWorkflow.php',
'PhabricatorCacheManagementWorkflow' => 'applications/cache/management/PhabricatorCacheManagementWorkflow.php',
Add a "setup" cache Summary: See T2062. This cache allows us to essentially implement this sort of block: if (this_code_has_not_run_since_the_last_server_restart()) { ... } This will let us do setup checks automatically (i.e., without a specialized setup mode) without imposing hundreds of milliseconds of `git submodule status` and similar checks on every page load, even if an install does not have APC. Broadly, the major goals here are: - Reduce user errors and support costs related to misconfiguration (e.g., failure to update submodules). - Simplify setup and configuration (remove 'phabricator.setup', remove/reduce PHABRICATOR_ENV). - Move as much configuration to the web as possible (required for SaaS). Test Plan: Added this block to webroot/index.php: $cache = PhabricatorCaches::getSetupCache(); $result = $cache->getKeys(array('x')); if (empty($result['x'])) { phlog('Cache miss + set.'); $cache->setKeys(array('x' => 'y')); } else { phlog('Cache hit.'); } Verified it used APC correctly. Disabled APC and verified it degraded to a reasonable disk-based behavior. If we miss both of these we end up with no actual caching, but that's the best we can do. This code will also run too early in setup for it to be appropriate to raise exceptions out of this pathway -- later on, we can raise a warning that APC is not installed. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2227, T2062 Differential Revision: https://secure.phabricator.com/D4281
2012-12-25 15:09:51 +01:00
'PhabricatorCaches' => 'applications/cache/PhabricatorCaches.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorCalendarBrowseController' => 'applications/calendar/controller/PhabricatorCalendarBrowseController.php',
'PhabricatorCalendarController' => 'applications/calendar/controller/PhabricatorCalendarController.php',
'PhabricatorCalendarDAO' => 'applications/calendar/storage/PhabricatorCalendarDAO.php',
Create a status tool by giving /calendar/ some teeth Summary: you can now add, edit, and delete status events. also added a "description" to status events and surface it in the big calendar view on mouse hover. some refactoring changes as well to make validation logic centralized within the storage class. Test Plan: added, edited, deleted. yay. Reviewers: epriestley, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T407 Differential Revision: https://secure.phabricator.com/D3810
2012-10-24 22:22:24 +02:00
'PhabricatorCalendarDeleteStatusController' => 'applications/calendar/controller/PhabricatorCalendarDeleteStatusController.php',
'PhabricatorCalendarEditStatusController' => 'applications/calendar/controller/PhabricatorCalendarEditStatusController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorCalendarHoliday' => 'applications/calendar/storage/PhabricatorCalendarHoliday.php',
'PhabricatorCalendarHolidayTestCase' => 'applications/calendar/storage/__tests__/PhabricatorCalendarHolidayTestCase.php',
Create a status tool by giving /calendar/ some teeth Summary: you can now add, edit, and delete status events. also added a "description" to status events and surface it in the big calendar view on mouse hover. some refactoring changes as well to make validation logic centralized within the storage class. Test Plan: added, edited, deleted. yay. Reviewers: epriestley, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T407 Differential Revision: https://secure.phabricator.com/D3810
2012-10-24 22:22:24 +02:00
'PhabricatorCalendarViewStatusController' => 'applications/calendar/controller/PhabricatorCalendarViewStatusController.php',
First (rough) pass at campfire protocol adapter for bot. Summary: Decided the best approach for refactoring the message/command stuff would be to actually start implementing the campfire adapter to get a better idea of what the abstractions should look like. It feels awkward and unwieldy trying to maintain the irc command interface (notice the message instantiation in the `processReadBuffer()` method. However, i'm still not clear what the best approach is without requiring a re-write of nearly all the existing handlers and defining essentially a custom dsl on top of irc's. I suppose given that alternative, implementing to irc's dsl doesn't sound all that bad. Just feels like poor coupling. Also, I know that there is some http stuff in libphutil's futures library, but the https future is shit and I need to do some custom curlopt stuff I wasn't sure how to do with that. But if you think this should be refactored, let me know. I tested this with the ObjectHandler (messages with DXXX initiate the bot to respond with the title/link just as with irc), but beyond that, I haven't tried any of the other handlers, so if there are complications you think i'm going to run into, just let me know (this is one of the reasons for requesting review early on). Also, this diff is against my last one, even though that hasn't been merged down yet. It was starting to get large and I'd prefer to keep to two conversations separate. Fixing some lint issues. Test Plan: Ran the bot with the Object Handler in campfire and observed it behaving properly. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4830
2013-02-07 15:31:29 +01:00
'PhabricatorCampfireProtocolAdapter' => 'infrastructure/daemon/bot/adapter/PhabricatorCampfireProtocolAdapter.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorChangesetResponse' => 'infrastructure/diff/PhabricatorChangesetResponse.php',
Added a new storage object Summary: Added a new storage object. Created PhabricatorChagLogChannel Test Plan: Will be specified by Evan :P Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4943
2013-02-14 13:10:42 +01:00
'PhabricatorChatLogChannel' => 'applications/chatlog/storage/PhabricatorChatLogChannel.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorChatLogChannelListController' => 'applications/chatlog/controller/PhabricatorChatLogChannelListController.php',
'PhabricatorChatLogChannelLogController' => 'applications/chatlog/controller/PhabricatorChatLogChannelLogController.php',
Moving code off channel Summary: Deleted code which used channel. Created PhabricatorChatLogChannelQuery.php Test Plan: By manually checking in the chatlog application. Reviewers: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5010
2013-02-22 15:59:17 +01:00
'PhabricatorChatLogChannelQuery' => 'applications/chatlog/PhabricatorChatLogChannelQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorChatLogConstants' => 'applications/chatlog/constants/PhabricatorChatLogConstants.php',
'PhabricatorChatLogController' => 'applications/chatlog/controller/PhabricatorChatLogController.php',
'PhabricatorChatLogDAO' => 'applications/chatlog/storage/PhabricatorChatLogDAO.php',
'PhabricatorChatLogEvent' => 'applications/chatlog/storage/PhabricatorChatLogEvent.php',
'PhabricatorChatLogEventType' => 'applications/chatlog/constants/PhabricatorChatLogEventType.php',
'PhabricatorChatLogQuery' => 'applications/chatlog/PhabricatorChatLogQuery.php',
'PhabricatorConduitAPIController' => 'applications/conduit/controller/PhabricatorConduitAPIController.php',
'PhabricatorConduitCertificateToken' => 'applications/conduit/storage/PhabricatorConduitCertificateToken.php',
Route internal conduit calls if other hosts available Summary: Ref T2785 Looks for hosts in `conduit.servers` config and if any exist route any conduit calls through any one of the hosts. Test Plan: Make some curl calls to public methods (`conduit.ping`), watch the access log for two requests. Make some calls from the UI that require authentication, watch the access log a bit more. Also ran the unit tests. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2785 Differential Revision: https://secure.phabricator.com/D5970
2013-05-19 13:16:09 +02:00
'PhabricatorConduitConfigOptions' => 'applications/conduit/config/PhabricatorConduitConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorConduitConnectionLog' => 'applications/conduit/storage/PhabricatorConduitConnectionLog.php',
'PhabricatorConduitConsoleController' => 'applications/conduit/controller/PhabricatorConduitConsoleController.php',
'PhabricatorConduitController' => 'applications/conduit/controller/PhabricatorConduitController.php',
'PhabricatorConduitDAO' => 'applications/conduit/storage/PhabricatorConduitDAO.php',
'PhabricatorConduitListController' => 'applications/conduit/controller/PhabricatorConduitListController.php',
'PhabricatorConduitLogController' => 'applications/conduit/controller/PhabricatorConduitLogController.php',
'PhabricatorConduitMethodCallLog' => 'applications/conduit/storage/PhabricatorConduitMethodCallLog.php',
'PhabricatorConduitTokenController' => 'applications/conduit/controller/PhabricatorConduitTokenController.php',
Move "show all config" from DarkConsole to /config/ Summary: Currently, we have a "config" panel in DarkConsole. It's useful to have a table of all effective config values, but it doesn't need to be in DarkConsole. Move it to Config instead. Basically: - You don't need to activate DarkConsole to see it anymore; - now visible only to admins; - respects config mask/hide; - somewhat prettier; - links to config edit; - no longer ships down on every DarkConsole request with a giant table of rarely-used data. Test Plan: Looked at the table. Looked at lack of table in darkconsole. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4473
2013-01-16 20:10:41 +01:00
'PhabricatorConfigAllController' => 'applications/config/controller/PhabricatorConfigAllController.php',
Start of a config web interface. Summary: This is somewhat clowny, particularly in how it handles JSON encode/decode, but I've commented why I did things the way I did. The goal is to store minified JSON but show pretty-printed JSON where possible, to the user editing it. Test Plan: * Went to /config/ and saw a list of keys from the `default` config. * Clicked on one of them, submitted the default value successfully. * Changed the value to invalid JSON and got a decent error. * Changed the value to valid JSON and checked the DB to confirm it saved. * Confirmed the DB values were minified. * Confirmed the user-facing values were pretty-printed where they could be. * Confirmed that PHIDs were getting assigned properly and that isDeleted properly defaulted to false/0. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2246 Differential Revision: https://secure.phabricator.com/D4290
2012-12-28 00:20:09 +01:00
'PhabricatorConfigController' => 'applications/config/controller/PhabricatorConfigController.php',
Add database configuration source to the source stack Summary: Read configuration from the new database source. This adds an extra MySQL connect + query to every page. They're very cheap so I think we can suffer them for now, but I'd like to put cache in front of this at some point. The difficulties are: - If we use APC, multi-frontend installs (Facebook) can't dirty it (major problem), and the CLI can't dirty it (fine for now, maybe a major problem later). - If we use Memcache, we need to add config stuff. - We could use APC in all non-Facebook installs if we can make it dirtyable from the CLI, but I don't see a reasonable way to do that. - We don't have any other caches which are faster than the database. So I'll probably implement Memcache support at some point, although this is a lame excuse for it. Test Plan: Added some config values via web UI, saw them active on the install. Reviewers: btrahan, codeblock, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221 Differential Revision: https://secure.phabricator.com/D4296
2013-01-18 00:10:21 +01:00
'PhabricatorConfigDatabaseSource' => 'infrastructure/env/PhabricatorConfigDatabaseSource.php',
Show all configuration defaults when editing configuration Summary: Show the value for all loaded configuration sources. Test Plan: {F28469} {F28470} {F28471} Reviewers: btrahan, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4312
2013-01-01 23:10:33 +01:00
'PhabricatorConfigDefaultSource' => 'infrastructure/env/PhabricatorConfigDefaultSource.php',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorConfigDictionarySource' => 'infrastructure/env/PhabricatorConfigDictionarySource.php',
Start of a config web interface. Summary: This is somewhat clowny, particularly in how it handles JSON encode/decode, but I've commented why I did things the way I did. The goal is to store minified JSON but show pretty-printed JSON where possible, to the user editing it. Test Plan: * Went to /config/ and saw a list of keys from the `default` config. * Clicked on one of them, submitted the default value successfully. * Changed the value to invalid JSON and got a decent error. * Changed the value to valid JSON and checked the DB to confirm it saved. * Confirmed the DB values were minified. * Confirmed the user-facing values were pretty-printed where they could be. * Confirmed that PHIDs were getting assigned properly and that isDeleted properly defaulted to false/0. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2246 Differential Revision: https://secure.phabricator.com/D4290
2012-12-28 00:20:09 +01:00
'PhabricatorConfigEditController' => 'applications/config/controller/PhabricatorConfigEditController.php',
Use transactions to show edit history for Configuration Summary: Use ApplicationTransactions in Config to create an edit history. Resolves T2256. Test Plan: {F28477} Reviewers: btrahan, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2256 Differential Revision: https://secure.phabricator.com/D4314
2013-01-02 03:14:41 +01:00
'PhabricatorConfigEditor' => 'applications/config/editor/PhabricatorConfigEditor.php',
Start of a config web interface. Summary: This is somewhat clowny, particularly in how it handles JSON encode/decode, but I've commented why I did things the way I did. The goal is to store minified JSON but show pretty-printed JSON where possible, to the user editing it. Test Plan: * Went to /config/ and saw a list of keys from the `default` config. * Clicked on one of them, submitted the default value successfully. * Changed the value to invalid JSON and got a decent error. * Changed the value to valid JSON and checked the DB to confirm it saved. * Confirmed the DB values were minified. * Confirmed the user-facing values were pretty-printed where they could be. * Confirmed that PHIDs were getting assigned properly and that isDeleted properly defaulted to false/0. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2246 Differential Revision: https://secure.phabricator.com/D4290
2012-12-28 00:20:09 +01:00
'PhabricatorConfigEntry' => 'applications/config/storage/PhabricatorConfigEntry.php',
'PhabricatorConfigEntryDAO' => 'applications/config/storage/PhabricatorConfigEntryDAO.php',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorConfigFileSource' => 'infrastructure/env/PhabricatorConfigFileSource.php',
Begin moving Phabricator configuration into PHP Summary: Ref T2255. Ref T2221. Lay the groundwork to move configuration into PHP, so we can show descriptions in the web UI, do typechecking, disable application options when an application is uninstalled, etc. Test Plan: {F28421} {F28420} {F28422} Reviewers: codeblock, btrahan, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221, T2255 Differential Revision: https://secure.phabricator.com/D4306
2012-12-31 00:36:06 +01:00
'PhabricatorConfigGroupController' => 'applications/config/controller/PhabricatorConfigGroupController.php',
Button to ignore setup issues + refractoring Summary: T2381 Test Plan: Click on the ignore link in /config/issue/ and respond to the dialog box. Also, test uninstalling and reinstalling an application in the web UI (to verify that refractoring didn't break anything). Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2381 Differential Revision: https://secure.phabricator.com/D5234
2013-03-06 23:14:09 +01:00
'PhabricatorConfigIgnoreController' => 'applications/config/controller/PhabricatorConfigIgnoreController.php',
Detect and raise setup warnings from within Phabricator Summary: This is basicaly a light version of D4286. The major problem with D4286 is that it's a huge leap and completely replaces the setup process in one step. Instead, I want to do this: - Add the post-setup warnings (yellow bar with "6 unresolved warnings..."). - Copy all setup checks into post-setup warnings (so every check has an old-style check and a new-style check). - Run that for a little bit and make sure it's stable. - Implement fatal post-setup checks (the red screen, vs the yellow bar). - Run that for a little bit. - Nuke setup mode and delete all the old checks. This should give us a bunch of very gradual steps toward the brave new world of simpler setup. Test Plan: - Faked APC setup failures, saw warnings raise. - Verified that this runs after restart (get + set). - Verified that this costs us only one cache hit after first-run (get only). Reviewers: btrahan, codeblock, vrana, chad Reviewed By: codeblock CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4295
2012-12-30 15:37:49 +01:00
'PhabricatorConfigIssueListController' => 'applications/config/controller/PhabricatorConfigIssueListController.php',
'PhabricatorConfigIssueViewController' => 'applications/config/controller/PhabricatorConfigIssueViewController.php',
Fix error in `PhabricatorSetupIssueView` Summary: - Move `prettyPrintJSON()` and make it static. - Use it from `PhabricatorSetupIssueView` - Update other `config/` places that use it to call it from the new class. This fixes a bug in `PhabricatorSetupIssueView` which showed up if the value was an array and couldn't be rendered by `phutil_escape_html()`. Test Plan: - Rendered some config options. - Went to /config/issue/config.unknown.phame.skins/ without error. Reviewers: epriestley, btrahan, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4411
2013-01-12 00:28:33 +01:00
'PhabricatorConfigJSON' => 'applications/config/json/PhabricatorConfigJSON.php',
Start of a config web interface. Summary: This is somewhat clowny, particularly in how it handles JSON encode/decode, but I've commented why I did things the way I did. The goal is to store minified JSON but show pretty-printed JSON where possible, to the user editing it. Test Plan: * Went to /config/ and saw a list of keys from the `default` config. * Clicked on one of them, submitted the default value successfully. * Changed the value to invalid JSON and got a decent error. * Changed the value to valid JSON and checked the DB to confirm it saved. * Confirmed the DB values were minified. * Confirmed the user-facing values were pretty-printed where they could be. * Confirmed that PHIDs were getting assigned properly and that isDeleted properly defaulted to false/0. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2246 Differential Revision: https://secure.phabricator.com/D4290
2012-12-28 00:20:09 +01:00
'PhabricatorConfigListController' => 'applications/config/controller/PhabricatorConfigListController.php',
Add a local configuration source and a non-environmental ENV config source Summary: See discussion in T2221. Before we can move configuration to the database, we have a bootstrapping problem: we need database credentials to live //somewhere// if we can't guess them (and we can only really guess localhost / root / no password). Some options for this are: - Have them live in ENV variables. - These are often somewhat unfamiliar to users. - Scripts would become a huge pain -- you'd have to dump a bunch of stuff into ENV. - Some environments have limited ability to set ENV vars. - SSH is also a pain. - Have them live in a normal config file. - This probably isn't really too awful, but: - Since we deploy/upgrade with git, we can't currently let them edit a file which already exists, or their working copy will become dirty. - So they have to copy or create a file, then edit it. - The biggest issue I have with this is that it will be difficult to give specific, easily-followed directions from Setup. The instructions need to be like "Copy template.conf.php to real.conf.php, then edit these keys: x, y, z". This isn't as easy to follow as "run script Y". - Have them live in an abnormal config file with script access (this diff). - I think this is a little better than a normal config file, because we can tell users 'run phabricator/bin/config set mysql.user phabricator' and such, which is easier to follow than editing a config file. I think this is only a marginal improvement over a normal config file and am open to arguments against this approach, but I think it will be a little easier for users to deal with than a normal config file. In most cases they should only need to store three values in this file -- db user/host/pass -- since once we have those we can bootstrap everything else. Normal config files also aren't going away for more advanced users, we're just offering a simple alternative for most users. This also adds an ENVIRONMENT file as an alternative to PHABRICATOR_ENV. This is just a simple way to specify the environment if you don't have convenient access to env vars. Test Plan: Ran `config set x y`, verified writes. Wrote to ENVIRONMENT, ran `PHABRICATOR_ENV= ./bin/repository`. Reviewers: btrahan, vrana, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2221 Differential Revision: https://secure.phabricator.com/D4294
2012-12-30 15:16:15 +01:00
'PhabricatorConfigLocalSource' => 'infrastructure/env/PhabricatorConfigLocalSource.php',
Increase the power of `bin/config` Summary: Fixes T2254. Make the CLI for config more powerful: - Add validation for `set`. - Add `get`. - Add `list`. - Add `delete`. The `get` command produces fairly verbose JSON to support flags like `--all`, or `--source database` later. The other commands are straightforward. Test Plan: Tested `config set`: $ ./bin/config set Usage Exception: Specify a configuration key and a value to set it to. $ ./bin/config set x Usage Exception: Specify a value to set the key 'x' to. $ ./bin/config set phabricator.base-uri Usage Exception: Specify a value to set the key 'phabricator.base-uri' to. $ ./bin/config set phabricator.base-uri x Usage Exception: Config option 'phabricator.base-uri' is invalid. The URI must start with 'http://' or 'https://'. $ ./bin/config set phabricator.base-uri http://x Usage Exception: Config option 'phabricator.base-uri' is invalid. The URI must contain a dot ('.'), like 'http://example.com/', not just a bare name like 'http://example/'. Some web browsers will not set cookies on domains with no TLD. $ ./bin/config set phabricator.base-uri http://x.com Set 'phabricator.base-uri' in local configuration. $ Tested `config get`: $ ./bin/config get pygments.enabled { "config" : [] } $ ./bin/config set pygments.enabled true Set 'pygments.enabled' in local configuration. $ ./bin/config get pygments.enabled { "config" : [ { "key" : "pygments.enabled", "source" : "local", "value" : true } ] } $ Tested `config delete`: $ ./bin/config delete Usage Exception: Specify a configuration key to delete. $ ./bin/config delete x x Usage Exception: Too many arguments: expected one key. $ ./bin/config delete x Usage Exception: No such configuration key 'x'! Use `config list` to list all keys. $ ./bin/config delete pygments.enabled Deleted 'pygments.enabled' from local configuration. $ ./bin/config delete pygments.enabled Usage Exception: Configuration key 'pygments.enabled' is not set in local configuration! $ Tested `config list`: $ ./bin/config list account.editable account.minimum-password-length amazon-ec2.access-key amazon-ec2.secret-key amazon-s3.access-key amazon-s3.endpoint amazon-s3.secret-key amazon-ses.access-key amazon-ses.secret-key aphront.default-application-configuration-class audit.can-author-close-audit auth.email-domains auth.login-message auth.password-auth-enabled auth.require-email-verification auth.sessions.conduit auth.sessions.web auth.sshkeys.enabled cache.enable-deflate celerity.force-disk-reads celerity.minify celerity.resource-hash celerity.resource-path config.hide config.lock config.mask controller.oauth-registration darkconsole.always-on darkconsole.enabled debug.profile-rate debug.stop-on-redirect differential.allow-reopen differential.allow-self-accept differential.always-allow-close differential.anonymous-access differential.custom-remarkup-block-rules differential.custom-remarkup-rules differential.days-fresh differential.days-stale differential.enable-email-accept differential.expose-emails-prudently differential.field-selector differential.generated-paths differential.require-test-plan-field differential.revision-custom-detail-renderer differential.show-host-field differential.show-test-plan-field differential.whitespace-matters disqus.application-id disqus.application-secret disqus.auth-enabled disqus.auth-permanent disqus.registration-enabled disqus.shortname environment.append-paths events.listeners facebook.application-id facebook.application-secret facebook.auth-enabled facebook.auth-permanent facebook.registration-enabled facebook.require-https-auth feed.http-hooks feed.public files.image-mime-types files.viewable-mime-types gcdaemon.ttl.daemon-logs gcdaemon.ttl.differential-parse-cache gcdaemon.ttl.general-cache gcdaemon.ttl.herald-transcripts gcdaemon.ttl.markup-cache gcdaemon.ttl.task-archive github.application-id github.application-secret github.auth-enabled github.auth-permanent github.registration-enabled google.application-id google.application-secret google.auth-enabled google.auth-permanent google.registration-enabled ldap.activedirectory_domain ldap.anonymous-user-name ldap.anonymous-user-password ldap.auth-enabled ldap.base_dn ldap.hostname ldap.port ldap.real_name_attributes ldap.referrals ldap.search-first ldap.search_attribute ldap.start-tls ldap.username-attribute ldap.version load-libraries log.access.format log.access.path maniphest.custom-fields maniphest.custom-task-extensions-class maniphest.default-priority maniphest.enabled metamta.can-send-as-user metamta.default-address metamta.differential.attach-patches metamta.differential.inline-patches metamta.differential.patch-format metamta.differential.reply-handler metamta.differential.reply-handler-domain metamta.differential.subject-prefix metamta.differential.unified-comment-context metamta.diffusion.attach-patches metamta.diffusion.byte-limit metamta.diffusion.inline-patches metamta.diffusion.reply-handler metamta.diffusion.reply-handler-domain metamta.diffusion.subject-prefix metamta.diffusion.time-limit metamta.domain metamta.herald.show-hints metamta.insecure-auth-with-reply-to metamta.macro.reply-handler-domain metamta.macro.subject-prefix metamta.mail-adapter metamta.maniphest.default-public-author metamta.maniphest.public-create-email metamta.maniphest.reply-handler metamta.maniphest.reply-handler-domain metamta.maniphest.subject-prefix metamta.one-mail-per-recipient metamta.package.reply-handler metamta.package.subject-prefix metamta.pholio.reply-handler-domain metamta.pholio.subject-prefix metamta.placeholder-to-recipient metamta.precedence-bulk metamta.public-replies metamta.re-prefix metamta.recipients.show-hints metamta.reply.show-hints metamta.send-immediately metamta.single-reply-handler-prefix metamta.user-address-format metamta.vary-subjects mysql.configuration-provider mysql.host mysql.implementation mysql.pass mysql.user notification.client-uri notification.debug notification.enabled notification.log notification.pidfile notification.server-uri notification.user phabricator.application-id phabricator.application-secret phabricator.auth-enabled phabricator.auth-permanent phabricator.base-uri phabricator.csrf-key phabricator.env phabricator.mail-key phabricator.oauth-uri phabricator.production-uri phabricator.registration-enabled phabricator.serious-business phabricator.setup phabricator.show-beta-applications phabricator.show-error-callout phabricator.show-stack-traces phabricator.timezone phame.skins phd.log-directory phd.pid-directory phd.start-taskmasters phd.trace phd.verbose phid.external-loaders phpmailer.mailer phpmailer.smtp-host phpmailer.smtp-password phpmailer.smtp-port phpmailer.smtp-protocol phpmailer.smtp-user phriction.enabled policy.allow-public pygments.dropdown-choices pygments.enabled recaptcha.enabled recaptcha.private-key recaptcha.public-key remarkup.enable-embedded-youtube repository.default-local-path search.elastic.host search.engine-selector security.alternate-file-domain security.hmac-key security.require-https sendgrid.api-key sendgrid.api-user storage.default-namespace storage.engine-selector storage.local-disk.path storage.mysql-engine.max-size storage.s3.bucket storage.upload-size-limit style.monospace syntax-highlighter.engine syntax.filemap test.value tokenizer.ondemand translation.override translation.provider uri.allowed-protocols $ Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2254 Differential Revision: https://secure.phabricator.com/D4570
2013-01-22 00:27:42 +01:00
'PhabricatorConfigManagementDeleteWorkflow' => 'applications/config/management/PhabricatorConfigManagementDeleteWorkflow.php',
'PhabricatorConfigManagementGetWorkflow' => 'applications/config/management/PhabricatorConfigManagementGetWorkflow.php',
'PhabricatorConfigManagementListWorkflow' => 'applications/config/management/PhabricatorConfigManagementListWorkflow.php',
'PhabricatorConfigManagementSetWorkflow' => 'applications/config/management/PhabricatorConfigManagementSetWorkflow.php',
'PhabricatorConfigManagementWorkflow' => 'applications/config/management/PhabricatorConfigManagementWorkflow.php',
Begin moving Phabricator configuration into PHP Summary: Ref T2255. Ref T2221. Lay the groundwork to move configuration into PHP, so we can show descriptions in the web UI, do typechecking, disable application options when an application is uninstalled, etc. Test Plan: {F28421} {F28420} {F28422} Reviewers: codeblock, btrahan, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221, T2255 Differential Revision: https://secure.phabricator.com/D4306
2012-12-31 00:36:06 +01:00
'PhabricatorConfigOption' => 'applications/config/option/PhabricatorConfigOption.php',
Allow configuration to have custom UI types Summary: Ref T1703. This sets the stage for (but does not yet implement) custom UI types for config. In particular, a draggable list for custom fields. I might make all the builtin types go through this at some point too, but don't really want to bother for the moment. It would be very slightly cleaner but woudn't get us much of anything. Test Plan: UI now renders via custom code, although that code does nothing (produces an unadorned text field): {F45693} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6154
2013-06-07 21:36:18 +02:00
'PhabricatorConfigOptionType' => 'applications/config/custom/PhabricatorConfigOptionType.php',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorConfigProxySource' => 'infrastructure/env/PhabricatorConfigProxySource.php',
Port extension checks to new-style setup Summary: - Allow new-style setup to raise fatal setup errors. - Port extension checks to new-style setup as fatal errors. - When fatal errors are raised, abort setup and show them in a chrome-free response. Test Plan: {F29981} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4587
2013-01-23 00:16:26 +01:00
'PhabricatorConfigResponse' => 'applications/config/response/PhabricatorConfigResponse.php',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorConfigSource' => 'infrastructure/env/PhabricatorConfigSource.php',
'PhabricatorConfigStackSource' => 'infrastructure/env/PhabricatorConfigStackSource.php',
Use transactions to show edit history for Configuration Summary: Use ApplicationTransactions in Config to create an edit history. Resolves T2256. Test Plan: {F28477} Reviewers: btrahan, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2256 Differential Revision: https://secure.phabricator.com/D4314
2013-01-02 03:14:41 +01:00
'PhabricatorConfigTransaction' => 'applications/config/storage/PhabricatorConfigTransaction.php',
'PhabricatorConfigTransactionQuery' => 'applications/config/query/PhabricatorConfigTransactionQuery.php',
Allow configuration to be explicitly validated, including validation of complex attributes Summary: - Allows us to implement setup warnings for edits which don't go through the web UI, e.g. "you edited a config file and set value X to something goofy". - Allows us to implement more sophisticated validations, beyond basic type checks (e.g., "phabricator.base-uri" must be a URI). - Fixes T358 (or, close enough -- fixes it for all options which have been migrated as per T2255. Test Plan: Set "darkconsole.enabled" to "xyz" in my config, observed setup warning. Added fake validation, observed web UI edit error. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255, T358 Differential Revision: https://secure.phabricator.com/D4315
2013-01-02 03:15:03 +01:00
'PhabricatorConfigValidationException' => 'applications/config/exception/PhabricatorConfigValidationException.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorContentSource' => 'applications/metamta/contentsource/PhabricatorContentSource.php',
'PhabricatorContentSourceView' => 'applications/metamta/contentsource/PhabricatorContentSourceView.php',
'PhabricatorController' => 'applications/base/controller/PhabricatorController.php',
Add "Core" config, with complex validation Summary: This is more or less a copy of the validation which lives in `webroot/index.php` right now, but I don't want to wipe that out just yet because there's no way for normal users to see this new validation. Test Plan: Tried to set "phabricator.base-uri" to crazy nonsense, was harshly rebuffed. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4316
2013-01-02 03:22:48 +01:00
'PhabricatorCoreConfigOptions' => 'applications/config/option/PhabricatorCoreConfigOptions.php',
Countdown revamp Summary: countdown_timer table named to countdown. datepoint and related stuff renamed to epoch. Countdowns now have phids. Various UI items changed from timer to countdown. Test Plan: Did run storage upgrade and added some countdowns. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2624 Differential Revision: https://secure.phabricator.com/D5812
2013-05-04 00:49:29 +02:00
'PhabricatorCountdown' => 'applications/countdown/storage/PhabricatorCountdown.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorCountdownController' => 'applications/countdown/controller/PhabricatorCountdownController.php',
'PhabricatorCountdownDAO' => 'applications/countdown/storage/PhabricatorCountdownDAO.php',
'PhabricatorCountdownDeleteController' => 'applications/countdown/controller/PhabricatorCountdownDeleteController.php',
'PhabricatorCountdownEditController' => 'applications/countdown/controller/PhabricatorCountdownEditController.php',
'PhabricatorCountdownListController' => 'applications/countdown/controller/PhabricatorCountdownListController.php',
Pre-prepare for hovercards Summary: D5120 and followups refactor and generalize object references in Remarkup -- notably, they move remarkup rules from a central location to the implementing applications. Preserve blame by doing moves/renames only first. This change moves application remarkup rules into those applications, and renames the ones D5120 modifies. Test Plan: Typed some preview text into a textarea, got a valid Remarkup render. Reviewers: vrana, chad Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5123
2013-02-26 23:57:41 +01:00
'PhabricatorCountdownRemarkupRule' => 'applications/countdown/remarkup/PhabricatorCountdownRemarkupRule.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorCountdownViewController' => 'applications/countdown/controller/PhabricatorCountdownViewController.php',
AphrontFormCountedToggleButtonsControl Summary: Like AphrontFormToggleButtonsControl, but with mouseover counters. These counters let you know how many of each thing there are in each category, which is useful when using this control for filtering a list of things in multiple dimensions. Test Plan: `/uiexample/view/PhabricatorCountedToggleButtonsExample/` Reviewers: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5118
2013-02-26 17:20:14 +01:00
'PhabricatorCountedToggleButtonsExample' => 'applications/uiexample/examples/PhabricatorCountedToggleButtonsExample.php',
Add a breadcrumbs element Summary: Add a basic breadcrumbs element, and implement it in Paste. This needs some polish but is most of the way there. Test Plan: {F26443} {F26444} {F26445} (This element is not visible on devices.) Reviewers: chad Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T1960 Differential Revision: https://secure.phabricator.com/D4087
2012-12-07 22:35:17 +01:00
'PhabricatorCrumbView' => 'view/layout/PhabricatorCrumbView.php',
'PhabricatorCrumbsView' => 'view/layout/PhabricatorCrumbsView.php',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorCursorPagedPolicyAwareQuery' => 'infrastructure/query/policy/PhabricatorCursorPagedPolicyAwareQuery.php',
Begin generalizing custom fields Summary: Ref T1703. We have currently have two custom field implementations (Maniphest, Differential) and are about to add a third (User, see D6122). I'd like to generalize custom fields before doing a third implementation, so we don't back ourselves into the ApplicationTransactions corner we have with Maniphest/Differential/Audit. For the most part, the existing custom fields work well and can be directly generalized. There are three specific things I want to improve, though: - Integration with ApplicationSearch: Custom fields aren't indexable. ApplicationSearch is now online and seems stable and good. D5278 provides a template for a backend which can integrate with ApplicationSearch, and ApplicationSearch solves many of the other UI problems implied by exposing custom fields into search (principally, giant pages full of query fields). Generally, I want to provide stronger builtin integration between custom fields and ApplicationSearch. - Integration with ApplicationTransactions: Likewise, custom fields should support more native integrations with ApplicationTransactions, which are also online and seem stable and well designed. - Selection and sorting: Selecting and sorting custom fields is a huge mess right now. I want to move this into config now that we have the UI to support it, and move away from requiring users to subclass a ton of stuff just to add a field. For ApplicationSearch, I've adopted and generalized D5278. For ApplicationTransactions, I haven't made any specific affordances yet. For selection and sorting, I've partially implemented config-based selection and sorting. It will work like this: - We add a new configuration value, like `differential.fields`. In the UI, this is a draggable list of supported fields. Fields can be reordered, and most fields can be disabled. - We load every avialable field to populate this list. New fields will appear at the bottom. - There are two downsides to this approach: - If we add fields in the upstream at a later date, they will appear at the end of the list if an install has customized list order or disabled fields, even if we insert them elsewhere in the upstream. - If we reorder fields in the upstream, the reordering will not be reflected in install which have customized the order/availability. - I think these are both acceptable costs. We only incur them if an admin edits this config, which implies they'll know how to fix it if they want to. - We can fix both of these problems with a straightforward configuration migration if we want to bother. - There are numerous upsides to this approach: - We can delete a bunch of code and replace it with simple configuration. - In general, we don't need the "selector" classes anymore. - Users can enable available-but-disabled fields with one click. - Users can add fields by putting their implementations in `src/extensions/` with zero subclassing or libphutil stuff. - Generally, it's super easy for users to understand. This doesn't actually do anything yet and will probably see some adjustments before anything starts running it. Test Plan: Static checks only, this code isn't reachable yet. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6147
2013-06-06 23:52:40 +02:00
'PhabricatorCustomField' => 'infrastructure/customfield/field/PhabricatorCustomField.php',
Allow configuration to have custom UI types Summary: Ref T1703. This sets the stage for (but does not yet implement) custom UI types for config. In particular, a draggable list for custom fields. I might make all the builtin types go through this at some point too, but don't really want to bother for the moment. It would be very slightly cleaner but woudn't get us much of anything. Test Plan: UI now renders via custom code, although that code does nothing (produces an unadorned text field): {F45693} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6154
2013-06-07 21:36:18 +02:00
'PhabricatorCustomFieldConfigOptionType' => 'infrastructure/customfield/config/PhabricatorCustomFieldConfigOptionType.php',
Begin generalizing custom fields Summary: Ref T1703. We have currently have two custom field implementations (Maniphest, Differential) and are about to add a third (User, see D6122). I'd like to generalize custom fields before doing a third implementation, so we don't back ourselves into the ApplicationTransactions corner we have with Maniphest/Differential/Audit. For the most part, the existing custom fields work well and can be directly generalized. There are three specific things I want to improve, though: - Integration with ApplicationSearch: Custom fields aren't indexable. ApplicationSearch is now online and seems stable and good. D5278 provides a template for a backend which can integrate with ApplicationSearch, and ApplicationSearch solves many of the other UI problems implied by exposing custom fields into search (principally, giant pages full of query fields). Generally, I want to provide stronger builtin integration between custom fields and ApplicationSearch. - Integration with ApplicationTransactions: Likewise, custom fields should support more native integrations with ApplicationTransactions, which are also online and seem stable and well designed. - Selection and sorting: Selecting and sorting custom fields is a huge mess right now. I want to move this into config now that we have the UI to support it, and move away from requiring users to subclass a ton of stuff just to add a field. For ApplicationSearch, I've adopted and generalized D5278. For ApplicationTransactions, I haven't made any specific affordances yet. For selection and sorting, I've partially implemented config-based selection and sorting. It will work like this: - We add a new configuration value, like `differential.fields`. In the UI, this is a draggable list of supported fields. Fields can be reordered, and most fields can be disabled. - We load every avialable field to populate this list. New fields will appear at the bottom. - There are two downsides to this approach: - If we add fields in the upstream at a later date, they will appear at the end of the list if an install has customized list order or disabled fields, even if we insert them elsewhere in the upstream. - If we reorder fields in the upstream, the reordering will not be reflected in install which have customized the order/availability. - I think these are both acceptable costs. We only incur them if an admin edits this config, which implies they'll know how to fix it if they want to. - We can fix both of these problems with a straightforward configuration migration if we want to bother. - There are numerous upsides to this approach: - We can delete a bunch of code and replace it with simple configuration. - In general, we don't need the "selector" classes anymore. - Users can enable available-but-disabled fields with one click. - Users can add fields by putting their implementations in `src/extensions/` with zero subclassing or libphutil stuff. - Generally, it's super easy for users to understand. This doesn't actually do anything yet and will probably see some adjustments before anything starts running it. Test Plan: Static checks only, this code isn't reachable yet. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6147
2013-06-06 23:52:40 +02:00
'PhabricatorCustomFieldDataNotAvailableException' => 'infrastructure/customfield/exception/PhabricatorCustomFieldDataNotAvailableException.php',
'PhabricatorCustomFieldImplementationIncompleteException' => 'infrastructure/customfield/exception/PhabricatorCustomFieldImplementationIncompleteException.php',
'PhabricatorCustomFieldIndexStorage' => 'infrastructure/customfield/storage/PhabricatorCustomFieldIndexStorage.php',
Flesh out ApplicationTransactions/CustomField integration Summary: None of this code is reachable yet. See discussion in D6147. Ref T1703. Provide tighter integration between ApplicationTransactions and CustomField. Basically, I'm just trying to get all the shared stuff into the base implementation. Test Plan: Code not reachable. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6149
2013-06-06 23:53:07 +02:00
'PhabricatorCustomFieldInterface' => 'infrastructure/customfield/interface/PhabricatorCustomFieldInterface.php',
'PhabricatorCustomFieldNotAttachedException' => 'infrastructure/customfield/exception/PhabricatorCustomFieldNotAttachedException.php',
Begin generalizing custom fields Summary: Ref T1703. We have currently have two custom field implementations (Maniphest, Differential) and are about to add a third (User, see D6122). I'd like to generalize custom fields before doing a third implementation, so we don't back ourselves into the ApplicationTransactions corner we have with Maniphest/Differential/Audit. For the most part, the existing custom fields work well and can be directly generalized. There are three specific things I want to improve, though: - Integration with ApplicationSearch: Custom fields aren't indexable. ApplicationSearch is now online and seems stable and good. D5278 provides a template for a backend which can integrate with ApplicationSearch, and ApplicationSearch solves many of the other UI problems implied by exposing custom fields into search (principally, giant pages full of query fields). Generally, I want to provide stronger builtin integration between custom fields and ApplicationSearch. - Integration with ApplicationTransactions: Likewise, custom fields should support more native integrations with ApplicationTransactions, which are also online and seem stable and well designed. - Selection and sorting: Selecting and sorting custom fields is a huge mess right now. I want to move this into config now that we have the UI to support it, and move away from requiring users to subclass a ton of stuff just to add a field. For ApplicationSearch, I've adopted and generalized D5278. For ApplicationTransactions, I haven't made any specific affordances yet. For selection and sorting, I've partially implemented config-based selection and sorting. It will work like this: - We add a new configuration value, like `differential.fields`. In the UI, this is a draggable list of supported fields. Fields can be reordered, and most fields can be disabled. - We load every avialable field to populate this list. New fields will appear at the bottom. - There are two downsides to this approach: - If we add fields in the upstream at a later date, they will appear at the end of the list if an install has customized list order or disabled fields, even if we insert them elsewhere in the upstream. - If we reorder fields in the upstream, the reordering will not be reflected in install which have customized the order/availability. - I think these are both acceptable costs. We only incur them if an admin edits this config, which implies they'll know how to fix it if they want to. - We can fix both of these problems with a straightforward configuration migration if we want to bother. - There are numerous upsides to this approach: - We can delete a bunch of code and replace it with simple configuration. - In general, we don't need the "selector" classes anymore. - Users can enable available-but-disabled fields with one click. - Users can add fields by putting their implementations in `src/extensions/` with zero subclassing or libphutil stuff. - Generally, it's super easy for users to understand. This doesn't actually do anything yet and will probably see some adjustments before anything starts running it. Test Plan: Static checks only, this code isn't reachable yet. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6147
2013-06-06 23:52:40 +02:00
'PhabricatorCustomFieldNumericIndexStorage' => 'infrastructure/customfield/storage/PhabricatorCustomFieldNumericIndexStorage.php',
'PhabricatorCustomFieldStorage' => 'infrastructure/customfield/storage/PhabricatorCustomFieldStorage.php',
'PhabricatorCustomFieldStringIndexStorage' => 'infrastructure/customfield/storage/PhabricatorCustomFieldStringIndexStorage.php',
'PhabricatorCustomFieldValidationException' => 'infrastructure/customfield/exception/PhabricatorCustomFieldValidationException.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorDaemon' => 'infrastructure/daemon/PhabricatorDaemon.php',
'PhabricatorDaemonCombinedLogController' => 'applications/daemon/controller/PhabricatorDaemonCombinedLogController.php',
'PhabricatorDaemonConsoleController' => 'applications/daemon/controller/PhabricatorDaemonConsoleController.php',
'PhabricatorDaemonControl' => 'infrastructure/daemon/PhabricatorDaemonControl.php',
'PhabricatorDaemonController' => 'applications/daemon/controller/PhabricatorDaemonController.php',
'PhabricatorDaemonDAO' => 'infrastructure/daemon/storage/PhabricatorDaemonDAO.php',
'PhabricatorDaemonLog' => 'infrastructure/daemon/storage/PhabricatorDaemonLog.php',
'PhabricatorDaemonLogEvent' => 'infrastructure/daemon/storage/PhabricatorDaemonLogEvent.php',
'PhabricatorDaemonLogEventsView' => 'applications/daemon/view/PhabricatorDaemonLogEventsView.php',
'PhabricatorDaemonLogListController' => 'applications/daemon/controller/PhabricatorDaemonLogListController.php',
'PhabricatorDaemonLogListView' => 'applications/daemon/view/PhabricatorDaemonLogListView.php',
'PhabricatorDaemonLogViewController' => 'applications/daemon/controller/PhabricatorDaemonLogViewController.php',
'PhabricatorDaemonReference' => 'infrastructure/daemon/control/PhabricatorDaemonReference.php',
Add a user-accessible hook for dumping debug code into an install Summary: Currently, there's no easy way for me to tell a user "run this code from the webserver and tell me what it says". Sometimes installs can add new .php files to, e.g., `webroot/rsrc/`, but this is setup-dependent and not universal. Generally I resort to saying "put this into index.php", but that's error prone and not acceptable on active installs. Add a "debug" controller so I can instead say "put this into support/debug.php, then visit /debug/". Test Plan: Visited /debug/ with and without support/debug.php files. Visited /staus/. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5212
2013-03-04 22:45:51 +01:00
'PhabricatorDebugController' => 'applications/system/PhabricatorDebugController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorDefaultFileStorageEngineSelector' => 'applications/files/engineselector/PhabricatorDefaultFileStorageEngineSelector.php',
'PhabricatorDefaultSearchEngineSelector' => 'applications/search/selector/PhabricatorDefaultSearchEngineSelector.php',
Add "Developer" and "Access Log" config option groups, some types Summary: - Add a "developer" option group. - Add an "access log" option group. - Render the types "bool", "int" and "string" in a more tailored way. - Add a config check for dead config. Right now this serves as a "TODO" list of things that need to be migrated. Test Plan: Looked at config options, setup issues. Edited bool, int, string options. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4308
2013-01-01 23:09:17 +01:00
'PhabricatorDeveloperConfigOptions' => 'applications/config/option/PhabricatorDeveloperConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorDifferenceEngine' => 'infrastructure/diff/PhabricatorDifferenceEngine.php',
Begin moving Phabricator configuration into PHP Summary: Ref T2255. Ref T2221. Lay the groundwork to move configuration into PHP, so we can show descriptions in the web UI, do typechecking, disable application options when an application is uninstalled, etc. Test Plan: {F28421} {F28420} {F28422} Reviewers: codeblock, btrahan, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221, T2255 Differential Revision: https://secure.phabricator.com/D4306
2012-12-31 00:36:06 +01:00
'PhabricatorDifferentialConfigOptions' => 'applications/differential/config/PhabricatorDifferentialConfigOptions.php',
xDiffs and Revisions Generating Summary: Ref T2903 Test Plan: Revisions and Diffs are visually being generated Reviewers: epriestley, xask.linus Reviewed By: epriestley CC: AnhNhan, aran, Korvin Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5835
2013-05-06 23:11:26 +02:00
'PhabricatorDifferentialRevisionTestDataGenerator' => 'applications/differential/lipsum/PhabricatorDifferentialRevisionTestDataGenerator.php',
Diffusion / MetaMTA options Summary: Implement Diffusion MetaMTA options. Also make the fake '{{config.option}}' rule work, and use Remarkup to render summaries as well as descriptions. Test Plan: Looked at Diffusion rules, edited some, looked at setup issues, verified '{{config.option}}' linked to the right option. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4466
2013-01-16 18:08:13 +01:00
'PhabricatorDiffusionConfigOptions' => 'applications/diffusion/config/PhabricatorDiffusionConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorDirectoryController' => 'applications/directory/controller/PhabricatorDirectoryController.php',
'PhabricatorDirectoryMainController' => 'applications/directory/controller/PhabricatorDirectoryMainController.php',
'PhabricatorDisabledUserController' => 'applications/auth/controller/PhabricatorDisabledUserController.php',
Add Disqus, Facebook, Google, GitHub auth config; AWS config Summary: Also improve behavior for the "unknown config" warning. Test Plan: Looked at configs, went through unknown config workflow. Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4310
2013-01-01 23:09:29 +01:00
'PhabricatorDisqusConfigOptions' => 'applications/config/option/PhabricatorDisqusConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorDraft' => 'applications/draft/storage/PhabricatorDraft.php',
'PhabricatorDraftDAO' => 'applications/draft/storage/PhabricatorDraftDAO.php',
'PhabricatorEdgeConfig' => 'infrastructure/edges/constants/PhabricatorEdgeConfig.php',
'PhabricatorEdgeConstants' => 'infrastructure/edges/constants/PhabricatorEdgeConstants.php',
Allow edges to be configured to prevent cycles Summary: Certain types of things we should be storing in edges (notably, Task X depends on Task Y) should always be acyclic. Allow `PhabricatorEdgeEditor` to enforce this, since we can't correctly enforce it outside of the editor without being vulnerable to races. Each edge type can be marked acyclic. If an edge type is acyclic, we perform additional steps when writing new edges of that type: - We acquire a global lock on the edge type before performing any reads or writes. This ensures we can't produce a cycle as a result of a race where two edits add edges which independently do not produce a cycle, but do produce a cycle when combined. - After performing writes but before committing transactions, we load the edge graph for each acyclic type and verify that it is, in fact, acyclic. If we detect cycles, we abort the edit. - When we're done, we release the edge type locks. This is a relatively high-complexity change, but gives us a simple way to flag an edge type as acyclic in a robust way. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D2940
2012-07-09 19:39:38 +02:00
'PhabricatorEdgeCycleException' => 'infrastructure/edges/exception/PhabricatorEdgeCycleException.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorEdgeEditor' => 'infrastructure/edges/editor/PhabricatorEdgeEditor.php',
Allow edges to be configured to prevent cycles Summary: Certain types of things we should be storing in edges (notably, Task X depends on Task Y) should always be acyclic. Allow `PhabricatorEdgeEditor` to enforce this, since we can't correctly enforce it outside of the editor without being vulnerable to races. Each edge type can be marked acyclic. If an edge type is acyclic, we perform additional steps when writing new edges of that type: - We acquire a global lock on the edge type before performing any reads or writes. This ensures we can't produce a cycle as a result of a race where two edits add edges which independently do not produce a cycle, but do produce a cycle when combined. - After performing writes but before committing transactions, we load the edge graph for each acyclic type and verify that it is, in fact, acyclic. If we detect cycles, we abort the edit. - When we're done, we release the edge type locks. This is a relatively high-complexity change, but gives us a simple way to flag an edge type as acyclic in a robust way. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D2940
2012-07-09 19:39:38 +02:00
'PhabricatorEdgeGraph' => 'infrastructure/edges/util/PhabricatorEdgeGraph.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorEdgeQuery' => 'infrastructure/edges/query/PhabricatorEdgeQuery.php',
Allow edges to be configured to prevent cycles Summary: Certain types of things we should be storing in edges (notably, Task X depends on Task Y) should always be acyclic. Allow `PhabricatorEdgeEditor` to enforce this, since we can't correctly enforce it outside of the editor without being vulnerable to races. Each edge type can be marked acyclic. If an edge type is acyclic, we perform additional steps when writing new edges of that type: - We acquire a global lock on the edge type before performing any reads or writes. This ensures we can't produce a cycle as a result of a race where two edits add edges which independently do not produce a cycle, but do produce a cycle when combined. - After performing writes but before committing transactions, we load the edge graph for each acyclic type and verify that it is, in fact, acyclic. If we detect cycles, we abort the edit. - When we're done, we release the edge type locks. This is a relatively high-complexity change, but gives us a simple way to flag an edge type as acyclic in a robust way. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D2940
2012-07-09 19:39:38 +02:00
'PhabricatorEdgeTestCase' => 'infrastructure/edges/__tests__/PhabricatorEdgeTestCase.php',
If users are on the email to Phabricator, do not send them the Phabricator reply. Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email. Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected. Reviewers: epriestley, vrana Reviewed By: vrana CC: aran, Korvin, vrana Maniphest Tasks: T1676 Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 19:18:23 +02:00
'PhabricatorEditor' => 'infrastructure/PhabricatorEditor.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorEmailLoginController' => 'applications/auth/controller/PhabricatorEmailLoginController.php',
'PhabricatorEmailTokenController' => 'applications/auth/controller/PhabricatorEmailTokenController.php',
'PhabricatorEmailVerificationController' => 'applications/people/controller/PhabricatorEmailVerificationController.php',
Introduce PhabricatorEmptyQueryException Summary: It's dumb to execute a query which we know will return an empty result. Test Plan: Looked at comment preview with "11", didn't see "1 = 0" in DarkConsole. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5177
2013-03-01 20:28:02 +01:00
'PhabricatorEmptyQueryException' => 'infrastructure/query/PhabricatorEmptyQueryException.php',
Use pht() Summary: This is the first step in Phabricator internationalization. It adds a translation selector and calls it at startup. Installations can add custom selectors to override some texts. We can add official translations in future. Next step is to allow user to choose his translation which will override the global one. This is currently used only for English plurals. Test Plan: Displayed a diff with unit test error, verified that it says 'Detail' or 'Details' and not 'Detail(s)'. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D2753
2012-06-14 22:43:09 +02:00
'PhabricatorEnglishTranslation' => 'infrastructure/internationalization/PhabricatorEnglishTranslation.php',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorEnv' => 'infrastructure/env/PhabricatorEnv.php',
'PhabricatorEnvTestCase' => 'infrastructure/env/__tests__/PhabricatorEnvTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorErrorExample' => 'applications/uiexample/examples/PhabricatorErrorExample.php',
'PhabricatorEvent' => 'infrastructure/events/PhabricatorEvent.php',
'PhabricatorEventEngine' => 'infrastructure/events/PhabricatorEventEngine.php',
'PhabricatorEventType' => 'infrastructure/events/constant/PhabricatorEventType.php',
Add an example event listener, improve documentation, and add a commit discovery event Summary: Improve documentation around Phabricator events. Test Plan: Generated and read documentation. Ran test script. Reviewers: btrahan, jungejason Reviewed By: jungejason CC: aran Maniphest Tasks: T1092 Differential Revision: https://secure.phabricator.com/D2917
2012-07-04 01:46:27 +02:00
'PhabricatorExampleEventListener' => 'infrastructure/events/PhabricatorExampleEventListener.php',
Add the "Extending Phabricator" config group. Summary: Refs T2255 and takes care of the "EXTENDING PHABRICATOR" group thereof. Test Plan: Looked at each of the new options. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4325
2013-01-03 00:52:30 +01:00
'PhabricatorExtendingPhabricatorConfigOptions' => 'applications/config/option/PhabricatorExtendingPhabricatorConfigOptions.php',
Created PhabricatorExternalAccount Class and Sql patch to create an external_account table. Summary: Created PhabricatorExternalAccount class with only data members. Will discuss with you regarding the necessary functions to be implemented in this class. Sql Patch to create a new table for external_accounts. Will I have to write unit tests the new storage object? Sending you this diff so that you can comment on this to further improve :). Test Plan: {F40977} Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T1536, T1205 Differential Revision: https://secure.phabricator.com/D5724
2013-04-19 20:40:13 +02:00
'PhabricatorExternalAccount' => 'applications/people/storage/PhabricatorExternalAccount.php',
Add Disqus, Facebook, Google, GitHub auth config; AWS config Summary: Also improve behavior for the "unknown config" warning. Test Plan: Looked at configs, went through unknown config workflow. Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4310
2013-01-01 23:09:29 +01:00
'PhabricatorFacebookConfigOptions' => 'applications/config/option/PhabricatorFacebookConfigOptions.php',
Add aggregated facts to the Facts application Summary: Some facts are aggregations of other facts. For example, we may compute how many times each macro is used in each object as a "raw fact": Dnnn uses macro "psyduck" 6 times. But we want to present this data in aggregate form, e.g. "order macros by popularity". We can do this at runtime and it probably won't be too awful a query, but we can also aggregate it cheaply: Macro "psyduck" is used 3920 times across all objects. ...and then do a query like "select macros ordered by usage". "Aggregate" facts support facts like this. The aggregate facts I've implemented are: - Count of all objects. - Count of objects of type X. - Last time facts were updated. These clearly fit the "aggregate" facts template well. I'm not 100% sure macros do. We can use this table to answer a question like "What are the most popular macros, ordered by use?" We can also use it to answer a question like "What are the most popular macros in the last 6 months?", if we build a specific fact for that. But we can't use it to answer a question like "What are the most popular macros between times X and Y?". Maybe that's important; maybe not. This seems like a good fit for at least some types of facts. I'll de-magic the keys a bit in the next diff. Test Plan: Ran the engines and got some aggregated facts about other facts. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3089
2012-07-27 22:46:01 +02:00
'PhabricatorFactAggregate' => 'applications/fact/storage/PhabricatorFactAggregate.php',
Allow Fact app to draw charts Summary: For any count fact, allow a chart to be drawn. INCREDIBLY POWERFUL DATA ANALYSIS PLATFORM. Test Plan: Drew a chart of object counts. Drew the Maniphest burn chart. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3099
2012-07-30 19:44:08 +02:00
'PhabricatorFactChartController' => 'applications/fact/controller/PhabricatorFactChartController.php',
Add aggregated facts to the Facts application Summary: Some facts are aggregations of other facts. For example, we may compute how many times each macro is used in each object as a "raw fact": Dnnn uses macro "psyduck" 6 times. But we want to present this data in aggregate form, e.g. "order macros by popularity". We can do this at runtime and it probably won't be too awful a query, but we can also aggregate it cheaply: Macro "psyduck" is used 3920 times across all objects. ...and then do a query like "select macros ordered by usage". "Aggregate" facts support facts like this. The aggregate facts I've implemented are: - Count of all objects. - Count of objects of type X. - Last time facts were updated. These clearly fit the "aggregate" facts template well. I'm not 100% sure macros do. We can use this table to answer a question like "What are the most popular macros, ordered by use?" We can also use it to answer a question like "What are the most popular macros in the last 6 months?", if we build a specific fact for that. But we can't use it to answer a question like "What are the most popular macros between times X and Y?". Maybe that's important; maybe not. This seems like a good fit for at least some types of facts. I'll de-magic the keys a bit in the next diff. Test Plan: Ran the engines and got some aggregated facts about other facts. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3089
2012-07-27 22:46:01 +02:00
'PhabricatorFactController' => 'applications/fact/controller/PhabricatorFactController.php',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactCountEngine' => 'applications/fact/engine/PhabricatorFactCountEngine.php',
Add FactCursors and application fact datasources Summary: - Add PhabricatorApplication. This is a general class that I have grand designs for, but used here to allow applications to provide objects for analysis by the facts appliction. - Add FactCursors, to keep track of where iterators are. - Make the daemon do something sort of useful. - Add `bin/fact cursors` for showing and managing objects and cursors. - Add some options to `bin/fact analyze`. Test Plan: - `bin/fact cursors`, `bin/fact cursors --reset DifferentialRevision`, `bin/fact cursors --reset X` - `bin/fact analyze`, `bin/fact analyze --all`, `bin/fact analyze --iterator DifferentialRevision --skip-aggregates` - `bin/phd debug fact` Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3098
2012-07-30 19:43:49 +02:00
'PhabricatorFactCursor' => 'applications/fact/storage/PhabricatorFactCursor.php',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactDAO' => 'applications/fact/storage/PhabricatorFactDAO.php',
'PhabricatorFactDaemon' => 'applications/fact/daemon/PhabricatorFactDaemon.php',
'PhabricatorFactEngine' => 'applications/fact/engine/PhabricatorFactEngine.php',
Add aggregated facts to the Facts application Summary: Some facts are aggregations of other facts. For example, we may compute how many times each macro is used in each object as a "raw fact": Dnnn uses macro "psyduck" 6 times. But we want to present this data in aggregate form, e.g. "order macros by popularity". We can do this at runtime and it probably won't be too awful a query, but we can also aggregate it cheaply: Macro "psyduck" is used 3920 times across all objects. ...and then do a query like "select macros ordered by usage". "Aggregate" facts support facts like this. The aggregate facts I've implemented are: - Count of all objects. - Count of objects of type X. - Last time facts were updated. These clearly fit the "aggregate" facts template well. I'm not 100% sure macros do. We can use this table to answer a question like "What are the most popular macros, ordered by use?" We can also use it to answer a question like "What are the most popular macros in the last 6 months?", if we build a specific fact for that. But we can't use it to answer a question like "What are the most popular macros between times X and Y?". Maybe that's important; maybe not. This seems like a good fit for at least some types of facts. I'll de-magic the keys a bit in the next diff. Test Plan: Ran the engines and got some aggregated facts about other facts. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3089
2012-07-27 22:46:01 +02:00
'PhabricatorFactHomeController' => 'applications/fact/controller/PhabricatorFactHomeController.php',
'PhabricatorFactLastUpdatedEngine' => 'applications/fact/engine/PhabricatorFactLastUpdatedEngine.php',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactManagementAnalyzeWorkflow' => 'applications/fact/management/PhabricatorFactManagementAnalyzeWorkflow.php',
Add FactCursors and application fact datasources Summary: - Add PhabricatorApplication. This is a general class that I have grand designs for, but used here to allow applications to provide objects for analysis by the facts appliction. - Add FactCursors, to keep track of where iterators are. - Make the daemon do something sort of useful. - Add `bin/fact cursors` for showing and managing objects and cursors. - Add some options to `bin/fact analyze`. Test Plan: - `bin/fact cursors`, `bin/fact cursors --reset DifferentialRevision`, `bin/fact cursors --reset X` - `bin/fact analyze`, `bin/fact analyze --all`, `bin/fact analyze --iterator DifferentialRevision --skip-aggregates` - `bin/phd debug fact` Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3098
2012-07-30 19:43:49 +02:00
'PhabricatorFactManagementCursorsWorkflow' => 'applications/fact/management/PhabricatorFactManagementCursorsWorkflow.php',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactManagementDestroyWorkflow' => 'applications/fact/management/PhabricatorFactManagementDestroyWorkflow.php',
'PhabricatorFactManagementListWorkflow' => 'applications/fact/management/PhabricatorFactManagementListWorkflow.php',
'PhabricatorFactManagementStatusWorkflow' => 'applications/fact/management/PhabricatorFactManagementStatusWorkflow.php',
'PhabricatorFactManagementWorkflow' => 'applications/fact/management/PhabricatorFactManagementWorkflow.php',
'PhabricatorFactRaw' => 'applications/fact/storage/PhabricatorFactRaw.php',
Add PhabricatorFactSpec, for naming and formatting facts Summary: Not totally sure about this but I think it's okay? Test Plan: Loaded /fact/, got a more readable page. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3090
2012-07-28 02:29:44 +02:00
'PhabricatorFactSimpleSpec' => 'applications/fact/spec/PhabricatorFactSimpleSpec.php',
'PhabricatorFactSpec' => 'applications/fact/spec/PhabricatorFactSpec.php',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactUpdateIterator' => 'applications/fact/extract/PhabricatorFactUpdateIterator.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFeedBuilder' => 'applications/feed/builder/PhabricatorFeedBuilder.php',
Feed options. Test Plan: Looked at them. Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4434
2013-01-15 02:49:32 +01:00
'PhabricatorFeedConfigOptions' => 'applications/feed/config/PhabricatorFeedConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFeedConstants' => 'applications/feed/constants/PhabricatorFeedConstants.php',
'PhabricatorFeedController' => 'applications/feed/controller/PhabricatorFeedController.php',
'PhabricatorFeedDAO' => 'applications/feed/storage/PhabricatorFeedDAO.php',
Make feed its own application Summary: Fixes the two-level nav issue introduced by D4376. (My claim that this page is device ready in the code is something of a lie, but it's fairly close.) (@chad, this could use an icon at some point, or you can point me at which one you want and I can take a stab at slicing it.) Test Plan: Looked at feed; saw it not-broken. Also checked public feed (which should just merge at some point). Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D4381
2013-01-11 01:06:29 +01:00
'PhabricatorFeedMainController' => 'applications/feed/controller/PhabricatorFeedMainController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFeedPublicStreamController' => 'applications/feed/controller/PhabricatorFeedPublicStreamController.php',
'PhabricatorFeedQuery' => 'applications/feed/PhabricatorFeedQuery.php',
'PhabricatorFeedStory' => 'applications/feed/story/PhabricatorFeedStory.php',
Support basic notification aggregation Summary: This is both only partially complete (supports Maniphest only) and somewhat overcomplicated (includes support for applying similar algorithms to Feed), but provides runtime aggregation of notifications. Test Plan: {F13502} Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2884
2012-07-01 20:08:59 +02:00
'PhabricatorFeedStoryAggregate' => 'applications/feed/story/PhabricatorFeedStoryAggregate.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFeedStoryAudit' => 'applications/feed/story/PhabricatorFeedStoryAudit.php',
Publish feed stories about commits Summary: When stuff gets committed, publish feed stories about it. Test Plan: {F13061} Reviewers: jungejason, vrana, voldern Reviewed By: jungejason CC: aran Maniphest Tasks: T1322 Differential Revision: https://secure.phabricator.com/D2805
2012-06-20 15:03:44 +02:00
'PhabricatorFeedStoryCommit' => 'applications/feed/story/PhabricatorFeedStoryCommit.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFeedStoryData' => 'applications/feed/storage/PhabricatorFeedStoryData.php',
'PhabricatorFeedStoryDifferential' => 'applications/feed/story/PhabricatorFeedStoryDifferential.php',
Aggregate Differential notifications Summary: Just a bunch of copy-pasta from D2884. I suppose this calls for a refactoring at some point... Test Plan: Make a bunch of updates, some from different users; check notifications dropdown and list. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3361
2012-08-22 17:19:38 +02:00
'PhabricatorFeedStoryDifferentialAggregate' => 'applications/feed/story/PhabricatorFeedStoryDifferentialAggregate.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFeedStoryManiphest' => 'applications/feed/story/PhabricatorFeedStoryManiphest.php',
Support basic notification aggregation Summary: This is both only partially complete (supports Maniphest only) and somewhat overcomplicated (includes support for applying similar algorithms to Feed), but provides runtime aggregation of notifications. Test Plan: {F13502} Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2884
2012-07-01 20:08:59 +02:00
'PhabricatorFeedStoryManiphestAggregate' => 'applications/feed/story/PhabricatorFeedStoryManiphestAggregate.php',
Adds base notification application Summary: First diff in a series of diffs to add notifications to Phabricator. This is the notification application ONLY. This commit does not include the changes to other applications that makes them add notifications. As such, no notifications will be generated beyond the initial database import. Test Plan: This is part of the notifications architecture which has been running on http://theoryphabricator.com for the past several months. Reviewers: epriestley, btrahan, ddfisher Reviewed By: epriestley CC: allenjohnashton, keebuhm, aran, Korvin, jungejason, nh Maniphest Tasks: T974 Differential Revision: https://secure.phabricator.com/D2571
2012-06-08 15:31:30 +02:00
'PhabricatorFeedStoryNotification' => 'applications/notification/storage/PhabricatorFeedStoryNotification.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFeedStoryPhriction' => 'applications/feed/story/PhabricatorFeedStoryPhriction.php',
'PhabricatorFeedStoryProject' => 'applications/feed/story/PhabricatorFeedStoryProject.php',
'PhabricatorFeedStoryPublisher' => 'applications/feed/PhabricatorFeedStoryPublisher.php',
'PhabricatorFeedStoryReference' => 'applications/feed/storage/PhabricatorFeedStoryReference.php',
'PhabricatorFeedStoryStatus' => 'applications/feed/story/PhabricatorFeedStoryStatus.php',
'PhabricatorFeedStoryTypeConstants' => 'applications/feed/constants/PhabricatorFeedStoryTypeConstants.php',
'PhabricatorFile' => 'applications/files/storage/PhabricatorFile.php',
'PhabricatorFileController' => 'applications/files/controller/PhabricatorFileController.php',
'PhabricatorFileDAO' => 'applications/files/storage/PhabricatorFileDAO.php',
'PhabricatorFileDataController' => 'applications/files/controller/PhabricatorFileDataController.php',
'PhabricatorFileDeleteController' => 'applications/files/controller/PhabricatorFileDeleteController.php',
'PhabricatorFileDropUploadController' => 'applications/files/controller/PhabricatorFileDropUploadController.php',
Move "Macros" to a first-class application Summary: This is mostly to unblock D3547. - Move "Macros" to a first-class application called "Macros". - After D3547, this application will also house "Memes" (macros with text on them). - This will also make them easier to find; the top navigational query I field is "where are image macros?" nowadays, since it's not intuitive they're part of files. - This makes some of the UI mobile-aware but doesn't set the `device` flag yet, since there are still some missing pieces. - I'll separate storage out and continue modernizing the UI as we unblock and integrate D3547. Test Plan: Created, edited and deleted macros. Viewed files. Reviewers: btrahan, vrana, teisenbe Reviewed By: vrana CC: aran Maniphest Tasks: T175 Differential Revision: https://secure.phabricator.com/D3572
2012-10-01 23:04:03 +02:00
'PhabricatorFileImageMacro' => 'applications/macro/storage/PhabricatorFileImageMacro.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFileInfoController' => 'applications/files/controller/PhabricatorFileInfoController.php',
Introduce lightbox view for images Summary: images attached to maniphest tasks and mentioned in remarkup anywhere now invoke a lightbox control that lets the user page through all the images. lightbox includes a download button, next / prev buttons, and if we're not at the tippy toppy of hte page an "X" or close button. we also respond to left, right, and esc for navigating. next time we should get non-images working in here...! Test Plan: played with maniphest - looks good made comments with images. looks good. made sure multiple image comments worked. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad Maniphest Tasks: T1896 Differential Revision: https://secure.phabricator.com/D3705
2012-10-23 04:06:56 +02:00
'PhabricatorFileLinkListView' => 'view/layout/PhabricatorFileLinkListView.php',
'PhabricatorFileLinkView' => 'view/layout/PhabricatorFileLinkView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFileListController' => 'applications/files/controller/PhabricatorFileListController.php',
Add PhabricatorFileQuery Summary: This doesn't do anything useful yet but Pholio needs to access Files and I wanted to get the groundwork in place for eventual policy-awareness. Test Plan: Will use in Pholio. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3829
2012-10-31 17:57:46 +01:00
'PhabricatorFileQuery' => 'applications/files/query/PhabricatorFileQuery.php',
Implement ApplicationSearch in Files Summary: Ref T2625. Ref T1163. A couple of small generalization nudges, but this is almost entirely straightforward. Test Plan: Executed various File queries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1163, T2625 Differential Revision: https://secure.phabricator.com/D6091
2013-05-31 19:51:05 +02:00
'PhabricatorFileSearchEngine' => 'applications/files/query/PhabricatorFileSearchEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFileShortcutController' => 'applications/files/controller/PhabricatorFileShortcutController.php',
'PhabricatorFileStorageBlob' => 'applications/files/storage/PhabricatorFileStorageBlob.php',
'PhabricatorFileStorageConfigurationException' => 'applications/files/exception/PhabricatorFileStorageConfigurationException.php',
'PhabricatorFileStorageEngine' => 'applications/files/engine/PhabricatorFileStorageEngine.php',
'PhabricatorFileStorageEngineSelector' => 'applications/files/engineselector/PhabricatorFileStorageEngineSelector.php',
Make file storage more testable Summary: Fixes T2474. Adds a storage dummy storage engine for unit tests, and adds a couple of simple tests for basic file storage. Test Plan: Ran `arc unit` to execute unit tests. Reviewers: kwadwon Reviewed By: kwadwon CC: aran Maniphest Tasks: T2474 Differential Revision: https://secure.phabricator.com/D4777
2013-02-06 22:37:42 +01:00
'PhabricatorFileTestCase' => 'applications/files/storage/__tests__/PhabricatorFileTestCase.php',
Files Generating Summary: Ref T2903 Test Plan: Files are being generating, albeit temporary. Reviewers: epriestley, AnhNhan Reviewed By: AnhNhan CC: aran, Korvin, AnhNhan, chad Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5801
2013-05-06 19:30:24 +02:00
'PhabricatorFileTestDataGenerator' => 'applications/files/lipsum/PhabricatorFileTestDataGenerator.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFileTransformController' => 'applications/files/controller/PhabricatorFileTransformController.php',
'PhabricatorFileUploadController' => 'applications/files/controller/PhabricatorFileUploadController.php',
Move Maniphest attached files section into textbox. Summary: Add a button to the Remarkup area that explains how to attach an image and remove the separate upload field. Test Plan: Check that the dialog pops up correctly and that dropping images onto the Remarkup area works. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T879 Differential Revision: https://secure.phabricator.com/D6049
2013-05-26 22:45:24 +02:00
'PhabricatorFileUploadDialogController' => 'applications/files/controller/PhabricatorFileUploadDialogController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFileUploadException' => 'applications/files/exception/PhabricatorFileUploadException.php',
First go at Files settings. Summary: Based on @epriestley's https://secure.phabricator.com/differential/diff/9186/ plus others that seemed like they belong here. Test Plan: Saw the new settings show up in the web interface. Reviewers: epriestley, btrahan, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4425
2013-01-14 02:01:00 +01:00
'PhabricatorFilesConfigOptions' => 'applications/files/config/PhabricatorFilesConfigOptions.php',
Add a script to migrate files between storage engines Summary: Quora requested this (moving to S3) but it's also clearly a good idea. Test Plan: Ran with various valid/invalid options to test options. Error/sanity checking seemed OK. Migrated individual local files. Migrated all my local files back and forth between engines several times. Uploaded some new files. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran Maniphest Tasks: T1950 Differential Revision: https://secure.phabricator.com/D3808
2012-10-25 20:36:38 +02:00
'PhabricatorFilesManagementEnginesWorkflow' => 'applications/files/management/PhabricatorFilesManagementEnginesWorkflow.php',
'PhabricatorFilesManagementMigrateWorkflow' => 'applications/files/management/PhabricatorFilesManagementMigrateWorkflow.php',
Add a `bin/files purge` workflow Summary: We can lose file data through various means; one reasonable way is if files get deleted from disk with 'local-disk' storage. If data goes missing, Ref T3265. Also, reduce some code duplication. Test Plan: Ran `bin/files purge`, `bin/files migrate`, `bin/files rebuild` with various args. Deleted a file with "local-disk" storage, ran `bin/files purge`, made sure it got picked up. Reviewers: dctrwatson, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3265 Differential Revision: https://secure.phabricator.com/D6068
2013-05-29 15:28:57 +02:00
'PhabricatorFilesManagementPurgeWorkflow' => 'applications/files/management/PhabricatorFilesManagementPurgeWorkflow.php',
Rename `bin/files metadata` to `bin/files rebuild` and let it rebuild MIME information Summary: See <https://github.com/facebook/phabricator/issues/320>. Files can end up with a bad MIME type, and we don't update it when uploading another copy of the file since obviously the new copy has the same data and thus the same MIME type. - Rename `bin/files metadata` to `bin/files rebuild` to make it a more consistent verb. - Let it rebuild MIME types so users who hit issues like this can run `bin/files rebuild --all --rebuild-mime` to straighten things out. Test Plan: Ran `bin/files` in various modes, examined output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5951
2013-05-17 19:00:31 +02:00
'PhabricatorFilesManagementRebuildWorkflow' => 'applications/files/management/PhabricatorFilesManagementRebuildWorkflow.php',
Add a script to migrate files between storage engines Summary: Quora requested this (moving to S3) but it's also clearly a good idea. Test Plan: Ran with various valid/invalid options to test options. Error/sanity checking seemed OK. Migrated individual local files. Migrated all my local files back and forth between engines several times. Uploaded some new files. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran Maniphest Tasks: T1950 Differential Revision: https://secure.phabricator.com/D3808
2012-10-25 20:36:38 +02:00
'PhabricatorFilesManagementWorkflow' => 'applications/files/management/PhabricatorFilesManagementWorkflow.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFlag' => 'applications/flag/storage/PhabricatorFlag.php',
'PhabricatorFlagColor' => 'applications/flag/constants/PhabricatorFlagColor.php',
'PhabricatorFlagConstants' => 'applications/flag/constants/PhabricatorFlagConstants.php',
'PhabricatorFlagController' => 'applications/flag/controller/PhabricatorFlagController.php',
'PhabricatorFlagDAO' => 'applications/flag/storage/PhabricatorFlagDAO.php',
'PhabricatorFlagDeleteController' => 'applications/flag/controller/PhabricatorFlagDeleteController.php',
'PhabricatorFlagEditController' => 'applications/flag/controller/PhabricatorFlagEditController.php',
'PhabricatorFlagListController' => 'applications/flag/controller/PhabricatorFlagListController.php',
'PhabricatorFlagListView' => 'applications/flag/view/PhabricatorFlagListView.php',
'PhabricatorFlagQuery' => 'applications/flag/query/PhabricatorFlagQuery.php',
Allow pastes to be flagged Summary: This does a few things: - Allows you to flag pastes. This is straightforward. - Allows Applications to register event listeners. - Makes object action lists emit a 'didrenderactions' event, so other applications can add more actions. The Flags application injects its action in this way. This should generally make it much easier to add actions to objects when we add new applications, with less code duplication and better modularity. We have a really hacky version of this in Differential that I want to get rid of in lieu of this more general approach. I'm going to make object lists do the same thing, so any application can jump in and add stuff. Test Plan: Flagged and unflagged pastes. Viewed home page, differential, flags list. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3377
2012-08-24 22:19:47 +02:00
'PhabricatorFlagsUIEventListener' => 'applications/flag/events/PhabricatorFlagsUIEventListener.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFormExample' => 'applications/uiexample/examples/PhabricatorFormExample.php',
Move GC into PHP and simplify it Summary: - Move GC options into PHP. - Remove the "run at" and "run for" options. The GC daemon doesn't actually do any table scans, is very gentle, and runs for like 3 seconds per day in any normal install. Just limit it to running once every 4 hours when it's caught up and call it a day. Test Plan: Edited GC options. Reviewers: btrahan, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4321
2013-01-02 23:03:08 +01:00
'PhabricatorGarbageCollectorConfigOptions' => 'applications/config/option/PhabricatorGarbageCollectorConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorGarbageCollectorDaemon' => 'infrastructure/daemon/PhabricatorGarbageCollectorDaemon.php',
Add support for device swipe events Summary: Ref T2700. Allow JS to listen for swipes on devices. There are a bunch of tricky cases here and I probably didn't get them all totally right, but this interaction broadly looks like this: - We implement gesture recognition for the mouse in device modes (narrow browser), and for touch events from an actual device. - The sigil `touchable` indicates that a node wants to react to touch events. - When the user touches a `touchable` node, we start listening for moves. They might be tapping/clicking (in which case we don't care), but they might also be gesturing. - Once the user moves their finger/pointer far enough away from the tap origin, we recognize it as a gesture. I hardcoded this at 20px; I wasn't able to find any "official" Apple value, but 20px seems like a common default. - At this point, we look at where their finger has moved. - If they moved it mostly up/down, we interpret the gesture as "scroll" and just stop listening. The device does its own thing. - However, if they moved it mostly left/right, we interpret it as a "swipe". We start killing the moves so the device doesn't scroll. - Once we've recognized that a gesture is underway, we send a "gesture.swipe.start" event and then "gesture.swipe.move" events for every move. - When the user ends the gesture, we send "gesture.swipe.end". - If the user cancels the gesture (currently, only by tapping with a second finger), we send "gesture.swipe.cancel". - Gesture events have raw position data and some convenience fields. Test Plan: Wrote UI example and used it from the Desktop, iPhone simulator, and a real iphone. - The code always seems to get "scroll" vs "swipe" correct (i.e., consistent with my intentions). - The threshold feels pretty good to me. - Tapping with a second finger cancels the action. Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T2700 Differential Revision: https://secure.phabricator.com/D5308
2013-03-09 22:53:15 +01:00
'PhabricatorGestureExample' => 'applications/uiexample/examples/PhabricatorGestureExample.php',
Use subprocess output streaming to improve performance of Git commit discovery Summary: Improve performance of large discovery tasks in Git by using subprocess streaming, like we do for Mercurial. Basically, we save the cost of running many `git log` commands by running one big `git log` command but only parsing as much of it as we need to. This is pretty complicated, but we more or less need it for mercurial (which has ~100ms of 'hg' overhead instead of ~5ms of 'git' overhead) so we're already committed to most of the complexity costs. The git implementation is much simpler than the hg implementation because we don't need to handle all the weird parent rules (git gives us to them easily). Test Plan: Before, `discover --repair` on Phabricator took 35s: real 0m35.324s user 0m13.364s sys 0m21.088s Now 7s: real 0m7.236s user 0m2.436s sys 0m3.444s Note that most of the time is spent inserting rows after discover, the actual speedup of the git discovery part is much larger (subjectively, it runs in less than a second now, from ~28 seconds before). Also ran discover/pull on single new commits in normal cases to verify that nothing broke in the common case. Reviewers: jungejason, nh, vrana Reviewed By: vrana CC: aran Maniphest Tasks: T1401 Differential Revision: https://secure.phabricator.com/D2851
2012-06-26 00:21:48 +02:00
'PhabricatorGitGraphStream' => 'applications/repository/daemon/PhabricatorGitGraphStream.php',
Add Disqus, Facebook, Google, GitHub auth config; AWS config Summary: Also improve behavior for the "unknown config" warning. Test Plan: Looked at configs, went through unknown config workflow. Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4310
2013-01-01 23:09:29 +01:00
'PhabricatorGitHubConfigOptions' => 'applications/config/option/PhabricatorGitHubConfigOptions.php',
Implement a MySQL-backed global lock Summary: Implementation is a little crazy but this seems to work as advertised. Test Plan: Acquired locks with "lock.php". Verified they held as long as the process reamined open and released properly on kill -9, ^C, etc. Reviewers: nh, jungejason, vrana, btrahan, Girish, edward Reviewed By: btrahan CC: aran Maniphest Tasks: T1400 Differential Revision: https://secure.phabricator.com/D2864
2012-06-27 22:59:12 +02:00
'PhabricatorGlobalLock' => 'infrastructure/util/PhabricatorGlobalLock.php',
Modernize file uploads Summary: Modernizes file uploads. In particular: - Adds a mobile menu, with an "Upload File" item. - Adds crumbs to the list view, detail view and upload view. - Adds "Upload File" action to crumbs. - Moves upload file to a separate page. - Removes the combined upload file + recent files page. - Makes upload file use a normal file control by default (works on mobile). - Home page, file list and file upload page are now global drop targets which accept files dropped anywhere on them. Dragging a file into the window shows a mask and an instructional message. - User education on this is a little weak but I think that's a big can of worms? - Fixes a bug where dropping multiple files into a Remarkup text area produced bad results (resolves T2190). T879 is related, although it's specifically about Maniphest. I've declined to make global drop targets yet there because there are multiple drop targets on the page with different meanings. That UI needs updating in general. @chad, do we have an "upload" icon (counterpart to "download")? Test Plan: Uploaded files in Maniphest, Differential, Files, and from Home. Dragged and dropped multiple files into Differential. Used crumbs, mobile. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2190 Differential Revision: https://secure.phabricator.com/D4200
2012-12-17 01:34:01 +01:00
'PhabricatorGlobalUploadTargetView' => 'applications/files/view/PhabricatorGlobalUploadTargetView.php',
Add Disqus, Facebook, Google, GitHub auth config; AWS config Summary: Also improve behavior for the "unknown config" warning. Test Plan: Looked at configs, went through unknown config workflow. Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4310
2013-01-01 23:09:29 +01:00
'PhabricatorGoogleConfigOptions' => 'applications/config/option/PhabricatorGoogleConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorHandleObjectSelectorDataView' => 'applications/phid/handle/view/PhabricatorHandleObjectSelectorDataView.php',
'PhabricatorHash' => 'infrastructure/util/PhabricatorHash.php',
Add PhabricatorHash::digestForIndex() Summary: Does this seem reasonable? It's a bit more compact than digest() (6 bits / byte instead of 4 bits / byte) and 72 bits of entropy @ 12 bytes instead of 128 bits of entropy @ 32 bytes. I feel like it's important to preserve the printability, though, and this seemed like a fairly good balance of concerns. Test Plan: unit tests Reviewers: vrana Reviewed By: vrana CC: aran, yemao932 Differential Revision: https://secure.phabricator.com/D4253
2012-12-21 14:43:33 +01:00
'PhabricatorHashTestCase' => 'infrastructure/util/__tests__/PhabricatorHashTestCase.php',
Modernize Paste Summary: - Add a PhabricatorApplication. - Make most of the views work well on tablets / phones. The actual "Create" form doesn't, but everything else is good -- need to make device-friendly form layouts before I can do the form. Test Plan: Will attach screenshots. Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3293
2012-08-15 19:45:06 +02:00
'PhabricatorHeaderView' => 'view/layout/PhabricatorHeaderView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorHelpController' => 'applications/help/controller/PhabricatorHelpController.php',
'PhabricatorHelpKeyboardShortcutController' => 'applications/help/controller/PhabricatorHelpKeyboardShortcutController.php',
First pass at hovercard design Summary: Refs T1048 - I'm pretty happy and happy to tell you Savepoint CR Everything's dummy right now. If you are testing locally, don't forget to edit the PHIDs. Or populate your own handles. Doesn't really matter. I'm mainly sending it in for the CSS, not the messy PHP code. Ignore the `margin: auto`, that's just for looking nice. Test Plan: UI Example » Hovercard Reviewers: epriestley, chad CC: aran, Korvin Maniphest Tasks: T1048 Differential Revision: https://secure.phabricator.com/D5519
2013-04-02 18:15:33 +02:00
'PhabricatorHovercardExample' => 'applications/uiexample/examples/PhabricatorHovercardExample.php',
'PhabricatorHovercardView' => 'view/widget/hovercard/PhabricatorHovercardView.php',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorIRCBot' => 'infrastructure/daemon/bot/PhabricatorIRCBot.php',
'PhabricatorIRCProtocolAdapter' => 'infrastructure/daemon/bot/adapter/PhabricatorIRCProtocolAdapter.php',
'PhabricatorIRCProtocolHandler' => 'infrastructure/daemon/bot/handler/PhabricatorIRCProtocolHandler.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorImageTransformer' => 'applications/files/PhabricatorImageTransformer.php',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'PhabricatorInfrastructureTestCase' => 'infrastructure/__tests__/PhabricatorInfrastructureTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorInlineCommentController' => 'infrastructure/diff/PhabricatorInlineCommentController.php',
'PhabricatorInlineCommentInterface' => 'infrastructure/diff/interface/PhabricatorInlineCommentInterface.php',
Make inline comment preview work in Diffusion Summary: created a PhabricatorInlineCommentPreviewController so controllers in Diffusion and Differential respectively just have to handle the URI mapping and data loading like good little controllers. Test Plan: left inline comments on commits, deleted inline commits, submitted inline comments -- all worked well did the same on some diffs Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1176 Differential Revision: https://secure.phabricator.com/D3034
2012-07-23 20:01:28 +02:00
'PhabricatorInlineCommentPreviewController' => 'infrastructure/diff/PhabricatorInlineCommentPreviewController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorInlineSummaryView' => 'infrastructure/diff/view/PhabricatorInlineSummaryView.php',
'PhabricatorJavelinLinter' => 'infrastructure/lint/linter/PhabricatorJavelinLinter.php',
'PhabricatorJumpNavHandler' => 'applications/search/engine/PhabricatorJumpNavHandler.php',
Implement a more compact, general database-backed key-value cache Summary: See discussion in D4204. Facebook currently has a 314MB remarkup cache with a 55MB index, which is slow to access. Under the theory that this is an index size/quality problem (the current index is on a potentially-384-byte field, with many keys sharing prefixes), provide a more general index with fancy new features: - It implements PhutilKeyValueCache, so it can be a component in cache stacks and supports TTL. - It has a 12-byte hash-based key. - It automatically compresses large blocks of data (most of what we store is highly-compressible HTML). Test Plan: - Basics: - Loaded /paste/, saw caches generate and save. - Reloaded /paste/, saw the page hit cache. - GC: - Ran GC daemon, saw nothing. - Set maximum lifetime to 1 second, ran GC daemon, saw it collect the entire cache. - Deflate: - Selected row formats from the database, saw a mixture of 'raw' and 'deflate' storage. - Used profiler to verify that 'deflate' is fast (12 calls @ 220us on my paste list). - Ran unit tests Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D4259
2012-12-21 23:17:56 +01:00
'PhabricatorKeyValueDatabaseCache' => 'applications/cache/PhabricatorKeyValueDatabaseCache.php',
Move LDAP config into PHP Summary: This config section is weak (poorly documented) and inconsistent (keys with "_" instead of "-") but I'm going to keep punting on improving it until after T1536. Test Plan: Loaded, examined LDAP config. Reviewers: btrahan, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4322
2013-01-02 23:04:05 +01:00
'PhabricatorLDAPConfigOptions' => 'applications/config/option/PhabricatorLDAPConfigOptions.php',
Made it possible to login using LDAP Summary: Made it possible to link and unlink LDAP accounts with Phabricator accounts. Test Plan: I've tested this code locally and in production where I work. I've tried creating an account from scratch by logging in with LDAP and linking and unlinking an LDAP account with an existing account. I've tried to associate the same LDAP account with different Phabricator accounts and it failed as expected. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, auduny, svemir Maniphest Tasks: T742 Differential Revision: https://secure.phabricator.com/D2722
2012-06-13 17:52:05 +02:00
'PhabricatorLDAPLoginController' => 'applications/auth/controller/PhabricatorLDAPLoginController.php',
'PhabricatorLDAPProvider' => 'applications/auth/ldap/PhabricatorLDAPProvider.php',
'PhabricatorLDAPRegistrationController' => 'applications/auth/controller/PhabricatorLDAPRegistrationController.php',
Prevent the ability to scrape for valid usernames - return the same error message when either bind or the username search fails to find a user - config variables should use hypen and not underscore
2012-07-26 23:32:51 +02:00
'PhabricatorLDAPUnknownUserException' => 'applications/auth/ldap/PhabricatorLDAPUnknownUserException.php',
Made it possible to login using LDAP Summary: Made it possible to link and unlink LDAP accounts with Phabricator accounts. Test Plan: I've tested this code locally and in production where I work. I've tried creating an account from scratch by logging in with LDAP and linking and unlinking an LDAP account with an existing account. I've tried to associate the same LDAP account with different Phabricator accounts and it failed as expected. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, auduny, svemir Maniphest Tasks: T742 Differential Revision: https://secure.phabricator.com/D2722
2012-06-13 17:52:05 +02:00
'PhabricatorLDAPUnlinkController' => 'applications/auth/controller/PhabricatorLDAPUnlinkController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorLintEngine' => 'infrastructure/lint/PhabricatorLintEngine.php',
Add a basic random image generator Summary: Adds an abstract base class for random image generation. Implements a concrete subclass for generating Mondrian-like images. Test Plan: {F40759} {F40760} {F40761} {F40762} {F40763} Reviewers: DeedyDas, AnhNhan Reviewed By: AnhNhan CC: chad, aran Differential Revision: https://secure.phabricator.com/D5705
2013-04-16 17:19:45 +02:00
'PhabricatorLipsumArtist' => 'applications/lipsum/image/PhabricatorLipsumArtist.php',
First Diff of Test Data Generator Summary: Progress to fix T2903 Test Plan: Ran './bin/lipsum help' and 'generate' workflows. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5672
2013-04-12 23:07:15 +02:00
'PhabricatorLipsumGenerateWorkflow' => 'applications/lipsum/management/PhabricatorLipsumGenerateWorkflow.php',
'PhabricatorLipsumManagementWorkflow' => 'applications/lipsum/management/PhabricatorLipsumManagementWorkflow.php',
Add a basic random image generator Summary: Adds an abstract base class for random image generation. Implements a concrete subclass for generating Mondrian-like images. Test Plan: {F40759} {F40760} {F40761} {F40762} {F40763} Reviewers: DeedyDas, AnhNhan Reviewed By: AnhNhan CC: chad, aran Differential Revision: https://secure.phabricator.com/D5705
2013-04-16 17:19:45 +02:00
'PhabricatorLipsumMondrianArtist' => 'applications/lipsum/image/PhabricatorLipsumMondrianArtist.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'PhabricatorLiskDAO' => 'infrastructure/storage/lisk/PhabricatorLiskDAO.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorLocalDiskFileStorageEngine' => 'applications/files/engine/PhabricatorLocalDiskFileStorageEngine.php',
'PhabricatorLocalTimeTestCase' => 'view/__tests__/PhabricatorLocalTimeTestCase.php',
'PhabricatorLoginController' => 'applications/auth/controller/PhabricatorLoginController.php',
'PhabricatorLoginValidateController' => 'applications/auth/controller/PhabricatorLoginValidateController.php',
'PhabricatorLogoutController' => 'applications/auth/controller/PhabricatorLogoutController.php',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorMacroCommentController' => 'applications/macro/controller/PhabricatorMacroCommentController.php',
MetaMTA: Owners, Pholio, Macro Summary: Port MetaMTA options for Owners, Pholio and Macro. At some point I'd like to get rid of all these options (provide one "reply domain", and not allow overrides of reply handlers -- use events instead) but that's a battle we can fight later. Test Plan: Looked at options, looked at setup issues, edited something. Reviewers: codeblock, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4469
2013-01-16 19:52:30 +01:00
'PhabricatorMacroConfigOptions' => 'applications/macro/config/PhabricatorMacroConfigOptions.php',
Move "Macros" to a first-class application Summary: This is mostly to unblock D3547. - Move "Macros" to a first-class application called "Macros". - After D3547, this application will also house "Memes" (macros with text on them). - This will also make them easier to find; the top navigational query I field is "where are image macros?" nowadays, since it's not intuitive they're part of files. - This makes some of the UI mobile-aware but doesn't set the `device` flag yet, since there are still some missing pieces. - I'll separate storage out and continue modernizing the UI as we unblock and integrate D3547. Test Plan: Created, edited and deleted macros. Viewed files. Reviewers: btrahan, vrana, teisenbe Reviewed By: vrana CC: aran Maniphest Tasks: T175 Differential Revision: https://secure.phabricator.com/D3572
2012-10-01 23:04:03 +02:00
'PhabricatorMacroController' => 'applications/macro/controller/PhabricatorMacroController.php',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorMacroDisableController' => 'applications/macro/controller/PhabricatorMacroDisableController.php',
Move "Macros" to a first-class application Summary: This is mostly to unblock D3547. - Move "Macros" to a first-class application called "Macros". - After D3547, this application will also house "Memes" (macros with text on them). - This will also make them easier to find; the top navigational query I field is "where are image macros?" nowadays, since it's not intuitive they're part of files. - This makes some of the UI mobile-aware but doesn't set the `device` flag yet, since there are still some missing pieces. - I'll separate storage out and continue modernizing the UI as we unblock and integrate D3547. Test Plan: Created, edited and deleted macros. Viewed files. Reviewers: btrahan, vrana, teisenbe Reviewed By: vrana CC: aran Maniphest Tasks: T175 Differential Revision: https://secure.phabricator.com/D3572
2012-10-01 23:04:03 +02:00
'PhabricatorMacroEditController' => 'applications/macro/controller/PhabricatorMacroEditController.php',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorMacroEditor' => 'applications/macro/editor/PhabricatorMacroEditor.php',
Move "Macros" to a first-class application Summary: This is mostly to unblock D3547. - Move "Macros" to a first-class application called "Macros". - After D3547, this application will also house "Memes" (macros with text on them). - This will also make them easier to find; the top navigational query I field is "where are image macros?" nowadays, since it's not intuitive they're part of files. - This makes some of the UI mobile-aware but doesn't set the `device` flag yet, since there are still some missing pieces. - I'll separate storage out and continue modernizing the UI as we unblock and integrate D3547. Test Plan: Created, edited and deleted macros. Viewed files. Reviewers: btrahan, vrana, teisenbe Reviewed By: vrana CC: aran Maniphest Tasks: T175 Differential Revision: https://secure.phabricator.com/D3572
2012-10-01 23:04:03 +02:00
'PhabricatorMacroListController' => 'applications/macro/controller/PhabricatorMacroListController.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorMacroMailReceiver' => 'applications/macro/mail/PhabricatorMacroMailReceiver.php',
Made Meme Generator Summary: Fixed T2353 Test Plan: Checked whether same text generated the same URL Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2353 Differential Revision: https://secure.phabricator.com/D4551
2013-01-20 03:43:35 +01:00
'PhabricatorMacroMemeController' => 'applications/macro/controller/PhabricatorMacroMemeController.php',
Create a basic meme dialog Summary: Simple dialog for creating memes. We can add more features (typeahead, selection thumbs, preview) later. Test Plan: {F29815} Reviewers: DeedyDas, chad Reviewed By: chad CC: aran Maniphest Tasks: T2353 Differential Revision: https://secure.phabricator.com/D4557
2013-01-22 03:46:04 +01:00
'PhabricatorMacroMemeDialogController' => 'applications/macro/controller/PhabricatorMacroMemeDialogController.php',
Adding some filters and queries to Macro application Summary: Fixes T2778 Introduces `PhabricatorMacroQuery`, which should consolidate all queries regarding macros Adds `PolicyInterface` to `PhabricatorImageMacro`, as else the query would fail (we should consider adding it to the ApplicationTransaction instead, if that was ever planned) Adds `Active Macros` filter, making it the default Adds `My Macros` filter. You may ask why it overwrites `$authors`. Well, I did not want the page jump to the conclusion that it is a search result. It //is// one more or less, but the filter would jump to `seach` instead of `my`. If you want `My Macros` removed, tell me. It is useful only to heavy-macro-uploaders-and-users though. Five or six people in `http://secure.phabricator.(org|com)`, and an estimated dozen and a half at bigger installs. Test Plan: created multiple macros from multiple authors, disabled them at will. browsed around, verified that Macros only appeared in the right filters and that nothing else broke. Reviewers: epriestley, chad, btrahan CC: aran, Korvin Maniphest Tasks: T2778 Differential Revision: https://secure.phabricator.com/D5409
2013-03-22 17:46:21 +01:00
'PhabricatorMacroQuery' => 'applications/macro/query/PhabricatorMacroQuery.php',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorMacroReplyHandler' => 'applications/macro/mail/PhabricatorMacroReplyHandler.php',
Implement generalized application search in Macros Summary: Ref T2625. Works out the last kinks of generalization and gives Macros the more powerful new query engine. Overall, this feels pretty good to me. Test Plan: Executed, saved and edited a bunch of Macro queries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6078
2013-05-30 23:09:37 +02:00
'PhabricatorMacroSearchEngine' => 'applications/macro/query/PhabricatorMacroSearchEngine.php',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorMacroTransaction' => 'applications/macro/storage/PhabricatorMacroTransaction.php',
'PhabricatorMacroTransactionComment' => 'applications/macro/storage/PhabricatorMacroTransactionComment.php',
'PhabricatorMacroTransactionQuery' => 'applications/macro/query/PhabricatorMacroTransactionQuery.php',
'PhabricatorMacroTransactionType' => 'applications/macro/constants/PhabricatorMacroTransactionType.php',
'PhabricatorMacroViewController' => 'applications/macro/controller/PhabricatorMacroViewController.php',
Require a viewer to load handles Summary: Unmuck almost all of the we-sort-of-have-viewers-some-of-the-time mess. There are a few notable cases here: - I used Omnipotent users when indexing objects for search. I think this is correct; we do policy filtering when showing results. - I cheated in a bad way in the Remarkup object rule, but fixing this requires fixing all the PhabricatorRemarkupEngine callsites (there are 85). I'll do that in the next diff. - I cheated in a few random places, like when sending mail about package edits. These aren't a big deal. Test Plan: - Grepped for all PhabricatorObjectHandleData references. - Gave them viewers. Reviewers: vrana Reviewed By: vrana CC: aran, edward Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D5151
2013-03-01 02:15:09 +01:00
'PhabricatorMail' => 'applications/metamta/PhabricatorMail.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMailImplementationAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationAdapter.php',
'PhabricatorMailImplementationAmazonSESAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationAmazonSESAdapter.php',
Support SMTP as the mailer. Summary: Support SMTP as the mailer and user could turn on SMTP authentication if needed. Import PHPMailer as PHPMailerLite doesn't support SMTP. Make class PhabricatorMailImplementationPHPMailerAdapter final. Test Plan: N/A Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2139 Differential Revision: https://secure.phabricator.com/D4063
2012-12-09 11:36:40 +01:00
'PhabricatorMailImplementationPHPMailerAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationPHPMailerAdapter.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMailImplementationPHPMailerLiteAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationPHPMailerLiteAdapter.php',
'PhabricatorMailImplementationSendGridAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationSendGridAdapter.php',
'PhabricatorMailImplementationTestAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationTestAdapter.php',
Introduce basic `bin/mail` with a `resend` workflow Summary: Fixes T2458. Ref T2843. @tido's email from T2843 has exhausted its retries and failed, but we want to try it again with the patch from D5464 to capture the actual error. This sort of thing has come up a few times in debugging, too. Also fixed some stuff that came up while debugging this. Test Plan: - Ran command with no args. - Ran resend with no args. - Ran resend with bad IDs. - Ran resend with already-queued messages, got "already queued" error. - Ran resend with already-sent message, got requeue. Reviewers: btrahan, tido Reviewed By: tido CC: aran Maniphest Tasks: T2458, T2843 Differential Revision: https://secure.phabricator.com/D5493
2013-03-30 23:53:49 +01:00
'PhabricatorMailManagementResendWorkflow' => 'applications/metamta/management/PhabricatorMailManagementResendWorkflow.php',
Provide some diagnostic tools for examining inbound and outbound mail Summary: We can't show this stuff on the web UI because it has password reset links and private reply-to addresses, but we can provide easier CLI tools than "root around in the database". Land a rough version of `bin/mail show-inbound` and `bin/mail show-outbound`. Test Plan: Used both commands to examine mail from the CLI. Reviewers: btrahan Reviewed By: btrahan CC: tido, euresti, aran Differential Revision: https://secure.phabricator.com/D5963
2013-05-20 19:13:42 +02:00
'PhabricatorMailManagementShowInboundWorkflow' => 'applications/metamta/management/PhabricatorMailManagementShowInboundWorkflow.php',
'PhabricatorMailManagementShowOutboundWorkflow' => 'applications/metamta/management/PhabricatorMailManagementShowOutboundWorkflow.php',
Introduce basic `bin/mail` with a `resend` workflow Summary: Fixes T2458. Ref T2843. @tido's email from T2843 has exhausted its retries and failed, but we want to try it again with the patch from D5464 to capture the actual error. This sort of thing has come up a few times in debugging, too. Also fixed some stuff that came up while debugging this. Test Plan: - Ran command with no args. - Ran resend with no args. - Ran resend with bad IDs. - Ran resend with already-queued messages, got "already queued" error. - Ran resend with already-sent message, got requeue. Reviewers: btrahan, tido Reviewed By: tido CC: aran Maniphest Tasks: T2458, T2843 Differential Revision: https://secure.phabricator.com/D5493
2013-03-30 23:53:49 +01:00
'PhabricatorMailManagementWorkflow' => 'applications/metamta/management/PhabricatorMailManagementWorkflow.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorMailReceiver' => 'applications/metamta/receiver/PhabricatorMailReceiver.php',
Add unit tests to cover PhabricatorMailReceiver::matchAddresses() Summary: Ref T3183. We should accept addresses like `"New Bug" <bugs@example.com>` to match `bugs@example.com`. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3183 Differential Revision: https://secure.phabricator.com/D5923
2013-05-15 00:04:17 +02:00
'PhabricatorMailReceiverTestCase' => 'applications/metamta/receiver/__tests__/PhabricatorMailReceiverTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMailReplyHandler' => 'applications/metamta/replyhandler/PhabricatorMailReplyHandler.php',
Moderize Mailing Lists Summary: Attempting to learn how to 'modernize' apps so I can update things. Adds a sidenav, crumbs, and views. Test Plan: Tested creating lists on web and mobile. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4598
2013-01-24 01:36:21 +01:00
'PhabricatorMailingListsController' => 'applications/mailinglists/controller/PhabricatorMailingListsController.php',
Move "Mailing Lists" to a separate application Summary: There's currently no way to get here from the UI since nav tabs don't exist anymore. It's also always been hard to find this feature even when we had the tabs, since it's surprising that it's inside "MetaMTA". - Move mailing lists to a separate application. - Add `buildApplicationPage()`, since we don't really need `buildStandardPageResponse()` any more -- we can infer all the information from `PhabricatorApplication`. This will let us get rid of a lot of the `PhabricatorXXXController` classes which just define application information. - Add `getApplicationURI()` to reduce code duplication, and in case we want to let you move applications around some day. Test Plan: Looked/edited/saved mailing lists. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T631 Differential Revision: https://secure.phabricator.com/D3248
2012-08-13 04:19:46 +02:00
'PhabricatorMailingListsEditController' => 'applications/mailinglists/controller/PhabricatorMailingListsEditController.php',
'PhabricatorMailingListsListController' => 'applications/mailinglists/controller/PhabricatorMailingListsListController.php',
Switch to new menubar Summary: - Looks better (can probably still use some tweaks), especially search. - Moves logout from weird footer location to main menu. - Reactive: on tablets and phones, the menu adjusts to remain useful. - Fixed position on desktops for future side nav changes. - Adds an icon header thing that's currently hard-coded but will be application-driven soon. Test Plan: Used menu on desktop, tablet, phone, logged in / logged out, toggled darkconsole. Will add some screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3105
2012-07-31 01:09:14 +02:00
'PhabricatorMainMenuGroupView' => 'view/page/menu/PhabricatorMainMenuGroupView.php',
'PhabricatorMainMenuIconView' => 'view/page/menu/PhabricatorMainMenuIconView.php',
'PhabricatorMainMenuSearchView' => 'view/page/menu/PhabricatorMainMenuSearchView.php',
'PhabricatorMainMenuView' => 'view/page/menu/PhabricatorMainMenuView.php',
Port Maniphest options. Test Plan: Viewed the new options. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4401
2013-01-11 19:24:35 +01:00
'PhabricatorManiphestConfigOptions' => 'applications/maniphest/config/PhabricatorManiphestConfigOptions.php',
Fixed Task Generation Summary: Ref T2903 Test Plan: Successfully generated tasks with authors and owners. Reviewers: epriestley, AnhNhan Reviewed By: epriestley CC: aran, Korvin, AnhNhan, chad Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5704
2013-04-25 03:17:30 +02:00
'PhabricatorManiphestTaskTestDataGenerator' => 'applications/maniphest/lipsum/PhabricatorManiphestTaskTestDataGenerator.php',
Add a generic multistep Markup cache Summary: The immediate issue this addresses is T1366, adding a rendering cache to Phriction. For wiki pages with code blocks especially, rerendering them each time is expensive. The broader issue is that out markup caches aren't very good right now. They have three major problems: **Problem 1: the data is stored in the wrong place.** We currently store remarkup caches on objects. This means we're always loading it and passing it around even when we don't need it, can't genericize cache management code (e.g., have one simple script to drop/GC caches), need to update authoritative rows to clear caches, and can't genericize rendering code since each object is different. To solve this, I created a dedicated cache database that I plan to move all markup caches to use. **Problem 2: time-variant rules break when cached.** Some rules like `**bold**` are time-invariant and always produce the same output, but some rules like `{Tnnn}` and `@username` are variant and may render differently (because a task was closed or a user is on vacation). Currently, we cache the raw output, so these time-variant rules get locked at whatever values they had when they were first rendered. This is the main reason Phriction doesn't have a cache right now -- I wanted `{Tnnn}` rules to reflect open/closed tasks. To solve this, I split markup into a "preprocessing" phase (which does all the parsing and evaluates all time-invariant rules) and a "postprocessing" phase (which evaluates time-variant rules only). The preprocessing phase is most of the expense (and, notably, includes syntax highlighting) so this is nearly as good as caching the final output. I did most of the work here in D737 / D738, but we never moved to use it in Phabricator -- we currently just do the two operations serially in all cases. This diff splits them apart and caches the output of preprocessing only, so we benefit from caching but also get accurate time-variant rendering. **Problem 3: cache access isn't batched/pipelined optimally.** When we're rendering a list of markup blocks, we should be able to batch datafetching better than we do. D738 helped with this (fetching is batched within a single hunk of markup) and this improves batching on cache access. We could still do better here, but this is at least a step forward. Also fixes a bug with generating a link in the Phriction history interface ($uri gets clobbered). I'm using PHP serialization instead of JSON serialization because Remarkup does some stuff with non-ascii characters that might not survive JSON. Test Plan: - Created a Phriction document and verified that previews don't go to cache (no rows appear in the cache table). - Verified that published documents come out of cache. - Verified that caches generate/regenerate correctly, time-variant rules render properly and old documents hit the right caches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1366 Differential Revision: https://secure.phabricator.com/D2945
2012-07-10 00:20:56 +02:00
'PhabricatorMarkupCache' => 'applications/cache/storage/PhabricatorMarkupCache.php',
Minor, move all remarkup code to src/infrastructure/markup/
2012-07-02 19:44:37 +02:00
'PhabricatorMarkupEngine' => 'infrastructure/markup/PhabricatorMarkupEngine.php',
Add a generic multistep Markup cache Summary: The immediate issue this addresses is T1366, adding a rendering cache to Phriction. For wiki pages with code blocks especially, rerendering them each time is expensive. The broader issue is that out markup caches aren't very good right now. They have three major problems: **Problem 1: the data is stored in the wrong place.** We currently store remarkup caches on objects. This means we're always loading it and passing it around even when we don't need it, can't genericize cache management code (e.g., have one simple script to drop/GC caches), need to update authoritative rows to clear caches, and can't genericize rendering code since each object is different. To solve this, I created a dedicated cache database that I plan to move all markup caches to use. **Problem 2: time-variant rules break when cached.** Some rules like `**bold**` are time-invariant and always produce the same output, but some rules like `{Tnnn}` and `@username` are variant and may render differently (because a task was closed or a user is on vacation). Currently, we cache the raw output, so these time-variant rules get locked at whatever values they had when they were first rendered. This is the main reason Phriction doesn't have a cache right now -- I wanted `{Tnnn}` rules to reflect open/closed tasks. To solve this, I split markup into a "preprocessing" phase (which does all the parsing and evaluates all time-invariant rules) and a "postprocessing" phase (which evaluates time-variant rules only). The preprocessing phase is most of the expense (and, notably, includes syntax highlighting) so this is nearly as good as caching the final output. I did most of the work here in D737 / D738, but we never moved to use it in Phabricator -- we currently just do the two operations serially in all cases. This diff splits them apart and caches the output of preprocessing only, so we benefit from caching but also get accurate time-variant rendering. **Problem 3: cache access isn't batched/pipelined optimally.** When we're rendering a list of markup blocks, we should be able to batch datafetching better than we do. D738 helped with this (fetching is batched within a single hunk of markup) and this improves batching on cache access. We could still do better here, but this is at least a step forward. Also fixes a bug with generating a link in the Phriction history interface ($uri gets clobbered). I'm using PHP serialization instead of JSON serialization because Remarkup does some stuff with non-ascii characters that might not survive JSON. Test Plan: - Created a Phriction document and verified that previews don't go to cache (no rows appear in the cache table). - Verified that published documents come out of cache. - Verified that caches generate/regenerate correctly, time-variant rules render properly and old documents hit the right caches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1366 Differential Revision: https://secure.phabricator.com/D2945
2012-07-10 00:20:56 +02:00
'PhabricatorMarkupInterface' => 'infrastructure/markup/PhabricatorMarkupInterface.php',
Provide a concrete class for one-off remarkup blocks Summary: I want to use some of these for instructional text in Diffusion. Provide a concrete class to make one-offs cacheable and switch Releeph to use it. Test Plan: {F44175} Reviewers: btrahan, chad, edward Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6032
2013-05-24 21:37:53 +02:00
'PhabricatorMarkupOneOff' => 'infrastructure/markup/PhabricatorMarkupOneOff.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMercurialGraphStream' => 'applications/repository/daemon/PhabricatorMercurialGraphStream.php',
'PhabricatorMetaMTAAttachment' => 'applications/metamta/storage/PhabricatorMetaMTAAttachment.php',
Implement all remaining config options Summary: Resolves T2255. Test Plan: Looked at mail options. Saw no remaining "Setup Issues". Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4477
2013-01-17 00:06:39 +01:00
'PhabricatorMetaMTAConfigOptions' => 'applications/config/option/PhabricatorMetaMTAConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMetaMTAController' => 'applications/metamta/controller/PhabricatorMetaMTAController.php',
'PhabricatorMetaMTADAO' => 'applications/metamta/storage/PhabricatorMetaMTADAO.php',
Add another pattern to quoted email body stripping Summary: Ref T3217. @hlau has an email client which quotes text with: ________________________________________ From: ... Add a regular expression to correctly detect this as quoted body text. Test Plan: Add unit test; executed unit test. Reviewers: btrahan, chad Reviewed By: chad CC: hlau, aran Maniphest Tasks: T3217 Differential Revision: https://secure.phabricator.com/D5986
2013-05-21 00:52:54 +02:00
'PhabricatorMetaMTAEmailBodyParser' => 'applications/metamta/parser/PhabricatorMetaMTAEmailBodyParser.php',
'PhabricatorMetaMTAEmailBodyParserTestCase' => 'applications/metamta/parser/__tests__/PhabricatorMetaMTAEmailBodyParserTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMetaMTAListController' => 'applications/metamta/controller/PhabricatorMetaMTAListController.php',
'PhabricatorMetaMTAMail' => 'applications/metamta/storage/PhabricatorMetaMTAMail.php',
Centralize rendering of application mail bodies Summary: This is a minor quality-of-life improvement to prevent D2968 from being as nasty as it is. Test Plan: Ran unit tests; generated Differential, Maniphest and Diffusion emails and verified the bodies looked sensible. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran Maniphest Tasks: T931 Differential Revision: https://secure.phabricator.com/D2986
2012-07-17 04:01:43 +02:00
'PhabricatorMetaMTAMailBody' => 'applications/metamta/view/PhabricatorMetaMTAMailBody.php',
'PhabricatorMetaMTAMailBodyTestCase' => 'applications/metamta/view/__tests__/PhabricatorMetaMTAMailBodyTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMetaMTAMailTestCase' => 'applications/metamta/storage/__tests__/PhabricatorMetaMTAMailTestCase.php',
Move "Mailing Lists" to a separate application Summary: There's currently no way to get here from the UI since nav tabs don't exist anymore. It's also always been hard to find this feature even when we had the tabs, since it's surprising that it's inside "MetaMTA". - Move mailing lists to a separate application. - Add `buildApplicationPage()`, since we don't really need `buildStandardPageResponse()` any more -- we can infer all the information from `PhabricatorApplication`. This will let us get rid of a lot of the `PhabricatorXXXController` classes which just define application information. - Add `getApplicationURI()` to reduce code duplication, and in case we want to let you move applications around some day. Test Plan: Looked/edited/saved mailing lists. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T631 Differential Revision: https://secure.phabricator.com/D3248
2012-08-13 04:19:46 +02:00
'PhabricatorMetaMTAMailingList' => 'applications/mailinglists/storage/PhabricatorMetaMTAMailingList.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMetaMTAReceiveController' => 'applications/metamta/controller/PhabricatorMetaMTAReceiveController.php',
'PhabricatorMetaMTAReceivedListController' => 'applications/metamta/controller/PhabricatorMetaMTAReceivedListController.php',
'PhabricatorMetaMTAReceivedMail' => 'applications/metamta/storage/PhabricatorMetaMTAReceivedMail.php',
Begin improving the soundness of received mail Summary: We/I broke a couple of things here recently (see D5911) and are doing some work here in general (see D5912, etc.). Generally, this code is pretty oldschool and not especially well architected for modern application-oriented Phabricator. It hardcodes a lot of stuff which should be applications' responsibilites. Take the first steps toward making it more solid to reduce the risk here. In particular: - Factor out the "self mail" and "duplicate mail" checks and add unit tests. - Make Message-ID hash handling automatic. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5915
2013-05-14 01:32:19 +02:00
'PhabricatorMetaMTAReceivedMailProcessingException' => 'applications/metamta/exception/PhabricatorMetaMTAReceivedMailProcessingException.php',
'PhabricatorMetaMTAReceivedMailTestCase' => 'applications/metamta/storage/__tests__/PhabricatorMetaMTAReceivedMailTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMetaMTASendController' => 'applications/metamta/controller/PhabricatorMetaMTASendController.php',
'PhabricatorMetaMTASendGridReceiveController' => 'applications/metamta/controller/PhabricatorMetaMTASendGridReceiveController.php',
'PhabricatorMetaMTAViewController' => 'applications/metamta/controller/PhabricatorMetaMTAViewController.php',
'PhabricatorMetaMTAWorker' => 'applications/metamta/PhabricatorMetaMTAWorker.php',
Build an AphrontMultiColumnView, use on workboards. Summary: Abstract out the multi-column code from workboards and have it be available separately. I feel like there will be some benefit here especially for custom developers in how they present infromation (like releeph). It also scales back to tablet and mobile fairly well, so they get those things for free. Test Plan: Tested mobile, tablet and chrome layouts. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5529
2013-04-02 20:23:24 +02:00
'PhabricatorMultiColumnExample' => 'applications/uiexample/examples/PhabricatorMultiColumnExample.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMustVerifyEmailController' => 'applications/auth/controller/PhabricatorMustVerifyEmailController.php',
Port MySQL settings to PHP Summary: - Ports MySQL settings to PHP. - Removes "mysql.retries" -- this existed only because Magic Numbers Are Bad, but there is no concievable reason it should ever be set to anything other than 3. - Introduced "Hidden" config, which isn't visible from the web (for SaaS, we'll just mark anything with secret keys as "hidden"). - Introduced "Masked" config, which will be masked in darkconsole once that gets updated. - "Hidden" implies "Masked" and "Locked". - Moved "storage.default-namespace" here -- it probably makes more sense than core; this was my bad in T2255. - Put cancel button back for hidden/locked config. - Introduce 'class' config type. Test Plan: Viewed MySQL options. None are editable. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4326
2013-01-03 15:01:14 +01:00
'PhabricatorMySQLConfigOptions' => 'applications/config/option/PhabricatorMySQLConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMySQLFileStorageEngine' => 'applications/files/engine/PhabricatorMySQLFileStorageEngine.php',
Add ability to name saved queries. Summary: Can name saved queries. Test Plan: Try naming some saved queries using the form. Reviewers: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D5878 Conflicts: src/infrastructure/storage/patch/PhabricatorBuiltinPatchList.php
2013-05-10 22:43:59 +02:00
'PhabricatorNamedQuery' => 'applications/search/storage/PhabricatorNamedQuery.php',
Introduce PhabricatorNamedQueryQuery Summary: Adds a first-class Query object for querying NamedQueries. xzibit would be proud. Test Plan: Updated query edit interface to use this query, verified it works correctly. Reviewers: btrahan, blc Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6051
2013-05-27 22:40:43 +02:00
'PhabricatorNamedQueryQuery' => 'applications/search/query/PhabricatorNamedQueryQuery.php',
Implement Maniphest auxiliary field 'default' key Summary: Fixes T404. Ref T2575. Allows default to be set for any field. Date defaults are interpreted by `strtotime()`. Other defaults are interpreted as expected. Test Plan: - Created a string custom field with default value "Orange". - Created a date custom field with a fixed default value (my birthday). - Created a date custom field with a relative default value ("today 4:59 PM"). - Created/edited tasks with these fields, verified everything behaved sensibly. Reviewers: hach-que, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T404, T2575 Differential Revision: https://secure.phabricator.com/D5282
2013-03-08 02:23:30 +01:00
'PhabricatorNoteExample' => 'applications/uiexample/examples/PhabricatorNoteExample.php',
Move files in notification one level up. Summary: Moved the files in notification one level up to match the rest of code base. And ran arc liberate. Test Plan: Made sure __phutil_library_map__ points to the right files. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: allenjohnashton, aran, Korvin Differential Revision: https://secure.phabricator.com/D2688
2012-06-08 22:00:07 +02:00
'PhabricatorNotificationBuilder' => 'applications/notification/builder/PhabricatorNotificationBuilder.php',
Add a "Mark All Read" button for notifications Summary: Adds a button to mark everything as read. Test Plan: Clicked button. Reviewers: btrahan, jungejason, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T974 Differential Revision: https://secure.phabricator.com/D2812
2012-06-20 22:51:19 +02:00
'PhabricatorNotificationClearController' => 'applications/notification/controller/PhabricatorNotificationClearController.php',
Move notification configuration into PHP Summary: Bring notification settings to PHP. Test Plan: Viewed notification settings in /config/. Reviewers: codeblock, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4337
2013-01-03 18:29:19 +01:00
'PhabricatorNotificationConfigOptions' => 'applications/config/option/PhabricatorNotificationConfigOptions.php',
Move files in notification one level up. Summary: Moved the files in notification one level up to match the rest of code base. And ran arc liberate. Test Plan: Made sure __phutil_library_map__ points to the right files. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: allenjohnashton, aran, Korvin Differential Revision: https://secure.phabricator.com/D2688
2012-06-08 22:00:07 +02:00
'PhabricatorNotificationController' => 'applications/notification/controller/PhabricatorNotificationController.php',
Make Notifications Realtime Summary: Adds the node.js Aphlict server, the flash Aphlict client, and some supporting javascript. Built on top of - and requires - D2703 (which is still in progress). Will likely work with no modification on top of the final version, though. The node server is currently run with sudo node support/aphlict/server/aphlict_server.js Test Plan: tested locally Reviewers: epriestley Reviewed By: epriestley CC: allenjohnashton, keebuhm, aran, Korvin Differential Revision: https://secure.phabricator.com/D2704
2012-06-12 02:49:32 +02:00
'PhabricatorNotificationIndividualController' => 'applications/notification/controller/PhabricatorNotificationIndividualController.php',
Add a list of all notifications Summary: Add a "View All Notifications" link and page. Test Plan: Viewed all notifications Reviewers: jungejason, vrana Reviewed By: jungejason CC: aran Maniphest Tasks: T974 Differential Revision: https://secure.phabricator.com/D2780
2012-06-18 23:07:38 +02:00
'PhabricatorNotificationListController' => 'applications/notification/controller/PhabricatorNotificationListController.php',
Adds the UI dropdown panel Summary: Add a dropdown to display notificaitons. Right now there is nothing real time about it, but we do update the panel when the user clicks. This panel is only displayed if the install has notifications enabled and you have them enabled in your preferences (not using them by default). Test Plan: Turn off notifications for user1, left them on for user2. Did things from user1 and from user2 on task both were cc'd on. user2 recieved all notifications, user1 recieved nothing. Made new user, made sure everything was switched off by default. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: keebuhm, ddfisher, aran, Korvin Differential Revision: https://secure.phabricator.com/D2703
2012-06-11 18:37:06 +02:00
'PhabricatorNotificationPanelController' => 'applications/notification/controller/PhabricatorNotificationPanelController.php',
Adds base notification application Summary: First diff in a series of diffs to add notifications to Phabricator. This is the notification application ONLY. This commit does not include the changes to other applications that makes them add notifications. As such, no notifications will be generated beyond the initial database import. Test Plan: This is part of the notifications architecture which has been running on http://theoryphabricator.com for the past several months. Reviewers: epriestley, btrahan, ddfisher Reviewed By: epriestley CC: allenjohnashton, keebuhm, aran, Korvin, jungejason, nh Maniphest Tasks: T974 Differential Revision: https://secure.phabricator.com/D2571
2012-06-08 15:31:30 +02:00
'PhabricatorNotificationQuery' => 'applications/notification/PhabricatorNotificationQuery.php',
Add a server status page for notification server Summary: - Add a /notification/status/ page which shows server status. - Remove various test controllers and routes. - Make the "no notifications" message look better. - Move port/URI configuration to config file. Test Plan: Started server, hit /notification/status/, saw server status. Reviewers: allenjohnashton, ddfisher, keebuhm, jungejason Reviewed By: jungejason CC: aran Maniphest Tasks: T944 Differential Revision: https://secure.phabricator.com/D2756
2012-06-17 20:35:18 +02:00
'PhabricatorNotificationStatusController' => 'applications/notification/controller/PhabricatorNotificationStatusController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOAuthClientAuthorization' => 'applications/oauthserver/storage/PhabricatorOAuthClientAuthorization.php',
'PhabricatorOAuthClientAuthorizationBaseController' => 'applications/oauthserver/controller/clientauthorization/PhabricatorOAuthClientAuthorizationBaseController.php',
'PhabricatorOAuthClientAuthorizationDeleteController' => 'applications/oauthserver/controller/clientauthorization/PhabricatorOAuthClientAuthorizationDeleteController.php',
'PhabricatorOAuthClientAuthorizationEditController' => 'applications/oauthserver/controller/clientauthorization/PhabricatorOAuthClientAuthorizationEditController.php',
'PhabricatorOAuthClientAuthorizationListController' => 'applications/oauthserver/controller/clientauthorization/PhabricatorOAuthClientAuthorizationListController.php',
'PhabricatorOAuthClientAuthorizationQuery' => 'applications/oauthserver/query/PhabricatorOAuthClientAuthorizationQuery.php',
'PhabricatorOAuthClientBaseController' => 'applications/oauthserver/controller/client/PhabricatorOAuthClientBaseController.php',
'PhabricatorOAuthClientDeleteController' => 'applications/oauthserver/controller/client/PhabricatorOAuthClientDeleteController.php',
'PhabricatorOAuthClientEditController' => 'applications/oauthserver/controller/client/PhabricatorOAuthClientEditController.php',
'PhabricatorOAuthClientListController' => 'applications/oauthserver/controller/client/PhabricatorOAuthClientListController.php',
'PhabricatorOAuthClientViewController' => 'applications/oauthserver/controller/client/PhabricatorOAuthClientViewController.php',
'PhabricatorOAuthDefaultRegistrationController' => 'applications/auth/controller/oauthregistration/PhabricatorOAuthDefaultRegistrationController.php',
'PhabricatorOAuthDiagnosticsController' => 'applications/auth/controller/PhabricatorOAuthDiagnosticsController.php',
'PhabricatorOAuthFailureView' => 'applications/auth/view/PhabricatorOAuthFailureView.php',
'PhabricatorOAuthLoginController' => 'applications/auth/controller/PhabricatorOAuthLoginController.php',
'PhabricatorOAuthProvider' => 'applications/auth/oauth/provider/PhabricatorOAuthProvider.php',
'PhabricatorOAuthProviderDisqus' => 'applications/auth/oauth/provider/PhabricatorOAuthProviderDisqus.php',
'PhabricatorOAuthProviderException' => 'applications/auth/oauth/provider/PhabricatorOAuthProviderException.php',
'PhabricatorOAuthProviderFacebook' => 'applications/auth/oauth/provider/PhabricatorOAuthProviderFacebook.php',
'PhabricatorOAuthProviderGitHub' => 'applications/auth/oauth/provider/PhabricatorOAuthProviderGitHub.php',
'PhabricatorOAuthProviderGoogle' => 'applications/auth/oauth/provider/PhabricatorOAuthProviderGoogle.php',
'PhabricatorOAuthProviderPhabricator' => 'applications/auth/oauth/provider/PhabricatorOAuthProviderPhabricator.php',
'PhabricatorOAuthRegistrationController' => 'applications/auth/controller/oauthregistration/PhabricatorOAuthRegistrationController.php',
'PhabricatorOAuthResponse' => 'applications/oauthserver/PhabricatorOAuthResponse.php',
'PhabricatorOAuthServer' => 'applications/oauthserver/PhabricatorOAuthServer.php',
'PhabricatorOAuthServerAccessToken' => 'applications/oauthserver/storage/PhabricatorOAuthServerAccessToken.php',
'PhabricatorOAuthServerAuthController' => 'applications/oauthserver/controller/PhabricatorOAuthServerAuthController.php',
'PhabricatorOAuthServerAuthorizationCode' => 'applications/oauthserver/storage/PhabricatorOAuthServerAuthorizationCode.php',
'PhabricatorOAuthServerClient' => 'applications/oauthserver/storage/PhabricatorOAuthServerClient.php',
'PhabricatorOAuthServerClientQuery' => 'applications/oauthserver/query/PhabricatorOAuthServerClientQuery.php',
'PhabricatorOAuthServerController' => 'applications/oauthserver/controller/PhabricatorOAuthServerController.php',
'PhabricatorOAuthServerDAO' => 'applications/oauthserver/storage/PhabricatorOAuthServerDAO.php',
'PhabricatorOAuthServerScope' => 'applications/oauthserver/PhabricatorOAuthServerScope.php',
'PhabricatorOAuthServerTestCase' => 'applications/oauthserver/__tests__/PhabricatorOAuthServerTestCase.php',
'PhabricatorOAuthServerTestController' => 'applications/oauthserver/controller/PhabricatorOAuthServerTestController.php',
'PhabricatorOAuthServerTokenController' => 'applications/oauthserver/controller/PhabricatorOAuthServerTokenController.php',
'PhabricatorOAuthUnlinkController' => 'applications/auth/controller/PhabricatorOAuthUnlinkController.php',
'PhabricatorObjectHandle' => 'applications/phid/PhabricatorObjectHandle.php',
'PhabricatorObjectHandleConstants' => 'applications/phid/handle/const/PhabricatorObjectHandleConstants.php',
'PhabricatorObjectHandleData' => 'applications/phid/handle/PhabricatorObjectHandleData.php',
'PhabricatorObjectHandleStatus' => 'applications/phid/handle/const/PhabricatorObjectHandleStatus.php',
Implement card style and extras for object item lists Summary: Initial pass at elements appearing on M10. Glaring omissions: - I cut a single icon out of M10 in a haphazard way. - No linear graident texture on the cards. Test Plan: {F35248} {F35249} Reviewers: chad Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D5311
2013-03-10 02:55:01 +01:00
'PhabricatorObjectItemListExample' => 'applications/uiexample/examples/PhabricatorObjectItemListExample.php',
Modernize Paste Summary: - Add a PhabricatorApplication. - Make most of the views work well on tablets / phones. The actual "Create" form doesn't, but everything else is good -- need to make device-friendly form layouts before I can do the form. Test Plan: Will attach screenshots. Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3293
2012-08-15 19:45:06 +02:00
'PhabricatorObjectItemListView' => 'view/layout/PhabricatorObjectItemListView.php',
'PhabricatorObjectItemView' => 'view/layout/PhabricatorObjectItemView.php',
Make project membership edits use transactions and PHIDs and not be awful Summary: - Split project profile editing apart from project membership editing. - Make project membership editing simpler and easier to use. - Drop role / owner stuff from the UI. Test Plan: Added and removed project members. Edited project profile information. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3184
2012-08-07 20:57:38 +02:00
'PhabricatorObjectListView' => 'view/control/PhabricatorObjectListView.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorObjectMailReceiver' => 'applications/metamta/receiver/PhabricatorObjectMailReceiver.php',
Move sender validation into MailReceiver classes Summary: Ref T1205. Finally able to delete a big chunk of this nastiness. Make MailReceivers responsible for validating senders. For object creation receivers (bugs, conpherences) this just means that users must not be disabled. For other receivers the senders must be able to see the objects, have the right hashes, etc., according to policy. Test Plan: Added a bunch of test cases (everything except policy). Verified behavior via the Receive test console. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5943
2013-05-17 12:49:29 +02:00
'PhabricatorObjectMailReceiverTestCase' => 'applications/metamta/receiver/__tests__/PhabricatorObjectMailReceiverTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorObjectSelectorDialog' => 'view/control/PhabricatorObjectSelectorDialog.php',
'PhabricatorOffsetPagedQuery' => 'infrastructure/query/PhabricatorOffsetPagedQuery.php',
'PhabricatorOwnerPathQuery' => 'applications/owners/query/PhabricatorOwnerPathQuery.php',
MetaMTA: Owners, Pholio, Macro Summary: Port MetaMTA options for Owners, Pholio and Macro. At some point I'd like to get rid of all these options (provide one "reply domain", and not allow overrides of reply handlers -- use events instead) but that's a battle we can fight later. Test Plan: Looked at options, looked at setup issues, edited something. Reviewers: codeblock, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4469
2013-01-16 19:52:30 +01:00
'PhabricatorOwnersConfigOptions' => 'applications/owners/config/PhabricatorOwnersConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOwnersController' => 'applications/owners/controller/PhabricatorOwnersController.php',
'PhabricatorOwnersDAO' => 'applications/owners/storage/PhabricatorOwnersDAO.php',
'PhabricatorOwnersDeleteController' => 'applications/owners/controller/PhabricatorOwnersDeleteController.php',
'PhabricatorOwnersDetailController' => 'applications/owners/controller/PhabricatorOwnersDetailController.php',
'PhabricatorOwnersEditController' => 'applications/owners/controller/PhabricatorOwnersEditController.php',
'PhabricatorOwnersListController' => 'applications/owners/controller/PhabricatorOwnersListController.php',
'PhabricatorOwnersOwner' => 'applications/owners/storage/PhabricatorOwnersOwner.php',
'PhabricatorOwnersPackage' => 'applications/owners/storage/PhabricatorOwnersPackage.php',
Track path moves in Owner's packages Summary: Currently, if a package is moved from one location to another those package paths become stale in Owner's packages. This diff fixes that by tracking the path moves in diffusion commit messages and updating the owners package paths accordingly. Test Plan: Tested the script by running the reparse.php script on the following test commits: https://phabricator.fb.com/rPHGITd7271a2de212e0b2de33d485b2ff806e75f73d36 https://phabricator.fb.com/rPHGIT0192fb41e7bd3e0faeeb14facdc7f7bea1b716d0 on the following packages: https://phabricator.fb.com/owners/package/1167/ https://phabricator.fb.com/owners/package/1168/ Reviewers: nh Reviewed By: nh CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D3985
2012-11-19 21:53:41 +01:00
'PhabricatorOwnersPackagePathValidator' => 'applications/repository/worker/commitchangeparser/PhabricatorOwnersPackagePathValidator.php',
Add PhabricatorOwnersPackageQuery Summary: This is a step toward unearthing Project queries enough that I can make them policy-aware. Right now, some ProjectQuery callsites do not have reasonable access to the viewer. In particular, Owners packages need to issue Project queries because we allow projects to own packages and resolve project members inside of some package queries. Currently, we have a very unmodern approach to querying packages, with a large number of one-off static load methods: PhabricatorOwnersPackage::loadAffectedPackages() PhabricatorOwnersPackage::loadOwningPackages() PhabricatorOwnersPackage::loadPackagesForPaths() PhabricatorOwnersOwner::loadAllForPackages() PhabricatorOwnersOwner::loadAffiliatedUserPHIDs() PhabricatorOwnersOwner::loadAffiliatedPackages() ConduitAPI_owners_query_Method::queryAll() ConduitAPI_owners_query_Method::queryByOwner() ConduitAPI_owners_query_Method::queryByAffiliatedUser() ConduitAPI_owners_query_Method::queryByPath() We should replace `PhabricatorOwnersOwner` with an Edge and move all of these calls to a Query class. I'm going to try to do as little of this work as I can for now since I'm much more interested in getting a functional policy implementation into other applications, but ProjectQuery needs to be policy-aware before I can do that and I need to dig some at least some of the callsites out enough that I can get a viewer in there without making the code worse than it is. This adds a PhabricatorOwnersPackageQuery class and removes one callsite of one of those static methods. I also intend to dissolve the two separate concepts of an "owner" (direct owner) and an "affiliated user" (indirect owner via project membership) since I think we're always fine with "affiliated users" owners. Test Plan: Loaded home page / audit tool, which use the modified path. Ran queries manually via script. Made sure results included directly owned packages and packages owned through project membership. Reviewers: vrana, btrahan, meitros Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3193
2012-08-08 21:25:11 +02:00
'PhabricatorOwnersPackageQuery' => 'applications/owners/query/PhabricatorOwnersPackageQuery.php',
Allow excluding paths from package Summary: Resolves T2149. Test Plan: $ bin/storage upgrade # /owners/ - saw + # /owners/package/1/ - saw + # /owners/edit/1/ - added exclude paths, saw correct e-mail # /rPabc123 - included paths are still highlighted and excluded not # /owners/view/search/?path=/included/ - found # /owners/view/search/?path=/excluded/ - not found # owners.query - path: /included/ # owners.query - path: /excluded/ # new unit test PhabricatorOwnersPackage::loadAffectedPackages( $repository, array('/excluded/b.php')); PhabricatorOwnersPackage::loadAffectedPackages( $repository, array('/included/a.php')); Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2149 Differential Revision: https://secure.phabricator.com/D4102
2012-12-07 02:23:56 +01:00
'PhabricatorOwnersPackageTestCase' => 'applications/owners/storage/__tests__/PhabricatorOwnersPackageTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOwnersPath' => 'applications/owners/storage/PhabricatorOwnersPath.php',
PHD Options. Test Plan: Looked at the options render properly. Reviewers: epriestley, btrahan, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4367
2013-01-09 15:05:34 +01:00
'PhabricatorPHDConfigOptions' => 'applications/config/option/PhabricatorPHDConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPHID' => 'applications/phid/storage/PhabricatorPHID.php',
Formalize phid.external-loaders Test Plan: /config/issue/ Reviewers: edward, codeblock, epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4516
2013-01-19 19:20:22 +01:00
'PhabricatorPHIDConfigOptions' => 'applications/phid/config/PhabricatorPHIDConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPHIDConstants' => 'applications/phid/PhabricatorPHIDConstants.php',
'PhabricatorPHIDController' => 'applications/phid/controller/PhabricatorPHIDController.php',
'PhabricatorPHIDLookupController' => 'applications/phid/controller/PhabricatorPHIDLookupController.php',
Bring PHPMailer config into the new config UI Summary: Port PHPMailer options. Also: - Don't show values on config lists if they're masked (this is mostly for passwords, to prevent them from being idly/accidentally disclosed). - Don't show "default" icon -- just show an icon if the value has been customized. This makes it easier to pick out custom values. Test Plan: Looked at / edited mailer values. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4441
2013-01-15 21:03:44 +01:00
'PhabricatorPHPMailerConfigOptions' => 'applications/config/option/PhabricatorPHPMailerConfigOptions.php',
Add a basic multipage form Summary: Ref T2232. Very busy day on IRC so I feel like I've made 20 minutes of progress in 1-minute spurts here, but this adds the basics for a form that can have multiple pages and automatically handle pagination and reading to/from the request, objects and responses. The UIExample is reasonably instructive. Basically, you make a form, add pages to the form, and add controls to the pages. The core flow control looks like this: if ($request->isFormPost()) { $form->readFromRequest($request); // (1) if ($form->isComplete()) { // (2) $response = $form->writeToResponse($response); // (3) // Process result here. // (4) } } else { $form->readFromObject($object); // (5) } The key parts are: # This reads the form state from the request, including reading all the inactive pages. # This tests if all pages are valid and the user just clicked "Done" on the last page. # This produces a "response", which might be writing to an object (for simpler forms) or creating a transaction record (for more complex forms). # Here, we would save the object or apply the transactions. # When the user views the form for the first time, we preload all the values from some object (which might just be empty). Ultimate goal here is to fix repository creation to not be a terrible pit of awfulness. There are probably a lot of rough edges and missing features still, but this seems to not be totally crazy. I'm using two submit buttons with different names which doesn't work on IE7 or something, but we can JS our way out of that if we need to. Test Plan: Paged forward and backward through the form. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2232 Differential Revision: https://secure.phabricator.com/D6003
2013-05-23 23:39:01 +02:00
'PhabricatorPagedFormExample' => 'applications/uiexample/examples/PhabricatorPagedFormExample.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPaste' => 'applications/paste/storage/PhabricatorPaste.php',
'PhabricatorPasteController' => 'applications/paste/controller/PhabricatorPasteController.php',
'PhabricatorPasteDAO' => 'applications/paste/storage/PhabricatorPasteDAO.php',
Split paste create/edit and list views Summary: We have this hybrid "create / last few pastes" landing screen right now but I ~never use the list at the bottom and it makes the controller kind of complicated. I want to let you edit pastes too, and this generally simplifies things. Also makes the textarea monospaced and cleans up the fork logic a bit. Test Plan: Created, forked pastes. Viewed paste lists. Viewed pastes. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1690 Differential Revision: https://secure.phabricator.com/D3375
2012-08-24 22:19:14 +02:00
'PhabricatorPasteEditController' => 'applications/paste/controller/PhabricatorPasteEditController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPasteListController' => 'applications/paste/controller/PhabricatorPasteListController.php',
'PhabricatorPasteQuery' => 'applications/paste/query/PhabricatorPasteQuery.php',
Pre-prepare for hovercards Summary: D5120 and followups refactor and generalize object references in Remarkup -- notably, they move remarkup rules from a central location to the implementing applications. Preserve blame by doing moves/renames only first. This change moves application remarkup rules into those applications, and renames the ones D5120 modifies. Test Plan: Typed some preview text into a textarea, got a valid Remarkup render. Reviewers: vrana, chad Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5123
2013-02-26 23:57:41 +01:00
'PhabricatorPasteRemarkupRule' => 'applications/paste/remarkup/PhabricatorPasteRemarkupRule.php',
Move paste search to generic search. Summary: Begin implementing generic application search and refactoring paste search. Test Plan: See if the paste search still works. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5621
2013-04-14 15:53:20 +02:00
'PhabricatorPasteSearchEngine' => 'applications/paste/query/PhabricatorPasteSearchEngine.php',
Completed Paste Generation Summary: Ref T2903 Test Plan: Pastes being generated with all types of parents, view policies, code, etc. Reviewers: epriestley, AnhNhan Reviewed By: epriestley CC: AnhNhan, aran, Korvin Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5707
2013-04-29 21:10:53 +02:00
'PhabricatorPasteTestDataGenerator' => 'applications/paste/lipsum/PhabricatorPasteTestDataGenerator.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPasteViewController' => 'applications/paste/controller/PhabricatorPasteViewController.php',
'PhabricatorPeopleController' => 'applications/people/controller/PhabricatorPeopleController.php',
'PhabricatorPeopleEditController' => 'applications/people/controller/PhabricatorPeopleEditController.php',
Adding hovercard event listeners for Users, Revisions, Conpherence and Commits Summary: Refs T1048 Adding Differential Hovercard EventListener Adding People Hovercard EventListener Adding basic Diffusion hovercard Adding Conpherence Hovercard EventListener Test Plan: Used in a combo with working hovercards. So beautiful. Also visited test page. Works alright. awesometown Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1048 Differential Revision: https://secure.phabricator.com/D5576
2013-04-06 02:01:54 +02:00
'PhabricatorPeopleHovercardEventListener' => 'applications/people/event/PhabricatorPeopleHovercardEventListener.php',
Added ldap import controller
2012-07-04 04:10:38 +02:00
'PhabricatorPeopleLdapController' => 'applications/people/controller/PhabricatorPeopleLdapController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPeopleListController' => 'applications/people/controller/PhabricatorPeopleListController.php',
'PhabricatorPeopleLogsController' => 'applications/people/controller/PhabricatorPeopleLogsController.php',
'PhabricatorPeopleProfileController' => 'applications/people/controller/PhabricatorPeopleProfileController.php',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
'PhabricatorPeopleProfileEditController' => 'applications/people/controller/PhabricatorPeopleProfileEditController.php',
Implement ApplicationSearch in People Summary: Ref T2625. Fixes T2812. Implement ApplicationSearch in People. {F44788} Test Plan: Made People queries. Used Conduit. Used `@mentions`. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2625, T2812 Differential Revision: https://secure.phabricator.com/D6092
2013-05-31 19:51:20 +02:00
'PhabricatorPeopleQuery' => 'applications/people/query/PhabricatorPeopleQuery.php',
'PhabricatorPeopleSearchEngine' => 'applications/people/query/PhabricatorPeopleSearchEngine.php',
Successfully Generated People Summary: Ref T2903 Test Plan: Added new person whose profile was visible afterwards. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan, btrahan Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5682
2013-04-15 04:09:20 +02:00
'PhabricatorPeopleTestDataGenerator' => 'applications/people/lipsum/PhabricatorPeopleTestDataGenerator.php',
OAuth options. Test Plan: Looked at the options. Reviewers: epriestley, btrahan, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4470
2013-01-16 19:00:51 +01:00
'PhabricatorPhabricatorOAuthConfigOptions' => 'applications/config/option/PhabricatorPhabricatorOAuthConfigOptions.php',
Move Phame config into config options Summary: so much work Test Plan: clicky clicky Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4448
2013-01-16 00:36:49 +01:00
'PhabricatorPhameConfigOptions' => 'applications/phame/config/PhabricatorPhameConfigOptions.php',
MetaMTA: Owners, Pholio, Macro Summary: Port MetaMTA options for Owners, Pholio and Macro. At some point I'd like to get rid of all these options (provide one "reply domain", and not allow overrides of reply handlers -- use events instead) but that's a battle we can fight later. Test Plan: Looked at options, looked at setup issues, edited something. Reviewers: codeblock, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4469
2013-01-16 19:52:30 +01:00
'PhabricatorPholioConfigOptions' => 'applications/pholio/config/PhabricatorPholioConfigOptions.php',
Parse VCS revert langauge in commit messages Summary: Ref T1751. When commit messages include language like "reverts X", parse it. This change doesn't do anything with the commits yet. I attempted to cover all "natural" VCS messages and all reasonable human variations of these messages. Test Plan: Added unit tests. Added `var_dump()` and used `scripts/repository/reparse.php --message X` to reparse some commit messages, with expected results. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1751 Differential Revision: https://secure.phabricator.com/D5840
2013-05-06 21:33:37 +02:00
'PhabricatorPholioMockTestDataGenerator' => 'applications/pholio/lipsum/PhabricatorPholioMockTestDataGenerator.php',
Implement Balanced Payments as a PhortunePaymentProvider Summary: Allows Balanced payment methods to be added. This works essentially the same way as Stripe, except everything is a little bit different. Slightly more stuff could be shared, but I feel //mostly// good about this. I'll probably do a bit more cleanup next. Some of the error handling is messy, in particular. Ref T2787. Test Plan: Added Balanced and Stripe payment methods. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5765
2013-04-25 18:48:04 +02:00
'PhabricatorPhortuneConfigOptions' => 'applications/phortune/option/PhabricatorPhortuneConfigOptions.php',
Implemented Phrequent time tracking functionality. Summary: This differential implements Phrequent's time tracking functionality for users and hooks it up to Maniphest. It also includes a basic "Time Tracked" list for the Phrequent application, where users can review what they've spent time working on. Test Plan: Apply the patch and track some things in Maniphest. They should appear in the "Time Tracked" view of Phrequent. There is also a `phrequent.show-prompt` option which toggles whether to display a prompt when tracking time. I'm unsure of whether the prompt is useful or is more likely to cause people to click "Track Time", go off and do the task and then come back to the prompt still waiting for them to confirm. A potential solution to the "accidentally clicking the button and recording 2 seconds of time" might be to show a prompt on stop if the total time is under 10 seconds, asking whether the user wants to keep or discard the tracked time. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2857 Differential Revision: https://secure.phabricator.com/D5479
2013-03-30 17:32:29 +01:00
'PhabricatorPhrequentConfigOptions' => 'applications/phrequent/config/PhabricatorPhrequentConfigOptions.php',
Phriction setting. Summary: One setting. Test Plan: - Looked at the setting in the web interface. - Waved to it - Introduced myself - Had a nice conversation - Made a new friend - Turns out `phriction.enabled` is a nice guy. Reviewers: epriestley, chad Reviewed By: chad CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4436
2013-01-15 15:31:53 +01:00
'PhabricatorPhrictionConfigOptions' => 'applications/phriction/config/PhabricatorPhrictionConfigOptions.php',
Use a "pinboard" UI to display image macros Summary: Moves toward unblocking D3547. Use a pinboard/album view to show image macros. Modernize and make (mostly) responsive. Test Plan: Will attach screenshots. Reviewers: btrahan, vrana, chad, teisenbe Reviewed By: vrana CC: aran Maniphest Tasks: T175 Differential Revision: https://secure.phabricator.com/D3576
2012-10-01 23:06:00 +02:00
'PhabricatorPinboardItemView' => 'view/layout/PhabricatorPinboardItemView.php',
'PhabricatorPinboardView' => 'view/layout/PhabricatorPinboardView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPolicies' => 'applications/policy/constants/PhabricatorPolicies.php',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorPolicy' => 'applications/policy/filter/PhabricatorPolicy.php',
'PhabricatorPolicyAwareQuery' => 'infrastructure/query/policy/PhabricatorPolicyAwareQuery.php',
'PhabricatorPolicyAwareTestQuery' => 'applications/policy/__tests__/PhabricatorPolicyAwareTestQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPolicyCapability' => 'applications/policy/constants/PhabricatorPolicyCapability.php',
Add Policy options. Test Plan: Looked at the setting and available options from the dropdown. Reviewers: epriestley, chad Reviewed By: chad CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4354
2013-01-07 21:47:26 +01:00
'PhabricatorPolicyConfigOptions' => 'applications/config/option/PhabricatorPolicyConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPolicyConstants' => 'applications/policy/constants/PhabricatorPolicyConstants.php',
'PhabricatorPolicyException' => 'applications/policy/exception/PhabricatorPolicyException.php',
'PhabricatorPolicyFilter' => 'applications/policy/filter/PhabricatorPolicyFilter.php',
'PhabricatorPolicyInterface' => 'applications/policy/interface/PhabricatorPolicyInterface.php',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorPolicyQuery' => 'applications/policy/query/PhabricatorPolicyQuery.php',
Move policy tests back into policy/ Summary: These were in an unusual location, but are better back in policy/ Test Plan: implicit arc unit Reviewers: vrana Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2638
2012-06-01 21:39:29 +02:00
'PhabricatorPolicyTestCase' => 'applications/policy/__tests__/PhabricatorPolicyTestCase.php',
'PhabricatorPolicyTestObject' => 'applications/policy/__tests__/PhabricatorPolicyTestObject.php',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorPolicyType' => 'applications/policy/constants/PhabricatorPolicyType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProfileHeaderView' => 'view/layout/PhabricatorProfileHeaderView.php',
'PhabricatorProject' => 'applications/project/storage/PhabricatorProject.php',
'PhabricatorProjectConstants' => 'applications/project/constants/PhabricatorProjectConstants.php',
'PhabricatorProjectController' => 'applications/project/controller/PhabricatorProjectController.php',
'PhabricatorProjectCreateController' => 'applications/project/controller/PhabricatorProjectCreateController.php',
'PhabricatorProjectDAO' => 'applications/project/storage/PhabricatorProjectDAO.php',
'PhabricatorProjectEditor' => 'applications/project/editor/PhabricatorProjectEditor.php',
Add project join/leave tests Summary: Add test coverage for joining and leaving projects. Test Plan: Ran tests. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3220
2012-08-11 16:05:20 +02:00
'PhabricatorProjectEditorTestCase' => 'applications/project/editor/__tests__/PhabricatorProjectEditorTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProjectListController' => 'applications/project/controller/PhabricatorProjectListController.php',
Make project membership edits use transactions and PHIDs and not be awful Summary: - Split project profile editing apart from project membership editing. - Make project membership editing simpler and easier to use. - Drop role / owner stuff from the UI. Test Plan: Added and removed project members. Edited project profile information. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3184
2012-08-07 20:57:38 +02:00
'PhabricatorProjectMembersEditController' => 'applications/project/controller/PhabricatorProjectMembersEditController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProjectNameCollisionException' => 'applications/project/exception/PhabricatorProjectNameCollisionException.php',
'PhabricatorProjectProfile' => 'applications/project/storage/PhabricatorProjectProfile.php',
'PhabricatorProjectProfileController' => 'applications/project/controller/PhabricatorProjectProfileController.php',
'PhabricatorProjectProfileEditController' => 'applications/project/controller/PhabricatorProjectProfileEditController.php',
'PhabricatorProjectQuery' => 'applications/project/query/PhabricatorProjectQuery.php',
'PhabricatorProjectStatus' => 'applications/project/constants/PhabricatorProjectStatus.php',
Finished Project Generation Summary: Progress on T2903 Test Plan: Projects are generating. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5794
2013-04-29 21:17:55 +02:00
'PhabricatorProjectTestDataGenerator' => 'applications/project/lipsum/PhabricatorProjectTestDataGenerator.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProjectTransaction' => 'applications/project/storage/PhabricatorProjectTransaction.php',
'PhabricatorProjectTransactionType' => 'applications/project/constants/PhabricatorProjectTransactionType.php',
'PhabricatorProjectUpdateController' => 'applications/project/controller/PhabricatorProjectUpdateController.php',
Allow PhabricatorPropertyListView to have associated content Summary: Some objects (like PhamePost and ManiphestTask) have a block of text/remarkup which serves as a description or core piece of content for the object. Accommodate this in PhabricatorPropertyListView. (This is primarily to let me do a reasonable first pass on this in Phame.) Test Plan: Made example, will attach screenshot. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3699
2012-10-15 23:50:53 +02:00
'PhabricatorPropertyListExample' => 'applications/uiexample/examples/PhabricatorPropertyListExample.php',
Modernize Paste Summary: - Add a PhabricatorApplication. - Make most of the views work well on tablets / phones. The actual "Create" form doesn't, but everything else is good -- need to make device-friendly form layouts before I can do the form. Test Plan: Will attach screenshots. Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3293
2012-08-15 19:45:06 +02:00
'PhabricatorPropertyListView' => 'view/layout/PhabricatorPropertyListView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorQuery' => 'infrastructure/query/PhabricatorQuery.php',
Move Recaptcha config to PHP Summary: Bring these over. Also sort the group list. Test Plan: Viewed config. Reviewers: btrahan, codeblock, chad Reviewed By: chad CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4338
2013-01-03 18:17:38 +01:00
'PhabricatorRecaptchaConfigOptions' => 'applications/config/option/PhabricatorRecaptchaConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRedirectController' => 'applications/base/controller/PhabricatorRedirectController.php',
'PhabricatorRefreshCSRFController' => 'applications/auth/controller/PhabricatorRefreshCSRFController.php',
New Registration Workflow Summary: Currently, registration and authentication are pretty messy. Two concrete problems: - The `PhabricatorLDAPRegistrationController` and `PhabricatorOAuthDefaultRegistrationController` controllers are giant copy/pastes of one another. This is really bad. - We can't practically implement OpenID because we can't reissue the authentication request. Additionally, the OAuth registration controller can be replaced wholesale by config, which is a huge API surface area and a giant mess. Broadly, the problem right now is that registration does too much: we hand it some set of indirect credentials (like OAuth tokens) and expect it to take those the entire way to a registered user. Instead, break registration into smaller steps: - User authenticates with remote service. - Phabricator pulls information (remote account ID, username, email, real name, profile picture, etc) from the remote service and saves it as `PhabricatorUserCredentials`. - Phabricator hands the `PhabricatorUserCredentials` to the registration form, which is agnostic about where they originate from: it can process LDAP credentials, OAuth credentials, plain old email credentials, HTTP basic auth credentials, etc. This doesn't do anything yet -- there is no way to create credentials objects (and no storage patch), but I wanted to get any initial feedback, especially about the event call for T2394. In particular, I think the implementation would look something like this: $profile = $event->getValue('profile') $username = $profile->getDefaultUsername(); $is_employee = is_this_a_facebook_employee($username); if (!$is_employee) { throw new Exception("You are not employed at Facebook."); } $fbid = get_fbid_for_facebook_username($username); $profile->setDefaultEmail($fbid); $profile->setCanEditUsername(false); $profile->setCanEditEmail(false); $profile->setCanEditRealName(false); $profile->setShouldVerifyEmail(true); Seem reasonable? Test Plan: N/A yet, probably fatals. Reviewers: vrana, btrahan, codeblock, chad Reviewed By: btrahan CC: aran, asherkin, nh, wez Maniphest Tasks: T1536, T2394 Differential Revision: https://secure.phabricator.com/D4647
2013-06-16 19:13:49 +02:00
'PhabricatorRegistrationProfile' => 'applications/people/storage/PhabricatorRegistrationProfile.php',
Make a PhabricatorRemarkupControl to de-duplicate code usage around adding a Remarkup reference to a TextAreaControl. Summary: ...also makes Maniphest Task Edit Controller use this when its not appropriate to upsell email. Test Plan: played around with each tool and verified the Remarkup reference was present Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1756 Differential Revision: https://secure.phabricator.com/D3468
2012-09-19 21:27:28 +02:00
'PhabricatorRemarkupControl' => 'view/form/control/PhabricatorRemarkupControl.php',
Pre-prepare for hovercards Summary: D5120 and followups refactor and generalize object references in Remarkup -- notably, they move remarkup rules from a central location to the implementing applications. Preserve blame by doing moves/renames only first. This change moves application remarkup rules into those applications, and renames the ones D5120 modifies. Test Plan: Typed some preview text into a textarea, got a valid Remarkup render. Reviewers: vrana, chad Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5123
2013-02-26 23:57:41 +01:00
'PhabricatorRemarkupRuleEmbedFile' => 'applications/files/remarkup/PhabricatorRemarkupRuleEmbedFile.php',
'PhabricatorRemarkupRuleImageMacro' => 'applications/macro/remarkup/PhabricatorRemarkupRuleImageMacro.php',
'PhabricatorRemarkupRuleMeme' => 'applications/macro/remarkup/PhabricatorRemarkupRuleMeme.php',
'PhabricatorRemarkupRuleMention' => 'applications/people/remarkup/PhabricatorRemarkupRuleMention.php',
Prepare for hovercards Summary: - Unify all the reference/embed Remarkup rules for Differential, Maniphest, Paste and Ponder. - Add rules for Pholio. - Does not yet unify Diffusion or Files (both are a bit more involved). - Prepare for hovercards. Test Plan: {F33894} Reviewers: chad, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5120
2013-02-26 23:59:31 +01:00
'PhabricatorRemarkupRuleObject' => 'infrastructure/markup/rule/PhabricatorRemarkupRuleObject.php',
Minor, move all remarkup code to src/infrastructure/markup/
2012-07-02 19:44:37 +02:00
'PhabricatorRemarkupRuleYoutube' => 'infrastructure/markup/rule/PhabricatorRemarkupRuleYoutube.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepository' => 'applications/repository/storage/PhabricatorRepository.php',
'PhabricatorRepositoryArcanistProject' => 'applications/repository/storage/PhabricatorRepositoryArcanistProject.php',
allow arcanist projects to be deleted via the ui Summary: tricky part is purging symbols at that time too. override "delete" method to get there, use transactions, etc. Test Plan: deleted an arcanist project - it worked! Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, mbishopim3 Maniphest Tasks: T1738 Differential Revision: https://secure.phabricator.com/D3613
2012-10-04 22:25:58 +02:00
'PhabricatorRepositoryArcanistProjectDeleteController' => 'applications/repository/controller/PhabricatorRepositoryArcanistProjectDeleteController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryArcanistProjectEditController' => 'applications/repository/controller/PhabricatorRepositoryArcanistProjectEditController.php',
'PhabricatorRepositoryAuditRequest' => 'applications/repository/storage/PhabricatorRepositoryAuditRequest.php',
Allow saving lint errors to database Summary: This saves lint errors to the path change of current commit. It requires pushed revision. It doesn't save difference from previous commit mentioned in T2038#comment-4 - I don't plan doing it after all, everything would be much more complicated and the amount of data saved with this approach isn't that bad. Test Plan: Applied patch, ran script, verified DB. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2038 Differential Revision: https://secure.phabricator.com/D3899
2012-11-06 08:09:36 +01:00
'PhabricatorRepositoryBranch' => 'applications/repository/storage/PhabricatorRepositoryBranch.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryCommit' => 'applications/repository/storage/PhabricatorRepositoryCommit.php',
'PhabricatorRepositoryCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/PhabricatorRepositoryCommitChangeParserWorker.php',
'PhabricatorRepositoryCommitData' => 'applications/repository/storage/PhabricatorRepositoryCommitData.php',
'PhabricatorRepositoryCommitHeraldWorker' => 'applications/repository/worker/PhabricatorRepositoryCommitHeraldWorker.php',
'PhabricatorRepositoryCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/PhabricatorRepositoryCommitMessageParserWorker.php',
'PhabricatorRepositoryCommitOwnersWorker' => 'applications/repository/worker/PhabricatorRepositoryCommitOwnersWorker.php',
'PhabricatorRepositoryCommitParserWorker' => 'applications/repository/worker/PhabricatorRepositoryCommitParserWorker.php',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorRepositoryCommitRef' => 'applications/repository/engine/PhabricatorRepositoryCommitRef.php',
Improve Search architecture Summary: The search indexing API has several problems right now: - Always runs in-process. - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it. - Being able to use the task queue will also make rebuilding indexes faster. - Instead, make the API phid-oriented. - No uniform indexing API. - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird. - Instead, provide a uniform API. - No uniform CLI. - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers. - Instead, let indexers expose documents for indexing. - Not application-oriented. - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world. - Instead, move indexers to applications and load them with SymbolLoader. Test Plan: - `bin/search index` - Indexed one revision, one task. - Indexed `--type TASK`, `--type DREV`, etc., for all types. - Indexed `--all`. - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it. - Creating users is a pain; searched for a user after indexing. - Creating commits is a pain; searched for a commit after indexing. - Mocks aren't currently loadable in the result view, so their indexing is moot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: 20after4, aran Maniphest Tasks: T1991, T2104 Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
'PhabricatorRepositoryCommitSearchIndexer' => 'applications/repository/search/PhabricatorRepositoryCommitSearchIndexer.php',
Repository option. Test Plan: Looked at the option. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4468
2013-01-16 18:35:47 +01:00
'PhabricatorRepositoryConfigOptions' => 'applications/repository/PhabricatorRepositoryConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryController' => 'applications/repository/controller/PhabricatorRepositoryController.php',
'PhabricatorRepositoryCreateController' => 'applications/repository/controller/PhabricatorRepositoryCreateController.php',
'PhabricatorRepositoryDAO' => 'applications/repository/storage/PhabricatorRepositoryDAO.php',
'PhabricatorRepositoryDeleteController' => 'applications/repository/controller/PhabricatorRepositoryDeleteController.php',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorRepositoryDiscoveryEngine' => 'applications/repository/engine/PhabricatorRepositoryDiscoveryEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryEditController' => 'applications/repository/controller/PhabricatorRepositoryEditController.php',
Begin transacitonalizing repository edits and provide a more sensible edit interface Summary: Ref T2231, T603. Plan of attack here is pretty much: - Built out a new (currently not linked in the UI) edit interface in Diffusion which is transaction-based and has a sensible layout. - Build out a new create interface based on PagedForm which dumps into the new edit interface. - Throw the old stuff away. - Everyone lives happily ever after. Test Plan: {F44163} {F44164} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D6029
2013-05-24 21:37:42 +02:00
'PhabricatorRepositoryEditor' => 'applications/repository/editor/PhabricatorRepositoryEditor.php',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorRepositoryEngine' => 'applications/repository/engine/PhabricatorRepositoryEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryGitCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/PhabricatorRepositoryGitCommitChangeParserWorker.php',
'PhabricatorRepositoryGitCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/PhabricatorRepositoryGitCommitMessageParserWorker.php',
'PhabricatorRepositoryListController' => 'applications/repository/controller/PhabricatorRepositoryListController.php',
upgrade repository delete function to full-blown workflow Summary: fancy title. really just make the delete() method aware of related objects and build a quick workflow which calls delete(). also make commit delete savvy about audit requests. Test Plan: deleted a repository per the instructions given to me in the web UI Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1416, T1958, T1372 Differential Revision: https://secure.phabricator.com/D3822
2012-10-26 01:23:41 +02:00
'PhabricatorRepositoryManagementDeleteWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementDeleteWorkflow.php',
Introduce "bin/repository" for repository management Summary: Nothing new or exciting here yet, just moving the random scripts/repositories/ things to bin/repository. Also add `repository list`. (Console stuff comes from D2841.) Test Plan: Ran `repository list`, `repository pull`, `repository discover`, `repository discover --verbose`, `repository help`. Reviewers: jungejason, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2849
2012-06-25 21:35:37 +02:00
'PhabricatorRepositoryManagementDiscoverWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementDiscoverWorkflow.php',
'PhabricatorRepositoryManagementListWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementListWorkflow.php',
'PhabricatorRepositoryManagementPullWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementPullWorkflow.php',
'PhabricatorRepositoryManagementWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementWorkflow.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryMercurialCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/PhabricatorRepositoryMercurialCommitChangeParserWorker.php',
'PhabricatorRepositoryMercurialCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/PhabricatorRepositoryMercurialCommitMessageParserWorker.php',
Make repository pulls testable Summary: Ref T2784. This moves us toward being able to test the background and Conduit pipelines for repositories. In particular: - Separate the logic for pulling repositories (`git pull`, `hg pull`) out of `PhabricatorRepositoryPullLocalDaemon` and put it in `PhabricatorRepositoryPullEngine`. This allows repositories to be pulled directly without invoking the daemons. - Add tests for the engine, including a future-looking base test case. - Add basic `PhutilDirectoryFixture`-based repositories. Next steps: # Do the same for repo discovery. # Then we can start writing tests against specific Conduit methods. Test Plan: Ran unit tests. Ran `bin/repository pull` on SVN, Hg and Git repositories. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran, nh Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5904
2013-05-13 04:05:52 +02:00
'PhabricatorRepositoryPullEngine' => 'applications/repository/engine/PhabricatorRepositoryPullEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryPullLocalDaemon' => 'applications/repository/daemon/PhabricatorRepositoryPullLocalDaemon.php',
Make Repositories partially policy-aware Summary: Small step toward repository hosting. No user-visible changes. Test Plan: Looked at repositories in Diffusion. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D4227
2012-12-19 20:07:06 +01:00
'PhabricatorRepositoryQuery' => 'applications/repository/query/PhabricatorRepositoryQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryShortcut' => 'applications/repository/storage/PhabricatorRepositoryShortcut.php',
'PhabricatorRepositorySvnCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/PhabricatorRepositorySvnCommitChangeParserWorker.php',
'PhabricatorRepositorySvnCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/PhabricatorRepositorySvnCommitMessageParserWorker.php',
'PhabricatorRepositorySymbol' => 'applications/repository/storage/PhabricatorRepositorySymbol.php',
'PhabricatorRepositoryTestCase' => 'applications/repository/storage/__tests__/PhabricatorRepositoryTestCase.php',
Begin transacitonalizing repository edits and provide a more sensible edit interface Summary: Ref T2231, T603. Plan of attack here is pretty much: - Built out a new (currently not linked in the UI) edit interface in Diffusion which is transaction-based and has a sensible layout. - Build out a new create interface based on PagedForm which dumps into the new edit interface. - Throw the old stuff away. - Everyone lives happily ever after. Test Plan: {F44163} {F44164} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D6029
2013-05-24 21:37:42 +02:00
'PhabricatorRepositoryTransaction' => 'applications/repository/storage/PhabricatorRepositoryTransaction.php',
'PhabricatorRepositoryTransactionQuery' => 'applications/repository/query/PhabricatorRepositoryTransactionQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryType' => 'applications/repository/constants/PhabricatorRepositoryType.php',
'PhabricatorS3FileStorageEngine' => 'applications/files/engine/PhabricatorS3FileStorageEngine.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'PhabricatorSQLPatchList' => 'infrastructure/storage/patch/PhabricatorSQLPatchList.php',
Implement SSHD glue and Conduit SSH endpoint Summary: - Build "sshd-auth" (for authentication) and "sshd-exec" (for command execution) binaries. These are callable by "sshd-vcs", located [[https://github.com/epriestley/sshd-vcs | in my account on GitHub]]. They are based on precursors [[https://github.com/epriestley/sshd-vcs-glue | here on GitHub]] which I deployed for TenXer about a year ago, so I have some confidence they at least basically work. - The problem this solves is that normally every user would need an account on a machine to connect to it, and/or their public keys would all need to be listed in `~/.authorized_keys`. This is a big pain in most installs. Software like Gitosis/Gitolite solve this problem by giving you an easy way to add public keys to `~/.authorized_keys`, but this is pretty gross. - Roughly, instead of looking in `~/.authorized_keys` when a user connects, the patched sshd instead runs `echo <public key> | sshd-auth`. The `sshd-auth` script looks up the public key and authorizes the matching user, if they exist. It also forces sshd to run `sshd-exec` instead of a normal shell. - `sshd-exec` receives the authenticated user and any command which was passed to ssh (like `git receive-pack`) and can route them appropriately. - Overall, this permits a single account to be set up on a server which all Phabricator users can connect to without any extra work, and which can safely execute commands and apply appropriate permissions, and disable users when they are disabled in Phabricator and all that stuff. - Build out "sshd-exec" to do more thorough checks and setup, and delegate command execution to Workflows (they now exist, and did not when I originally built this stuff). - Convert @btrahan's conduit API script into a workflow and slightly simplify it (ConduitCall did not exist at the time it was written). The next steps here on the Repository side are to implement Workflows for Git, SVN and HG wire protocols. These will mostly just proxy the protocols, but also need to enforce permissions. So the approach will basically be: - Implement workflows for stuff like `git receive-pack`. - These workflows will implement enough of the underlying protocol to determine what resource the user is trying to access, and whether they want to read or write it. - They'll then do a permissons check, and kick the user out if they don't have permission to do whatever they are trying to do. - If the user does have permission, we just proxy the rest of the transaction. Next steps on the Conduit side are more simple: - Make ConduitClient understand "ssh://" URLs. Test Plan: Ran `sshd-exec --phabricator-ssh-user epriestley conduit differential.query`, etc. This will get a more comprehensive test once I set up sshd-vcs. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T550 Differential Revision: https://secure.phabricator.com/D4229
2012-12-19 20:08:07 +01:00
'PhabricatorSSHWorkflow' => 'infrastructure/ssh/PhabricatorSSHWorkflow.php',
Move paste search to generic search. Summary: Begin implementing generic application search and refactoring paste search. Test Plan: See if the paste search still works. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5621
2013-04-14 15:53:20 +02:00
'PhabricatorSavedQuery' => 'applications/search/storage/PhabricatorSavedQuery.php',
Introduce PhabricatorSavedQueryQuery Summary: Same as D6051, but for SavedQueries instead of NamedQueries. These are POLICY_PUBLIC because you need to know the hash to access them, and because we want to let users copy/paste query URLs. Ref T2625. Test Plan: Saved a query, reused a saved query. Reviewers: btrahan, blc Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6054
2013-05-27 22:41:20 +02:00
'PhabricatorSavedQueryQuery' => 'applications/search/query/PhabricatorSavedQueryQuery.php',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorScopedEnv' => 'infrastructure/env/PhabricatorScopedEnv.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSearchAbstractDocument' => 'applications/search/index/PhabricatorSearchAbstractDocument.php',
'PhabricatorSearchAttachController' => 'applications/search/controller/PhabricatorSearchAttachController.php',
'PhabricatorSearchBaseController' => 'applications/search/controller/PhabricatorSearchBaseController.php',
Search options. Test Plan: - Looked at the new options - Saved `search.engine-selector` successfully. Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4410
2013-01-12 00:28:16 +01:00
'PhabricatorSearchConfigOptions' => 'applications/search/config/PhabricatorSearchConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSearchController' => 'applications/search/controller/PhabricatorSearchController.php',
'PhabricatorSearchDAO' => 'applications/search/storage/PhabricatorSearchDAO.php',
Allow custom queries to be deleted Summary: Ref T2625. Currently, custom saved queries can be edited but not deleted. Allow them to be deleted. Also: - Clean up an unused property in `PhabricatorPasteViewController`. - Fix an issue with left nav highlighting of builtin queries. - Improve submit behavior for edits. - Add a cancel button on edits. Test Plan: Saved, edited and deleted queries. Reviewers: btrahan, blc Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6059
2013-05-27 22:42:44 +02:00
'PhabricatorSearchDeleteController' => 'applications/search/controller/PhabricatorSearchDeleteController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSearchDocument' => 'applications/search/storage/document/PhabricatorSearchDocument.php',
'PhabricatorSearchDocumentField' => 'applications/search/storage/document/PhabricatorSearchDocumentField.php',
Improve Search architecture Summary: The search indexing API has several problems right now: - Always runs in-process. - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it. - Being able to use the task queue will also make rebuilding indexes faster. - Instead, make the API phid-oriented. - No uniform indexing API. - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird. - Instead, provide a uniform API. - No uniform CLI. - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers. - Instead, let indexers expose documents for indexing. - Not application-oriented. - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world. - Instead, move indexers to applications and load them with SymbolLoader. Test Plan: - `bin/search index` - Indexed one revision, one task. - Indexed `--type TASK`, `--type DREV`, etc., for all types. - Indexed `--all`. - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it. - Creating users is a pain; searched for a user after indexing. - Creating commits is a pain; searched for a commit after indexing. - Mocks aren't currently loadable in the result view, so their indexing is moot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: 20after4, aran Maniphest Tasks: T1991, T2104 Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
'PhabricatorSearchDocumentIndexer' => 'applications/search/index/PhabricatorSearchDocumentIndexer.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSearchDocumentRelationship' => 'applications/search/storage/document/PhabricatorSearchDocumentRelationship.php',
Make saved queries editable Summary: Ref T2625. Rename the "Name" controller to "Edit" and allow it to edit named queries. Also some UI touchups. Add an edit link to the saved query browse view. Test Plan: Created and edited named queries. Reviewers: btrahan, blc Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6056
2013-05-27 22:42:01 +02:00
'PhabricatorSearchEditController' => 'applications/search/controller/PhabricatorSearchEditController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSearchEngine' => 'applications/search/engine/PhabricatorSearchEngine.php',
'PhabricatorSearchEngineElastic' => 'applications/search/engine/PhabricatorSearchEngineElastic.php',
'PhabricatorSearchEngineMySQL' => 'applications/search/engine/PhabricatorSearchEngineMySQL.php',
'PhabricatorSearchEngineSelector' => 'applications/search/selector/PhabricatorSearchEngineSelector.php',
'PhabricatorSearchField' => 'applications/search/constants/PhabricatorSearchField.php',
Added basic hovercard controller Summary: Refs T1048; Depends on D5542, D5543, D5544 - It currently just renders multiple hovercards nicely for test purposes. More is on the way. Mode `test`: Human test chamber. Mode `retrieve`: For JS. Added so it would not clash with search key routing. badassery Test Plan: `/search/hovercard/test/?phids[hover-T4]=PHID-TASK-g5pduvwrrwvkq5gkx736&phids[hover-T2]=PHID-TASK-gta6lzaaagziavkktima` Verified the appearance of two tasks with correct rendering and correct ids Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1048 Differential Revision: https://secure.phabricator.com/D5545
2013-04-03 17:31:27 +02:00
'PhabricatorSearchHovercardController' => 'applications/search/controller/PhabricatorSearchHovercardController.php',
Improve Search architecture Summary: The search indexing API has several problems right now: - Always runs in-process. - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it. - Being able to use the task queue will also make rebuilding indexes faster. - Instead, make the API phid-oriented. - No uniform indexing API. - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird. - Instead, provide a uniform API. - No uniform CLI. - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers. - Instead, let indexers expose documents for indexing. - Not application-oriented. - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world. - Instead, move indexers to applications and load them with SymbolLoader. Test Plan: - `bin/search index` - Indexed one revision, one task. - Indexed `--type TASK`, `--type DREV`, etc., for all types. - Indexed `--all`. - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it. - Creating users is a pain; searched for a user after indexing. - Creating commits is a pain; searched for a commit after indexing. - Mocks aren't currently loadable in the result view, so their indexing is moot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: 20after4, aran Maniphest Tasks: T1991, T2104 Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
'PhabricatorSearchIndexer' => 'applications/search/index/PhabricatorSearchIndexer.php',
'PhabricatorSearchManagementIndexWorkflow' => 'applications/search/management/PhabricatorSearchManagementIndexWorkflow.php',
'PhabricatorSearchManagementWorkflow' => 'applications/search/management/PhabricatorSearchManagementWorkflow.php',
Allow named queries to be reordered by dragging Summary: Also you have to drop them. So drag, and then drop. This needs some cleanup and reconciliation/generalization with the Maniphest implementation. In particular, you can't drag things to the very top right now, and they should share more CSS and more behaviors. Test Plan: Look I alphabetized them: {F45286} Reviewers: chad Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6136
2013-06-06 01:22:27 +02:00
'PhabricatorSearchOrderController' => 'applications/search/controller/PhabricatorSearchOrderController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSearchQuery' => 'applications/search/storage/PhabricatorSearchQuery.php',
'PhabricatorSearchRelationship' => 'applications/search/constants/PhabricatorSearchRelationship.php',
'PhabricatorSearchResultView' => 'applications/search/view/PhabricatorSearchResultView.php',
'PhabricatorSearchScope' => 'applications/search/constants/PhabricatorSearchScope.php',
'PhabricatorSearchSelectController' => 'applications/search/controller/PhabricatorSearchSelectController.php',
Add the "Security" config group options. Summary: Added all the "Security" group options listed in T2255. Test Plan: - Looked at all the options. - Tested validation on `security.alternate-file-domain` Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4334
2013-01-03 14:45:23 +01:00
'PhabricatorSecurityConfigOptions' => 'applications/config/option/PhabricatorSecurityConfigOptions.php',
Bring SendGrid configuration into PHP Summary: Port more settings. Test Plan: Looked at, edited settings. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4442
2013-01-15 21:04:05 +01:00
'PhabricatorSendGridConfigOptions' => 'applications/config/option/PhabricatorSendGridConfigOptions.php',
Move Settings to a separate directory Summary: We currently have two relatively distinct applications, "People" and "Settings", living in /people/. Move settings to its own directory. This renames a couple of classes but makes no real code changes. Test Plan: Browsed /settings/, changed some settings. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569, T631 Differential Revision: https://secure.phabricator.com/D3256
2012-08-13 21:37:18 +02:00
'PhabricatorSettingsAdjustController' => 'applications/settings/controller/PhabricatorSettingsAdjustController.php',
'PhabricatorSettingsMainController' => 'applications/settings/controller/PhabricatorSettingsMainController.php',
Make settings panels more modular and modern Summary: Currently, we have a hard-coded list of settings panels. Make them a bit more modular. - Allow new settings panels to be defined by third-party code (see {D2340}, for example -- @ptarjan). - This makes the OAuth stuff more flexible for {T887} / {T1536}. - Reduce the number of hard-coded URIs in various places. Test Plan: Viewed / edited every option in every panel. Grepped for all references to these URIs. Reviewers: btrahan, vrana, ptarjan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3257
2012-08-13 21:37:26 +02:00
'PhabricatorSettingsPanel' => 'applications/settings/panel/PhabricatorSettingsPanel.php',
'PhabricatorSettingsPanelAccount' => 'applications/settings/panel/PhabricatorSettingsPanelAccount.php',
'PhabricatorSettingsPanelConduit' => 'applications/settings/panel/PhabricatorSettingsPanelConduit.php',
Conpherence - add per thread notification setting Summary: Introduces a new settings panel for Conpherence specific settings. Test Plan: started a thread with a test user, thus two participants total. Replied to conpherence, toggling notification settings in between. Verified 1 or 2 emails were sent as appropos to the current toggle. Toggled global setting and verified setting was updated in conpherences where nothing was specified. Verified setting conpherence setting overrides global setting. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2521 Differential Revision: https://secure.phabricator.com/D5391
2013-03-26 21:30:35 +01:00
'PhabricatorSettingsPanelConpherencePreferences' => 'applications/settings/panel/PhabricatorSettingsPanelConpherencePreferences.php',
Add a preference to completely disable the file tree Summary: See D4812. - This preference disables the file tree completely. - It defaults off, so users who want it will have to go turn it on. - Maybe slightly cleaner would be doing this if the tree was hidden and then ajaxing it in if you press "F", but that's complicated and I don't want to bother. - Generally, I think this element is useful to something like 5% of users and not useful to 95%. Test Plan: Enabled and disabled file tree. Looked at commits and revisions; verified they reflected the setting correctly. Reviewers: vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D4813
2013-02-05 02:00:27 +01:00
'PhabricatorSettingsPanelDiffPreferences' => 'applications/settings/panel/PhabricatorSettingsPanelDiffPreferences.php',
Make settings panels more modular and modern Summary: Currently, we have a hard-coded list of settings panels. Make them a bit more modular. - Allow new settings panels to be defined by third-party code (see {D2340}, for example -- @ptarjan). - This makes the OAuth stuff more flexible for {T887} / {T1536}. - Reduce the number of hard-coded URIs in various places. Test Plan: Viewed / edited every option in every panel. Grepped for all references to these URIs. Reviewers: btrahan, vrana, ptarjan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3257
2012-08-13 21:37:26 +02:00
'PhabricatorSettingsPanelDisplayPreferences' => 'applications/settings/panel/PhabricatorSettingsPanelDisplayPreferences.php',
'PhabricatorSettingsPanelEmailAddresses' => 'applications/settings/panel/PhabricatorSettingsPanelEmailAddresses.php',
'PhabricatorSettingsPanelEmailPreferences' => 'applications/settings/panel/PhabricatorSettingsPanelEmailPreferences.php',
Allow users to customize applicaiton tile sizes Summary: See discussion in D4438. Allows users to customize application tiles, and implements generally reasonable defaults so they hopefully won't. Sizes are "invisible" (internal only, used to hide admin apps from non-admins), "hidden" (hide by default, show after clicking "Show More Applications"), "show" (show a small square tile) and "full" (show a full-width tile with subtitle). Test Plan: Default view for a non-admin: {F29375} Adjusted settings, hidden: {F29373} Adjusted settings, shown: {F29374} Reviewers: chad, btrahan Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D4439
2013-01-16 18:00:11 +01:00
'PhabricatorSettingsPanelHomePreferences' => 'applications/settings/panel/PhabricatorSettingsPanelHomePreferences.php',
Make settings panels more modular and modern Summary: Currently, we have a hard-coded list of settings panels. Make them a bit more modular. - Allow new settings panels to be defined by third-party code (see {D2340}, for example -- @ptarjan). - This makes the OAuth stuff more flexible for {T887} / {T1536}. - Reduce the number of hard-coded URIs in various places. Test Plan: Viewed / edited every option in every panel. Grepped for all references to these URIs. Reviewers: btrahan, vrana, ptarjan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3257
2012-08-13 21:37:26 +02:00
'PhabricatorSettingsPanelLDAP' => 'applications/settings/panel/PhabricatorSettingsPanelLDAP.php',
'PhabricatorSettingsPanelOAuth' => 'applications/settings/panel/PhabricatorSettingsPanelOAuth.php',
'PhabricatorSettingsPanelPassword' => 'applications/settings/panel/PhabricatorSettingsPanelPassword.php',
'PhabricatorSettingsPanelProfile' => 'applications/settings/panel/PhabricatorSettingsPanelProfile.php',
'PhabricatorSettingsPanelSSHKeys' => 'applications/settings/panel/PhabricatorSettingsPanelSSHKeys.php',
'PhabricatorSettingsPanelSearchPreferences' => 'applications/settings/panel/PhabricatorSettingsPanelSearchPreferences.php',
Detect and raise setup warnings from within Phabricator Summary: This is basicaly a light version of D4286. The major problem with D4286 is that it's a huge leap and completely replaces the setup process in one step. Instead, I want to do this: - Add the post-setup warnings (yellow bar with "6 unresolved warnings..."). - Copy all setup checks into post-setup warnings (so every check has an old-style check and a new-style check). - Run that for a little bit and make sure it's stable. - Implement fatal post-setup checks (the red screen, vs the yellow bar). - Run that for a little bit. - Nuke setup mode and delete all the old checks. This should give us a bunch of very gradual steps toward the brave new world of simpler setup. Test Plan: - Faked APC setup failures, saw warnings raise. - Verified that this runs after restart (get + set). - Verified that this costs us only one cache hit after first-run (get only). Reviewers: btrahan, codeblock, vrana, chad Reviewed By: codeblock CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4295
2012-12-30 15:37:49 +01:00
'PhabricatorSetupCheck' => 'applications/config/check/PhabricatorSetupCheck.php',
'PhabricatorSetupCheckAPC' => 'applications/config/check/PhabricatorSetupCheckAPC.php',
Don't require phabricator.base-uri to be configured Summary: Fixes T2293. We currently hard-require this in setup. We do not need to; we don't actually need it until we start running daemons. Move it to post-install and provide more guidance. We could make this even easier in the future, but we'd need to special case it, since it's dangerous to let it be set to any value (if you set it to the wrong value, you can't log in). We could safely have a workflow which writes the current request URI into the database configuration, or a two-stage workflow where we set the URI and then verify it, but these both imply some special casing and complication. This should be a step forward from where we are today, regardless. Test Plan: Removed "phabricator.base-uri" from my configuration. Verified Phabricator still works. Without "phabricator.base-uri" configured, logged in from multiple host names (127.0.0.1:8080, local.aphront.com:8080). Configured "phabricator.base-uri". Verified my unblessed session no longer worked. Verified setup issue went away. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2293 Differential Revision: https://secure.phabricator.com/D4580
2013-01-22 22:57:02 +01:00
'PhabricatorSetupCheckBaseURI' => 'applications/config/check/PhabricatorSetupCheckBaseURI.php',
Add setup checks for the availability of 'which' and 'diff' binaries Summary: Spent an hour or two helping a user figure this out. Make sure I never do that again. If the webserver is configured with an empty or bogus PATH, binaries like 'which' and 'diff' (and 'git', and 'svn', etc.) may not be available. In most cases, this is fine, because we get an error like "sh: whatever-command not found", which is obvious to diagnose. In the case of 'diff', we don't get this, because 'diff' is expected to exit with a nonzero code for differing files -- so we interpret the "sh: whatever-command not found" as "files differ" and then try to parse the empty output. Explicitly check for 'which' (on Windows, 'where') and 'diff' during setup (I plan to refine the behavior around 'git', 'svn' and 'hg' at some point, but this is less pressing since the errors are trivial to support). Test Plan: Faked failures on all modes, verified setup warnings look reasonable. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6008
2013-05-23 23:42:07 +02:00
'PhabricatorSetupCheckBinaries' => 'applications/config/check/PhabricatorSetupCheckBinaries.php',
Move database configuration into new-style setup checks Summary: Port the database checks over. Test Plan: Triggered all the checks via intentional misconfiguration. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4590
2013-01-23 01:16:24 +01:00
'PhabricatorSetupCheckDatabase' => 'applications/config/check/PhabricatorSetupCheckDatabase.php',
Port extension checks to new-style setup Summary: - Allow new-style setup to raise fatal setup errors. - Port extension checks to new-style setup as fatal errors. - When fatal errors are raised, abort setup and show them in a chrome-free response. Test Plan: {F29981} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4587
2013-01-23 00:16:26 +01:00
'PhabricatorSetupCheckExtensions' => 'applications/config/check/PhabricatorSetupCheckExtensions.php',
Add "Developer" and "Access Log" config option groups, some types Summary: - Add a "developer" option group. - Add an "access log" option group. - Render the types "bool", "int" and "string" in a more tailored way. - Add a config check for dead config. Right now this serves as a "TODO" list of things that need to be migrated. Test Plan: Looked at config options, setup issues. Edited bool, int, string options. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4308
2013-01-01 23:09:17 +01:00
'PhabricatorSetupCheckExtraConfig' => 'applications/config/check/PhabricatorSetupCheckExtraConfig.php',
Move Facebook setup checks to post-install Summary: Technically we should have these for all the OAuth providers but I don't think anyone really has trouble with them and it can probably be done generically after T1536. Preserve the functionality, at least. Test Plan: Broke my config, verified warnings appeared. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4506
2013-01-19 17:42:15 +01:00
'PhabricatorSetupCheckFacebook' => 'applications/config/check/PhabricatorSetupCheckFacebook.php',
Add a setup warning about missing 'fileinfo' Summary: See <https://github.com/facebook/phabricator/issues/320>. We have a soft dependency on 'fileinfo', which we try to recover from (with `file`) but won't be able to on Windows and apparently FreeBSD systems. Since users can ignore setup checks anyway now, just raise a warning during install. I believe almost all installs should have this extension, it has been part of the core for a long time. Test Plan: Faked setup failure, looked at warning. "Solved" setup failure, saw it go away. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5952
2013-05-17 19:00:40 +02:00
'PhabricatorSetupCheckFileinfo' => 'applications/config/check/PhabricatorSetupCheckFileinfo.php',
Migrate `max_allowed_packet` and GD checks to new setup stuff Summary: These are nonblocking warnings and can move to post-install. Test Plan: Broke my environment and observed the warnings. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran, asherkin Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4505
2013-01-19 17:41:45 +01:00
'PhabricatorSetupCheckGD' => 'applications/config/check/PhabricatorSetupCheckGD.php',
Preserving the Animation of Gif Images Summary: Preserving animation of GIF profile Pictures Test Plan: Uploaded Animated images as profile pictures to check if the animation of gif images is preserved and it does :) somewhat ! Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4833
2013-02-08 18:14:28 +01:00
'PhabricatorSetupCheckImagemagick' => 'applications/config/check/PhabricatorSetupCheckImagemagick.php',
Allow configuration to be explicitly validated, including validation of complex attributes Summary: - Allows us to implement setup warnings for edits which don't go through the web UI, e.g. "you edited a config file and set value X to something goofy". - Allows us to implement more sophisticated validations, beyond basic type checks (e.g., "phabricator.base-uri" must be a URI). - Fixes T358 (or, close enough -- fixes it for all options which have been migrated as per T2255. Test Plan: Set "darkconsole.enabled" to "xyz" in my config, observed setup warning. Added fake validation, observed web UI edit error. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255, T358 Differential Revision: https://secure.phabricator.com/D4315
2013-01-02 03:15:03 +01:00
'PhabricatorSetupCheckInvalidConfig' => 'applications/config/check/PhabricatorSetupCheckInvalidConfig.php',
Move mail-related setup issues to setup checks Summary: Ports mail stuff from the existing setup process to the more modular setup checks. Test Plan: Configured my local install to have all these errors, verified setup raised them. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4494
2013-01-18 22:28:30 +01:00
'PhabricatorSetupCheckMail' => 'applications/config/check/PhabricatorSetupCheckMail.php',
Migrate `max_allowed_packet` and GD checks to new setup stuff Summary: These are nonblocking warnings and can move to post-install. Test Plan: Broke my environment and observed the warnings. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran, asherkin Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4505
2013-01-19 17:41:45 +01:00
'PhabricatorSetupCheckMySQL' => 'applications/config/check/PhabricatorSetupCheckMySQL.php',
Move open_basedir and safe_mode checks into new setup Summary: Newer and shinier! Test Plan: Intentionally misconfigured myself into all three setup failures (safe_mode, open_basedir/fatal, open_basedir/nonfatal). Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4589
2013-01-23 01:15:54 +01:00
'PhabricatorSetupCheckPHPConfig' => 'applications/config/check/PhabricatorSetupCheckPHPConfig.php',
Move PATH checks to post-install Summary: We no longer need to do PHP CLI checks (D4568) or run `git submodule` (D4581) so we don't need $PATH to be set to complete setup. Move it to post-install. Drop the instructions about PHP-FPM because the Phabricator config is dramatically easier now that we have it. Test Plan: Set environment.append-paths to various things, faked lack of $PATH, verified I got the warning when I expected to setting Phabricator config cleared it. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4585
2013-01-22 23:45:19 +01:00
'PhabricatorSetupCheckPath' => 'applications/config/check/PhabricatorSetupCheckPath.php',
Phabricator now checks whether pygmentize script can be run when user enables pygments Summary: Check if pygmentize is runnable if pygments is enabled Test Plan: Enable pygments with pygmentize unavailable in path Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5157
2013-02-28 18:17:01 +01:00
'PhabricatorSetupCheckPygment' => 'applications/config/check/PhabricatorSetupCheckPygment.php',
Migrate local disk storage setup check Summary: Migrate to the new hotness. Also: - Remove a string test, which is now impossible since the config will repair itself and raise a type error. - Restore the header even in /config/ -- this check is kind of hacky and it feels a bit more natural now that it's above the menu. Test Plan: Set my local disk path to something invalid, verified I got a setup error. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4497
2013-01-19 17:39:27 +01:00
'PhabricatorSetupCheckStorage' => 'applications/config/check/PhabricatorSetupCheckStorage.php',
Improve resolution process for nonfatal setup issues Summary: - When a setup issue is nonfatal (i.e., a warning), instruct the user to edit the value from the web UI instead of using `bin/config`. - When the user edits configuration in response to a setup issue, send them back to the issue when they're done. - When an issue relates to PHP configuration, link to the PHP documentation on configuration. - Add new-style setup check for timezone issues. Test Plan: Mucked with my timezone config, resolved the issues I created. Reviewers: codeblock, btrahan, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221, T2228 Differential Revision: https://secure.phabricator.com/D4298
2012-12-31 02:04:38 +01:00
'PhabricatorSetupCheckTimezone' => 'applications/config/check/PhabricatorSetupCheckTimezone.php',
Detect and raise setup warnings from within Phabricator Summary: This is basicaly a light version of D4286. The major problem with D4286 is that it's a huge leap and completely replaces the setup process in one step. Instead, I want to do this: - Add the post-setup warnings (yellow bar with "6 unresolved warnings..."). - Copy all setup checks into post-setup warnings (so every check has an old-style check and a new-style check). - Run that for a little bit and make sure it's stable. - Implement fatal post-setup checks (the red screen, vs the yellow bar). - Run that for a little bit. - Nuke setup mode and delete all the old checks. This should give us a bunch of very gradual steps toward the brave new world of simpler setup. Test Plan: - Faked APC setup failures, saw warnings raise. - Verified that this runs after restart (get + set). - Verified that this costs us only one cache hit after first-run (get only). Reviewers: btrahan, codeblock, vrana, chad Reviewed By: codeblock CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4295
2012-12-30 15:37:49 +01:00
'PhabricatorSetupIssue' => 'applications/config/issue/PhabricatorSetupIssue.php',
Use phutil_tag in Setup issue stuff Summary: These are pretty straightforward, they just have a fair amount of instructional text with inline markup. Test Plan: Added and viewed a UIExample. Reviewers: vrana Reviewed By: vrana CC: aran Maniphest Tasks: T2432 Differential Revision: https://secure.phabricator.com/D4686
2013-01-29 20:29:56 +01:00
'PhabricatorSetupIssueExample' => 'applications/uiexample/examples/PhabricatorSetupIssueExample.php',
Detect and raise setup warnings from within Phabricator Summary: This is basicaly a light version of D4286. The major problem with D4286 is that it's a huge leap and completely replaces the setup process in one step. Instead, I want to do this: - Add the post-setup warnings (yellow bar with "6 unresolved warnings..."). - Copy all setup checks into post-setup warnings (so every check has an old-style check and a new-style check). - Run that for a little bit and make sure it's stable. - Implement fatal post-setup checks (the red screen, vs the yellow bar). - Run that for a little bit. - Nuke setup mode and delete all the old checks. This should give us a bunch of very gradual steps toward the brave new world of simpler setup. Test Plan: - Faked APC setup failures, saw warnings raise. - Verified that this runs after restart (get + set). - Verified that this costs us only one cache hit after first-run (get only). Reviewers: btrahan, codeblock, vrana, chad Reviewed By: codeblock CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4295
2012-12-30 15:37:49 +01:00
'PhabricatorSetupIssueView' => 'applications/config/view/PhabricatorSetupIssueView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSlowvoteChoice' => 'applications/slowvote/storage/PhabricatorSlowvoteChoice.php',
'PhabricatorSlowvoteComment' => 'applications/slowvote/storage/PhabricatorSlowvoteComment.php',
'PhabricatorSlowvoteController' => 'applications/slowvote/controller/PhabricatorSlowvoteController.php',
'PhabricatorSlowvoteCreateController' => 'applications/slowvote/controller/PhabricatorSlowvoteCreateController.php',
'PhabricatorSlowvoteDAO' => 'applications/slowvote/storage/PhabricatorSlowvoteDAO.php',
'PhabricatorSlowvoteListController' => 'applications/slowvote/controller/PhabricatorSlowvoteListController.php',
'PhabricatorSlowvoteOption' => 'applications/slowvote/storage/PhabricatorSlowvoteOption.php',
'PhabricatorSlowvotePoll' => 'applications/slowvote/storage/PhabricatorSlowvotePoll.php',
'PhabricatorSlowvotePollController' => 'applications/slowvote/controller/PhabricatorSlowvotePollController.php',
Embed slowvotes have basic interaction Summary: User can now vote through embed slowvote Test Plan: Voted'n stuff Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad, AnhNhan Maniphest Tasks: T2883 Differential Revision: https://secure.phabricator.com/D5743
2013-05-04 00:48:59 +02:00
'PhabricatorSlowvoteVoteController' => 'applications/slowvote/controller/PhabricatorSlowvoteVoteController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSlug' => 'infrastructure/util/PhabricatorSlug.php',
'PhabricatorSlugTestCase' => 'infrastructure/util/__tests__/PhabricatorSlugTestCase.php',
'PhabricatorSortTableExample' => 'applications/uiexample/examples/PhabricatorSortTableExample.php',
Modernize Paste Summary: - Add a PhabricatorApplication. - Make most of the views work well on tablets / phones. The actual "Create" form doesn't, but everything else is good -- need to make device-friendly form layouts before I can do the form. Test Plan: Will attach screenshots. Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3293
2012-08-15 19:45:06 +02:00
'PhabricatorSourceCodeView' => 'view/layout/PhabricatorSourceCodeView.php',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
'PhabricatorStandardCustomField' => 'infrastructure/customfield/field/PhabricatorStandardCustomField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorStandardPageView' => 'view/page/PhabricatorStandardPageView.php',
Add a user-accessible hook for dumping debug code into an install Summary: Currently, there's no easy way for me to tell a user "run this code from the webserver and tell me what it says". Sometimes installs can add new .php files to, e.g., `webroot/rsrc/`, but this is setup-dependent and not universal. Generally I resort to saying "put this into index.php", but that's error prone and not acceptable on active installs. Add a "debug" controller so I can instead say "put this into support/debug.php, then visit /debug/". Test Plan: Visited /debug/ with and without support/debug.php files. Visited /staus/. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5212
2013-03-04 22:45:51 +01:00
'PhabricatorStatusController' => 'applications/system/PhabricatorStatusController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorStorageFixtureScopeGuard' => 'infrastructure/testing/fixture/PhabricatorStorageFixtureScopeGuard.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'PhabricatorStorageManagementAPI' => 'infrastructure/storage/management/PhabricatorStorageManagementAPI.php',
'PhabricatorStorageManagementDatabasesWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementDatabasesWorkflow.php',
'PhabricatorStorageManagementDestroyWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementDestroyWorkflow.php',
'PhabricatorStorageManagementDumpWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementDumpWorkflow.php',
'PhabricatorStorageManagementStatusWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementStatusWorkflow.php',
'PhabricatorStorageManagementUpgradeWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementUpgradeWorkflow.php',
'PhabricatorStorageManagementWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementWorkflow.php',
'PhabricatorStoragePatch' => 'infrastructure/storage/management/PhabricatorStoragePatch.php',
Add basic "Subscriptions" application Summary: Basic infrastructure for generalizing subscriptions/CCs for T1808, T1514 and T1663. - Implement `PhabricatorSubscribableInterface` and you'll get a subscribe/unsubscribe button for free. - If there are any auto-subscribed users (like the question author) you can specify them; this makes more sense for Tasks and Revisions than Ponder probably, but maybe the author should be auto-subscribed. - Subscriptions are either "explicit" (the user clicked 'subscribe') or "implicit" (the user did something which causes them to become subscribed naturally). If a user unsubscribes, they'll no longer be added by implicit subscriptions. This may or may not be relevant to Ponder but is an existing Herald feature in Differential. - Helper method on PhabricatorSubscribersQuery to load subscribers. - This doesn't handle actually sending email, etc. I think that's all so application-specific that it doesn't belong here. - Now seems to work. Test Plan: {F20552} {F20553} Reviewers: pieter, btrahan Reviewed By: pieter CC: aran Maniphest Tasks: T1663, T1514, T1808 Differential Revision: https://secure.phabricator.com/D3637
2012-10-05 22:18:05 +02:00
'PhabricatorSubscribableInterface' => 'applications/subscriptions/interface/PhabricatorSubscribableInterface.php',
'PhabricatorSubscribersQuery' => 'applications/subscriptions/query/PhabricatorSubscribersQuery.php',
'PhabricatorSubscriptionsEditController' => 'applications/subscriptions/controller/PhabricatorSubscriptionsEditController.php',
'PhabricatorSubscriptionsEditor' => 'applications/subscriptions/editor/PhabricatorSubscriptionsEditor.php',
'PhabricatorSubscriptionsUIEventListener' => 'applications/subscriptions/events/PhabricatorSubscriptionsUIEventListener.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSymbolNameLinter' => 'infrastructure/lint/hook/PhabricatorSymbolNameLinter.php',
Minor, move all remarkup code to src/infrastructure/markup/
2012-07-02 19:44:37 +02:00
'PhabricatorSyntaxHighlighter' => 'infrastructure/markup/PhabricatorSyntaxHighlighter.php',
Add syntax highlighting options. Test Plan: Quick view of each option in the web interface. Reviewers: epriestley, btrahan, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4386
2013-01-10 18:56:36 +01:00
'PhabricatorSyntaxHighlightingConfigOptions' => 'applications/config/option/PhabricatorSyntaxHighlightingConfigOptions.php',
Build PhabricatorTagView Summary: Builds out most of the non-hover-stuff from `overview-hovercards.png`. Things I didn't build: - Tokens (I like them a lot but don't want to scope creep) - Functions (backend mess / future work) - Icons for tags. - Tags with pointy ends and holes in them (an earlier mock had this I think but they're gone on final) - The cyaney color for "Sporadic" since I just noticed it while typing this up. Test Plan: Looked at UIExample page. Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2089 Differential Revision: https://secure.phabricator.com/D4029
2012-11-24 15:47:06 +01:00
'PhabricatorTagExample' => 'applications/uiexample/examples/PhabricatorTagExample.php',
'PhabricatorTagView' => 'view/layout/PhabricatorTagView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorTaskmasterDaemon' => 'infrastructure/daemon/workers/PhabricatorTaskmasterDaemon.php',
'PhabricatorTestCase' => 'infrastructure/testing/PhabricatorTestCase.php',
Successfully Generated People Summary: Ref T2903 Test Plan: Added new person whose profile was visible afterwards. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan, btrahan Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5682
2013-04-15 04:09:20 +02:00
'PhabricatorTestDataGenerator' => 'applications/lipsum/generator/PhabricatorTestDataGenerator.php',
Make file storage more testable Summary: Fixes T2474. Adds a storage dummy storage engine for unit tests, and adds a couple of simple tests for basic file storage. Test Plan: Ran `arc unit` to execute unit tests. Reviewers: kwadwon Reviewed By: kwadwon CC: aran Maniphest Tasks: T2474 Differential Revision: https://secure.phabricator.com/D4777
2013-02-06 22:37:42 +01:00
'PhabricatorTestStorageEngine' => 'applications/files/engine/PhabricatorTestStorageEngine.php',
Factor out task execution and formalize permanent failures Summary: - Clean up a TODO about permanent failures. - Clean up a TODO about failing tasks after too many retries. - Clean up a TODO about testing for bad leases. - Make the lease/retry implementation more flexible and natural. - Make completely bogus tasks fail permanently. - Make PhabricatorMetaMTAWorker use new `getWaitBeforeRetry()` (as intended), not hackily implement logic in `getRequiredLeaseTime()`. - Document worker hooks for failures and retries. - Provide coverage on everything. Test Plan: Ran unit tests. Ran `bin/phd debug taskmaster`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3859
2012-11-01 19:30:23 +01:00
'PhabricatorTestWorker' => 'infrastructure/daemon/workers/__tests__/PhabricatorTestWorker.php',
Consolidate some datetime code and add unit tests Summary: See D6115. Test Plan: - Ran unit tests. - Viewed reports. - Created a countdown. - Searched chatlog. - Searched pastes by created date. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6116
2013-06-03 21:58:11 +02:00
'PhabricatorTime' => 'infrastructure/time/PhabricatorTime.php',
'PhabricatorTimeGuard' => 'infrastructure/time/PhabricatorTimeGuard.php',
'PhabricatorTimeTestCase' => 'infrastructure/time/__tests__/PhabricatorTimeTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorTimelineCursor' => 'infrastructure/daemon/timeline/storage/PhabricatorTimelineCursor.php',
'PhabricatorTimelineDAO' => 'infrastructure/daemon/timeline/storage/PhabricatorTimelineDAO.php',
'PhabricatorTimelineEvent' => 'infrastructure/daemon/timeline/storage/PhabricatorTimelineEvent.php',
'PhabricatorTimelineEventData' => 'infrastructure/daemon/timeline/storage/PhabricatorTimelineEventData.php',
Add basic transaction/timeline view Summary: This is still rough and not completely accurate to the mocks (and the mobile view is quite crude and mostly just "hey this technically works"), but I want to build Pholio on top of it rather than building it on something else and then swapping it out later and the API is reasonable enough. This should probably be called `PhabricatorTransactionView` but we already have one of those. I might juggle the names in a future diff. Test Plan: Desktop {F22352} Mobile {F22351} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3833
2012-11-22 02:24:56 +01:00
'PhabricatorTimelineEventView' => 'view/layout/PhabricatorTimelineEventView.php',
'PhabricatorTimelineExample' => 'applications/uiexample/examples/PhabricatorTimelineExample.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorTimelineIterator' => 'infrastructure/daemon/timeline/cursor/PhabricatorTimelineIterator.php',
Add basic transaction/timeline view Summary: This is still rough and not completely accurate to the mocks (and the mobile view is quite crude and mostly just "hey this technically works"), but I want to build Pholio on top of it rather than building it on something else and then swapping it out later and the API is reasonable enough. This should probably be called `PhabricatorTransactionView` but we already have one of those. I might juggle the names in a future diff. Test Plan: Desktop {F22352} Mobile {F22351} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3833
2012-11-22 02:24:56 +01:00
'PhabricatorTimelineView' => 'view/layout/PhabricatorTimelineView.php',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorToken' => 'applications/tokens/storage/PhabricatorToken.php',
'PhabricatorTokenController' => 'applications/tokens/controller/PhabricatorTokenController.php',
'PhabricatorTokenCount' => 'applications/tokens/storage/PhabricatorTokenCount.php',
Surface token counts for Pholio Summary: Provide this data so the list view can present it somehow. Test Plan: {F34520} Reviewers: chad Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D5210
2013-03-04 20:47:58 +01:00
'PhabricatorTokenCountQuery' => 'applications/tokens/query/PhabricatorTokenCountQuery.php',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorTokenDAO' => 'applications/tokens/storage/PhabricatorTokenDAO.php',
'PhabricatorTokenGiveController' => 'applications/tokens/controller/PhabricatorTokenGiveController.php',
'PhabricatorTokenGiven' => 'applications/tokens/storage/PhabricatorTokenGiven.php',
'PhabricatorTokenGivenController' => 'applications/tokens/controller/PhabricatorTokenGivenController.php',
'PhabricatorTokenGivenEditor' => 'applications/tokens/editor/PhabricatorTokenGivenEditor.php',
Notify users when an object they created gets awarded a token Summary: - Publish feed/notification. - I think this is too lightweight for an email? - We don't tell them which token right now. Laziness? Or intentional aura of mystery?! - For tasks, notify both author and current owner. - Fixes T2562. Test Plan: {F33187} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2562 Differential Revision: https://secure.phabricator.com/D5007
2013-02-19 02:44:45 +01:00
'PhabricatorTokenGivenFeedStory' => 'applications/tokens/feed/PhabricatorTokenGivenFeedStory.php',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorTokenGivenQuery' => 'applications/tokens/query/PhabricatorTokenGivenQuery.php',
Add basic token leader board functionality. Summary: Implement basic token leader board. No pagination yet. Test Plan: Assign some tasks tokens and check that they are displayed properly. Reviewers: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2689 Differential Revision: https://secure.phabricator.com/D5379
2013-03-22 00:04:29 +01:00
'PhabricatorTokenLeaderController' => 'applications/tokens/controller/PhabricatorTokenLeaderController.php',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorTokenQuery' => 'applications/tokens/query/PhabricatorTokenQuery.php',
'PhabricatorTokenReceiverInterface' => 'applications/tokens/interface/PhabricatorTokenReceiverInterface.php',
Add basic token leader board functionality. Summary: Implement basic token leader board. No pagination yet. Test Plan: Assign some tasks tokens and check that they are displayed properly. Reviewers: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2689 Differential Revision: https://secure.phabricator.com/D5379
2013-03-22 00:04:29 +01:00
'PhabricatorTokenReceiverQuery' => 'applications/tokens/query/PhabricatorTokenReceiverQuery.php',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorTokenUIEventListener' => 'applications/tokens/event/PhabricatorTokenUIEventListener.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorTransactionView' => 'view/layout/PhabricatorTransactionView.php',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorTransactions' => 'applications/transactions/constants/PhabricatorTransactions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorTransformedFile' => 'applications/files/storage/PhabricatorTransformedFile.php',
Use pht() Summary: This is the first step in Phabricator internationalization. It adds a translation selector and calls it at startup. Installations can add custom selectors to override some texts. We can add official translations in future. Next step is to allow user to choose his translation which will override the global one. This is currently used only for English plurals. Test Plan: Displayed a diff with unit test error, verified that it says 'Detail' or 'Details' and not 'Detail(s)'. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D2753
2012-06-14 22:43:09 +02:00
'PhabricatorTranslation' => 'infrastructure/internationalization/PhabricatorTranslation.php',
Add translations config group. Summary: Adds the translations group as per T2255. Currently `translation.override` is `wild` -- it should be changed to dict<string, string> when that exists. Also fixes a small bug from D4326 which caused "class" types to not ever validate. Test Plan: - Looked at the settings. - Successfully saved a setting relating to classes. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4350
2013-01-05 01:22:52 +01:00
'PhabricatorTranslationsConfigOptions' => 'applications/config/option/PhabricatorTranslationsConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorTrivialTestCase' => 'infrastructure/testing/__tests__/PhabricatorTrivialTestCase.php',
Apront Two Column View Summary: Wanted to pull this out in case we don't use it in Maniphest, still useful perhaps in the future. Creates a sidebar that wraps when on mobile. Test Plan: Tested UIExample Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5321
2013-03-11 03:20:01 +01:00
'PhabricatorTwoColumnExample' => 'applications/uiexample/examples/PhabricatorTwoColumnExample.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorTypeaheadCommonDatasourceController' => 'applications/typeahead/controller/PhabricatorTypeaheadCommonDatasourceController.php',
'PhabricatorTypeaheadDatasourceController' => 'applications/typeahead/controller/PhabricatorTypeaheadDatasourceController.php',
Make typeahead results more structured Summary: Get rid of this positional array garbage. Test Plan: Used typeaheads in menu, herald, maniphest, differential, repository/projects. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3116
2012-08-01 21:36:19 +02:00
'PhabricatorTypeaheadResult' => 'applications/typeahead/storage/PhabricatorTypeaheadResult.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUIExample' => 'applications/uiexample/examples/PhabricatorUIExample.php',
'PhabricatorUIExampleRenderController' => 'applications/uiexample/controller/PhabricatorUIExampleRenderController.php',
'PhabricatorUIListFilterExample' => 'applications/uiexample/examples/PhabricatorUIListFilterExample.php',
Add a basic notification UI element Summary: This is //extremely// basic but dead simple and should cover us for v1, I think. Let me know what features you need. Test Plan: Used UI example page. Reviewers: allenjohnashton, ddfisher, keebuhm Reviewed By: ddfisher CC: aran, ender Maniphest Tasks: T944 Differential Revision: https://secure.phabricator.com/D2732
2012-06-14 00:00:24 +02:00
'PhabricatorUINotificationExample' => 'applications/uiexample/examples/PhabricatorUINotificationExample.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUIPagerExample' => 'applications/uiexample/examples/PhabricatorUIPagerExample.php',
'PhabricatorUITooltipExample' => 'applications/uiexample/examples/PhabricatorUITooltipExample.php',
'PhabricatorUnitsTestCase' => 'view/__tests__/PhabricatorUnitsTestCase.php',
'PhabricatorUser' => 'applications/people/storage/PhabricatorUser.php',
Add "Title" and "Blurb" to new profile editor Summary: Ref T1703. - Adds "Title". - Adds "Blurb". - Adds `user.fields` config for selecting and reordering. This will get UI in the next patch. Test Plan: {F45689} {F45690} Edited the fields, too. Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6153
2013-06-07 19:22:45 +02:00
'PhabricatorUserBlurbField' => 'applications/people/customfield/PhabricatorUserBlurbField.php',
'PhabricatorUserConfigOptions' => 'applications/people/config/PhabricatorUserConfigOptions.php',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
'PhabricatorUserCustomField' => 'applications/people/customfield/PhabricatorUserCustomField.php',
'PhabricatorUserCustomFieldInterface' => 'applications/people/customfield/PhabricatorUserCustomFieldInterface.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUserDAO' => 'applications/people/storage/PhabricatorUserDAO.php',
Flesh out ApplicationTransactions/CustomField integration Summary: None of this code is reachable yet. See discussion in D6147. Ref T1703. Provide tighter integration between ApplicationTransactions and CustomField. Basically, I'm just trying to get all the shared stuff into the base implementation. Test Plan: Code not reachable. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6149
2013-06-06 23:53:07 +02:00
'PhabricatorUserEditor' => 'applications/people/editor/PhabricatorUserEditor.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUserEmail' => 'applications/people/storage/PhabricatorUserEmail.php',
'PhabricatorUserLog' => 'applications/people/storage/PhabricatorUserLog.php',
'PhabricatorUserOAuthInfo' => 'applications/people/storage/PhabricatorUserOAuthInfo.php',
Move Settings to a separate directory Summary: We currently have two relatively distinct applications, "People" and "Settings", living in /people/. Move settings to its own directory. This renames a couple of classes but makes no real code changes. Test Plan: Browsed /settings/, changed some settings. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569, T631 Differential Revision: https://secure.phabricator.com/D3256
2012-08-13 21:37:18 +02:00
'PhabricatorUserPreferences' => 'applications/settings/storage/PhabricatorUserPreferences.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUserProfile' => 'applications/people/storage/PhabricatorUserProfile.php',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
'PhabricatorUserProfileEditor' => 'applications/people/editor/PhabricatorUserProfileEditor.php',
'PhabricatorUserRealNameField' => 'applications/people/customfield/PhabricatorUserRealNameField.php',
Move Settings to a separate directory Summary: We currently have two relatively distinct applications, "People" and "Settings", living in /people/. Move settings to its own directory. This renames a couple of classes but makes no real code changes. Test Plan: Browsed /settings/, changed some settings. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569, T631 Differential Revision: https://secure.phabricator.com/D3256
2012-08-13 21:37:18 +02:00
'PhabricatorUserSSHKey' => 'applications/settings/storage/PhabricatorUserSSHKey.php',
Improve Search architecture Summary: The search indexing API has several problems right now: - Always runs in-process. - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it. - Being able to use the task queue will also make rebuilding indexes faster. - Instead, make the API phid-oriented. - No uniform indexing API. - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird. - Instead, provide a uniform API. - No uniform CLI. - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers. - Instead, let indexers expose documents for indexing. - Not application-oriented. - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world. - Instead, move indexers to applications and load them with SymbolLoader. Test Plan: - `bin/search index` - Indexed one revision, one task. - Indexed `--type TASK`, `--type DREV`, etc., for all types. - Indexed `--all`. - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it. - Creating users is a pain; searched for a user after indexing. - Creating commits is a pain; searched for a commit after indexing. - Mocks aren't currently loadable in the result view, so their indexing is moot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: 20after4, aran Maniphest Tasks: T1991, T2104 Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
'PhabricatorUserSearchIndexer' => 'applications/people/search/PhabricatorUserSearchIndexer.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUserStatus' => 'applications/people/storage/PhabricatorUserStatus.php',
Create a status tool by giving /calendar/ some teeth Summary: you can now add, edit, and delete status events. also added a "description" to status events and surface it in the big calendar view on mouse hover. some refactoring changes as well to make validation logic centralized within the storage class. Test Plan: added, edited, deleted. yay. Reviewers: epriestley, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T407 Differential Revision: https://secure.phabricator.com/D3810
2012-10-24 22:22:24 +02:00
'PhabricatorUserStatusInvalidEpochException' => 'applications/people/exception/PhabricatorUserStatusInvalidEpochException.php',
'PhabricatorUserStatusOverlapException' => 'applications/people/exception/PhabricatorUserStatusOverlapException.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUserTestCase' => 'applications/people/storage/__tests__/PhabricatorUserTestCase.php',
Add "Title" and "Blurb" to new profile editor Summary: Ref T1703. - Adds "Title". - Adds "Blurb". - Adds `user.fields` config for selecting and reordering. This will get UI in the next patch. Test Plan: {F45689} {F45690} Edited the fields, too. Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6153
2013-06-07 19:22:45 +02:00
'PhabricatorUserTitleField' => 'applications/people/customfield/PhabricatorUserTitleField.php',
Flesh out ApplicationTransactions/CustomField integration Summary: None of this code is reachable yet. See discussion in D6147. Ref T1703. Provide tighter integration between ApplicationTransactions and CustomField. Basically, I'm just trying to get all the shared stuff into the base implementation. Test Plan: Code not reachable. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6149
2013-06-06 23:53:07 +02:00
'PhabricatorUserTransaction' => 'applications/people/storage/PhabricatorUserTransaction.php',
Workboards Summary: Adds Workboards and workpanels. This is a preliminary diff, I'm still working on mobile and tablet and a few missing features (header actions) Test Plan: FF, Chrome, iOS, iPad, iPhone, IE Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5455
2013-03-30 17:51:35 +01:00
'PhabricatorWorkboardExample' => 'applications/uiexample/examples/PhabricatorWorkboardExample.php',
'PhabricatorWorkboardView' => 'view/layout/PhabricatorWorkboardView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorWorker' => 'infrastructure/daemon/workers/PhabricatorWorker.php',
Move completed tasks to an "archive" table and delete them in the GC Summary: Currently, when taskmasters complete a task it is immediately deleted. This prevents us from doing some general things, like: - Supporting the idea of permanent failure (e.g., after N failures just stop trying). - Showing the user how fast taskmasters are completing tasks. - Showing the user how long tasks took to complete. Having better visibility into this is important to Drydock, which builds on the task system. Also, generally buff debug output for task execution. Test Plan: Ran `bin/phd debug taskmaster`. Ran `bin/phd debug garbage`. Queued some tasks via various systems. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3852
2012-10-31 23:22:16 +01:00
'PhabricatorWorkerActiveTask' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerActiveTask.php',
'PhabricatorWorkerArchiveTask' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerArchiveTask.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorWorkerDAO' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerDAO.php',
Move task leasing to a dedicated query Summary: This simplifies the fairly thorny logic of leasing tasks a bit. I'm planning to introduce another callsite shortly for Drydock. Test Plan: Ran `bin/phd debug taskmaster`, observed sensible queries and correct operation. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3855
2012-11-01 19:30:16 +01:00
'PhabricatorWorkerLeaseQuery' => 'infrastructure/daemon/workers/query/PhabricatorWorkerLeaseQuery.php',
Factor out task execution and formalize permanent failures Summary: - Clean up a TODO about permanent failures. - Clean up a TODO about failing tasks after too many retries. - Clean up a TODO about testing for bad leases. - Make the lease/retry implementation more flexible and natural. - Make completely bogus tasks fail permanently. - Make PhabricatorMetaMTAWorker use new `getWaitBeforeRetry()` (as intended), not hackily implement logic in `getRequiredLeaseTime()`. - Document worker hooks for failures and retries. - Provide coverage on everything. Test Plan: Ran unit tests. Ran `bin/phd debug taskmaster`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3859
2012-11-01 19:30:23 +01:00
'PhabricatorWorkerPermanentFailureException' => 'infrastructure/daemon/workers/exception/PhabricatorWorkerPermanentFailureException.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorWorkerTask' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerTask.php',
'PhabricatorWorkerTaskData' => 'infrastructure/daemon/workers/storage/PhabricatorWorkerTaskData.php',
'PhabricatorWorkerTaskDetailController' => 'applications/daemon/controller/PhabricatorWorkerTaskDetailController.php',
'PhabricatorWorkerTaskUpdateController' => 'applications/daemon/controller/PhabricatorWorkerTaskUpdateController.php',
Factor out task execution and formalize permanent failures Summary: - Clean up a TODO about permanent failures. - Clean up a TODO about failing tasks after too many retries. - Clean up a TODO about testing for bad leases. - Make the lease/retry implementation more flexible and natural. - Make completely bogus tasks fail permanently. - Make PhabricatorMetaMTAWorker use new `getWaitBeforeRetry()` (as intended), not hackily implement logic in `getRequiredLeaseTime()`. - Document worker hooks for failures and retries. - Provide coverage on everything. Test Plan: Ran unit tests. Ran `bin/phd debug taskmaster`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3859
2012-11-01 19:30:23 +01:00
'PhabricatorWorkerTestCase' => 'infrastructure/daemon/workers/__tests__/PhabricatorWorkerTestCase.php',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorWorkingCopyDiscoveryTestCase' => 'applications/repository/engine/__tests__/PhabricatorWorkingCopyDiscoveryTestCase.php',
Make repository pulls testable Summary: Ref T2784. This moves us toward being able to test the background and Conduit pipelines for repositories. In particular: - Separate the logic for pulling repositories (`git pull`, `hg pull`) out of `PhabricatorRepositoryPullLocalDaemon` and put it in `PhabricatorRepositoryPullEngine`. This allows repositories to be pulled directly without invoking the daemons. - Add tests for the engine, including a future-looking base test case. - Add basic `PhutilDirectoryFixture`-based repositories. Next steps: # Do the same for repo discovery. # Then we can start writing tests against specific Conduit methods. Test Plan: Ran unit tests. Ran `bin/repository pull` on SVN, Hg and Git repositories. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran, nh Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5904
2013-05-13 04:05:52 +02:00
'PhabricatorWorkingCopyPullTestCase' => 'applications/repository/engine/__tests__/PhabricatorWorkingCopyPullTestCase.php',
'PhabricatorWorkingCopyTestCase' => 'applications/repository/engine/__tests__/PhabricatorWorkingCopyTestCase.php',
Workboards Summary: Adds Workboards and workpanels. This is a preliminary diff, I'm still working on mobile and tablet and a few missing features (header actions) Test Plan: FF, Chrome, iOS, iPad, iPhone, IE Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5455
2013-03-30 17:51:35 +01:00
'PhabricatorWorkpanelView' => 'view/layout/PhabricatorWorkpanelView.php',
Move Conduit methods inside applications Test Plan: /conduit/ /conduit/method/arcanist.projectinfo/ Call method $ echo '{}' | arc call-conduit user.whoami Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4268
2012-12-21 21:12:26 +01:00
'PhabricatorXHPASTViewController' => 'applications/phpast/controller/PhabricatorXHPASTViewController.php',
'PhabricatorXHPASTViewDAO' => 'applications/phpast/storage/PhabricatorXHPASTViewDAO.php',
'PhabricatorXHPASTViewFrameController' => 'applications/phpast/controller/PhabricatorXHPASTViewFrameController.php',
'PhabricatorXHPASTViewFramesetController' => 'applications/phpast/controller/PhabricatorXHPASTViewFramesetController.php',
'PhabricatorXHPASTViewInputController' => 'applications/phpast/controller/PhabricatorXHPASTViewInputController.php',
'PhabricatorXHPASTViewPanelController' => 'applications/phpast/controller/PhabricatorXHPASTViewPanelController.php',
'PhabricatorXHPASTViewParseTree' => 'applications/phpast/storage/PhabricatorXHPASTViewParseTree.php',
'PhabricatorXHPASTViewRunController' => 'applications/phpast/controller/PhabricatorXHPASTViewRunController.php',
'PhabricatorXHPASTViewStreamController' => 'applications/phpast/controller/PhabricatorXHPASTViewStreamController.php',
'PhabricatorXHPASTViewTreeController' => 'applications/phpast/controller/PhabricatorXHPASTViewTreeController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorXHProfController' => 'applications/xhprof/controller/PhabricatorXHProfController.php',
Do sampled profiling of requests Summary: People have occasionally complained about phabricator being slow. We have the access log to look at to see when slowness happens, but it doesn't tell us much about why it happened. Since it's usually a sporadic issue that's reported, it's hard to reproduce and then profile. This change will allow us to collect sampled profiles so we can look at them when slowness occurs. Test Plan: checking that sampling works correctly: - set rate to 0; do several page loads; check no new entries in table - set rate to 1; check that there's a new row in the table for each page load - set rate to 10; check that some requests write to table and some don't check new ui for samples: - load /xhprof/list/all/, see a list with a lot of samples - load /xhprof/list/sampled/, see only sampled runs - load /xhprof/list/manual/, see only non-sampled runs - load /xhprof/list/my-runs/, se only my manual runs Reviewers: vrana, epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3458
2012-08-25 00:14:38 +02:00
'PhabricatorXHProfDAO' => 'applications/xhprof/storage/PhabricatorXHProfDAO.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorXHProfProfileController' => 'applications/xhprof/controller/PhabricatorXHProfProfileController.php',
'PhabricatorXHProfProfileSymbolView' => 'applications/xhprof/view/PhabricatorXHProfProfileSymbolView.php',
'PhabricatorXHProfProfileTopLevelView' => 'applications/xhprof/view/PhabricatorXHProfProfileTopLevelView.php',
'PhabricatorXHProfProfileView' => 'applications/xhprof/view/PhabricatorXHProfProfileView.php',
Do sampled profiling of requests Summary: People have occasionally complained about phabricator being slow. We have the access log to look at to see when slowness happens, but it doesn't tell us much about why it happened. Since it's usually a sporadic issue that's reported, it's hard to reproduce and then profile. This change will allow us to collect sampled profiles so we can look at them when slowness occurs. Test Plan: checking that sampling works correctly: - set rate to 0; do several page loads; check no new entries in table - set rate to 1; check that there's a new row in the table for each page load - set rate to 10; check that some requests write to table and some don't check new ui for samples: - load /xhprof/list/all/, see a list with a lot of samples - load /xhprof/list/sampled/, see only sampled runs - load /xhprof/list/manual/, see only non-sampled runs - load /xhprof/list/my-runs/, se only my manual runs Reviewers: vrana, epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3458
2012-08-25 00:14:38 +02:00
'PhabricatorXHProfSample' => 'applications/xhprof/storage/PhabricatorXHProfSample.php',
'PhabricatorXHProfSampleListController' => 'applications/xhprof/controller/PhabricatorXHProfSampleListController.php',
Move skins toward modularization Summary: Two high-level things happening here: - We no longer ever need to put meta-UI (content creation, editing, notices, etc.) on live blog views, since this is all in Phame now. I pulled this out. - On the other hand, I pushed more routing/control logic into Skins and made the root skin a Controller instead of a View. This simplifies some of the code above skins, and the theory behind this is that it gives us greater flexibility to, e.g., put a glue layer between Phame and Wordpress templates or whatever else, and allows skins to handle routing and thus add pages like "About" or "Bio". - I added a basic skin below the root skin which is more like the old root skin and has standard rendering hooks. - "Ten Eleven" is a play on the popular (default?) Wordpress themes called "Twenty Ten", "Twenty Eleven" and "Twenty Twelve". Test Plan: Viewed live blog and live posts. They aren't pretty, but they don't have extraneous resources. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3714
2012-10-17 17:36:25 +02:00
'PhameBasicBlogSkin' => 'applications/phame/skins/PhameBasicBlogSkin.php',
Allow simple template-based skin definitions Summary: Lower the barrier to entry for installing and creating skins, so we can kill Wordpress. You can now install skins by dropping them into a directory, and build either "advanced" (full phutil library) skins or "basic" (simple PHP templates) skins. Next up is getting static resources working in an easy way for skins. I put these in `externals/` for now so they don't get hit by lint. Test Plan: Viewed the Pokeblog with the Oblivious skin. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3717
2012-10-17 17:36:48 +02:00
'PhameBasicTemplateBlogSkin' => 'applications/phame/skins/PhameBasicTemplateBlogSkin.php',
Phame - introduce blogs Summary: blogs are collections of posts. a blog also has metadata like a name, description and "bloggers" that can edit the metadata of the blog and contribute posts. changes include the post edit flow where bloggers can now select which blogs to publish to. also made various small tweaks throughout the UI to make things sensical and clean as the concept of blogs is introduced. there's edges powering this stuff. bloggers <=> blogs and posts <=> blogs in particular. Test Plan: made blogs, deleted blogs, tried to make blogs with no bloggers. all went well. verified ui to publish only showed up for public posts, published posts to blogs, un-published posts to blogs, re-published posts to blogs, deleted posts and verified they disappeared from blogs. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3003
2012-07-19 18:03:10 +02:00
'PhameBlog' => 'applications/phame/storage/PhameBlog.php',
'PhameBlogDeleteController' => 'applications/phame/controller/blog/PhameBlogDeleteController.php',
'PhameBlogEditController' => 'applications/phame/controller/blog/PhameBlogEditController.php',
Add Atom export to Phame Summary: There's no link to this yet, I'll add it to some skin. Fixes T2272. Test Plan: http://validator.w3.org/appc/ Reviewers: btrahan, epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2272 Differential Revision: https://secure.phabricator.com/D4366
2013-01-09 04:53:34 +01:00
'PhameBlogFeedController' => 'applications/phame/controller/blog/PhameBlogFeedController.php',
Modernize blog UI Summary: Cleans up some of the mess I made in D3694. Basically: - All blogs have an "internal" view with posts that uses mobile-friendly UIs, etc., so we don't have to do as much work with skins -- they just have to look pretty. - Blogs now have a separate "live" view that we use to handle domains / skins. - Simplified some views and use IDs in some URLs for consistency. - Delete a bunch of edge/blogger/multi-blog code that's now obsolete. Test Plan: Will attach screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3695
2012-10-15 23:50:12 +02:00
'PhameBlogListController' => 'applications/phame/controller/blog/PhameBlogListController.php',
'PhameBlogLiveController' => 'applications/phame/controller/blog/PhameBlogLiveController.php',
Phame - introduce blogs Summary: blogs are collections of posts. a blog also has metadata like a name, description and "bloggers" that can edit the metadata of the blog and contribute posts. changes include the post edit flow where bloggers can now select which blogs to publish to. also made various small tweaks throughout the UI to make things sensical and clean as the concept of blogs is introduced. there's edges powering this stuff. bloggers <=> blogs and posts <=> blogs in particular. Test Plan: made blogs, deleted blogs, tried to make blogs with no bloggers. all went well. verified ui to publish only showed up for public posts, published posts to blogs, un-published posts to blogs, re-published posts to blogs, deleted posts and verified they disappeared from blogs. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3003
2012-07-19 18:03:10 +02:00
'PhameBlogQuery' => 'applications/phame/query/PhameBlogQuery.php',
Move skins toward modularization Summary: Two high-level things happening here: - We no longer ever need to put meta-UI (content creation, editing, notices, etc.) on live blog views, since this is all in Phame now. I pulled this out. - On the other hand, I pushed more routing/control logic into Skins and made the root skin a Controller instead of a View. This simplifies some of the code above skins, and the theory behind this is that it gives us greater flexibility to, e.g., put a glue layer between Phame and Wordpress templates or whatever else, and allows skins to handle routing and thus add pages like "About" or "Bio". - I added a basic skin below the root skin which is more like the old root skin and has standard rendering hooks. - "Ten Eleven" is a play on the popular (default?) Wordpress themes called "Twenty Ten", "Twenty Eleven" and "Twenty Twelve". Test Plan: Viewed live blog and live posts. They aren't pretty, but they don't have extraneous resources. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3714
2012-10-17 17:36:25 +02:00
'PhameBlogSkin' => 'applications/phame/skins/PhameBlogSkin.php',
Phame - introduce blogs Summary: blogs are collections of posts. a blog also has metadata like a name, description and "bloggers" that can edit the metadata of the blog and contribute posts. changes include the post edit flow where bloggers can now select which blogs to publish to. also made various small tweaks throughout the UI to make things sensical and clean as the concept of blogs is introduced. there's edges powering this stuff. bloggers <=> blogs and posts <=> blogs in particular. Test Plan: made blogs, deleted blogs, tried to make blogs with no bloggers. all went well. verified ui to publish only showed up for public posts, published posts to blogs, un-published posts to blogs, re-published posts to blogs, deleted posts and verified they disappeared from blogs. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3003
2012-07-19 18:03:10 +02:00
'PhameBlogViewController' => 'applications/phame/controller/blog/PhameBlogViewController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhameController' => 'applications/phame/controller/PhameController.php',
'PhameDAO' => 'applications/phame/storage/PhameDAO.php',
'PhamePost' => 'applications/phame/storage/PhamePost.php',
'PhamePostDeleteController' => 'applications/phame/controller/post/PhamePostDeleteController.php',
'PhamePostEditController' => 'applications/phame/controller/post/PhamePostEditController.php',
Mostly modernize post edit/detail UIs Summary: Still some big chunks left but this moves us a bit closer to getting everything device-ready. Stuff not addressed here but which I'm planning to do soon: - Posts don't have a live URI yet. - Post detail pages don't actually show the post content. I'm going to tweak PhabricatorObjectPropertyListView for this since we need it some other places. - Some of the hinting about use/states is gone (e.g., "This post is a draft, publish it to make it live to the world."); I'm planning to restore it. - Left nav is still a bit of a mess with states/highlighting. Major changes are: - If you click "New Post" you get a screen asking you to pick a blog to post to. - "Publish/Preview" and Unpublish are now separate actions from the post detail screen. - "Publish/Preview" renders a preview of the post in an iframe and gives you a "Publish" button. Test Plan: Will attach screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3697
2012-10-15 23:50:45 +02:00
'PhamePostFramedController' => 'applications/phame/controller/post/PhamePostFramedController.php',
Modernize Phame post lists Summary: Use device UI for all post lists. Left menu is a bit wonky but I'll clean that up shortly. Test Plan: Will add screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3696
2012-10-15 23:50:37 +02:00
'PhamePostListController' => 'applications/phame/controller/post/PhamePostListController.php',
Mostly modernize post edit/detail UIs Summary: Still some big chunks left but this moves us a bit closer to getting everything device-ready. Stuff not addressed here but which I'm planning to do soon: - Posts don't have a live URI yet. - Post detail pages don't actually show the post content. I'm going to tweak PhabricatorObjectPropertyListView for this since we need it some other places. - Some of the hinting about use/states is gone (e.g., "This post is a draft, publish it to make it live to the world."); I'm planning to restore it. - Left nav is still a bit of a mess with states/highlighting. Major changes are: - If you click "New Post" you get a screen asking you to pick a blog to post to. - "Publish/Preview" and Unpublish are now separate actions from the post detail screen. - "Publish/Preview" renders a preview of the post in an iframe and gives you a "Publish" button. Test Plan: Will attach screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3697
2012-10-15 23:50:45 +02:00
'PhamePostNewController' => 'applications/phame/controller/post/PhamePostNewController.php',
Improve Phame live blogs/posts Summary: Make "View Live" work on Posts. Test Plan: Clicked "View Live" on live/not-live posts/blogs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3703
2012-10-15 23:51:30 +02:00
'PhamePostNotLiveController' => 'applications/phame/controller/post/PhamePostNotLiveController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhamePostPreviewController' => 'applications/phame/controller/post/PhamePostPreviewController.php',
Mostly modernize post edit/detail UIs Summary: Still some big chunks left but this moves us a bit closer to getting everything device-ready. Stuff not addressed here but which I'm planning to do soon: - Posts don't have a live URI yet. - Post detail pages don't actually show the post content. I'm going to tweak PhabricatorObjectPropertyListView for this since we need it some other places. - Some of the hinting about use/states is gone (e.g., "This post is a draft, publish it to make it live to the world."); I'm planning to restore it. - Left nav is still a bit of a mess with states/highlighting. Major changes are: - If you click "New Post" you get a screen asking you to pick a blog to post to. - "Publish/Preview" and Unpublish are now separate actions from the post detail screen. - "Publish/Preview" renders a preview of the post in an iframe and gives you a "Publish" button. Test Plan: Will attach screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3697
2012-10-15 23:50:45 +02:00
'PhamePostPublishController' => 'applications/phame/controller/post/PhamePostPublishController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhamePostQuery' => 'applications/phame/query/PhamePostQuery.php',
Mostly modernize post edit/detail UIs Summary: Still some big chunks left but this moves us a bit closer to getting everything device-ready. Stuff not addressed here but which I'm planning to do soon: - Posts don't have a live URI yet. - Post detail pages don't actually show the post content. I'm going to tweak PhabricatorObjectPropertyListView for this since we need it some other places. - Some of the hinting about use/states is gone (e.g., "This post is a draft, publish it to make it live to the world."); I'm planning to restore it. - Left nav is still a bit of a mess with states/highlighting. Major changes are: - If you click "New Post" you get a screen asking you to pick a blog to post to. - "Publish/Preview" and Unpublish are now separate actions from the post detail screen. - "Publish/Preview" renders a preview of the post in an iframe and gives you a "Publish" button. Test Plan: Will attach screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3697
2012-10-15 23:50:45 +02:00
'PhamePostUnpublishController' => 'applications/phame/controller/post/PhamePostUnpublishController.php',
Move skins toward modularization Summary: Two high-level things happening here: - We no longer ever need to put meta-UI (content creation, editing, notices, etc.) on live blog views, since this is all in Phame now. I pulled this out. - On the other hand, I pushed more routing/control logic into Skins and made the root skin a Controller instead of a View. This simplifies some of the code above skins, and the theory behind this is that it gives us greater flexibility to, e.g., put a glue layer between Phame and Wordpress templates or whatever else, and allows skins to handle routing and thus add pages like "About" or "Bio". - I added a basic skin below the root skin which is more like the old root skin and has standard rendering hooks. - "Ten Eleven" is a play on the popular (default?) Wordpress themes called "Twenty Ten", "Twenty Eleven" and "Twenty Twelve". Test Plan: Viewed live blog and live posts. They aren't pretty, but they don't have extraneous resources. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3714
2012-10-17 17:36:25 +02:00
'PhamePostView' => 'applications/phame/view/PhamePostView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhamePostViewController' => 'applications/phame/controller/post/PhamePostViewController.php',
Allow blog resources to be served without Celerity Summary: Allow skins to serve arbitrary resources without needing to be mapped, so we can have a vibrant community of amateur skinners. For "basic" skins, just put all the "css/" on the page always. Includes an image to prove that works. @vrana, pretty sure this has no impact outside of Phame but it does change Celerity so it might be to blame if there's any weirdness with static resources. Test Plan: {F21341} {F21340} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3719
2012-10-17 17:37:05 +02:00
'PhameResourceController' => 'applications/phame/controller/PhameResourceController.php',
Allow simple template-based skin definitions Summary: Lower the barrier to entry for installing and creating skins, so we can kill Wordpress. You can now install skins by dropping them into a directory, and build either "advanced" (full phutil library) skins or "basic" (simple PHP templates) skins. Next up is getting static resources working in an easy way for skins. I put these in `externals/` for now so they don't get hit by lint. Test Plan: Viewed the Pokeblog with the Oblivious skin. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3717
2012-10-17 17:36:48 +02:00
'PhameSkinSpecification' => 'applications/phame/skins/PhameSkinSpecification.php',
Phlux v0 Summary: Yup, it's sitevars. No conduit or caching or fancy stuff yet. Ref T2793. Test Plan: {F36525} {F36526} {F36527} {F36528} {F36529} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2793 Differential Revision: https://secure.phabricator.com/D5397
2013-03-21 02:01:52 +01:00
'PhluxController' => 'applications/phlux/controller/PhluxController.php',
'PhluxDAO' => 'applications/phlux/storage/PhluxDAO.php',
'PhluxEditController' => 'applications/phlux/controller/PhluxEditController.php',
'PhluxListController' => 'applications/phlux/controller/PhluxListController.php',
'PhluxTransaction' => 'applications/phlux/storage/PhluxTransaction.php',
'PhluxTransactionQuery' => 'applications/phlux/query/PhluxTransactionQuery.php',
'PhluxVariable' => 'applications/phlux/storage/PhluxVariable.php',
'PhluxVariableEditor' => 'applications/phlux/editor/PhluxVariableEditor.php',
'PhluxVariableQuery' => 'applications/phlux/query/PhluxVariableQuery.php',
'PhluxViewController' => 'applications/phlux/controller/PhluxViewController.php',
Make Pholio mock edits (mostly) transaction-oriented Summary: - Use transactions to apply edits. - Use Editor to apply transactions. - Some special casing for tricky stuff I don't want to deal with yet (mock images). Test Plan: {F22368} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3837
2012-11-22 02:27:44 +01:00
'PholioConstants' => 'applications/pholio/constants/PholioConstants.php',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioController' => 'applications/pholio/controller/PholioController.php',
'PholioDAO' => 'applications/pholio/storage/PholioDAO.php',
'PholioImage' => 'applications/pholio/storage/PholioImage.php',
Show editor Summary: Show editor when user clicks edit button for inline comment. Test Plan: Verified that editor is shown. Reviewers: epriestley CC: aran, Korvin Maniphest Tasks: T2446 Differential Revision: https://secure.phabricator.com/D5030
2013-02-22 15:39:08 +01:00
'PholioInlineCommentEditView' => 'applications/pholio/view/PholioInlineCommentEditView.php',
'PholioInlineCommentSaveView' => 'applications/pholio/view/PholioInlineCommentSaveView.php',
Moved rendering to PholioInlineCommentView Summary: Rendering of inline comments has now been moved to PholioInlineCommentView controller. Delete almost deletes and edit... well not so much, but replaced google.fi with amazing popup. Test Plan: Verified that inline comments still show up. Verified that delete almost deletes. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2446 Differential Revision: https://secure.phabricator.com/D4994 Conflicts: src/applications/pholio/controller/PholioInlineController.php
2013-02-19 23:12:33 +01:00
'PholioInlineCommentView' => 'applications/pholio/view/PholioInlineCommentView.php',
Show saved inline comments Summary: Saved inline comments are now shown for images. Test Plan: Verified that inline comments are loaded and shown. Reviewers: epriestley CC: aran, Korvin Maniphest Tasks: T2446 Differential Revision: https://secure.phabricator.com/D4866
2013-02-08 16:24:17 +01:00
'PholioInlineController' => 'applications/pholio/controller/PholioInlineController.php',
Moved rendering to PholioInlineCommentView Summary: Rendering of inline comments has now been moved to PholioInlineCommentView controller. Delete almost deletes and edit... well not so much, but replaced google.fi with amazing popup. Test Plan: Verified that inline comments still show up. Verified that delete almost deletes. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2446 Differential Revision: https://secure.phabricator.com/D4994 Conflicts: src/applications/pholio/controller/PholioInlineController.php
2013-02-19 23:12:33 +01:00
'PholioInlineDeleteController' => 'applications/pholio/controller/PholioInlineDeleteController.php',
Show editor Summary: Show editor when user clicks edit button for inline comment. Test Plan: Verified that editor is shown. Reviewers: epriestley CC: aran, Korvin Maniphest Tasks: T2446 Differential Revision: https://secure.phabricator.com/D5030
2013-02-22 15:39:08 +01:00
'PholioInlineEditController' => 'applications/pholio/controller/PholioInlineEditController.php',
Select portions from mock Summary: Comment draft is now saved Test Plan: Verified that draft is saved Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2446 Differential Revision: https://secure.phabricator.com/D4831
2013-02-06 20:28:03 +01:00
'PholioInlineSaveController' => 'applications/pholio/controller/PholioInlineSaveController.php',
Pholio inline comment now include a thumbnail and link Summary: Pholio inline comment now include a thumbnail and link to the Image being commented on Test Plan: {F36331} Reviewers: chad, epriestley Reviewed By: epriestley CC: aran, Korvin, btrahan Maniphest Tasks: T2709 Differential Revision: https://secure.phabricator.com/D5375
2013-03-20 13:36:53 +01:00
'PholioInlineThumbController' => 'applications/pholio/controller/PholioInlineThumbController.php',
Moved rendering to PholioInlineCommentView Summary: Rendering of inline comments has now been moved to PholioInlineCommentView controller. Delete almost deletes and edit... well not so much, but replaced google.fi with amazing popup. Test Plan: Verified that inline comments still show up. Verified that delete almost deletes. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2446 Differential Revision: https://secure.phabricator.com/D4994 Conflicts: src/applications/pholio/controller/PholioInlineController.php
2013-02-19 23:12:33 +01:00
'PholioInlineViewController' => 'applications/pholio/controller/PholioInlineViewController.php',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioMock' => 'applications/pholio/storage/PholioMock.php',
Allow users to add comments in Pholio Summary: Basic support for adding comments. Missing a lot of frills. Uses new comment/transaction UI. Test Plan: Added some comments. Tried to add an empty comment. Some comments: {F22361} No text provided: {F22362} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3834
2012-11-22 02:27:20 +01:00
'PholioMockCommentController' => 'applications/pholio/controller/PholioMockCommentController.php',
Add very basic create interface for Pholio Summary: Nothing app-specific yet, just stitching groundwork together from readymade components. {F22347} Test Plan: Created some mocks via web UI. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3830
2012-11-22 02:23:28 +01:00
'PholioMockEditController' => 'applications/pholio/controller/PholioMockEditController.php',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioMockEditor' => 'applications/pholio/editor/PholioMockEditor.php',
Pholio mocks embed in a fancy way Summary: Pholio mocks are now embed in a fancy way Test Plan: {F34804} Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin, AnhNhan Maniphest Tasks: T2626 Differential Revision: https://secure.phabricator.com/D5249
2013-03-07 17:23:40 +01:00
'PholioMockEmbedView' => 'applications/pholio/view/PholioMockEmbedView.php',
Pholio tile to home page and mock to show first image Summary: Pholio tile to show up on home page First image is shown at mock page. Test Plan: Pholio app shows up on home page. First image is shown at mock page. Reviewers: epriestley CC: aran, Korvin Maniphest Tasks: T2356 Differential Revision: https://secure.phabricator.com/D4553
2013-01-20 18:29:34 +01:00
'PholioMockImagesView' => 'applications/pholio/view/PholioMockImagesView.php',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioMockListController' => 'applications/pholio/controller/PholioMockListController.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PholioMockMailReceiver' => 'applications/pholio/mail/PholioMockMailReceiver.php',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioMockQuery' => 'applications/pholio/query/PholioMockQuery.php',
'PholioMockViewController' => 'applications/pholio/controller/PholioMockViewController.php',
Prepare for hovercards Summary: - Unify all the reference/embed Remarkup rules for Differential, Maniphest, Paste and Ponder. - Add rules for Pholio. - Does not yet unify Diffusion or Files (both are a bit more involved). - Prepare for hovercards. Test Plan: {F33894} Reviewers: chad, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5120
2013-02-26 23:59:31 +01:00
'PholioRemarkupRule' => 'applications/pholio/remarkup/PholioRemarkupRule.php',
Add basic email support to Pholio Summary: These emails aren't yet useful, but thread/multiplex/etc correctly. Test Plan: Got some Pholio emails. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3842
2012-11-22 02:39:46 +01:00
'PholioReplyHandler' => 'applications/pholio/mail/PholioReplyHandler.php',
Support search indexing in ApplicationTransaction Summary: Hook D4261 into ApplicationTransaction Test Plan: Edited a mock; searched for it. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4262
2012-12-21 23:21:50 +01:00
'PholioSearchIndexer' => 'applications/pholio/search/PholioSearchIndexer.php',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioTransaction' => 'applications/pholio/storage/PholioTransaction.php',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PholioTransactionComment' => 'applications/pholio/storage/PholioTransactionComment.php',
Allow users to add comments in Pholio Summary: Basic support for adding comments. Missing a lot of frills. Uses new comment/transaction UI. Test Plan: Added some comments. Tried to add an empty comment. Some comments: {F22361} No text provided: {F22362} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3834
2012-11-22 02:27:20 +01:00
'PholioTransactionQuery' => 'applications/pholio/query/PholioTransactionQuery.php',
Make Pholio mock edits (mostly) transaction-oriented Summary: - Use transactions to apply edits. - Use Editor to apply transactions. - Some special casing for tricky stuff I don't want to deal with yet (mock images). Test Plan: {F22368} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3837
2012-11-22 02:27:44 +01:00
'PholioTransactionType' => 'applications/pholio/constants/PholioTransactionType.php',
Group inline transactions in Pholio Summary: Fixes T2639 by grouping related transactions at display time, so all the inlines merge into a nice block. (Note that this does not do anything about T2709 yet, so there's still no way to figure out where the inlines actually are.) Test Plan: {F35262} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2639 Differential Revision: https://secure.phabricator.com/D5313
2013-03-10 04:23:50 +01:00
'PholioTransactionView' => 'applications/pholio/view/PholioTransactionView.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneAccount' => 'applications/phortune/storage/PhortuneAccount.php',
Don't use deprected "1" value to cURL CURLOPT_SSL_VERIFYHOST Summary: Fixes T2962. That task discusses this issue. Test Plan: Read php-curl documentation to verify this change makes sense. Sent an email with SES. Reviewers: btrahan, garoevans Reviewed By: garoevans CC: aran Maniphest Tasks: T2962 Differential Revision: https://secure.phabricator.com/D5669
2013-04-12 17:10:22 +02:00
'PhortuneAccountBuyController' => 'applications/phortune/controller/PhortuneAccountBuyController.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneAccountEditor' => 'applications/phortune/editor/PhortuneAccountEditor.php',
'PhortuneAccountQuery' => 'applications/phortune/query/PhortuneAccountQuery.php',
'PhortuneAccountTransaction' => 'applications/phortune/storage/PhortuneAccountTransaction.php',
'PhortuneAccountTransactionQuery' => 'applications/phortune/query/PhortuneAccountTransactionQuery.php',
'PhortuneAccountViewController' => 'applications/phortune/controller/PhortuneAccountViewController.php',
Implement Balanced Payments as a PhortunePaymentProvider Summary: Allows Balanced payment methods to be added. This works essentially the same way as Stripe, except everything is a little bit different. Slightly more stuff could be shared, but I feel //mostly// good about this. I'll probably do a bit more cleanup next. Some of the error handling is messy, in particular. Ref T2787. Test Plan: Added Balanced and Stripe payment methods. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5765
2013-04-25 18:48:04 +02:00
'PhortuneBalancedPaymentProvider' => 'applications/phortune/provider/PhortuneBalancedPaymentProvider.php',
Add "Carts" to Phortune Summary: Although I imagine we aren't really going to have an "add to cart" type storefront, putting this in place makes a lot of other workflows simpler. No storage yet, just allows reasonable construction of a "buy stuff" page. Test Plan: {F41342} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5745
2013-04-25 18:45:07 +02:00
'PhortuneCart' => 'applications/phortune/storage/PhortuneCart.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneCharge' => 'applications/phortune/storage/PhortuneCharge.php',
General cleanup for adding payment methods in Phortune Summary: This has no real behavioral changes (except better error handling), it just factors things out to be a bit cleaner. In particular: - Move more shared form behaviors into the common JS form component. - Move more error handling into shared pathways. - Make the specialized Stripe / Balanced methods do less work. This needs some more polish for nontrival errors (especially on the Balanced side) but none of the error behavior is worse than it was and a lot of it is much better. Ref T2787. Test Plan: Hit all invalid form errors, added valid payment methods with Stripe and Balacned. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5771
2013-04-25 18:49:32 +02:00
'PhortuneConstants' => 'applications/phortune/constants/PhortuneConstants.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneController' => 'applications/phortune/controller/PhortuneController.php',
Clean up rendering of credit card form Summary: General cleanup and separation into generic vs Stripe blocks of code. - There was an old CC form view for Stripe stuff that I never cleaned up; clean that up. - Move non-Stripe CC form rendering into a base class (Balanced can reuse it). - Move non-Stripe CC form JS into a shareable class. - Simplify JS a bit (JX.Workflow can add extra parameters to a request, so we don't need hidden inputs). - Genericize CSS. - Depend on Stripe JS directly, if they're down we're not going to be able to add cards anyway. Ref T2787. Test Plan: Hit all Stripe errors and added new cards. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5758
2013-04-25 18:46:59 +02:00
'PhortuneCreditCardForm' => 'applications/phortune/view/PhortuneCreditCardForm.php',
Show prices in "$... USD" in Phortune Summary: Ref T2787. See discussion in D5834. - Replace `PhortuneUtil` with `PhortuneCurrency`, which feels a little better and more flexible / future-proof. - Add unit tests. - Display prices explicitly as "$... USD". Test Plan: Hit product list, cart, purchase flow, verified displays. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5841
2013-05-07 03:04:45 +02:00
'PhortuneCurrency' => 'applications/phortune/currency/PhortuneCurrency.php',
'PhortuneCurrencyTestCase' => 'applications/phortune/currency/__tests__/PhortuneCurrencyTestCase.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneDAO' => 'applications/phortune/storage/PhortuneDAO.php',
General cleanup for adding payment methods in Phortune Summary: This has no real behavioral changes (except better error handling), it just factors things out to be a bit cleaner. In particular: - Move more shared form behaviors into the common JS form component. - Move more error handling into shared pathways. - Make the specialized Stripe / Balanced methods do less work. This needs some more polish for nontrival errors (especially on the Balanced side) but none of the error behavior is worse than it was and a lot of it is much better. Ref T2787. Test Plan: Hit all invalid form errors, added valid payment methods with Stripe and Balacned. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5771
2013-04-25 18:49:32 +02:00
'PhortuneErrCode' => 'applications/phortune/constants/PhortuneErrCode.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneLandingController' => 'applications/phortune/controller/PhortuneLandingController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhortuneMonthYearExpiryControl' => 'applications/phortune/control/PhortuneMonthYearExpiryControl.php',
Add basic payment providers to Phortune Summary: Abstract out the Stripiness of payment providers so we can add a Test provider (and maybe MtGox / Balanced / Paypal / etc). Ref T2787. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5752
2013-04-25 18:45:43 +02:00
'PhortuneMultiplePaymentProvidersException' => 'applications/phortune/exception/PhortuneMultiplePaymentProvidersException.php',
'PhortuneNoPaymentProviderException' => 'applications/phortune/exception/PhortuneNoPaymentProviderException.php',
Clean up rendering of credit card form Summary: General cleanup and separation into generic vs Stripe blocks of code. - There was an old CC form view for Stripe stuff that I never cleaned up; clean that up. - Move non-Stripe CC form rendering into a base class (Balanced can reuse it). - Move non-Stripe CC form JS into a shareable class. - Simplify JS a bit (JX.Workflow can add extra parameters to a request, so we don't need hidden inputs). - Genericize CSS. - Depend on Stripe JS directly, if they're down we're not going to be able to add cards anyway. Ref T2787. Test Plan: Hit all Stripe errors and added new cards. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5758
2013-04-25 18:46:59 +02:00
'PhortuneNotImplementedException' => 'applications/phortune/exception/PhortuneNotImplementedException.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortunePaymentMethod' => 'applications/phortune/storage/PhortunePaymentMethod.php',
Phortune v0.1: add payment methods Summary: Hook @btrahan's Stripe form to the rest of Phortune. - Users can add payment methods. - They are saved to Stripe and associated with PhortunePaymentMethods on our side. - Payment methods appear on account overview. Test Plan: {F37548} {F37549} {F37550} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5438
2013-03-28 17:11:42 +01:00
'PhortunePaymentMethodEditController' => 'applications/phortune/controller/PhortunePaymentMethodEditController.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortunePaymentMethodListController' => 'applications/phortune/controller/PhortunePaymentMethodListController.php',
Phortune v0.1: add payment methods Summary: Hook @btrahan's Stripe form to the rest of Phortune. - Users can add payment methods. - They are saved to Stripe and associated with PhortunePaymentMethods on our side. - Payment methods appear on account overview. Test Plan: {F37548} {F37549} {F37550} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5438
2013-03-28 17:11:42 +01:00
'PhortunePaymentMethodQuery' => 'applications/phortune/query/PhortunePaymentMethodQuery.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortunePaymentMethodViewController' => 'applications/phortune/controller/PhortunePaymentMethodViewController.php',
Add basic payment providers to Phortune Summary: Abstract out the Stripiness of payment providers so we can add a Test provider (and maybe MtGox / Balanced / Paypal / etc). Ref T2787. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5752
2013-04-25 18:45:43 +02:00
'PhortunePaymentProvider' => 'applications/phortune/provider/PhortunePaymentProvider.php',
'PhortunePaymentProviderTestCase' => 'applications/phortune/provider/__tests__/PhortunePaymentProviderTestCase.php',
Add initial cut of PayPal and pay-once-at-checkout providers to Phortune Summary: Paypal doesn't let us capture cards in a PCI-free way like Stripe and Balanced do, but we can provide a "pay with paypal" option at checkout. (For subscriptions, we'll have to invoice monthly to retain control over billing, but this doesn't seem wildly unreasonable.) The bitcoin provider MtGox works in a similar way, as do some other providers we might some day want to implement. This adds: - Hooks to providers so they can offer "pay once at checkout" workflows. - Hooks so providers can have controllers, for redirect-based third-party workflows. - Basic Paypal integration using the "Express Checkout Merchant API", which seems like the best fit for our use case. This only goes as far as shoving the user through the payment flow; we don't actually capture payments yet (paypal has around 35 different APIs, but this one seems to be the only PCI-free one which wouldn't give users an awful experience). This diff is fairly checkpointey, but Phortune doesn't really bill anything yet anyway. Ref T2787. Test Plan: Ran through Paypal sandbox workflow; "paid" for stuff. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5834
2013-05-06 20:44:24 +02:00
'PhortunePaypalPaymentProvider' => 'applications/phortune/provider/PhortunePaypalPaymentProvider.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneProduct' => 'applications/phortune/storage/PhortuneProduct.php',
Phortune v0.1: products Summary: Ref T2787. A product is the abstract representation of something you can buy or rent/subscribe to. Although the interface isn't locked down yet, this would ultimately be internal/administrative. Products likely have some user-facing skin on top of them: plans would have a purchasing/comparison flow, physical goods would have a storefront, etc., so products don't have any information like descriptions or images, just the data that Phortune needs to correctly bill accounts. Generally, this is very basic for the moment. Test Plan: {F37594} {F37595} {F37596} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5441
2013-03-28 17:13:07 +01:00
'PhortuneProductEditController' => 'applications/phortune/controller/PhortuneProductEditController.php',
'PhortuneProductEditor' => 'applications/phortune/editor/PhortuneProductEditor.php',
'PhortuneProductListController' => 'applications/phortune/controller/PhortuneProductListController.php',
'PhortuneProductQuery' => 'applications/phortune/query/PhortuneProductQuery.php',
'PhortuneProductTransaction' => 'applications/phortune/storage/PhortuneProductTransaction.php',
'PhortuneProductTransactionQuery' => 'applications/phortune/query/PhortuneProductTransactionQuery.php',
'PhortuneProductViewController' => 'applications/phortune/controller/PhortuneProductViewController.php',
Add initial cut of PayPal and pay-once-at-checkout providers to Phortune Summary: Paypal doesn't let us capture cards in a PCI-free way like Stripe and Balanced do, but we can provide a "pay with paypal" option at checkout. (For subscriptions, we'll have to invoice monthly to retain control over billing, but this doesn't seem wildly unreasonable.) The bitcoin provider MtGox works in a similar way, as do some other providers we might some day want to implement. This adds: - Hooks to providers so they can offer "pay once at checkout" workflows. - Hooks so providers can have controllers, for redirect-based third-party workflows. - Basic Paypal integration using the "Express Checkout Merchant API", which seems like the best fit for our use case. This only goes as far as shoving the user through the payment flow; we don't actually capture payments yet (paypal has around 35 different APIs, but this one seems to be the only PCI-free one which wouldn't give users an awful experience). This diff is fairly checkpointey, but Phortune doesn't really bill anything yet anyway. Ref T2787. Test Plan: Ran through Paypal sandbox workflow; "paid" for stuff. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5834
2013-05-06 20:44:24 +02:00
'PhortuneProviderController' => 'applications/phortune/controller/PhortuneProviderController.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortunePurchase' => 'applications/phortune/storage/PhortunePurchase.php',
Add basic payment providers to Phortune Summary: Abstract out the Stripiness of payment providers so we can add a Test provider (and maybe MtGox / Balanced / Paypal / etc). Ref T2787. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5752
2013-04-25 18:45:43 +02:00
'PhortuneStripePaymentProvider' => 'applications/phortune/provider/PhortuneStripePaymentProvider.php',
'PhortuneTestExtraPaymentProvider' => 'applications/phortune/provider/__tests__/PhortuneTestExtraPaymentProvider.php',
'PhortuneTestPaymentProvider' => 'applications/phortune/provider/PhortuneTestPaymentProvider.php',
Add WePay as a one-time payment provider Summary: Ref T2787. I //think// we could also use WePay as a recurring payment provider, but this is somewhat messy (OAuth + requires account) -- basically it's "add a WePay account" instead of "add a credit card". The WePay checkout workflow is a bit upsell-y but basically reasonable. I like that their API just has a `request($method, $params)` method instead of 30,000 lines of methods for each request type. I did hit one bug; I'll send a pull for that. Test Plan: Got as far as the charge callback in testing; the rest isn't implemented for any provider yet. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5982
2013-05-22 00:34:46 +02:00
'PhortuneWePayPaymentProvider' => 'applications/phortune/provider/PhortuneWePayPaymentProvider.php',
Implemented Phrequent time tracking functionality. Summary: This differential implements Phrequent's time tracking functionality for users and hooks it up to Maniphest. It also includes a basic "Time Tracked" list for the Phrequent application, where users can review what they've spent time working on. Test Plan: Apply the patch and track some things in Maniphest. They should appear in the "Time Tracked" view of Phrequent. There is also a `phrequent.show-prompt` option which toggles whether to display a prompt when tracking time. I'm unsure of whether the prompt is useful or is more likely to cause people to click "Track Time", go off and do the task and then come back to the prompt still waiting for them to confirm. A potential solution to the "accidentally clicking the button and recording 2 seconds of time" might be to show a prompt on stop if the total time is under 10 seconds, asking whether the user wants to keep or discard the tracked time. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2857 Differential Revision: https://secure.phabricator.com/D5479
2013-03-30 17:32:29 +01:00
'PhrequentController' => 'applications/phrequent/controller/PhrequentController.php',
'PhrequentDAO' => 'applications/phrequent/storage/PhrequentDAO.php',
'PhrequentListController' => 'applications/phrequent/controller/PhrequentListController.php',
'PhrequentTrackController' => 'applications/phrequent/controller/PhrequentTrackController.php',
'PhrequentTrackableInterface' => 'applications/phrequent/interface/PhrequentTrackableInterface.php',
'PhrequentUIEventListener' => 'applications/phrequent/event/PhrequentUIEventListener.php',
'PhrequentUserTime' => 'applications/phrequent/storage/PhrequentUserTime.php',
'PhrequentUserTimeQuery' => 'applications/phrequent/query/PhrequentUserTimeQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhrictionActionConstants' => 'applications/phriction/constants/PhrictionActionConstants.php',
'PhrictionChangeType' => 'applications/phriction/constants/PhrictionChangeType.php',
'PhrictionConstants' => 'applications/phriction/constants/PhrictionConstants.php',
'PhrictionContent' => 'applications/phriction/storage/PhrictionContent.php',
'PhrictionController' => 'applications/phriction/controller/PhrictionController.php',
'PhrictionDAO' => 'applications/phriction/storage/PhrictionDAO.php',
'PhrictionDeleteController' => 'applications/phriction/controller/PhrictionDeleteController.php',
'PhrictionDiffController' => 'applications/phriction/controller/PhrictionDiffController.php',
'PhrictionDocument' => 'applications/phriction/storage/PhrictionDocument.php',
'PhrictionDocumentController' => 'applications/phriction/controller/PhrictionDocumentController.php',
'PhrictionDocumentEditor' => 'applications/phriction/editor/PhrictionDocumentEditor.php',
'PhrictionDocumentPreviewController' => 'applications/phriction/controller/PhrictionDocumentPreviewController.php',
Implement PhrictionDocumentQuery Summary: Companion for D5284. Move all the query logic to a policy-aware query class. In particular: - Currently, anyone can view and edit a project's wiki documents. For callsites using this query class, you must be able to view or edit the project to view or edit its documents. - There's some very sketchy logic with the content/document joins. This cleans that up. - This cleans up loading projects by moving it inside the query. We need to do this anyway to perform policy checks. Test Plan: Viewed active/all/updated. Set page size to 2, verified pager works. Reviewers: AnhNhan, chad Reviewed By: AnhNhan CC: aran Differential Revision: https://secure.phabricator.com/D5285
2013-03-08 16:12:24 +01:00
'PhrictionDocumentQuery' => 'applications/phriction/query/PhrictionDocumentQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhrictionDocumentStatus' => 'applications/phriction/constants/PhrictionDocumentStatus.php',
'PhrictionDocumentTestCase' => 'applications/phriction/storage/__tests__/PhrictionDocumentTestCase.php',
'PhrictionEditController' => 'applications/phriction/controller/PhrictionEditController.php',
'PhrictionHistoryController' => 'applications/phriction/controller/PhrictionHistoryController.php',
'PhrictionListController' => 'applications/phriction/controller/PhrictionListController.php',
Phriction Documents can be moved Summary: Refs T1575 Test Plan: created plenty of pages, did all kind of stuff with them, moved them around, verified expected behaviour. {F34453} {F34455} Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, epriestley, Korvin Maniphest Tasks: T1575 Differential Revision: https://secure.phabricator.com/D5198
2013-03-06 22:12:04 +01:00
'PhrictionMoveController' => 'applications/phriction/controller/PhrictionMoveController.php',
Create a "New Document" button in phriction Summary: gives user a dialogue and they can fill out what comes after /w/ Test Plan: made some new wiki docs. played with garbage data and edit scenarios as well as vanilla create -- good ish Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1360 Differential Revision: https://secure.phabricator.com/D3946
2012-11-10 00:08:37 +01:00
'PhrictionNewController' => 'applications/phriction/controller/PhrictionNewController.php',
Pre-prepare for hovercards Summary: D5120 and followups refactor and generalize object references in Remarkup -- notably, they move remarkup rules from a central location to the implementing applications. Preserve blame by doing moves/renames only first. This change moves application remarkup rules into those applications, and renames the ones D5120 modifies. Test Plan: Typed some preview text into a textarea, got a valid Remarkup render. Reviewers: vrana, chad Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5123
2013-02-26 23:57:41 +01:00
'PhrictionRemarkupRule' => 'applications/phriction/remarkup/PhrictionRemarkupRule.php',
Improve Search architecture Summary: The search indexing API has several problems right now: - Always runs in-process. - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it. - Being able to use the task queue will also make rebuilding indexes faster. - Instead, make the API phid-oriented. - No uniform indexing API. - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird. - Instead, provide a uniform API. - No uniform CLI. - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers. - Instead, let indexers expose documents for indexing. - Not application-oriented. - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world. - Instead, move indexers to applications and load them with SymbolLoader. Test Plan: - `bin/search index` - Indexed one revision, one task. - Indexed `--type TASK`, `--type DREV`, etc., for all types. - Indexed `--all`. - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it. - Creating users is a pain; searched for a user after indexing. - Creating commits is a pain; searched for a commit after indexing. - Mocks aren't currently loadable in the result view, so their indexing is moot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: 20after4, aran Maniphest Tasks: T1991, T2104 Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
'PhrictionSearchIndexer' => 'applications/phriction/search/PhrictionSearchIndexer.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderAddAnswerView' => 'applications/ponder/view/PonderAddAnswerView.php',
adding comments to ponder Summary: This is pretty spartan, but it does the job. Test Plan: Patch, update storage, add some comment to your favorite question or answer. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7 Maniphest Tasks: T1645 Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
'PonderAddCommentView' => 'applications/ponder/view/PonderAddCommentView.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderAnswer' => 'applications/ponder/storage/PonderAnswer.php',
'PonderAnswerEditor' => 'applications/ponder/editor/PonderAnswerEditor.php',
'PonderAnswerListView' => 'applications/ponder/view/PonderAnswerListView.php',
'PonderAnswerPreviewController' => 'applications/ponder/controller/PonderAnswerPreviewController.php',
'PonderAnswerQuery' => 'applications/ponder/query/PonderAnswerQuery.php',
'PonderAnswerSaveController' => 'applications/ponder/controller/PonderAnswerSaveController.php',
'PonderAnswerViewController' => 'applications/ponder/controller/PonderAnswerViewController.php',
Hook Ponder to Subscriptions Summary: Adding email aggro email aggro Test Plan: Added some content; annoyed some coworkers. Reviewers: epriestley, nh, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1808 Differential Revision: https://secure.phabricator.com/D3643
2012-10-08 23:47:21 +02:00
'PonderAnsweredMail' => 'applications/ponder/mail/PonderAnsweredMail.php',
adding comments to ponder Summary: This is pretty spartan, but it does the job. Test Plan: Patch, update storage, add some comment to your favorite question or answer. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7 Maniphest Tasks: T1645 Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
'PonderComment' => 'applications/ponder/storage/PonderComment.php',
move ponder writes into editors; better search indexing Summary: * Moved the remaining `->save()` calls into editors * for the `PonderQuestion`, separate `attachRelated` (needed for indexing and viewing) from `attachVotes` (needed for viewing but not indexing) * Update the indexer to include comment and answer content in the search index. Test Plan: Stuff works as before. Also: add a comment or answer with some easily-identifiable text and search for it; observe that it gets indexed appropriately. Reviewers: epriestley, nh, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1869 Differential Revision: https://secure.phabricator.com/D3654
2012-10-07 23:35:01 +02:00
'PonderCommentEditor' => 'applications/ponder/editor/PonderCommentEditor.php',
adding comments to ponder Summary: This is pretty spartan, but it does the job. Test Plan: Patch, update storage, add some comment to your favorite question or answer. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7 Maniphest Tasks: T1645 Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
'PonderCommentListView' => 'applications/ponder/view/PonderCommentListView.php',
Hook Ponder to Subscriptions Summary: Adding email aggro email aggro Test Plan: Added some content; annoyed some coworkers. Reviewers: epriestley, nh, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1808 Differential Revision: https://secure.phabricator.com/D3643
2012-10-08 23:47:21 +02:00
'PonderCommentMail' => 'applications/ponder/mail/PonderCommentMail.php',
adding comments to ponder Summary: This is pretty spartan, but it does the job. Test Plan: Patch, update storage, add some comment to your favorite question or answer. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7 Maniphest Tasks: T1645 Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
'PonderCommentQuery' => 'applications/ponder/query/PonderCommentQuery.php',
'PonderCommentSaveController' => 'applications/ponder/controller/PonderCommentSaveController.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderConstants' => 'applications/ponder/PonderConstants.php',
'PonderController' => 'applications/ponder/controller/PonderController.php',
'PonderDAO' => 'applications/ponder/storage/PonderDAO.php',
'PonderFeedController' => 'applications/ponder/controller/PonderFeedController.php',
Hook Ponder to Subscriptions Summary: Adding email aggro email aggro Test Plan: Added some content; annoyed some coworkers. Reviewers: epriestley, nh, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1808 Differential Revision: https://secure.phabricator.com/D3643
2012-10-08 23:47:21 +02:00
'PonderMail' => 'applications/ponder/mail/PonderMail.php',
'PonderMentionMail' => 'applications/ponder/mail/PonderMentionMail.php',
adding comments to ponder Summary: This is pretty spartan, but it does the job. Test Plan: Patch, update storage, add some comment to your favorite question or answer. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7 Maniphest Tasks: T1645 Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
'PonderPostBodyView' => 'applications/ponder/view/PonderPostBodyView.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderQuestion' => 'applications/ponder/storage/PonderQuestion.php',
'PonderQuestionAskController' => 'applications/ponder/controller/PonderQuestionAskController.php',
'PonderQuestionDetailView' => 'applications/ponder/view/PonderQuestionDetailView.php',
move ponder writes into editors; better search indexing Summary: * Moved the remaining `->save()` calls into editors * for the `PonderQuestion`, separate `attachRelated` (needed for indexing and viewing) from `attachVotes` (needed for viewing but not indexing) * Update the indexer to include comment and answer content in the search index. Test Plan: Stuff works as before. Also: add a comment or answer with some easily-identifiable text and search for it; observe that it gets indexed appropriately. Reviewers: epriestley, nh, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1869 Differential Revision: https://secure.phabricator.com/D3654
2012-10-07 23:35:01 +02:00
'PonderQuestionEditor' => 'applications/ponder/editor/PonderQuestionEditor.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PonderQuestionMailReceiver' => 'applications/ponder/mail/PonderQuestionMailReceiver.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderQuestionPreviewController' => 'applications/ponder/controller/PonderQuestionPreviewController.php',
'PonderQuestionQuery' => 'applications/ponder/query/PonderQuestionQuery.php',
'PonderQuestionSummaryView' => 'applications/ponder/view/PonderQuestionSummaryView.php',
'PonderQuestionViewController' => 'applications/ponder/controller/PonderQuestionViewController.php',
Pre-prepare for hovercards Summary: D5120 and followups refactor and generalize object references in Remarkup -- notably, they move remarkup rules from a central location to the implementing applications. Preserve blame by doing moves/renames only first. This change moves application remarkup rules into those applications, and renames the ones D5120 modifies. Test Plan: Typed some preview text into a textarea, got a valid Remarkup render. Reviewers: vrana, chad Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5123
2013-02-26 23:57:41 +01:00
'PonderRemarkupRule' => 'applications/ponder/remarkup/PonderRemarkupRule.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PonderReplyHandler' => 'applications/ponder/mail/PonderReplyHandler.php',
Improve Search architecture Summary: The search indexing API has several problems right now: - Always runs in-process. - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it. - Being able to use the task queue will also make rebuilding indexes faster. - Instead, make the API phid-oriented. - No uniform indexing API. - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird. - Instead, provide a uniform API. - No uniform CLI. - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers. - Instead, let indexers expose documents for indexing. - Not application-oriented. - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world. - Instead, move indexers to applications and load them with SymbolLoader. Test Plan: - `bin/search index` - Indexed one revision, one task. - Indexed `--type TASK`, `--type DREV`, etc., for all types. - Indexed `--all`. - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it. - Creating users is a pain; searched for a user after indexing. - Creating commits is a pain; searched for a commit after indexing. - Mocks aren't currently loadable in the result view, so their indexing is moot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: 20after4, aran Maniphest Tasks: T1991, T2104 Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
'PonderSearchIndexer' => 'applications/ponder/search/PonderSearchIndexer.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderUserProfileView' => 'applications/ponder/view/PonderUserProfileView.php',
'PonderVotableInterface' => 'applications/ponder/storage/PonderVotableInterface.php',
'PonderVotableView' => 'applications/ponder/view/PonderVotableView.php',
'PonderVoteEditor' => 'applications/ponder/editor/PonderVoteEditor.php',
'PonderVoteSaveController' => 'applications/ponder/controller/PonderVoteSaveController.php',
Implement #yoloswag Summary: Ref T3190. #shipit Likely future work: - Extract project mentions from remarkup for ApplicationTransactions; this isn't relevant in any apps right now (but will be in Pholio before tooo long). Ref T3189. - Allow projects to have alternate short names. As written, this is fine for most projects ("Differential" is `#differential`) but not so great for other projects ("Phabricator Public & Media Relations" is `#phabricator_public_media_relations`). This also breaks refs when you rename a project. Better would be letting long project names have short aliases (`#pr`) as permitted alternatives. Since this mention uses `#` instead of a letter, I needed to do a small amount of regexp gymnastics. Test Plan: you only #yolo once {F43615} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3189, T3190 Differential Revision: https://secure.phabricator.com/D5954
2013-05-18 11:46:39 +02:00
'ProjectRemarkupRule' => 'applications/project/remarkup/ProjectRemarkupRule.php',
Move qsprintf() test cases from libphutil to Phabricator Summary: Also move the other tests up so they'll trigger when this stuff is touched. Test Plan: liberate Reviewers: nh, btrahan, vrana Reviewed By: nh CC: aran Maniphest Tasks: T1283 Differential Revision: https://secure.phabricator.com/D3074
2012-07-26 21:01:47 +02:00
'QueryFormattingTestCase' => 'infrastructure/storage/__tests__/QueryFormattingTestCase.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephActiveProjectListView' => 'applications/releeph/view/project/list/ReleephActiveProjectListView.php',
'ReleephAuthorFieldSpecification' => 'applications/releeph/field/specification/ReleephAuthorFieldSpecification.php',
'ReleephBranch' => 'applications/releeph/storage/ReleephBranch.php',
'ReleephBranchAccessController' => 'applications/releeph/controller/branch/ReleephBranchAccessController.php',
'ReleephBranchBoxView' => 'applications/releeph/view/branch/ReleephBranchBoxView.php',
'ReleephBranchCommitFieldSpecification' => 'applications/releeph/field/specification/ReleephBranchCommitFieldSpecification.php',
'ReleephBranchCreateController' => 'applications/releeph/controller/branch/ReleephBranchCreateController.php',
'ReleephBranchEditController' => 'applications/releeph/controller/branch/ReleephBranchEditController.php',
'ReleephBranchEditor' => 'applications/releeph/editor/ReleephBranchEditor.php',
'ReleephBranchNamePreviewController' => 'applications/releeph/controller/branch/ReleephBranchNamePreviewController.php',
'ReleephBranchPreviewView' => 'applications/releeph/view/branch/ReleephBranchPreviewView.php',
'ReleephBranchTemplate' => 'applications/releeph/view/branch/ReleephBranchTemplate.php',
'ReleephBranchViewController' => 'applications/releeph/controller/branch/ReleephBranchViewController.php',
'ReleephCommitFinder' => 'applications/releeph/commitfinder/ReleephCommitFinder.php',
'ReleephCommitFinderException' => 'applications/releeph/commitfinder/ReleephCommitFinderException.php',
'ReleephCommitMessageFieldSpecification' => 'applications/releeph/field/specification/ReleephCommitMessageFieldSpecification.php',
'ReleephController' => 'applications/releeph/controller/ReleephController.php',
'ReleephDAO' => 'applications/releeph/storage/ReleephDAO.php',
'ReleephDefaultFieldSelector' => 'applications/releeph/field/selector/ReleephDefaultFieldSelector.php',
'ReleephDefaultUserView' => 'applications/releeph/view/user/ReleephDefaultUserView.php',
'ReleephDiffChurnFieldSpecification' => 'applications/releeph/field/specification/ReleephDiffChurnFieldSpecification.php',
'ReleephDiffMessageFieldSpecification' => 'applications/releeph/field/specification/ReleephDiffMessageFieldSpecification.php',
'ReleephDiffSizeFieldSpecification' => 'applications/releeph/field/specification/ReleephDiffSizeFieldSpecification.php',
'ReleephDifferentialRevisionDetailRenderer' => 'applications/releeph/differential/ReleephDifferentialRevisionDetailRenderer.php',
'ReleephEvent' => 'applications/releeph/storage/event/ReleephEvent.php',
'ReleephFieldParseException' => 'applications/releeph/field/exception/ReleephFieldParseException.php',
'ReleephFieldSelector' => 'applications/releeph/field/selector/ReleephFieldSelector.php',
'ReleephFieldSpecification' => 'applications/releeph/field/specification/ReleephFieldSpecification.php',
'ReleephFieldSpecificationIncompleteException' => 'applications/releeph/field/exception/ReleephFieldSpecificationIncompleteException.php',
'ReleephInactiveProjectListView' => 'applications/releeph/view/project/list/ReleephInactiveProjectListView.php',
'ReleephIntentFieldSpecification' => 'applications/releeph/field/specification/ReleephIntentFieldSpecification.php',
'ReleephLevelFieldSpecification' => 'applications/releeph/field/specification/ReleephLevelFieldSpecification.php',
'ReleephObjectHandleLoader' => 'applications/releeph/ReleephObjectHandleLoader.php',
'ReleephOriginalCommitFieldSpecification' => 'applications/releeph/field/specification/ReleephOriginalCommitFieldSpecification.php',
'ReleephPHIDConstants' => 'applications/releeph/ReleephPHIDConstants.php',
'ReleephProject' => 'applications/releeph/storage/ReleephProject.php',
'ReleephProjectActionController' => 'applications/releeph/controller/project/ReleephProjectActionController.php',
'ReleephProjectCreateController' => 'applications/releeph/controller/project/ReleephProjectCreateController.php',
'ReleephProjectEditController' => 'applications/releeph/controller/project/ReleephProjectEditController.php',
'ReleephProjectListController' => 'applications/releeph/controller/project/ReleephProjectListController.php',
Introduce ReleephProjectQuery Summary: Adds a policy-aware query class for selecting Releeph projects. This doesn't really change anything. - Make `ReleephProject` implment `PhabricatorPolicyInterface`, beginning the long journey to make it policy-aware. - Implement `ReleephProjectQuery`, for querying projects using cursor-based, policy-aware paging. - Use it on the list view, so we load only ~100 projects instead of all of them. - Tweaked some of the URI routing stuff to make it a little more consistent with common practices. Ref T2714. Test Plan: {F36434} {F36435} Reviewers: edward Reviewed By: edward CC: aran Maniphest Tasks: T2714 Differential Revision: https://secure.phabricator.com/D5390
2013-03-22 14:29:37 +01:00
'ReleephProjectQuery' => 'applications/releeph/query/ReleephProjectQuery.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephProjectView' => 'applications/releeph/view/ReleephProjectView.php',
'ReleephProjectViewController' => 'applications/releeph/controller/project/ReleephProjectViewController.php',
'ReleephReasonFieldSpecification' => 'applications/releeph/field/specification/ReleephReasonFieldSpecification.php',
'ReleephRequest' => 'applications/releeph/storage/ReleephRequest.php',
'ReleephRequestActionController' => 'applications/releeph/controller/request/ReleephRequestActionController.php',
ReleephRequest xactions Summary: Migrate to `PhabricatorApplicationTransactions` (`ReleephRequestTransactions` applied by `ReleephRequestTransactionalEditor`, instead of `ReleephRequestEvents` created by `ReleephRequestEditor`) and migrate all the old events into transactions. Email is supported in the standard way (no more `ReleephRequestMail`) as well. This also collapses the Releeph request create and edit controllers into one class, as well as breaking everyone's subject-based mail rules by standardising them (but which should be more easily filtered by looking at headers.) Test Plan: * Make requests, then pick them. * Pick and revert the same request so that discovery happens way after `arc` has told Releeph about what's been happening. * Try to pick something that fails to pick in a project with pick instructions (and see the instructions are in the email.) * Load all of FB's Releeph data into my DB and run the `storage upgrade` script. * Request a commit via the "action" in a Differential revision. Reviewers: epriestley Reviewed By: epriestley CC: epriestley, aran, Korvin, wez Maniphest Tasks: T3092, T2720 Differential Revision: https://secure.phabricator.com/D5868
2013-04-08 17:34:21 +02:00
'ReleephRequestCommentController' => 'applications/releeph/controller/request/ReleephRequestCommentController.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephRequestDifferentialCreateController' => 'applications/releeph/controller/request/ReleephRequestDifferentialCreateController.php',
'ReleephRequestEditController' => 'applications/releeph/controller/request/ReleephRequestEditController.php',
'ReleephRequestEvent' => 'applications/releeph/storage/request/ReleephRequestEvent.php',
'ReleephRequestException' => 'applications/releeph/storage/request/exception/ReleephRequestException.php',
'ReleephRequestHeaderListView' => 'applications/releeph/view/request/header/ReleephRequestHeaderListView.php',
'ReleephRequestHeaderView' => 'applications/releeph/view/request/header/ReleephRequestHeaderView.php',
'ReleephRequestIntentsView' => 'applications/releeph/view/request/ReleephRequestIntentsView.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ReleephRequestMailReceiver' => 'applications/releeph/mail/ReleephRequestMailReceiver.php',
Add unit tests to cover PhabricatorMailReceiver::matchAddresses() Summary: Ref T3183. We should accept addresses like `"New Bug" <bugs@example.com>` to match `bugs@example.com`. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3183 Differential Revision: https://secure.phabricator.com/D5923
2013-05-15 00:04:17 +02:00
'ReleephRequestQuery' => 'applications/releeph/query/ReleephRequestQuery.php',
ReleephRequest xactions Summary: Migrate to `PhabricatorApplicationTransactions` (`ReleephRequestTransactions` applied by `ReleephRequestTransactionalEditor`, instead of `ReleephRequestEvents` created by `ReleephRequestEditor`) and migrate all the old events into transactions. Email is supported in the standard way (no more `ReleephRequestMail`) as well. This also collapses the Releeph request create and edit controllers into one class, as well as breaking everyone's subject-based mail rules by standardising them (but which should be more easily filtered by looking at headers.) Test Plan: * Make requests, then pick them. * Pick and revert the same request so that discovery happens way after `arc` has told Releeph about what's been happening. * Try to pick something that fails to pick in a project with pick instructions (and see the instructions are in the email.) * Load all of FB's Releeph data into my DB and run the `storage upgrade` script. * Request a commit via the "action" in a Differential revision. Reviewers: epriestley Reviewed By: epriestley CC: epriestley, aran, Korvin, wez Maniphest Tasks: T3092, T2720 Differential Revision: https://secure.phabricator.com/D5868
2013-04-08 17:34:21 +02:00
'ReleephRequestReplyHandler' => 'applications/releeph/mail/ReleephRequestReplyHandler.php',
ReleephRequestStatus Summary: This is just a bit of gardening in order to make the responsive-UI diff easier; I'll be putting `getColorFor($status)` type things in this class, following the pattern in `ManiphestTaskStatus`. Test Plan: Poke around Releeph. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5893
2013-05-10 18:07:33 +02:00
'ReleephRequestStatus' => 'applications/releeph/constants/ReleephRequestStatus.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephRequestStatusView' => 'applications/releeph/view/request/ReleephRequestStatusView.php',
ReleephRequest xactions Summary: Migrate to `PhabricatorApplicationTransactions` (`ReleephRequestTransactions` applied by `ReleephRequestTransactionalEditor`, instead of `ReleephRequestEvents` created by `ReleephRequestEditor`) and migrate all the old events into transactions. Email is supported in the standard way (no more `ReleephRequestMail`) as well. This also collapses the Releeph request create and edit controllers into one class, as well as breaking everyone's subject-based mail rules by standardising them (but which should be more easily filtered by looking at headers.) Test Plan: * Make requests, then pick them. * Pick and revert the same request so that discovery happens way after `arc` has told Releeph about what's been happening. * Try to pick something that fails to pick in a project with pick instructions (and see the instructions are in the email.) * Load all of FB's Releeph data into my DB and run the `storage upgrade` script. * Request a commit via the "action" in a Differential revision. Reviewers: epriestley Reviewed By: epriestley CC: epriestley, aran, Korvin, wez Maniphest Tasks: T3092, T2720 Differential Revision: https://secure.phabricator.com/D5868
2013-04-08 17:34:21 +02:00
'ReleephRequestTransaction' => 'applications/releeph/storage/ReleephRequestTransaction.php',
'ReleephRequestTransactionComment' => 'applications/releeph/storage/ReleephRequestTransactionComment.php',
'ReleephRequestTransactionQuery' => 'applications/releeph/query/ReleephRequestTransactionQuery.php',
'ReleephRequestTransactionalEditor' => 'applications/releeph/editor/ReleephRequestTransactionalEditor.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephRequestTypeaheadControl' => 'applications/releeph/view/request/ReleephRequestTypeaheadControl.php',
'ReleephRequestTypeaheadController' => 'applications/releeph/controller/request/ReleephRequestTypeaheadController.php',
'ReleephRequestViewController' => 'applications/releeph/controller/request/ReleephRequestViewController.php',
'ReleephRequestorFieldSpecification' => 'applications/releeph/field/specification/ReleephRequestorFieldSpecification.php',
'ReleephRevisionFieldSpecification' => 'applications/releeph/field/specification/ReleephRevisionFieldSpecification.php',
'ReleephRiskFieldSpecification' => 'applications/releeph/field/specification/ReleephRiskFieldSpecification.php',
'ReleephSeverityFieldSpecification' => 'applications/releeph/field/specification/ReleephSeverityFieldSpecification.php',
'ReleephStatusFieldSpecification' => 'applications/releeph/field/specification/ReleephStatusFieldSpecification.php',
'ReleephSummaryFieldSpecification' => 'applications/releeph/field/specification/ReleephSummaryFieldSpecification.php',
'ReleephUserView' => 'applications/releeph/view/user/ReleephUserView.php',
v0 embedding slowvotes Summary: Slowvotes can now be embed using {V*} syntax. Nothing fancy there yet. Test Plan: {F40842} Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2883 Differential Revision: https://secure.phabricator.com/D5713
2013-04-16 17:18:52 +02:00
'SlowvoteEmbedView' => 'applications/slowvote/view/SlowvoteEmbedView.php',
'SlowvoteRemarkupRule' => 'applications/slowvote/remarkup/SlowvoteRemarkupRule.php',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
),
'function' =>
array(
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'_phabricator_date_format' => 'view/viewutils.php',
'celerity_generate_unique_node_id' => 'infrastructure/celerity/api.php',
'celerity_get_resource_uri' => 'infrastructure/celerity/api.php',
'celerity_register_resource_map' => 'infrastructure/celerity/map.php',
Introduce some convenience methods for handle rendering Summary: So I don't have to copy/paste everything again. Used them at places I could find with my limited `grep` skills. Test Plan: Visited hovercards, revision and tasks. No crashes. Reviewers: epriestley, btrahan, chad Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5592
2013-04-06 02:01:35 +02:00
'implode_handle_links' => 'applications/phid/handle/view/render.php',
'implode_selected_handle_links' => 'applications/phid/handle/view/render.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'javelin_render_tag' => 'infrastructure/javelin/markup.php',
Merge branch 'master' into phutil_tag (Synchronizing.)
2013-01-29 20:05:02 +01:00
'javelin_tag' => 'infrastructure/javelin/markup.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'phabricator_date' => 'view/viewutils.php',
'phabricator_datetime' => 'view/viewutils.php',
render_tag -> tag: phabricator_form, differential inline comment Summary: Pretty straightforward. Test Plan: Viewed inline edit on left / right and new /edit. Reviewers: vrana Reviewed By: vrana CC: aran Maniphest Tasks: T2432 Differential Revision: https://secure.phabricator.com/D4724
2013-01-30 20:24:30 +01:00
'phabricator_form' => 'infrastructure/javelin/markup.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'phabricator_format_bytes' => 'view/viewutils.php',
'phabricator_format_local_time' => 'view/viewutils.php',
'phabricator_format_relative_time' => 'view/viewutils.php',
Move policy tests back into policy/ Summary: These were in an unusual location, but are better back in policy/ Test Plan: implicit arc unit Reviewers: vrana Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2638
2012-06-01 21:39:29 +02:00
'phabricator_format_relative_time_detailed' => 'view/viewutils.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'phabricator_format_units_generic' => 'view/viewutils.php',
'phabricator_on_relative_date' => 'view/viewutils.php',
'phabricator_parse_bytes' => 'view/viewutils.php',
'phabricator_relative_date' => 'view/viewutils.php',
'phabricator_render_form' => 'infrastructure/javelin/markup.php',
'phabricator_time' => 'view/viewutils.php',
Add feed integration to generic transactions Summary: Publish feed stories, including from Pholio. Actual stories are somewhat garbage but it's all display-time; I'm going to do a pass on feed in general. Test Plan: {F26832} Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4140
2012-12-11 23:00:21 +01:00
'phid_get_subtype' => 'applications/phid/utils.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'phid_get_type' => 'applications/phid/utils.php',
'phid_group_by_type' => 'applications/phid/utils.php',
'require_celerity_resource' => 'infrastructure/celerity/api.php',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
),
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'xmap' =>
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
array(
Allow Celerity to return "304 Not Modified" responses Summary: We always return HTTP 200 right now and don't send a "Last-Modified" header, so browsers download more data then necessary if you sit on a page mashing reload (for example). Test Plan: Used Charles to verify HTTP response codes from 400, 404 and 304 responses. Mashed reload a bunch and saw that the server sent back 304s. Changed the resource hash seed and saw 200s, then 304s on reload. Reviewed By: tuomaspelkonen Reviewers: tuomaspelkonen, jungejason, aran CC: bmaurer, aran, tuomaspelkonen Differential Revision: 253
2011-05-09 10:10:40 +02:00
'Aphront304Response' => 'AphrontResponse',
Write pathway for Differential Comments
2011-01-30 21:08:40 +01:00
'Aphront400Response' => 'AphrontResponse',
Make webpage response final
2012-11-29 08:57:13 +01:00
'Aphront403Response' => 'AphrontHTMLResponse',
'Aphront404Response' => 'AphrontHTMLResponse',
Javelin integration.
2011-01-25 20:57:47 +01:00
'AphrontAjaxResponse' => 'AphrontResponse',
Improve drag-and-drop uploader Summary: Make it discoverable, show uploading progress, show file thumbnails, allow you to remove files, make it a generic form component. Test Plan: Uploaded ducks Reviewed By: tomo Reviewers: aran, tomo, jungejason, tuomaspelkonen CC: anjali, aran, epriestley, tomo Differential Revision: 334
2011-05-23 01:11:41 +02:00
'AphrontAttachedFileView' => 'AphrontView',
AphrontBars Summary: Aphront widgets that render the either a discrete or continuous value as a horizontal shape. Like a progress bar, or a five-star rating bar. Test Plan: `/uiexample/view/PhabricatorAphrontBarExample/` ...which shows this, amongst other things: {F33898} Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5122
2013-03-05 17:46:09 +01:00
'AphrontBarView' => 'AphrontView',
Fix conservative CSRF token cycling limit Summary: We currently cycle CSRF tokens every hour and check for the last two valid ones. This means that a form could go stale in as little as an hour, and is certainly stale after two. When a stale form is submitted, you basically get a terrible heisen-state where some of your data might persist if you're lucky but more likely it all just vanishes. The .js file below outlines some more details. This is a pretty terrible UX and we don't need to be as conservative about CSRF validation as we're being. Remedy this problem by: - Accepting the last 6 CSRF tokens instead of the last 1 (i.e., pages are valid for at least 6 hours, and for as long as 7). - Using JS to refresh the CSRF token every 55 minutes (i.e., pages connected to the internet are valid indefinitely). - Showing the user an explicit message about what went wrong when CSRF validation fails so the experience is less bewildering. They should now only be able to submit with a bad CSRF token if: - They load a page, disconnect from the internet for 7 hours, reconnect, and submit the form within 55 minutes; or - They are actually the victim of a CSRF attack. We could eventually fix the first one by tracking reconnects, which might be "free" once the notification server gets built. It will probably never be an issue in practice. Test Plan: - Reduced CSRF cycle frequency to 2 seconds, submitted a form after 15 seconds, got the CSRF exception. - Reduced csrf-refresh cycle frequency to 3 seconds, submitted a form after 15 seconds, got a clean form post. - Added debugging code the the csrf refresh to make sure it was doing sensible things (pulling different tokens, finding all the inputs). Reviewed By: aran Reviewers: tuomaspelkonen, jungejason, aran CC: aran, epriestley Differential Revision: 660
2011-07-13 23:05:18 +02:00
'AphrontCSRFException' => 'AphrontException',
Show user status on calendar Summary: This is a rough cut, but gets some of the basics at least. Here's what it looks like: {F11690} Some things that would be nice for future diffs: - Different colors for different event types (tasks? MEETINGS?!) - When events span across multiple days, keep them in the same row. - Switch which month you're looking at. - Show specific users instead of all. - etc etc etc Test Plan: See screenshot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2514
2012-05-21 19:24:23 +02:00
'AphrontCalendarEventView' => 'AphrontView',
Build a basic calendar view Summary: This is a very small step toward building a Status and possibly an Oncall tool. Build a calendar view which renders months. Much of my hesitance to bang these tools out is that dealing with dates/calendaring is basically horrible, so I'm trying to ease into it. This calendar is locale-aware and all that jazz. Test Plan: - See: https://secure.phabricator.com/file/view/PHID-FILE-c07a9c663a7d040d2529/ - Verified that months have the right number of days, today is the right day of the week, months begin on the day after previous months end on, etc. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran Commenters: cwbeck, jungejason CC: blair, aran, epriestley, cwbeck, jungejason Differential Revision: 791
2011-08-08 03:26:31 +02:00
'AphrontCalendarMonthView' => 'AphrontView',
Tweak style on "Create Another Task" button Summary: Not totally sure I'm in love with this but I think it's somewhat non-terrible, despite the lack of lens flare. Also made "Cancel" take you back to the task if you got to "Create" from "Create Another Task". Test Plan: - Style: https://secure.phabricator.com/file/view/PHID-FILE-ad37d3c1f3b2c7a7a7d1/ - Hit "Cancel" from "Create Another", got sent back to task. - Hit "Cancel" from normal create, got sent back to list. - Tried to save an invalid task after making changes to CC/Projects, changes were preserved. Reviewed By: codeblock Reviewers: hunterbridges, jungejason, tuomaspelkonen, aran, codeblock CC: aran, epriestley, codeblock Differential Revision: 736
2011-07-27 19:46:22 +02:00
'AphrontContextBarView' => 'AphrontView',
Throw instead of log for invalid properties Summary: Continue work started at D3601. Test Plan: Commented declaration `AphrontController::$request`, saw exception. Brought it back, didn't see exception. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4233
2012-12-19 01:11:07 +01:00
'AphrontController' => 'Phobject',
Rename "IDPaged" to "CursorPaged", "executeWithPager" to "executeWith[Cursor|Offset]Pager" Summary: I'm trying to make progress on the policy/visibility stuff since it's a blocker for Wikimedia. First, I want to improve Projects so they can serve as policy groups (e.g., an object can have a visibility policy like "Visible to: members of project 'security'"). However, doing this without breaking anything or snowballing into a bigger change is a bit awkward because Projects are name-ordered and we have a Conduit API which does offset paging. Rather than breaking or rewriting this stuff, I want to just continue offset paging them for now. So I'm going to make PhabricatorPolicyQuery extend PhabricatorOffsetPagedQuery, but can't currently since the `executeWithPager` methods would clash. These methods do different things anyway and are probably better with different names. This also generally improves the names of these classes, since cursors are not necessarily IDs (in the feed case, they're "chronlogicalKeys", for example). I did leave some of the interals as "ID" since calling them "Cursor"s (e.g., `setAfterCursor()`) seemed a little wrong -- it should maybe be `setAfterCursorPosition()`. These APIs have very limited use and can easily be made more consistent later. Test Plan: Browsed around various affected tools; any issues here should throw/fail in a loud/obvious way. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3177
2012-08-07 20:54:06 +02:00
'AphrontCursorPagerView' => 'AphrontView',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontDefaultApplicationConfiguration' => 'AphrontApplicationConfiguration',
'AphrontDialogResponse' => 'AphrontResponse',
'AphrontDialogView' => 'AphrontView',
'AphrontErrorView' => 'AphrontView',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'AphrontException' => 'Exception',
Phabricator file upload application.
2011-01-23 03:33:00 +01:00
'AphrontFileResponse' => 'AphrontResponse',
MetaMTA
2011-01-26 02:40:21 +01:00
'AphrontFormCheckboxControl' => 'AphrontFormControl',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontFormControl' => 'AphrontView',
AphrontFormCountedToggleButtonsControl Summary: Like AphrontFormToggleButtonsControl, but with mouseover counters. These counters let you know how many of each thing there are in each category, which is useful when using this control for filtering a list of things in multiple dimensions. Test Plan: `/uiexample/view/PhabricatorCountedToggleButtonsExample/` Reviewers: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5118
2013-02-26 17:20:14 +01:00
'AphrontFormCountedToggleButtonsControl' => 'AphrontFormControl',
Conpherence - add crop Summary: mainly, this adds the image cropper - yay! - also removes the file image from the handle stuff I added in V1. now we do all this crazy photo stuff. Test Plan: - uploaded a photo by dragging to header and noted 120 x 80 showed up on reload - uploaded a photo by dragging to edit dialogue spot and noted 120 x 80 showed up on reload - cropped a photo - noted it cropped right - cropped a photo again and again and again - seems like it crops okay Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2418, T2399 Differential Revision: https://secure.phabricator.com/D4790
2013-02-06 23:03:52 +01:00
'AphrontFormCropControl' => 'AphrontFormControl',
Add a datepicker control Summary: I looooove JS! It makes me giddy with glee! Test Plan: Picked dates. See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2086
2012-04-04 21:14:10 +02:00
'AphrontFormDateControl' => 'AphrontFormControl',
Various fixes, particularly on the revision update workflow.
2011-02-05 02:53:14 +01:00
'AphrontFormDividerControl' => 'AphrontFormControl',
Improve drag-and-drop uploader Summary: Make it discoverable, show uploading progress, show file thumbnails, allow you to remove files, make it a generic form component. Test Plan: Uploaded ducks Reviewed By: tomo Reviewers: aran, tomo, jungejason, tuomaspelkonen CC: anjali, aran, epriestley, tomo Differential Revision: 334
2011-05-23 01:11:41 +02:00
'AphrontFormDragAndDropUploadControl' => 'AphrontFormControl',
Phabricator file upload application.
2011-01-23 03:33:00 +01:00
'AphrontFormFileControl' => 'AphrontFormControl',
Robustify profile image controls ever so slightly Summary: show project profile image on pertinent edit page. also add a "Use Default Image" checkbox for both project and user profiles. Also added a function for projects to get the profile picture to prevent some copy + paste action. Test Plan: set my user profile and project profile image. clicked "Use Default Image" and got the default image back. Reviewers: epriestley, floatinglomas Reviewed By: floatinglomas CC: aran, Korvin Maniphest Tasks: T1307 Differential Revision: https://secure.phabricator.com/D2852
2012-06-26 17:14:15 +02:00
'AphrontFormImageControl' => 'AphrontFormControl',
Inset view controller for inset elements of forms. Summary: T937 suggests 'inset' could have its own view controller. It has the following methods: - setTitle for title - setRightbutton if you have to place something (preferably a button) on the right side of the form - setDescription if you want to describe what it does - setContent for the main content - addDivAttributes REALLY not sure about this one but it had to be included because of a single controller (see owners/controller/edit/PhabricatorOwnersEditController.php:238) - appendChild works as usual if your form is complex but you still want to remove ->appendChild('<div class..') ->appendChild('</div>'); It might be an overkill so maybe some could be dropped: - addDivAttributes() and just rewrite how PhabricatorOwnersEditController.php works - setContent() and use appendChild for the main content? Test Plan: - Looked at the controllers in phabricator - Changed the controller - Opened the page in another tab - If something didnd't look the same I fixed it. Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1926
2012-03-16 01:10:19 +01:00
'AphrontFormInsetView' => 'AphrontView',
Allow projects to be quickly added from the Maniphest task creation interface Summary: Provide a quick workflow for adding a new project. This ended up being sort of complicated because we don't currently put forms in dialogs. I separated the actual <form /> tag out of the display/layout of AphrontFormView to enable this (the dialog is itself a form). Limitations: if you create a new project and then remove it, it won't appear in the tokenizer until you reload the page. We need to add the ability for the datasource to drop its cache to enable this, which is super complicated. Test Plan: Used "Create new project" to add a new project when creating a task. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran CC: anjali, aran, epriestley Differential Revision: 422
2011-06-10 00:28:29 +02:00
'AphrontFormLayoutView' => 'AphrontView',
Conduit: user.find
2011-01-24 20:36:53 +01:00
'AphrontFormMarkupControl' => 'AphrontFormControl',
PhabricatorEnv 'infratructure' -> 'infrastructure' (rofl) Recaptcha Email Login / Forgot Password Password Reset
2011-01-31 20:55:26 +01:00
'AphrontFormPasswordControl' => 'AphrontFormControl',
Add basic per-object privacy policies Summary: Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change. Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request. The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens. We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can. Test Plan: Unit tests, played around in the UI with various policy settings. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
'AphrontFormPolicyControl' => 'AphrontFormControl',
Improve Herald personal/global UI/UX Summary: - Default "personal" vs "global" choice to "personal". - Don't show global rules under "My Rules". - After editing or creating a global rule, redirect back to global rule list. - Use radio buttons for "personal" vs "global" and add captions explaining the difference. - For "global" rules, don't show the owner/author in the rule detail view -- they effectively have no owner (see also D1387). - For "global" rules, don't show the owner/author in the rule list view, as above. - For admin views, show rule type (global vs personal). Test Plan: - Created and edited new global and personal rules. - Viewed "my", "global" and "admin" views. Reviewers: btrahan, jungejason, nh, xela Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1518
2012-01-31 21:09:29 +01:00
'AphrontFormRadioButtonControl' => 'AphrontFormControl',
PhabricatorEnv 'infratructure' -> 'infrastructure' (rofl) Recaptcha Email Login / Forgot Password Password Reset
2011-01-31 20:55:26 +01:00
'AphrontFormRecaptchaControl' => 'AphrontFormControl',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontFormSelectControl' => 'AphrontFormControl',
Phabricator file upload application.
2011-01-23 03:33:00 +01:00
'AphrontFormStaticControl' => 'AphrontFormControl',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontFormSubmitControl' => 'AphrontFormControl',
'AphrontFormTextAreaControl' => 'AphrontFormControl',
'AphrontFormTextControl' => 'AphrontFormControl',
AphrontListFilterView, for list filtering.
2011-04-04 00:50:06 +02:00
'AphrontFormToggleButtonsControl' => 'AphrontFormControl',
Typeaheads
2011-01-25 22:48:05 +01:00
'AphrontFormTokenizerControl' => 'AphrontFormControl',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontFormView' => 'AphrontView',
AphrontBars Summary: Aphront widgets that render the either a discrete or continuous value as a horizontal shape. Like a progress bar, or a five-star rating bar. Test Plan: `/uiexample/view/PhabricatorAphrontBarExample/` ...which shows this, amongst other things: {F33898} Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5122
2013-03-05 17:46:09 +01:00
'AphrontGlyphBarView' => 'AphrontBarView',
Make webpage response final
2012-11-29 08:57:13 +01:00
'AphrontHTMLResponse' => 'AphrontResponse',
Provide software protections for HTTP response splitting Summary: This addresses a few things: - Provide a software HTTP response spliting guard as an extra layer of security, see http://news.php.net/php.internals/57655 and who knows what HPHP/i does. - Cleans up webroot/index.php a little bit, I want to get that file under control eventually. - Eventually I want to collect bytes in/out metrics and this allows us to do that easily. - We may eventually want to write to a socket or do something else like that, ala Litespawn. Test Plan: - Ran unit tests. - Browsed around, checked headers and HTTP status codes. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1564
2012-02-06 18:59:34 +01:00
'AphrontHTTPSinkTestCase' => 'PhabricatorTestCase',
Provide an "isolated" database connection for testing Summary: This provides a new connection which doesn't connect to anything, so effects can be isolated to the current process (for unit testing). Test Plan: Ran unit tests. Reviewed By: aran Reviewers: aran, tuomaspelkonen, jungejason CC: aran, epriestley Differential Revision: 193
2011-04-30 19:11:41 +02:00
'AphrontIsolatedDatabaseConnectionTestCase' => 'PhabricatorTestCase',
Provide software protections for HTTP response splitting Summary: This addresses a few things: - Provide a software HTTP response spliting guard as an extra layer of security, see http://news.php.net/php.internals/57655 and who knows what HPHP/i does. - Cleans up webroot/index.php a little bit, I want to get that file under control eventually. - Eventually I want to collect bytes in/out metrics and this allows us to do that easily. - We may eventually want to write to a socket or do something else like that, ala Litespawn. Test Plan: - Ran unit tests. - Browsed around, checked headers and HTTP status codes. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1564
2012-02-06 18:59:34 +01:00
'AphrontIsolatedHTTPSink' => 'AphrontHTTPSink',
Encode "<" and ">" in JSON/Ajax responses to prevent content-sniffing attacks Summary: Some browsers will still sniff content types even with "Content-Type" and "X-Content-Type-Options: nosniff". Encode "<" and ">" to prevent them from sniffing the content as HTML. See T865. Also unified some of the code on this pathway. Test Plan: Verified Opera no longer sniffs the Conduit response into HTML for the test case in T865. Unit tests pass. Reviewers: cbg, btrahan Reviewed By: cbg CC: aran, epriestley Maniphest Tasks: T139, T865 Differential Revision: https://secure.phabricator.com/D1606
2012-02-14 23:51:51 +01:00
'AphrontJSONResponse' => 'AphrontResponse',
Examples using JX.View Summary: Provide a dirt-simple working example of client-side templating and reactive programming. Test Plan: Load the examples Reviewers: epriestley, mroch, tomo Reviewed By: epriestley CC: ide, schrockn, aran, rzadorozny, epriestley Differential Revision: 908
2011-09-07 23:01:13 +02:00
'AphrontJavelinView' => 'AphrontView',
Provide basic keyboard navigation support for Differential. Summary: ReviewBoard has a fancier version of this feature that's more granular -- the keyboard can focus on individual changes. I think that's good and intend to implement something similar, but this gets us a step closer and gets rid of some of the bookkeeping stuff like making shortcuts discoverable. (I have another brnach with Maniphest merging which also uses fatcow icons, which is why the README seems a little out of context.) Test Plan: Used "j" and "k" to jump between changesets. Pressed "?" and got a list of available shortcuts. Reviewed By: tuomaspelkonen Reviewers: aran, jungejason, tuomaspelkonen CC: moskov, aran, epriestley, tuomaspelkonen Differential Revision: 412
2011-06-08 20:53:10 +02:00
'AphrontKeyboardShortcutsAvailableView' => 'AphrontView',
AphrontListFilterView, for list filtering.
2011-04-04 00:50:06 +02:00
'AphrontListFilterView' => 'AphrontView',
Reduce size of "Unbreak Now" and "Needs Triage" panels when no action is required Summary: Make these things like 1/4th the size if they aren't actionable. Test Plan: Loaded home page with actionable, unactionable panels. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1613
2012-02-15 01:23:53 +01:00
'AphrontMiniPanelView' => 'AphrontView',
Show "show more..." link in "Local Commits" view in Differential Summary: Javascript! Depends on D2437 to do anything useful. Test Plan: Clicked "show more", saw more. Reviewers: csilvers, btrahan Reviewed By: csilvers CC: aran Maniphest Tasks: T1189 Differential Revision: https://secure.phabricator.com/D2438
2012-05-10 00:56:37 +02:00
'AphrontMoreView' => 'AphrontView',
Build an AphrontMultiColumnView, use on workboards. Summary: Abstract out the multi-column code from workboards and have it be available separately. I feel like there will be some benefit here especially for custom developers in how they present infromation (like releeph). It also scales back to tablet and mobile fairly well, so they get those things for free. Test Plan: Tested mobile, tablet and chrome layouts. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5529
2013-04-02 20:23:24 +02:00
'AphrontMultiColumnView' => 'AphrontView',
Simplify Aphront transaction code Summary: In D1515, I introduced some excessively-complicated semantics for detecting connections that are lost while transactional. These semantics cause us to reenter establishConnection() and establish twice as many connections as we need in the common case. We don't need a hook there at all -- it's sufficient to throw the exception rather than retrying the query when we encounter it. This doesn't have reentrancy problems. Test Plan: - Added some encapsulation-violating hooks and a unit test for them - Verified we no longer double-connect. Reviewers: btrahan, nh Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T835 Differential Revision: https://secure.phabricator.com/D1576
2012-02-07 23:58:37 +01:00
'AphrontMySQLDatabaseConnectionTestCase' => 'PhabricatorTestCase',
Implement Maniphest auxiliary field 'default' key Summary: Fixes T404. Ref T2575. Allows default to be set for any field. Date defaults are interpreted by `strtotime()`. Other defaults are interpreted as expected. Test Plan: - Created a string custom field with default value "Orange". - Created a date custom field with a fixed default value (my birthday). - Created a date custom field with a relative default value ("today 4:59 PM"). - Created/edited tasks with these fields, verified everything behaved sensibly. Reviewers: hach-que, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T404, T2575 Differential Revision: https://secure.phabricator.com/D5282
2013-03-08 02:23:30 +01:00
'AphrontNoteView' => 'AphrontView',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontNullView' => 'AphrontView',
Provide software protections for HTTP response splitting Summary: This addresses a few things: - Provide a software HTTP response spliting guard as an extra layer of security, see http://news.php.net/php.internals/57655 and who knows what HPHP/i does. - Cleans up webroot/index.php a little bit, I want to get that file under control eventually. - Eventually I want to collect bytes in/out metrics and this allows us to do that easily. - We may eventually want to write to a socket or do something else like that, ala Litespawn. Test Plan: - Ran unit tests. - Browsed around, checked headers and HTTP status codes. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1564
2012-02-06 18:59:34 +01:00
'AphrontPHPHTTPSink' => 'AphrontHTTPSink',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontPageView' => 'AphrontView',
AphrontPagerView and UIExamples.
2011-04-01 02:06:33 +02:00
'AphrontPagerView' => 'AphrontView',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontPanelView' => 'AphrontView',
Improve error message for Conduit path problems Summary: A few people in IRC have been having issues here recently. If you misconfigure the IRC bot, e.g., you get a 200 response back with a bunch of login HTML in it. This is unhelpful. Try to detect that a conduit request is going to the wrong path and raise a concise, explicit error which is comprehensible from the CLI. Also created a "PlainText" response and moved the IE nosniff header to the base response object. Test Plan: As a logged-out user, hit various nonsense with "?__conduit__=true" in the URI. Got good error messages. Hit nonsense without it, got login screens. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T775 Differential Revision: https://secure.phabricator.com/D1407
2012-01-15 20:06:13 +01:00
'AphrontPlainTextResponse' => 'AphrontResponse',
AphrontBars Summary: Aphront widgets that render the either a discrete or continuous value as a horizontal shape. Like a progress bar, or a five-star rating bar. Test Plan: `/uiexample/view/PhabricatorAphrontBarExample/` ...which shows this, amongst other things: {F33898} Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5122
2013-03-05 17:46:09 +01:00
'AphrontProgressBarView' => 'AphrontBarView',
Minor, formalize changeset response class.
2012-03-13 05:39:05 +01:00
'AphrontProxyResponse' => 'AphrontResponse',
Authentication
2011-01-26 22:21:12 +01:00
'AphrontRedirectException' => 'AphrontException',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontRedirectResponse' => 'AphrontResponse',
Allow revisions to be edited from Maniphest Summary: You can currently attach tasks to revisions from Differential, but not revisions to tasks from Maniphest. Allow editing from either side. This logic is kind of tricky but the alternative was massive code duplication. Test Plan: Added and removed revisions from maniphest. Added and removed tasks from differential. This should have no impact on the Facebook install since none of this is used there. Reviewed By: aran Reviewers: tomo, tuomaspelkonen, jungejason, aran CC: aran, epriestley Differential Revision: 288
2011-05-16 20:43:39 +02:00
'AphrontReloadResponse' => 'AphrontRedirectResponse',
Make 404 page somewhat prettier.
2011-01-30 18:15:01 +01:00
'AphrontRequestFailureView' => 'AphrontView',
Add getStrList() to AphrontRequest Summary: - We have a few places where we do some kind of ad-hoc comma list tokenizing, and I'm adding another one in D1290. Add a helper to the request object. - Add some unit tests. Test Plan: - Ran unit tests. - Used PHID manager, Maniphest custom view, and Repository project editor. Reviewers: btrahan, fratrik, jungejason Reviewed By: btrahan CC: aran, btrahan, epriestley Differential Revision: https://secure.phabricator.com/D1302
2012-01-04 06:57:45 +01:00
'AphrontRequestTestCase' => 'PhabricatorTestCase',
Take the first step on the long journey of fixing "Projects" Summary: - Allow more than the 100 most recent projects to be viewed. - Provide some useful filters. - Default the view to your projects, not all projects. - Put query logic in a query object. - Put filter view logic in a view object. We can port more stuff to it later. Test Plan: Looked at active/owned/all projects. Set page size to 5 and paged through projects. Reviewers: btrahan, jungejason, zeeg Reviewed By: btrahan CC: aran, btrahan Differential Revision: 1227
2011-12-17 02:08:18 +01:00
'AphrontSideNavFilterView' => 'AphrontView',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontTableView' => 'AphrontView',
Genericize implementing views which expose common attributes Summary: Some views expose some/most/all of the basics (id, class, sigil, metadata, etc); let them extend a dedicated view to get it for free. Test Plan: Viewed home page, paste, mobile dropdown, etc. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D4440
2013-01-16 19:50:41 +01:00
'AphrontTagView' => 'AphrontView',
Some herald improvements.
2011-03-23 04:41:02 +01:00
'AphrontTokenizerTemplateView' => 'AphrontView',
Apront Two Column View Summary: Wanted to pull this out in case we don't use it in Maniphest, still useful perhaps in the future. Creates a sidebar that wraps when on mobile. Test Plan: Tested UIExample Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5321
2013-03-11 03:20:01 +01:00
'AphrontTwoColumnView' => 'AphrontView',
Some owners read workflows.
2011-04-04 04:20:47 +02:00
'AphrontTypeaheadTemplateView' => 'AphrontView',
Improve tag support in Diffusion Summary: - When viewing a commit, show its tags. - For commits with many tags, show a list of all tags on the tag list interface. - Improve some handling of symbolic references. - When tags contain content, show it on the browse view reached by clicking the tag name. Test Plan: Looked at commits with and without tags, clicked "More tags...", clicked tag names. Reviewers: btrahan, vrana, davidreuss, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1130 Differential Revision: https://secure.phabricator.com/D2290
2012-04-24 03:36:25 +02:00
'AphrontUsageException' => 'AphrontException',
Have AphrontView implement PhutilSafeHTMLProducerInterface Summary: Allows views to work like tags. Test Plan: Implemented a few completely arbitrary render() / singleView simplifications. I just picked some that were easy to test. I'll do a more thorough pass on this in a followup; these calls don't really hurt anything. Reviewers: chad, vrana Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D5306
2013-03-09 22:52:21 +01:00
'AphrontView' =>
array(
0 => 'Phobject',
1 => 'PhutilSafeHTMLProducerInterface',
),
Make webpage response final
2012-11-29 08:57:13 +01:00
'AphrontWebpageResponse' => 'AphrontHTMLResponse',
Update PeopleMenu to only show integration with applications if they are installed Summary: do so via event engine. note different order now... Test Plan: toggled "show beta applications" to off and noted that Conpherence disappeared. Otherwise noted that links showed. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2424 Differential Revision: https://secure.phabricator.com/D4708
2013-02-05 22:46:02 +01:00
'AuditPeopleMenuEventListener' => 'PhutilEventListener',
Allow blog resources to be served without Celerity Summary: Allow skins to serve arbitrary resources without needing to be mapped, so we can have a vibrant community of amateur skinners. For "basic" skins, just put all the "css/" on the page always. Includes an image to prove that works. @vrana, pretty sure this has no impact outside of Phame but it does change Celerity so it might be to blame if there's any weirdness with static resources. Test Plan: {F21341} {F21340} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3719
2012-10-17 17:37:05 +02:00
'CelerityPhabricatorResourceController' => 'CelerityResourceController',
Make CelerityController extend PhabricatorController Summary: Currently, CelerityController extends AphrontController, not PhabricatorController. (I think I imagined Celerity being somewhat stand-alone and didn't want to create a dependency.) This creates a concrete problem if a static resource is missing, since we throw an exception, but the higher-level exception handlers depend on the User existing in order to show an appropriate response page. This is the only controller which doesn't extend PhabricatorController, and it doesn't seem worthwhile to make a weird edge case out of it. Specific repro case is: - Remove `externals/javelin/` (or forget to run `git submodule update --init`). - Load a static resource. - Get "[Rendering Exception] Argument 1 passed to PhabricatorMainMenuView::setUser() must be an instance of PhabricatorUser, null given, called in /services/apache/phabricator/phabricator/src/view/page/PhabricatorStandardPageView.php on line 435 and defined" Test Plan: - Followed above steps, no more fataling. - Verified this is the only weird controller. Reviewers: voldern, vrana, btrahan Reviewed By: voldern CC: aran Differential Revision: https://secure.phabricator.com/D3389
2012-08-28 22:46:35 +02:00
'CelerityResourceController' => 'PhabricatorController',
Add cycle detection to celerity mapper Summary: create CelerityResourceGraph, which extends AbstractDirectedGraph. since we've done a bunch of work already to load the resource graph into memory CelerityResourceGraph simply stores a copy and makes loadEdges work off that stored copy. Test Plan: made phabricator-prefab require herald-rule-editor ~/code/phabricator> ./scripts/celerity_mapper.php webroot Finding static resources... Processing 154 files.......................................................................................................................................................... [2011-11-22 11:28:29] EXCEPTION: (Exception) Cycle detected in resource graph: phabricator-prefab => herald-rule-editor => phabricator-prefab at [/Users/btrahan/Dropbox/code/phabricator/scripts/celerity_mapper.php:173] fixed phabricator-prefab requiring herald-rule-editor. re-ran celerity_mapper and no errors! Reviewers: epriestley Reviewed By: epriestley CC: aran, btrahan, epriestley Differential Revision: 1132
2011-11-22 20:36:57 +01:00
'CelerityResourceGraph' => 'AbstractDirectedGraph',
Use Celerity to version all static resources Summary: We don't use versioned URIs for images, so when they change users may get old versions. This was a particular issue with the recent logo change, which several users reported cache-related issues from. Instead, use Celerity to manage image URI versions in addition to CSS/JS. This is complicated, because we need to rewrite image URIs inside of CSS, which means the hash of a CSS file has to be derived from the current image data. Otherwise, when we updated an image the CSS wouldn't update, so we wouldn't be any better off. So basically we: - Find all the "raw" files, and put them into the map. - Find all the CSS/JS, perform content-altering transformations on it (i.e., not minification) based on the partial map, and then put it into the map based on transformed hashes. (If we wanted, we could now do CSS variables or whatever for "free", more or less.) Test Plan: - Regenerated celerity map, browsed site, verified images generated with versioned URIs. - Moved "blue" flag image over "green" flag image, regenerated map, verified "green" flag image and the associated CSS changed hashes. - Added transformation unit tests; ran unit tests. Reviewers: btrahan, vrana, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1073 Differential Revision: https://secure.phabricator.com/D2146
2012-04-08 19:07:51 +02:00
'CelerityResourceTransformerTestCase' => 'PhabricatorTestCase',
Add an "arcanist.projectinfo" Conduit call Summary: We currently rely on "remote_hooks_enabled" in .arcconfig to determine whether commands like "arc amend" and "arc merge" should imply "arc mark-committed". However, this is a historical artifact that is now bad for a bunch of reasons: - The option name is confusing, it really means 'repository is tracked'. - The option is hard to discover and generally sucks. - We can empirically determine the right answer since we now know if a project is in a tracked repository. Add a call which arcanist can make on these workflows to figure out if it is interacting with a project in a tracked repository or not. Also added an "isTracked()" convenience method to reduce the number of magic strings all over the place. Test Plan: Ran "arcanist.projectinfo" for nonexistent, untracked and tracked projects. Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran Reviewed By: Makinde CC: aran, epriestley, Makinde Differential Revision: 945
2011-09-16 20:42:45 +02:00
'ConduitAPI_arcanist_Method' => 'ConduitAPIMethod',
'ConduitAPI_arcanist_projectinfo_Method' => 'ConduitAPI_arcanist_Method',
Provide an audit.query method for Conduit Summary: Conduit access for open audits. Test Plan: Used test console to run some queries. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1792
2012-03-07 00:12:27 +01:00
'ConduitAPI_audit_Method' => 'ConduitAPIMethod',
'ConduitAPI_audit_query_Method' => 'ConduitAPI_audit_Method',
Add a basic chatlog Summary: This is pretty simple and unpolished, but it's getting pretty big and it seems like a reasonable starting point. - Log chat in various "channels". - Conduit record and query methods. - IRCBot integration for IRC logging Major TODO: - Web UI is really unpolished and has no search, paging, anchor-linking, etc. Basically all presentation stuff, though. - I think the bot should have a map of channels to log with channel aliases? - The "channels" should probably be in a separate table. - The "authors" should probably be correlated to Phabricator accounts somehow, where possible. Test Plan: Used phabotlocal to log #phabricator. Reviewers: kdeggelman, btrahan, Koolvin Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T837 Differential Revision: https://secure.phabricator.com/D1625
2012-02-17 19:21:38 +01:00
'ConduitAPI_chatlog_Method' => 'ConduitAPIMethod',
'ConduitAPI_chatlog_query_Method' => 'ConduitAPI_chatlog_Method',
'ConduitAPI_chatlog_record_Method' => 'ConduitAPI_chatlog_Method',
Conduit: conduit.connect
2011-01-24 20:30:10 +01:00
'ConduitAPI_conduit_connect_Method' => 'ConduitAPIMethod',
"arc install-certificate", server-side components Summary: Provides a new workflow for making it non-horrible to install certificates. Basically you run "arc install-certificate" and then copy/paste a short token off a webpage and it does the ~/.arcrc edits for you. Test Plan: Installed certificates, used bad tokens, hit rate limiting. Reviewed By: aran Reviewers: aran, jungejason, tuomaspelkonen CC: aran Differential Revision: 460
2011-06-14 21:17:14 +02:00
'ConduitAPI_conduit_getcertificate_Method' => 'ConduitAPIMethod',
conduit.ping Summary: Test Plan: Reviewers: CC:
2011-02-19 07:36:32 +01:00
'ConduitAPI_conduit_ping_Method' => 'ConduitAPIMethod',
Adding the Conduit query method. Summary: T2154 Adding the Conduit query method implementation, and metadata to the phutil register library. Test Plan: Choose conduit.query on the web UI to see information about the method. Then, click the "Call Method" button and observe the method result. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4550
2013-01-20 01:37:06 +01:00
'ConduitAPI_conduit_query_Method' => 'ConduitAPIMethod',
Conpherence - add createthread method Summary: Ref T3166. I moved the create logic into a static method in the editor class to keep things tidy. Test Plan: created a conpherence from UI. purdy. tried errors and got UI to show "required". for conduit, created a thread with all the bells and whistles and it worked. verified i got proper exceptions with bum conduit calls Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3166 Differential Revision: https://secure.phabricator.com/D6083
2013-05-31 01:37:51 +02:00
'ConduitAPI_conpherence_Method' => 'ConduitAPIMethod',
'ConduitAPI_conpherence_createthread_Method' => 'ConduitAPI_conpherence_Method',
Conpherence - add querythead conduit method Summary: nice title. also adds a description to the create thread method which I forgot to add... Ref T3166. Test Plan: queried threads by ids, by phids, and by offset / limit tweakage. Got the right stuff! Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3166 Differential Revision: https://secure.phabricator.com/D6096
2013-05-31 19:43:46 +02:00
'ConduitAPI_conpherence_querythread_Method' => 'ConduitAPI_conpherence_Method',
Conpherence - add querytransaction method Summary: Ref T3166. Returned all the data I could think of, though notable "metadata" isn't used in conpherence (yet afaik) AND its somewhat silly to return the conpherence id / phid you specified, but seems handy. Test Plan: played with conduit console. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3166 Differential Revision: https://secure.phabricator.com/D6098
2013-05-31 20:27:49 +02:00
'ConduitAPI_conpherence_querytransaction_Method' => 'ConduitAPI_conpherence_Method',
Conpherence - add an updatethread conduit method Summary: Last of the methods. Fixes T3166. Test Plan: updated a thread in all the various ways except remove and it worked. removed myself and it worked! tried to remove someone else and it yelled at me. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3166 Differential Revision: https://secure.phabricator.com/D6103
2013-05-31 23:58:02 +02:00
'ConduitAPI_conpherence_updatethread_Method' => 'ConduitAPI_conpherence_Method',
Diffusion/phd/console improvements.
2011-03-15 21:38:14 +01:00
'ConduitAPI_daemon_launched_Method' => 'ConduitAPIMethod',
'ConduitAPI_daemon_log_Method' => 'ConduitAPIMethod',
Save daemon state to database Summary: To make it easier to monitor daemons, let's store their current state (running, died, exited, or unknown) to the db. The purpose of this is to provide more information on the daemon console about the status of daemons, especially when they are running on multiple machines. This is mostly backend work, with only a few frontend changes. (It is also dependent on a change to libphutil.) These changes will make dead or stuck daemons more obvious, and will allow more work on the frontend to hide daemons (and logs) that have exited cleanly, i.e. ones we don't care about any more. Test Plan: - run db migration, check in db that all daemons were marked as exited - start up a daemon, check in db that it is marked as running - open web interface, check that daemon is listed as running - after daemon has been running for a little bit, check in db that dateModified is being updated (indicating daemon is properly sending heartbeat) - kill -9 daemon (but don't run bin/phd yet), and check that db still shows it as running - edit daemon db entry to show it as being on a different host, and backdate dateModified field by 3 minutes, and check the web ui to show that the status is unknown. - change db entry to have proper host, check in web ui that daemon status is displayed as dead. Check db to see that the status was saved. - run bin/phd stop, and see that the formerly dead daemon is now exited. Reviewers: epriestley, vrana Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3126
2012-08-02 02:06:04 +02:00
'ConduitAPI_daemon_setstatus_Method' => 'ConduitAPIMethod',
Add a "differential.createrawdiff" Conduit method Summary: "differential.creatediff" requires a mostly-parsed diff, but there's no reason we can't make DifferentialDiffs out of raw diffs. This mainly serves to lower the adoption barrier if getting "arc" distributed is too much of a hassle. Test Plan: Made a diff out of a raw block of diff text. Reviewers: ffx, vrana, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2751
2012-06-20 21:35:04 +02:00
'ConduitAPI_differential_Method' => 'ConduitAPIMethod',
Use "closed", not "committed", in Differential Summary: "Committed" is SVN-specific language, and confusing in Git and Mercurial. Use neutral language instead. Test Plan: Inspection. Reviewers: btrahan, Makinde, vrana, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T909 Differential Revision: https://secure.phabricator.com/D2087
2012-04-24 02:40:57 +02:00
'ConduitAPI_differential_close_Method' => 'ConduitAPIMethod',
Add a "createcomment" method to Differential Summary: Added a new method differential.createcomment Task ID: #752014 Test Plan: I created a test diff and called this method via the conduit from a client PHP script to add comments. I confirmed that 1) the comment appeared on the revision, 2) URLs within the comment were turned into hyperlinks, and 3) Phabricator sent a notification email to the people watching the test diff. Reviewers: nh, jungejason, epriestley Reviewed By: nh CC: aran, nh Differential Revision: 1128
2011-11-18 18:16:40 +01:00
'ConduitAPI_differential_createcomment_Method' => 'ConduitAPIMethod',
Conduit: differential.creatediff
2011-01-24 20:01:53 +01:00
'ConduitAPI_differential_creatediff_Method' => 'ConduitAPIMethod',
Add an iterator to make it easier to perform database migrations Summary: See D3006, D3007. Make it easier to do migrations like that without holding all results in memory. Test Plan: Ran this code with an artificially small page size (2): foreach (new LiskMigrationIterator(new DifferentialRevision()) as $rev) { echo "Revision ".$rev->getID()."\n"; } Verified each revision as loaded and processed. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D3008
2012-07-19 05:01:23 +02:00
'ConduitAPI_differential_createinline_Method' => 'ConduitAPI_differential_Method',
Add a "differential.createrawdiff" Conduit method Summary: "differential.creatediff" requires a mostly-parsed diff, but there's no reason we can't make DifferentialDiffs out of raw diffs. This mainly serves to lower the adoption barrier if getting "arc" distributed is too much of a hassle. Test Plan: Made a diff out of a raw block of diff text. Reviewers: ffx, vrana, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2751
2012-06-20 21:35:04 +02:00
'ConduitAPI_differential_createrawdiff_Method' => 'ConduitAPI_differential_Method',
differential.createrevision Summary: Conduit method. Test Plan: Meta Reviewers: CC: Differential Revision: 23
2011-02-06 22:49:23 +01:00
'ConduitAPI_differential_createrevision_Method' => 'ConduitAPIMethod',
differential.find Summary: Test Plan: meta Reviewers: CC:
2011-02-06 23:43:06 +01:00
'ConduitAPI_differential_find_Method' => 'ConduitAPIMethod',
Add support for postponed linters Summary: This adds: 1) A new "arc:lint-postponed" diff property which stores a list of lint names that are postponed and a finishpostponedlinters conduit method which removes linters from this list. Postponed linters are shown in the lint details. 2) A updatelintmessages conduit message, which adds additional lint messages to the "arc:lint" diff property. In combination, this provides very basic support for running asynchronous static analysis tools. When the diff is being created, a list of asynchronous static analysis runs can be added to the diff's postponed linters list. As these postponed linters finish up, then can report new lint messages back to the diff then mark themselves as complete. The client is currently responsible for filtering the lint messages by things like affected lines and files. Test Plan: Used conduit call API to add lint messages and remove postponed linters from a test diff. Reviewers: epriestley, vrana, nh, jungejason Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1332 Differential Revision: https://secure.phabricator.com/D2792
2012-06-15 02:09:24 +02:00
'ConduitAPI_differential_finishpostponedlinters_Method' => 'ConduitAPIMethod',
Added a conduit method for getting all the diffs for a revision. Summary: Loading all diffs for a differential revision is needed by at least perflab. Test Plan: Created a simple script that queried the conduit and made sure that it returned correct values. Reviewed By: jungejason Reviewers: jungejason CC: epriestley, jungejason Differential Revision: 155
2011-04-21 00:29:02 +02:00
'ConduitAPI_differential_getalldiffs_Method' => 'ConduitAPIMethod',
Conduit: differential.getcommitmessage Summary: Test Plan: Reviewers: CC:
2011-02-09 18:41:26 +01:00
'ConduitAPI_differential_getcommitmessage_Method' => 'ConduitAPIMethod',
differential.getcommitpaths Summary: Test Plan: Reviewers: CC:
2011-02-19 07:28:03 +01:00
'ConduitAPI_differential_getcommitpaths_Method' => 'ConduitAPIMethod',
Provide differential.getdiff, useful for 'arc patch'. Summary: Test Plan: ran 'arc patch' Reviewers: CC:
2011-02-19 07:15:28 +01:00
'ConduitAPI_differential_getdiff_Method' => 'ConduitAPIMethod',
add a getrevision conduit method Summary: Add a method to get the information about a revision, including its full list of diffs. We could add an option to just return the diff IDs if we wanted. For my use case, I need the full set of information for each diff, so fewer round trips is better. This is also how the old json.php page used to work. Test Plan: Tuomas tested it in his sandbox. Reviewed By: tuomaspelkonen Reviewers: jungejason, tuomaspelkonen, epriestley CC: tuomaspelkonen Differential Revision: 156
2011-04-21 01:38:16 +02:00
'ConduitAPI_differential_getrevision_Method' => 'ConduitAPIMethod',
Add an iterator to make it easier to perform database migrations Summary: See D3006, D3007. Make it easier to do migrations like that without holding all results in memory. Test Plan: Ran this code with an artificially small page size (2): foreach (new LiskMigrationIterator(new DifferentialRevision()) as $rev) { echo "Revision ".$rev->getID()."\n"; } Verified each revision as loaded and processed. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D3008
2012-07-19 05:01:23 +02:00
'ConduitAPI_differential_getrevisioncomments_Method' => 'ConduitAPI_differential_Method',
Added a conduit method for querying revision feedback. Summary: Push tools needs information about differential revision comments. Added a method that returns the needed information. Test Plan: Tested that /intern/push/merges shows correct information. Reviewed By: jungejason Reviewers: jungejason CC: epriestley, jungejason Differential Revision: 152
2011-04-20 01:24:45 +02:00
'ConduitAPI_differential_getrevisionfeedback_Method' => 'ConduitAPIMethod',
differential.markcommitted Summary: Test Plan: Reviewers: CC:
2011-02-09 18:48:26 +01:00
'ConduitAPI_differential_markcommitted_Method' => 'ConduitAPIMethod',
differential.parsecommitmessage Test plan: meta
2011-02-06 22:42:00 +01:00
'ConduitAPI_differential_parsecommitmessage_Method' => 'ConduitAPIMethod',
Add differential.query conduit method Summary: Created a differential.query conduit method that is built on top of DifferentialRevisionQuery. I also added support for querying by author, ccs, and reviewers to DifferentialRevisionQuery, so feature parity can be brought up to match differential.find and its backing class DifferentialRevisionListData. Test Plan: Tried a few calls to the conduit call using the web interface, and got back reasonable looking data. Reviewers: epriestley, jungejason, btrahan Reviewed By: epriestley CC: aran, nh, epriestley Differential Revision: 1158
2011-12-02 01:57:06 +01:00
'ConduitAPI_differential_query_Method' => 'ConduitAPIMethod',
Conduit: differential.setdiffproperty
2011-01-24 21:07:34 +01:00
'ConduitAPI_differential_setdiffproperty_Method' => 'ConduitAPIMethod',
differential.updaterevision Summary: Test Plan: meta Reviewers: CC: Differential Revision: 24
2011-02-06 23:00:32 +01:00
'ConduitAPI_differential_updaterevision_Method' => 'ConduitAPIMethod',
Added a conduit call to update arc unit results for a postponed test. Summary: It was not possible before to update arc unit results for a postponed test. This change makes it possible. Also the number of postponed tests are shown in differential. Let me know if this looks too Facebook specific. Test Plan: Tested the conduit call manually from Conduit Console and updated test results for a diff that had 20 postponed tests. Reviewed By: jungejason Reviewers: epriestley, jungejason Commenters: epriestley CC: slawekbiel, aran, tuomaspelkonen, jungejason, epriestley Differential Revision: 416
2011-06-09 01:16:59 +02:00
'ConduitAPI_differential_updateunitresults_Method' => 'ConduitAPIMethod',
Uninstall Conduit calls when uninstalling applications Summary: Fixes T2698. When applications are installed, their Conduit calls should drop out. This will also let us land Releeph without exposing Conduit calls. Test Plan: - Viewed Conduit console; uninstalled some applications and verified their calls dropped out. - Tried to make an uninstalled call; got an appropriate error. Reviewers: edward, btrahan Reviewed By: edward CC: aran Maniphest Tasks: T2698 Differential Revision: https://secure.phabricator.com/D5302
2013-03-13 15:09:05 +01:00
'ConduitAPI_diffusion_Method' => 'ConduitAPIMethod',
Diffusion - move DiffusionExistsQuery to work over conduit Summary: le title. However, this also "is the first" conversion so sets the precedence for how this will all work. See comments in the code. I think this helps us keep the new code we're writing to a minimum. Wondering if the conduit end point could be more generic, and rather than have a switch statement on VCS type, one can just implement the "handleSubversion" version and have that called? Ref T2784 Test Plan: slapped an "or true" in the conditional protecting this code path. verified it worked on all 3 vcs systems, including typing in garbage and getting a 404 Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5803
2013-05-01 23:44:28 +02:00
'ConduitAPI_diffusion_abstractquery_Method' => 'ConduitAPI_diffusion_Method',
DiffusionBranchQuery => Conduit Summary: ref T2784. This one had a few fun spots where I had to move data around. Also, is there some common object (or should I add it?) that can do this toDictionary newFromConduit stuff? Also, this assumes D5803 is largely correct at the time of this diff. Test Plan: browsed mercurial and git repository page. saw the branches i expected. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5810
2013-05-01 23:56:36 +02:00
'ConduitAPI_diffusion_branchquery_Method' => 'ConduitAPI_diffusion_abstractquery_Method',
Diffusion - move DiffusionBrowseQuery => Conduit Summary: see title. Ref T2784. Test Plan: In diffusion, for each of SVN, Mercurial, and Git, I loaded up /diffusion/CALLSIGN/. I verified the README was displayed and things looked good. Next I clicked on "browse" on the top-most commit and verified things looked correct. Also clicked through to a file for a good measure and things looked good. In owners, for each of SVN, Mercurial, and Git, I played around with the path typeahead / validator. It worked correctly! Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5883
2013-05-10 20:02:58 +02:00
'ConduitAPI_diffusion_browsequery_Method' => 'ConduitAPI_diffusion_abstractquery_Method',
Diffusion - move commit branches query to conduit Summary: Ref T2784. Test Plan: loaded up a mercurial and a git commit. verified branches showed up correctly in object detail panel Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5958
2013-05-18 01:54:10 +02:00
'ConduitAPI_diffusion_commitbranchesquery_Method' => 'ConduitAPI_diffusion_abstractquery_Method',
Diffusion - move commit parents query to conduit Summary: Ref T2784. Relatively complicated one as this bad boy is used in a repository daemon. While testing, I noticed bugs in the expandshortname query stuff. Those variables are private to the parent class so they need some setX love. Also, was unable to find links to the "before" stuff, but made them by hand by looking at some of these T2784 diffs, browsing a file at a specific revision, then hacking the "before" variable to be some known commit that also touched the file. This produced sensical results. On the process of doing that I upgraded a query to use the proper policy query. Test Plan: In git, mercurial, svn, verified on a commit page the "parents" showed up correctly. played around with ?before parameter on specific file browse page, with commits known to have interesting history and stuff looked good Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5988
2013-05-22 01:22:49 +02:00
'ConduitAPI_diffusion_commitparentsquery_Method' => 'ConduitAPI_diffusion_abstractquery_Method',
Diffusion - move DiffQuery to Conduit Summary: title does not say it all; also added conduit wrappers for rawdiffquery and lastmodifiedquery. These get the wrapper treatment since they are used in daemons. Ref T2784. Test Plan: for each of the 3 VCS, did the following: 1) loaded up CALLSIGN and verified 'Modified' column data showed up correctly in Browse Repository box. 2) loaded up the "change" view for a specific file and verified content showed up correctly. 3) loaded up a specific commit and noted the changes ajax loaded A-OK Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5896
2013-05-14 22:53:32 +02:00
'ConduitAPI_diffusion_diffquery_Method' => 'ConduitAPI_diffusion_abstractquery_Method',
Diffusion - move DiffusionExistsQuery to work over conduit Summary: le title. However, this also "is the first" conversion so sets the precedence for how this will all work. See comments in the code. I think this helps us keep the new code we're writing to a minimum. Wondering if the conduit end point could be more generic, and rather than have a switch statement on VCS type, one can just implement the "handleSubversion" version and have that called? Ref T2784 Test Plan: slapped an "or true" in the conditional protecting this code path. verified it worked on all 3 vcs systems, including typing in garbage and getting a 404 Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5803
2013-05-01 23:44:28 +02:00
'ConduitAPI_diffusion_existsquery_Method' => 'ConduitAPI_diffusion_abstractquery_Method',
Diffusion - move some DiffusionRequest queries to occur over Conduit Summary: Ref T2784. This one was a wee bit complicated. Had to add PhabricatorUser and concept of initFromConduit (or not) to DiffusionRequest. Test Plan: foreach repo, visited CALLSIGN and clicked a commit and verified they laoded correctly. Hacked code to hit NOT via Conduit and repeated tests to great success. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5928
2013-05-15 00:32:19 +02:00
'ConduitAPI_diffusion_expandshortcommitquery_Method' => 'ConduitAPI_diffusion_abstractquery_Method',
DiffusionFileContentQuery => Conduit Summary: Ref T2784. This is probably pretty good except the fancy lint error saver now issue serial queries via Conduit. Test Plan: reparsed commits on 3 repos - yay. viewed readme from diffusion UI on 3 repos - yay. viewed file content from diffusion UI on 3 repos - yay. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5824
2013-05-07 23:57:08 +02:00
'ConduitAPI_diffusion_filecontentquery_Method' => 'ConduitAPI_diffusion_abstractquery_Method',
Uninstall Conduit calls when uninstalling applications Summary: Fixes T2698. When applications are installed, their Conduit calls should drop out. This will also let us land Releeph without exposing Conduit calls. Test Plan: - Viewed Conduit console; uninstalled some applications and verified their calls dropped out. - Tried to make an uninstalled call; got an appropriate error. Reviewers: edward, btrahan Reviewed By: edward CC: aran Maniphest Tasks: T2698 Differential Revision: https://secure.phabricator.com/D5302
2013-03-13 15:09:05 +01:00
'ConduitAPI_diffusion_findsymbols_Method' => 'ConduitAPI_diffusion_Method',
'ConduitAPI_diffusion_getcommits_Method' => 'ConduitAPI_diffusion_Method',
'ConduitAPI_diffusion_getlintmessages_Method' => 'ConduitAPI_diffusion_Method',
'ConduitAPI_diffusion_getrecentcommitsbypath_Method' => 'ConduitAPI_diffusion_Method',
Diffusion - move history query to conduit Summary: Ref T2784 Test Plan: for each flavor of VCS, I loaded up the repository home page. verified I saw some parent action where appropos. next, clicked through to 'view history' and verified it loaded up A-OK. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5960
2013-05-20 21:45:34 +02:00
'ConduitAPI_diffusion_historyquery_Method' => 'ConduitAPI_diffusion_abstractquery_Method',
Diffusion - move DiffQuery to Conduit Summary: title does not say it all; also added conduit wrappers for rawdiffquery and lastmodifiedquery. These get the wrapper treatment since they are used in daemons. Ref T2784. Test Plan: for each of the 3 VCS, did the following: 1) loaded up CALLSIGN and verified 'Modified' column data showed up correctly in Browse Repository box. 2) loaded up the "change" view for a specific file and verified content showed up correctly. 3) loaded up a specific commit and noted the changes ajax loaded A-OK Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5896
2013-05-14 22:53:32 +02:00
'ConduitAPI_diffusion_lastmodifiedquery_Method' => 'ConduitAPI_diffusion_abstractquery_Method',
Diffusion - move merged commits query to happen over conduit. Summary: Ref T2784. Also sneaks in a fix for branch query -- forgot to catch the unsupported VCS exception. One strange thing is I have test Phabricator repositories and the mercurial one is showing different data than git for the same commit. The data shown is consistent pre and post this diff though so its an existing issue. Also note the mercurial is an import of git so maybe its busted-ish? Test Plan: viewed commits in mercurial, svn, and git that were merge commits. saw the right stuff in mercurial and git. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5985
2013-05-21 02:04:51 +02:00
'ConduitAPI_diffusion_mergedcommitsquery_Method' => 'ConduitAPI_diffusion_abstractquery_Method',
Diffusion - move DiffQuery to Conduit Summary: title does not say it all; also added conduit wrappers for rawdiffquery and lastmodifiedquery. These get the wrapper treatment since they are used in daemons. Ref T2784. Test Plan: for each of the 3 VCS, did the following: 1) loaded up CALLSIGN and verified 'Modified' column data showed up correctly in Browse Repository box. 2) loaded up the "change" view for a specific file and verified content showed up correctly. 3) loaded up a specific commit and noted the changes ajax loaded A-OK Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5896
2013-05-14 22:53:32 +02:00
'ConduitAPI_diffusion_rawdiffquery_Method' => 'ConduitAPI_diffusion_abstractquery_Method',
Diffusion - break out readme query all on its own Summary: nice title. Ref T2784. Fixes T3171. Test Plan: For all 3 VCS types, viewed phabricator repository and saw readme. browsed said repository and saw readme. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784, T3171 Differential Revision: https://secure.phabricator.com/D5993
2013-05-21 22:47:06 +02:00
'ConduitAPI_diffusion_readmequery_Method' => 'ConduitAPI_diffusion_abstractquery_Method',
Diffusion - move build refs to occur over Conduit Summary: Ref T2784. Test Plan: loaded up a git commit with refs and they showed up! loaded up a git commit without revs and nothing showed up. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5957
2013-05-17 23:13:48 +02:00
'ConduitAPI_diffusion_refsquery_Method' => 'ConduitAPI_diffusion_abstractquery_Method',
Diffusion - move search (grep) system commands to happen over Conduit Summary: Ref T2784. Test Plan: loaded up my git and mercurial copies of Phabricator. Searched for "diff". Observed many results and pagination working correctly. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5955
2013-05-17 23:11:20 +02:00
'ConduitAPI_diffusion_searchquery_Method' => 'ConduitAPI_diffusion_abstractquery_Method',
Diffusion - move querying for stable commit name to occur over conduit Summary: Ref T2784. This is a lower-level one from drequest so it gets the conditional initialization treatment. Consolidated SVN as well even though SVN is issuing database queries; I felt better about the code de-duplication despite the small performance hit when we could just query the DB directly in the SVN case. Test Plan: browsed around my Phabricator repositories in Mercurial, Git, and SVN flavors. Looked good. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5956
2013-05-17 23:12:46 +02:00
'ConduitAPI_diffusion_stablecommitnamequery_Method' => 'ConduitAPI_diffusion_abstractquery_Method',
Diffusion - tag queries => conduit Summary: title. Ref T2784. Test Plan: foreach of SVN, Mercurial, and Git, loaded up a repository. Verified that only git had a tags box and it showed up correctly. Went to CALLSIGN/tags and verified that only git had a tags box and it showed up correctly. Went to various commits across vcs and verified it said "none" unless it was a git commit that also was tagged. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5894
2013-05-11 00:22:35 +02:00
'ConduitAPI_diffusion_tagsquery_Method' => 'ConduitAPI_diffusion_abstractquery_Method',
Uninstall Conduit calls when uninstalling applications Summary: Fixes T2698. When applications are installed, their Conduit calls should drop out. This will also let us land Releeph without exposing Conduit calls. Test Plan: - Viewed Conduit console; uninstalled some applications and verified their calls dropped out. - Tried to make an uninstalled call; got an appropriate error. Reviewers: edward, btrahan Reviewed By: edward CC: aran Maniphest Tasks: T2698 Differential Revision: https://secure.phabricator.com/D5302
2013-03-13 15:09:05 +01:00
'ConduitAPI_feed_Method' => 'ConduitAPIMethod',
'ConduitAPI_feed_publish_Method' => 'ConduitAPI_feed_Method',
'ConduitAPI_feed_query_Method' => 'ConduitAPI_feed_Method',
'ConduitAPI_file_Method' => 'ConduitAPIMethod',
'ConduitAPI_file_download_Method' => 'ConduitAPI_file_Method',
'ConduitAPI_file_info_Method' => 'ConduitAPI_file_Method',
'ConduitAPI_file_upload_Method' => 'ConduitAPI_file_Method',
'ConduitAPI_file_uploadhash_Method' => 'ConduitAPI_file_Method',
Add "Flags" to allow users to collect the things they love Summary: Flags are a personal collection of things you want to take a look at later. You can use several different colors and add notes. Not really sure if this is actually a good idea or not but it was easy to build. Planned features: - Allow Herald rules to add flags. - In the "edit flag" dialog, have a "[x] Subscribe Me" checkbox that CCs you. - Support Diffusion. - Support Phriction. - Always show flags on an object if you have them (in every view)? - Edit dialog feels a little heavy? - More filtering in /flag/ tool. - Add a top-level links somewhere? Test Plan: Added, edited and removed flags from things. Viewed flags in flag view. Reviewers: aran, btrahan Reviewed By: btrahan CC: aran, epriestley, Koolvin Maniphest Tasks: T1041 Differential Revision: https://secure.phabricator.com/D2024
2012-03-28 01:22:40 +02:00
'ConduitAPI_flag_Method' => 'ConduitAPIMethod',
Add a flag.delete Conduit method Summary: Fairly straightforward: allow deletion of flags from Conduit. Test Plan: Try arc call-conduit with different ids. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1556 Differential Revision: https://secure.phabricator.com/D3132
2012-08-02 21:25:01 +02:00
'ConduitAPI_flag_delete_Method' => 'ConduitAPI_flag_Method',
Improve the flag.* Conduit methods Summary: - Put the code to generate informational dicts about flags into the base class. - Update flag.delete to accept an object PHID in order to delete the flag on that object, since currently the model is that each object may have at most one flag, and each flag has exactly one object, although the former is not enforced. - Add flag.edit, which creates or updates a flag, optionally with the given color and note. Test Plan: Spend endless hours repeatedly running arc call-conduit and arc flag. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3141
2012-08-03 20:41:33 +02:00
'ConduitAPI_flag_edit_Method' => 'ConduitAPI_flag_Method',
Add "Flags" to allow users to collect the things they love Summary: Flags are a personal collection of things you want to take a look at later. You can use several different colors and add notes. Not really sure if this is actually a good idea or not but it was easy to build. Planned features: - Allow Herald rules to add flags. - In the "edit flag" dialog, have a "[x] Subscribe Me" checkbox that CCs you. - Support Diffusion. - Support Phriction. - Always show flags on an object if you have them (in every view)? - Edit dialog feels a little heavy? - More filtering in /flag/ tool. - Add a top-level links somewhere? Test Plan: Added, edited and removed flags from things. Viewed flags in flag view. Reviewers: aran, btrahan Reviewed By: btrahan CC: aran, epriestley, Koolvin Maniphest Tasks: T1041 Differential Revision: https://secure.phabricator.com/D2024
2012-03-28 01:22:40 +02:00
'ConduitAPI_flag_query_Method' => 'ConduitAPI_flag_Method',
Bring macros to IRC Summary: Adds a macro handler that spams your channel with macros. Config is: - macro.size: scale macros to this size before rasterizing - macro.sleep: sleep this many seconds between lines (evade flood protection) Test Plan: derpderp Reviewers: kdeggelman, btrahan Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1838
2012-03-09 21:40:03 +01:00
'ConduitAPI_macro_Method' => 'ConduitAPIMethod',
'ConduitAPI_macro_query_Method' => 'ConduitAPI_macro_Method',
Provide a basic maniphest.createtask method via Conduit Summary: This could be a lot fancier but let's see what else we need. Also fixed some bugs with maniphest.info. Test Plan: Used the Conduit web console to create some tasks with different values. Reviewers: jungejason, tuomaspelkonen, aran Reviewed By: jungejason CC: aran, jungejason, epriestley Differential Revision: 824
2011-08-18 00:19:48 +02:00
'ConduitAPI_maniphest_Method' => 'ConduitAPIMethod',
'ConduitAPI_maniphest_createtask_Method' => 'ConduitAPI_maniphest_Method',
Add specific close status queries to maniphest.find (and rename it to maniphest.query) Summary: - Allow clients to query for specific closed statuses (invalid, resolved, wontfix, etc), not just "closed" tasks. - Rename this method to maniphest.query and deprecate maniphest.find as an alias to maniphest.query, for API consistency. Test Plan: Ran queries for all tasks, "wontfix" tasks, closed tasks. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2887
2012-06-29 18:17:19 +02:00
'ConduitAPI_maniphest_find_Method' => 'ConduitAPI_maniphest_query_Method',
Added conduit method to get maniphest transactions Summary: Added a Conduit API method to return all transactions for a given set of task_ids. This will be used to comments and other important information about the tasks. Test Plan: Use Conduit to execute ##maniphest.gettasktransactions## and visually verify that transaction information is returned. Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1361
2012-01-11 04:51:55 +01:00
'ConduitAPI_maniphest_gettasktransactions_Method' => 'ConduitAPI_maniphest_Method',
Provide a basic maniphest.createtask method via Conduit Summary: This could be a lot fancier but let's see what else we need. Also fixed some bugs with maniphest.info. Test Plan: Used the Conduit web console to create some tasks with different values. Reviewers: jungejason, tuomaspelkonen, aran Reviewed By: jungejason CC: aran, jungejason, epriestley Differential Revision: 824
2011-08-18 00:19:48 +02:00
'ConduitAPI_maniphest_info_Method' => 'ConduitAPI_maniphest_Method',
Add specific close status queries to maniphest.find (and rename it to maniphest.query) Summary: - Allow clients to query for specific closed statuses (invalid, resolved, wontfix, etc), not just "closed" tasks. - Rename this method to maniphest.query and deprecate maniphest.find as an alias to maniphest.query, for API consistency. Test Plan: Ran queries for all tasks, "wontfix" tasks, closed tasks. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2887
2012-06-29 18:17:19 +02:00
'ConduitAPI_maniphest_query_Method' => 'ConduitAPI_maniphest_Method',
Add a "maniphest.update" Conduit method Summary: - Add maniphest.update - Add support for auxiliary fields to maniphest.createtask Test Plan: - Created tasks with maniphest.createtask - Updated tasks with maniphest.update Reviewers: btrahan, jungejason, zeeg Reviewed By: btrahan CC: aran, btrahan Differential Revision: https://secure.phabricator.com/D1330
2012-01-06 04:02:50 +01:00
'ConduitAPI_maniphest_update_Method' => 'ConduitAPI_maniphest_Method',
Uninstall Conduit calls when uninstalling applications Summary: Fixes T2698. When applications are installed, their Conduit calls should drop out. This will also let us land Releeph without exposing Conduit calls. Test Plan: - Viewed Conduit console; uninstalled some applications and verified their calls dropped out. - Tried to make an uninstalled call; got an appropriate error. Reviewers: edward, btrahan Reviewed By: edward CC: aran Maniphest Tasks: T2698 Differential Revision: https://secure.phabricator.com/D5302
2013-03-13 15:09:05 +01:00
'ConduitAPI_owners_Method' => 'ConduitAPIMethod',
'ConduitAPI_owners_query_Method' => 'ConduitAPI_owners_Method',
Provide a paste.create Conduit method Summary: - Allow the console to handle abstract classes correctly. - Move paste dictionary generation to an abstract base class. - Add paste.create. - Add 'objectName', 'parentPHID', and 'content' to Paste info dictionaries (you can use filePHID with file.download to get the content but I think just always sending it back is reasonable). Test Plan: - Use paste.create to create new pastes. - Used paste.info to get existing pastes. - Checked console UI to make sure "paste." didn't show up or anything silly/dumb like that. - Tried to call the method "paste" and got the right exception. Reviewed By: codeblock Reviewers: codeblock, jungejason, tuomaspelkonen, aran CC: aran, codeblock Differential Revision: 747
2011-07-30 03:31:14 +02:00
'ConduitAPI_paste_Method' => 'ConduitAPIMethod',
'ConduitAPI_paste_create_Method' => 'ConduitAPI_paste_Method',
'ConduitAPI_paste_info_Method' => 'ConduitAPI_paste_Method',
Add 'paste.query' conduit method and deprecate 'paste.info' Summary: - Modernize the Paste Conduit API. - Deprecate 'paste.info'. - Make queries policy-aware. - Move methods into the application to support greater modularity. Test Plan: Made `paste.query`, `paste.info`, `paste.create` calls. Browsed Paste interfaces. Forked a paste. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3379
2012-08-24 22:20:20 +02:00
'ConduitAPI_paste_query_Method' => 'ConduitAPI_paste_Method',
Add user.info and phid.info Conduit methods Summary: Allow user and arbitrary object lookup by PHID. Test Plan: Executed user.whoami, user.info, user.find and phid.info via Conduit console. Reviewers: jungejason, tuomaspelkonen, aran, nh Reviewed By: nh CC: skrul, aran, nh, jungejason, epriestley Differential Revision: 870
2011-08-30 21:03:58 +02:00
'ConduitAPI_phid_Method' => 'ConduitAPIMethod',
'ConduitAPI_phid_info_Method' => 'ConduitAPI_phid_Method',
Improve the flag.* Conduit methods Summary: - Put the code to generate informational dicts about flags into the base class. - Update flag.delete to accept an object PHID in order to delete the flag on that object, since currently the model is that each object may have at most one flag, and each flag has exactly one object, although the former is not enforced. - Add flag.edit, which creates or updates a flag, optionally with the given color and note. Test Plan: Spend endless hours repeatedly running arc call-conduit and arc flag. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3141
2012-08-03 20:41:33 +02:00
'ConduitAPI_phid_lookup_Method' => 'ConduitAPI_phid_Method',
[conduit] create phid.query method Summary: Provide a phid.query method that returns the same information as phid.info, but allows querying for multiple phids at once. Test Plan: Called the method from the web conduit console. Reviewers: btrahan, epriestley, jungejason Reviewed By: epriestley CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1617
2012-02-15 03:26:27 +01:00
'ConduitAPI_phid_query_Method' => 'ConduitAPI_phid_Method',
Uninstall Conduit calls when uninstalling applications Summary: Fixes T2698. When applications are installed, their Conduit calls should drop out. This will also let us land Releeph without exposing Conduit calls. Test Plan: - Viewed Conduit console; uninstalled some applications and verified their calls dropped out. - Tried to make an uninstalled call; got an appropriate error. Reviewers: edward, btrahan Reviewed By: edward CC: aran Maniphest Tasks: T2698 Differential Revision: https://secure.phabricator.com/D5302
2013-03-13 15:09:05 +01:00
'ConduitAPI_phpast_Method' => 'ConduitAPIMethod',
Replaced AphrontCrumbsView with PhabricatorCrumbsView in PhrictionDiffController Summary: Same as title Test Plan: By checking in Phriction UI in Phabricator Reviewers: epriestley, AnhNhan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5327
2013-03-13 23:15:58 +01:00
'ConduitAPI_phpast_getast_Method' => 'ConduitAPI_phpast_Method',
'ConduitAPI_phpast_version_Method' => 'ConduitAPI_phpast_Method',
Provide access to Phriction via Conduit Summary: Provide three Phriction methods for programmatic access to Phriction: - phriction.info: get information about a document - phriction.history: get change history for a document - phriction.edit: create or update a document I moved all the editing/creation logic into a new PhrictionDocumentEditor to share code between the Conduit and Web edit pathways. Test Plan: Got info and history via conduit. Edited and created new pages via conduit and web. Reviewers: hsb, jungejason, tuomaspelkonen, aran, hunterbridges Reviewed By: hunterbridges CC: skrul, aran, hunterbridges Differential Revision: 866
2011-08-26 21:50:28 +02:00
'ConduitAPI_phriction_Method' => 'ConduitAPIMethod',
'ConduitAPI_phriction_edit_Method' => 'ConduitAPI_phriction_Method',
'ConduitAPI_phriction_history_Method' => 'ConduitAPI_phriction_Method',
'ConduitAPI_phriction_info_Method' => 'ConduitAPI_phriction_Method',
Add project.query to Conduit Summary: Add a conduit method to query project information. Test Plan: Ran method from API test console. Reviewers: bill, btrahan, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T681 Differential Revision: https://secure.phabricator.com/D1444
2012-01-18 01:29:35 +01:00
'ConduitAPI_project_Method' => 'ConduitAPIMethod',
'ConduitAPI_project_query_Method' => 'ConduitAPI_project_Method',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ConduitAPI_releeph_Method' => 'ConduitAPIMethod',
'ConduitAPI_releeph_getbranches_Method' => 'ConduitAPI_releeph_Method',
'ConduitAPI_releeph_projectinfo_Method' => 'ConduitAPI_releeph_Method',
Add get Releeph Requests conduit method Summary: Added "getrequests" conduit method Test Plan: Open /conduit/method/differential.getrequests/ and try different inputs. Reviewers: edward, epriestley Reviewed By: edward CC: aran, epriestley, Korvin Maniphest Tasks: T3057 Differential Revision: https://secure.phabricator.com/D5788
2013-04-26 18:07:38 +02:00
'ConduitAPI_releeph_queryrequests_Method' => 'ConduitAPI_releeph_Method',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ConduitAPI_releeph_request_Method' => 'ConduitAPI_releeph_Method',
'ConduitAPI_releephwork_canpush_Method' => 'ConduitAPI_releeph_Method',
'ConduitAPI_releephwork_getauthorinfo_Method' => 'ConduitAPI_releeph_Method',
'ConduitAPI_releephwork_getbranch_Method' => 'ConduitAPI_releeph_Method',
'ConduitAPI_releephwork_getbranchcommitmessage_Method' => 'ConduitAPI_releeph_Method',
'ConduitAPI_releephwork_getcommitmessage_Method' => 'ConduitAPI_releeph_Method',
'ConduitAPI_releephwork_getorigcommitmessage_Method' => 'ConduitAPI_releeph_Method',
'ConduitAPI_releephwork_nextrequest_Method' => 'ConduitAPI_releeph_Method',
'ConduitAPI_releephwork_record_Method' => 'ConduitAPI_releeph_Method',
'ConduitAPI_releephwork_recordpickstatus_Method' => 'ConduitAPI_releeph_Method',
Add remarkup.process conduit method Summary: This exposes a few remarkup engines over conduit. Test Plan: Local conduit console, and playing with 'cat example.json | arc call-conduit remarkup.process' Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1551
2012-02-03 01:42:29 +01:00
'ConduitAPI_remarkup_process_Method' => 'ConduitAPIMethod',
Add "repository.create" and "repository.query" methods to Conduit Summary: Primarily for @csilvers who has 92 million repositories or something. This is a touch hacky, but movitated by pragmatism. Test Plan: - Ran "repository.create" to create repositories, "repository.query" to list them. - Tested most or maybe all of the error conditions, probably. Reviewers: btrahan, vrana, csilvers Reviewed By: csilvers CC: aran Differential Revision: https://secure.phabricator.com/D2396
2012-05-05 01:16:22 +02:00
'ConduitAPI_repository_Method' => 'ConduitAPIMethod',
'ConduitAPI_repository_create_Method' => 'ConduitAPI_repository_Method',
'ConduitAPI_repository_query_Method' => 'ConduitAPI_repository_Method',
Uninstall Conduit calls when uninstalling applications Summary: Fixes T2698. When applications are installed, their Conduit calls should drop out. This will also let us land Releeph without exposing Conduit calls. Test Plan: - Viewed Conduit console; uninstalled some applications and verified their calls dropped out. - Tried to make an uninstalled call; got an appropriate error. Reviewers: edward, btrahan Reviewed By: edward CC: aran Maniphest Tasks: T2698 Differential Revision: https://secure.phabricator.com/D5302
2013-03-13 15:09:05 +01:00
'ConduitAPI_slowvote_Method' => 'ConduitAPIMethod',
'ConduitAPI_slowvote_info_Method' => 'ConduitAPI_slowvote_Method',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'ConduitAPI_token_Method' => 'ConduitAPIMethod',
'ConduitAPI_token_give_Method' => 'ConduitAPI_token_Method',
'ConduitAPI_token_given_Method' => 'ConduitAPI_token_Method',
'ConduitAPI_token_query_Method' => 'ConduitAPI_token_Method',
Add user.info and phid.info Conduit methods Summary: Allow user and arbitrary object lookup by PHID. Test Plan: Executed user.whoami, user.info, user.find and phid.info via Conduit console. Reviewers: jungejason, tuomaspelkonen, aran, nh Reviewed By: nh CC: skrul, aran, nh, jungejason, epriestley Differential Revision: 870
2011-08-30 21:03:58 +02:00
'ConduitAPI_user_Method' => 'ConduitAPIMethod',
Allowing setting user status Summary: I will use it for highlighting users which are not currently available. Maybe I will also use it in the nagging tool. I don't plan creating a UI for it as API is currently enough for us. Maybe I will visualize it at /calendar/ later. I plan creating `user.deletestatus` method when this one will be done. Test Plan: `storage upgrade` Call Conduit `user.addstatus`. Verify DB. Reviewers: epriestley Reviewed By: epriestley CC: aran, Koolvin Differential Revision: https://secure.phabricator.com/D2382
2012-05-04 00:47:34 +02:00
'ConduitAPI_user_addstatus_Method' => 'ConduitAPI_user_Method',
Add Conduit method to disable user Summary: There's no method for enabling users somewhat intentionally. Test Plan: Disable myself (oops, this is probably my last diff ever). Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D2497
2012-05-18 20:51:24 +02:00
'ConduitAPI_user_disable_Method' => 'ConduitAPI_user_Method',
Add user.enable conduit method Test Plan: enabled a disabled user Reviewers: vrana, epriestley Reviewed By: vrana CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D2800
2012-06-19 23:36:08 +02:00
'ConduitAPI_user_enable_Method' => 'ConduitAPI_user_Method',
Add user.info and phid.info Conduit methods Summary: Allow user and arbitrary object lookup by PHID. Test Plan: Executed user.whoami, user.info, user.find and phid.info via Conduit console. Reviewers: jungejason, tuomaspelkonen, aran, nh Reviewed By: nh CC: skrul, aran, nh, jungejason, epriestley Differential Revision: 870
2011-08-30 21:03:58 +02:00
'ConduitAPI_user_find_Method' => 'ConduitAPI_user_Method',
'ConduitAPI_user_info_Method' => 'ConduitAPI_user_Method',
Conduit user.query method Summary: also includes a PhabricatorPeopleQuery object Test Plan: queried for various combinations username, realname, id, phid, and email. verified correct results. Reviewers: epriestley Reviewed By: epriestley CC: zeeg, aran, Koolvin Maniphest Tasks: T1075 Differential Revision: https://secure.phabricator.com/D2416
2012-05-07 22:35:09 +02:00
'ConduitAPI_user_query_Method' => 'ConduitAPI_user_Method',
Simplify transaction handling and restore read/write locks Summary: - We used to have connection-level caching, so we needed getTransactionKey() to make sure there was one transaction state per real connection. We now cache in Lisk and each Connection object is guaranteed to represent a real, unique connection, so we can make this a non-static. - I kept the classes separate because it was a little easier, but maybe we should merge them? - Also track/implement read/write locking. - (The advantage of this over just writing LOCK IN SHARE MODE is that you can use, e.g., some Query class even if you don't have access to the queries it runs.) Test Plan: Can you come up with a way to write unit tests for this? It seems like testing that it works requires deadlocking MySQL if the test is running in one process. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2398
2012-05-05 20:29:09 +02:00
'ConduitAPI_user_removestatus_Method' => 'ConduitAPI_user_Method',
Add user.info and phid.info Conduit methods Summary: Allow user and arbitrary object lookup by PHID. Test Plan: Executed user.whoami, user.info, user.find and phid.info via Conduit console. Reviewers: jungejason, tuomaspelkonen, aran, nh Reviewed By: nh CC: skrul, aran, nh, jungejason, epriestley Differential Revision: 870
2011-08-30 21:03:58 +02:00
'ConduitAPI_user_whoami_Method' => 'ConduitAPI_user_Method',
Allow applications to call Conduit directly Summary: Sorry this took so long, had a bunch of stuff going on today. Separate the actual core part of making conduit calls from the controller, so the application can make conduit calls without needing to invoke HTTP or redo auth. Generally, this lets us build more parts of the application on top of Conduit, as appropriate. This diff can be simplified, but I wanted to unblock you guys first. I'll followup with a cleanup patch once I have a chance. Test Plan: Ran unit tests, ran calls from the conduit API console, and ran calls over arc. Reviewers: nodren, 20after4, btrahan, vrana Reviewed By: 20after4 CC: aran, svemir Maniphest Tasks: T945 Differential Revision: https://secure.phabricator.com/D2718
2012-06-17 17:47:09 +02:00
'ConduitCallTestCase' => 'PhabricatorTestCase',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'ConduitException' => 'Exception',
Implement SSHD glue and Conduit SSH endpoint Summary: - Build "sshd-auth" (for authentication) and "sshd-exec" (for command execution) binaries. These are callable by "sshd-vcs", located [[https://github.com/epriestley/sshd-vcs | in my account on GitHub]]. They are based on precursors [[https://github.com/epriestley/sshd-vcs-glue | here on GitHub]] which I deployed for TenXer about a year ago, so I have some confidence they at least basically work. - The problem this solves is that normally every user would need an account on a machine to connect to it, and/or their public keys would all need to be listed in `~/.authorized_keys`. This is a big pain in most installs. Software like Gitosis/Gitolite solve this problem by giving you an easy way to add public keys to `~/.authorized_keys`, but this is pretty gross. - Roughly, instead of looking in `~/.authorized_keys` when a user connects, the patched sshd instead runs `echo <public key> | sshd-auth`. The `sshd-auth` script looks up the public key and authorizes the matching user, if they exist. It also forces sshd to run `sshd-exec` instead of a normal shell. - `sshd-exec` receives the authenticated user and any command which was passed to ssh (like `git receive-pack`) and can route them appropriately. - Overall, this permits a single account to be set up on a server which all Phabricator users can connect to without any extra work, and which can safely execute commands and apply appropriate permissions, and disable users when they are disabled in Phabricator and all that stuff. - Build out "sshd-exec" to do more thorough checks and setup, and delegate command execution to Workflows (they now exist, and did not when I originally built this stuff). - Convert @btrahan's conduit API script into a workflow and slightly simplify it (ConduitCall did not exist at the time it was written). The next steps here on the Repository side are to implement Workflows for Git, SVN and HG wire protocols. These will mostly just proxy the protocols, but also need to enforce permissions. So the approach will basically be: - Implement workflows for stuff like `git receive-pack`. - These workflows will implement enough of the underlying protocol to determine what resource the user is trying to access, and whether they want to read or write it. - They'll then do a permissons check, and kick the user out if they don't have permission to do whatever they are trying to do. - If the user does have permission, we just proxy the rest of the transaction. Next steps on the Conduit side are more simple: - Make ConduitClient understand "ssh://" URLs. Test Plan: Ran `sshd-exec --phabricator-ssh-user epriestley conduit differential.query`, etc. This will get a more comprehensive test once I set up sshd-vcs. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T550 Differential Revision: https://secure.phabricator.com/D4229
2012-12-19 20:08:07 +01:00
'ConduitSSHWorkflow' => 'PhabricatorSSHWorkflow',
Conpherence - reply handler integration Summary: Added a reply handler. A few problems -- first, I can't seem to get this to actually send me email so I haven't been able to reply (which I would have done by generating a reply, then copying the raw email into scripts/mail_handler.php). Second, the subject is often terrible on these emails -- unless the conpherence is named its something gross like "E4:" Third, on create I am noticing an error on array_combine() which I think is related to the need to write array_combine_not_broken or what have you I saw go by... (PhabricatorTransactionEditor does array_combine(xaction->getOldValue(), xaction->getOldValue()) and complains that the arrays are empty) Test Plan: noted that /mail/ said mails were being sent Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2399 Differential Revision: https://secure.phabricator.com/D4656
2013-01-26 01:03:54 +01:00
'ConpherenceConfigOptions' => 'PhabricatorApplicationConfigOptions',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceController' => 'PhabricatorController',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ConpherenceCreateThreadMailReceiver' => 'PhabricatorMailReceiver',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceDAO' => 'PhabricatorLiskDAO',
'ConpherenceEditor' => 'PhabricatorApplicationTransactionEditor',
Conpherence - people widget Summary: adds ye olde people widget. Features include - handle-based display, so we get status for free. (Note less pretty than M14 would have it!) - can add a person - can remove a person - can see the people already in the conpherence Test Plan: added and removed people and noted they joined / re-added as appropriate. Tried to add someone already in the conpherence and got a "transaction has no effect" message Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2399 Differential Revision: https://secure.phabricator.com/D5466
2013-04-02 18:32:40 +02:00
'ConpherenceFileWidgetView' => 'ConpherenceWidgetView',
Adding hovercard event listeners for Users, Revisions, Conpherence and Commits Summary: Refs T1048 Adding Differential Hovercard EventListener Adding People Hovercard EventListener Adding basic Diffusion hovercard Adding Conpherence Hovercard EventListener Test Plan: Used in a combo with working hovercards. So beautiful. Also visited test page. Works alright. awesometown Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1048 Differential Revision: https://secure.phabricator.com/D5576
2013-04-06 02:01:54 +02:00
'ConpherenceHovercardEventListener' => 'PhutilEventListener',
Consolidate Conpherence frame rendering Summary: Conpherence frame rendering is spread out a bit across ConpherenceController, ConpherenceListController, and previously ConpherenceNewController. I want to let the Thread and Widget controllers render the frame for mobile. Ref T2421. Test Plan: Viewed conpherences, switched between conpherences. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2421 Differential Revision: https://secure.phabricator.com/D5501
2013-04-01 21:43:07 +02:00
'ConpherenceLayoutView' => 'AphrontView',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceListController' => 'ConpherenceController',
'ConpherenceMenuItemView' => 'AphrontTagView',
'ConpherenceNewController' => 'ConpherenceController',
'ConpherenceParticipant' => 'ConpherenceDAO',
Conpherence - paginate thread list Summary: this is D5750 but just the conpherence part. fixes a few random conpherence bugs / quirks as well. Also messes with ApplicationTransactionEditor to expose the xactions so Conpherence doesn't over-update participation rows. Fixes T2429. Test Plan: set LIMIT to 3. verified I could scroll down all conpherences. next, picked a conpherence "in the middle" to load. verified I could page up and down. next, picked a conpherence in the middle then had another user update that conpherence. verified as I paged up the conpherence re-loaded properly selected Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin, vrana Maniphest Tasks: T2429 Differential Revision: https://secure.phabricator.com/D5783
2013-04-26 19:30:41 +02:00
'ConpherenceParticipantCountQuery' => 'PhabricatorOffsetPagedQuery',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceParticipantQuery' => 'PhabricatorOffsetPagedQuery',
'ConpherenceParticipationStatus' => 'ConpherenceConstants',
Update PeopleMenu to only show integration with applications if they are installed Summary: do so via event engine. note different order now... Test Plan: toggled "show beta applications" to off and noted that Conpherence disappeared. Otherwise noted that links showed. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2424 Differential Revision: https://secure.phabricator.com/D4708
2013-02-05 22:46:02 +01:00
'ConpherencePeopleMenuEventListener' => 'PhutilEventListener',
Conpherence - people widget Summary: adds ye olde people widget. Features include - handle-based display, so we get status for free. (Note less pretty than M14 would have it!) - can add a person - can remove a person - can see the people already in the conpherence Test Plan: added and removed people and noted they joined / re-added as appropriate. Tried to add someone already in the conpherence and got a "transaction has no effect" message Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2399 Differential Revision: https://secure.phabricator.com/D5466
2013-04-02 18:32:40 +02:00
'ConpherencePeopleWidgetView' => 'ConpherenceWidgetView',
Conpherence - reply handler integration Summary: Added a reply handler. A few problems -- first, I can't seem to get this to actually send me email so I haven't been able to reply (which I would have done by generating a reply, then copying the raw email into scripts/mail_handler.php). Second, the subject is often terrible on these emails -- unless the conpherence is named its something gross like "E4:" Third, on create I am noticing an error on array_combine() which I think is related to the need to write array_combine_not_broken or what have you I saw go by... (PhabricatorTransactionEditor does array_combine(xaction->getOldValue(), xaction->getOldValue()) and complains that the arrays are empty) Test Plan: noted that /mail/ said mails were being sent Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2399 Differential Revision: https://secure.phabricator.com/D4656
2013-01-26 01:03:54 +01:00
'ConpherenceReplyHandler' => 'PhabricatorMailReplyHandler',
Conpherence - add per thread notification setting Summary: Introduces a new settings panel for Conpherence specific settings. Test Plan: started a thread with a test user, thus two participants total. Replied to conpherence, toggling notification settings in between. Verified 1 or 2 emails were sent as appropos to the current toggle. Toggled global setting and verified setting was updated in conpherences where nothing was specified. Verified setting conpherence setting overrides global setting. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2521 Differential Revision: https://secure.phabricator.com/D5391
2013-03-26 21:30:35 +01:00
'ConpherenceSettings' => 'ConpherenceConstants',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceThread' =>
array(
0 => 'ConpherenceDAO',
1 => 'PhabricatorPolicyInterface',
),
Render Conpherence threads as a separate menu inside the layout, not a side nav Summary: Currently, the thread list is in a standard side nav, but that makes it awkward to render (rendering logic needs to live in the base controller) and gives it some bad beahviors (like autohiding on mobile). Instead, move it into its own view and make it a little more custom. Ref T2421. Test Plan: {F38098} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T2421 Differential Revision: https://secure.phabricator.com/D5504
2013-04-01 21:50:39 +02:00
'ConpherenceThreadListView' => 'AphrontView',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ConpherenceThreadMailReceiver' => 'PhabricatorObjectMailReceiver',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceThreadQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Conpherence - implement epoch creation slightly differently Summary: D6114 fixed some bugs but on production it shows up as a new bug where Saturday is the first day? stop messing with the DateTime object so much and do some old school epoch manipulation. This works correctly on my laptop and my still fail in production, but it will rule out DateTime suckage. Test Plan: still works on laptop Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6115
2013-06-04 00:40:00 +02:00
'ConpherenceTimeUtilTestCase' => 'PhabricatorTestCase',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceTransaction' => 'PhabricatorApplicationTransaction',
'ConpherenceTransactionComment' => 'PhabricatorApplicationTransactionComment',
'ConpherenceTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'ConpherenceTransactionType' => 'ConpherenceConstants',
'ConpherenceTransactionView' => 'AphrontView',
Conpherence - continue the load less quest Summary: basically makes it so we only really load what we need from the server for any particular update action. the javascript thus then has some things deleted from it. made a spot or two ready for when the pertinent UI won't be there as well. also added a feature in javascript -- updating the document title to the current conpherence title. Ref T2867 T2399 Test Plan: played with conpherence for quite a bit. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2867 Differential Revision: https://secure.phabricator.com/D5625
2013-04-10 20:37:04 +02:00
'ConpherenceUpdateActions' => 'ConpherenceConstants',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceUpdateController' => 'ConpherenceController',
'ConpherenceViewController' => 'ConpherenceController',
Renders the last 100 conpherence transactions only Summary: Fixed T2428 a little bit Test Plan: On trial, only the last n transactions loaded as hardcoded in ConpherenceViewController.php. Button was rendered. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2428 Differential Revision: https://secure.phabricator.com/D4898
2013-02-15 23:01:27 +01:00
'ConpherenceWidgetController' => 'ConpherenceController',
Conpherence - people widget Summary: adds ye olde people widget. Features include - handle-based display, so we get status for free. (Note less pretty than M14 would have it!) - can add a person - can remove a person - can see the people already in the conpherence Test Plan: added and removed people and noted they joined / re-added as appropriate. Tried to add someone already in the conpherence and got a "transaction has no effect" message Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2399 Differential Revision: https://secure.phabricator.com/D5466
2013-04-02 18:32:40 +02:00
'ConpherenceWidgetView' => 'AphrontView',
Countdown revamp 2 Summary: Now has policy support (not really) Now uses CountdownQuery Now has handles Now uses common way for remarkup Remarkup still looks terrible Test Plan: Added countdowns, edited countdowns. Did even embed some. Couldn't break it Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2624 Differential Revision: https://secure.phabricator.com/D6012
2013-05-23 15:47:54 +02:00
'CountdownQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Flesh out some DarkConsole stuff.
2011-02-03 07:38:42 +01:00
'DarkConsoleController' => 'PhabricatorController',
DarkConsole: fix rendering, move request log, load over ajax Summary: This accomplishes three major goals: # Fixes phutil_render_tag -> phutil_tag callsites in DarkConsole. # Moves the Ajax request log to a new panel on the left. This panel (and the tabs panel) get scrollbars when they get large, instead of making the page constantly scroll down. # Loads the panel content over ajax, instead of dumping it into the page body / ajax response body. I've been planning to do this for about 3 years, which is why the plugins are architected the way they are. This should make debugging easier by making response bodies not be 50%+ darkconsole stuff. Additionally, load the plugins dynamically (the old method predates library maps and PhutilSymbolLoader). Test Plan: {F30675} - Switched between requests and tabs, reloaded page, saw same tab. - Used "analyze queries", "profile page", triggered errors. - Verified page does not load anything by default if dark console is closed with Charles. - Generally banged on it a bit. Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2432 Differential Revision: https://secure.phabricator.com/D4692
2013-01-29 03:45:32 +01:00
'DarkConsoleDataController' => 'PhabricatorController',
Very rough cut of DarkConsole + XHProf
2011-02-02 22:48:52 +01:00
'DarkConsoleErrorLogPlugin' => 'DarkConsolePlugin',
Add an "Event" plugin to DarkConsole for event inspection Summary: Shows events which a page dispatched, plus all the registered listeners. Test Plan: Pretty basic for now, but works OK: https://secure.phabricator.com/file/view/PHID-FILE-49fcd23081ce55cf9369/ (I also made it dispatch some dummy events to verify they show up.) Reviewers: aran Reviewed By: aran CC: aran Differential Revision: 973
2011-09-30 21:54:17 +02:00
'DarkConsoleEventPlugin' => 'DarkConsolePlugin',
Move event framework from Phabricator to libphutil Summary: Move event framework from Phabricator to libphutil so it can be used in other phutil projects, such as Arcanist. Test plan: Use along with path to libphutil, events should work as expected. Reviewers: epriestley Differential Revision: 1098
2011-11-10 02:23:33 +01:00
'DarkConsoleEventPluginAPI' => 'PhutilEventListener',
Very rough cut of DarkConsole + XHProf
2011-02-02 22:48:52 +01:00
'DarkConsoleRequestPlugin' => 'DarkConsolePlugin',
'DarkConsoleServicesPlugin' => 'DarkConsolePlugin',
'DarkConsoleXHProfPlugin' => 'DarkConsolePlugin',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'DefaultDatabaseConfigurationProvider' => 'DatabaseConfigurationProvider',
Improve behavior when user submits a no-op action in Differential Summary: See T730 and the slightly-less-pretty version of this in D1398. When a user takes an action in Differential that has no effect (for instance, accepting an already-accepted revision), prompt them: Action Has No Effect You can not accept this revision because it has already been accepted. Do you want to post the feedback anyway, as a normal comment? [Cancel] [Post as Comment] If they have no comment text, the dialog only says "Cancel". I think this is probably the best way to balance all the concerns here -- it might occasionally be a little annoying, but that should be rare, and it should never be confusing (the current workflow is extremely confusing). This also fixes the issue where you can add all sorts of CCs who are already part of the revision, either explicitly or via mentions. Test Plan: Posted some has-effect and has-no-effect comments, made different choices in the dialog, everything seems to work OK? Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran, vrana Maniphest Tasks: T730 Differential Revision: https://secure.phabricator.com/D1403
2012-01-14 20:39:22 +01:00
'DifferentialActionHasNoEffectException' => 'DifferentialException',
AddCommentView
2011-01-30 20:02:22 +01:00
'DifferentialAddCommentView' => 'AphrontView',
Build an "affected path" index when attaching diffs to revisions Summary: See T262. This creates the index on the Differential side which we need in order to execute this query efficiently on the Diffusion side. Also renames "DiffusionGitPathIDQuery" to "DiffusionPathIDQuery", this query object has nothing to do with git. Test Plan: Attached top-level and sub-level diffs to revisions and verified they populated the table with sensible data. Reviewers: bmaurer, aravindn, fmoo, jungejason, nh, tuomaspelkonen, aran CC: Differential Revision: 931
2011-09-14 19:59:52 +02:00
'DifferentialAffectedPath' => 'DifferentialDAO',
Move Differential's simple fields to the extensible field schema Summary: Differential has a bunch of display-only fields, implement them all as field specifications instead of hard-coded fields. Also add some more documentation and fix redundant string constants in blame rev/revert plan fields. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 807
2011-08-14 20:29:56 +02:00
'DifferentialApplyPatchFieldSpecification' => 'DifferentialFieldSpecification',
Move Differential's read-only fields to the extensible field schema Summary: Move additional fields (which rely on loading handles) to the extensible field classes and out of hardcoding in the controller. Depends on D807. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 808
2011-08-14 21:33:54 +02:00
'DifferentialArcanistProjectFieldSpecification' => 'DifferentialFieldSpecification',
Add an "Auditors" field to commit messages which pushes audit requests when present Summary: Adds an optional "Auditors" field (like "Reviewers") to commit messages which gives installs a zero-config method for making audit requests. This field does not appear on templates unless set, and is mostly ignored (but validated and preserved) by Differential. It is then parsed by the daemons if present, and audit requests are pushed to valid users. Test Plan: Made an "Auditors" commit and verified it was retained with "arc amend --show". Pushed it and verified the audit was triggered. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904, T880 Differential Revision: https://secure.phabricator.com/D1793
2012-03-07 00:10:35 +01:00
'DifferentialAuditorsFieldSpecification' => 'DifferentialFieldSpecification',
Move Differential's read-only fields to the extensible field schema Summary: Move additional fields (which rely on loading handles) to the extensible field classes and out of hardcoding in the controller. Depends on D807. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 808
2011-08-14 21:33:54 +02:00
'DifferentialAuthorFieldSpecification' => 'DifferentialFieldSpecification',
Add basic auxiliary field storage for Differential Summary: Precursor to building this out to solve T343. This is similar to the Maniphest fields we landed recently, although I think they're dissimilar enough that it isn't worth going crazy trying to make them share code, at least for now. This doesn't really do anything yet, just adds a storage object and a couple of selector/field indirection classes. Test Plan: Ran SQL upgrade script, created an aux field. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason Differential Revision: 798
2011-08-10 20:29:08 +02:00
'DifferentialAuxiliaryField' => 'DifferentialDAO',
Provide builtin definitions for "Blame Revision" and "Revert Plan" fields Summary: This is just to ease transitions for any installs which use these fields (e.g., Facebook). I'll write some docs and a migration script once this stuff is a little more solid, too. Depends on D800. Technically these are "better" than the current fields since they show up other places than the edit screen (derp derp). Test Plan: Created a field selector which provides these; verified they work by typing stuff into them and saving the revision. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, epriestley, jungejason Differential Revision: 801
2011-08-11 00:36:18 +02:00
'DifferentialBlameRevisionFieldSpecification' => 'DifferentialFieldSpecification',
Separate field for branch in revision Summary: The main purpose of this change is to allow selecting the branch by triple-click. Plus it is not perfectly clear that the text in brackets means branch. Test Plan: Display revision. Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1585
2012-02-07 01:34:25 +01:00
'DifferentialBranchFieldSpecification' => 'DifferentialFieldSpecification',
DifferentialRevisionEditor
2011-01-26 02:17:19 +01:00
'DifferentialCCWelcomeMail' => 'DifferentialReviewRequestMail',
Move Differential's remaining field views to extensble field schema Summary: Move all the rest of the fields into the custom field schema, for revision views. I left a couple of stubs in here (willWriteRevision, didWriteRevision) since I'd planned to do edits here too, but this diff is sort of big-ish already. I'll do all the edit fields in the next revision. Depends on D808. Test Plan: Viewed, edited and conduit'ed some revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 809
2011-08-14 22:55:30 +02:00
'DifferentialCCsFieldSpecification' => 'DifferentialFieldSpecification',
Conduit: differential.creatediff
2011-01-24 20:01:53 +01:00
'DifferentialChangeset' => 'DifferentialDAO',
DifferentialDiffView
2011-01-24 22:18:41 +01:00
'DifferentialChangesetDetailView' => 'AphrontView',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialChangesetHTMLRenderer' => 'DifferentialChangesetRenderer',
make differential use fluid width for code layout Summary: assume at least 360px for a given code pane. that's about when the comment box starts fighting back anyway. we'll use the yet-to-be-built one page render for the narrow viewport cases. This address the cases as laid out in T2005. It fails the "MMMMM" case pretty horribly. However, if there is a space it works just fine and presumably folks are stretching out their windows on big glorious monitors at 160 characters wide or whatever. Re-factored things just a tad but figure I'll take a nice big chunk of "renderer" to move forward T2009 Test Plan: looked at all sorts of funky diffs Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2005 Differential Revision: https://secure.phabricator.com/D4083
2012-12-06 20:33:04 +01:00
'DifferentialChangesetListView' => 'AphrontView',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialChangesetOneUpRenderer' => 'DifferentialChangesetHTMLRenderer',
'DifferentialChangesetOneUpTestRenderer' => 'DifferentialChangesetTestRenderer',
'DifferentialChangesetParserTestCase' => 'PhabricatorTestCase',
'DifferentialChangesetTestRenderer' => 'DifferentialChangesetRenderer',
'DifferentialChangesetTwoUpRenderer' => 'DifferentialChangesetHTMLRenderer',
'DifferentialChangesetTwoUpTestRenderer' => 'DifferentialChangesetTestRenderer',
DifferentialChangesetView
2011-01-25 00:52:35 +01:00
'DifferentialChangesetViewController' => 'DifferentialController',
Simplify lightboxing and fix a few things Summary: Minor tweaks to lightboxes. - With "position: fixed;", we don't need to do any of the scroll/resize stuff. Just remove it. - Make the lightbox go over the menu bar -- was it intentional that it wasn't? - Make 'jx-mask' use "position: fixed;" too. - Add a loading indicator. - In Differential/Maniphest/etc, a preview may bring in an image but won't bring in the CSS we need. The "real" fix is to ship CSS/JS with ajax, but that's really hard -- fake it by pulling in the right CSS any time we render a remarkup area. I'm going to do a couple of other tweaks here but need to update JX.Mask. Test Plan: Verified behavior is reasonable in Safari, Firefox, Chrome with multiple images / scroll / previews / resize. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1896 Differential Revision: https://secure.phabricator.com/D3795
2012-10-24 02:34:43 +02:00
'DifferentialComment' =>
array(
0 => 'DifferentialDAO',
1 => 'PhabricatorMarkupInterface',
),
If users are on the email to Phabricator, do not send them the Phabricator reply. Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email. Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected. Reviewers: epriestley, vrana Reviewed By: vrana CC: aran, Korvin, vrana Maniphest Tasks: T1676 Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 19:18:23 +02:00
'DifferentialCommentEditor' => 'PhabricatorEditor',
Write pathway for Differential Comments
2011-01-30 21:08:40 +01:00
'DifferentialCommentMail' => 'DifferentialMail',
Differential comment previews.
2011-02-01 03:05:20 +01:00
'DifferentialCommentPreviewController' => 'DifferentialController',
Write pathway for Differential Comments
2011-01-30 21:08:40 +01:00
'DifferentialCommentSaveController' => 'DifferentialController',
Move Differential's read-only fields to the extensible field schema Summary: Move additional fields (which rely on loading handles) to the extensible field classes and out of hardcoding in the controller. Depends on D807. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 808
2011-08-14 21:33:54 +02:00
'DifferentialCommitsFieldSpecification' => 'DifferentialFieldSpecification',
Parse Conflicts field in commit message Summary: Git adds it automatically. I don't like this solution much because there could be other unknown fields appended to the end of the commit message which will break parsing. Test Plan: Reparsed commit ending with: > Differential Revision: ... > Conflicts: ... Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4157
2012-12-12 01:34:08 +01:00
'DifferentialConflictsFieldSpecification' => 'DifferentialFieldSpecification',
DifferentialDiffView
2011-01-24 22:18:41 +01:00
'DifferentialController' => 'PhabricatorController',
Conduit: differential.creatediff
2011-01-24 20:01:53 +01:00
'DifferentialDAO' => 'PhabricatorLiskDAO',
Drive differential revision list with custom fields Summary: Build the revision list table out of custom fields instead of hard-coding it, so installs can add all sorts of zany things to it. NOTE: You may need to implement sortFieldsForRevisionList() if you have a custom DifferentialFieldSelector, or some fields might show up out of order. This implementation will preserve the expected behavior: public function sortFieldsForRevisionList(array $fields) { $default = new DifferentialDefaultFieldSelector(); return $default->sortFieldsForRevisionList($fields); } Test Plan: - Loaded differential revision list, identical to old list. - Profiled page to verify the cost increase isn't significant (it's quite small). Reviewers: jungejason, btrahan Reviewed By: btrahan CC: aran, btrahan, davidreuss, epriestley Maniphest Tasks: T773, T729 Differential Revision: https://secure.phabricator.com/D1388
2012-02-20 14:38:21 +01:00
'DifferentialDateCreatedFieldSpecification' => 'DifferentialFieldSpecification',
'DifferentialDateModifiedFieldSpecification' => 'DifferentialFieldSpecification',
Add basic auxiliary field storage for Differential Summary: Precursor to building this out to solve T343. This is similar to the Maniphest fields we landed recently, although I think they're dissimilar enough that it isn't worth going crazy trying to make them share code, at least for now. This doesn't really do anything yet, just adds a storage object and a couple of selector/field indirection classes. Test Plan: Ran SQL upgrade script, created an aux field. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason Differential Revision: 798
2011-08-10 20:29:08 +02:00
'DifferentialDefaultFieldSelector' => 'DifferentialFieldSelector',
Move Differential's read-only fields to the extensible field schema Summary: Move additional fields (which rely on loading handles) to the extensible field classes and out of hardcoding in the controller. Depends on D807. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 808
2011-08-14 21:33:54 +02:00
'DifferentialDependenciesFieldSpecification' => 'DifferentialFieldSpecification',
Display dependent revisions in revision detail Summary: I have a chain of revisions sometimes. I want to see also revisions depending on me. Test Plan: Displayed revision in the middle of chain. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3399
2012-08-29 00:24:01 +02:00
'DifferentialDependsOnFieldSpecification' => 'DifferentialFieldSpecification',
Conduit: differential.creatediff
2011-01-24 20:01:53 +01:00
'DifferentialDiff' => 'DifferentialDAO',
DifferentialRevisionEditor
2011-01-26 02:17:19 +01:00
'DifferentialDiffContentMail' => 'DifferentialMail',
Differential lazyweb diff create workflow.
2011-02-05 21:20:18 +01:00
'DifferentialDiffCreateController' => 'DifferentialController',
Conduit: differential.setdiffproperty
2011-01-24 21:07:34 +01:00
'DifferentialDiffProperty' => 'DifferentialDAO',
DifferentialDiffView
2011-01-24 22:18:41 +01:00
'DifferentialDiffTableOfContentsView' => 'AphrontView',
Don't skip even lines in copied code detector Summary: PHP 3 basics: `each()` advances internal pointer so calling `next()` is wrong. Test Plan: New test. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4011
2012-11-21 21:30:38 +01:00
'DifferentialDiffTestCase' => 'ArcanistPhutilTestCase',
DifferentialDiffView
2011-01-24 22:18:41 +01:00
'DifferentialDiffViewController' => 'DifferentialController',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'DifferentialException' => 'Exception',
Add reply handler for differential revision Summary: add email reply handler so that the user can reply to a differential email to act on the revision. It generates the reply-to email address, creates email body text with supported commands list, and handle the action request on the differential revision. Right now the reply-to handing is disabled in the config file. But a site using Phabricator can enable it and implement a class inheriting from DifferentialReplyHandler to enable customized email handing. Later we will need to add code to DifferentialMail.php to support sending separate email to each email recipient to achieve better security (see D226). The reply-to will be something like D<revision_id>+<user_id>+<hash>@domain.com. We will create separate task for it. Test Plan: tried comment on a revision from web UI and the email was sent out as before without any change. When a subclass of DifferentialReplyHandler is implemented and enabled, email's reply-to is set and email text is added. Reply to the email with valid command did create action to the revision. Reviewed By: epriestley Reviewers: tuomaspelkonen, epriestley, slawekbiel, dpepper CC: aran, epriestley, jungejason Differential Revision: 224
2011-05-01 04:40:05 +02:00
'DifferentialExceptionMail' => 'DifferentialMail',
Move Differential's simple fields to the extensible field schema Summary: Differential has a bunch of display-only fields, implement them all as field specifications instead of hard-coded fields. Also add some more documentation and fix redundant string constants in blame rev/revert plan fields. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 807
2011-08-14 20:29:56 +02:00
'DifferentialExportPatchFieldSpecification' => 'DifferentialFieldSpecification',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'DifferentialFieldDataNotAvailableException' => 'Exception',
'DifferentialFieldParseException' => 'Exception',
'DifferentialFieldSpecificationIncompleteException' => 'Exception',
'DifferentialFieldValidationException' => 'Exception',
Detect tasks referenced in commit messages and either link or update the mentioned tasks. Refs T945 Summary: This takes the place of D2721 which I am going to abandon. Test Plan: * Make a commit with "Closes T###" in the summary field. See that the mentioned task gets closed. * Make a commit with "refs T###" in the summary. See that it gets added as a related commit via edges. Reviewers: 20after4 Reviewed By: epriestley CC: aran, Korvin, champo Maniphest Tasks: T945 Differential Revision: https://secure.phabricator.com/D3466
2012-09-11 19:37:30 +02:00
'DifferentialFreeformFieldSpecification' => 'DifferentialFieldSpecification',
Parse VCS revert langauge in commit messages Summary: Ref T1751. When commit messages include language like "reverts X", parse it. This change doesn't do anything with the commits yet. I attempted to cover all "natural" VCS messages and all reasonable human variations of these messages. Test Plan: Added unit tests. Added `var_dump()` and used `scripts/repository/reparse.php --message X` to reparse some commit messages, with expected results. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1751 Differential Revision: https://secure.phabricator.com/D5840
2013-05-06 21:33:37 +02:00
'DifferentialFreeformFieldTestCase' => 'PhabricatorTestCase',
Drive revision update from Conduit via custom fields Summary: When we create or update a revision, we use a parsed commit message dictionary to edit its fields. Drive consumption of the dictionary through custom fields instead of hardcoding. This requires adding some fields which don't really do anything right now to cover fields which appear only in the commit message. Test Plan: "arc diff"'d this revision against localhost, "arc diff"'d again to update. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason Differential Revision: 811
2011-08-15 03:52:09 +02:00
'DifferentialGitSVNIDFieldSpecification' => 'DifferentialFieldSpecification',
Move Differential's simple fields to the extensible field schema Summary: Differential has a bunch of display-only fields, implement them all as field specifications instead of hard-coded fields. Also add some more documentation and fix redundant string constants in blame rev/revert plan fields. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 807
2011-08-14 20:29:56 +02:00
'DifferentialHostFieldSpecification' => 'DifferentialFieldSpecification',
Adding hovercard event listeners for Users, Revisions, Conpherence and Commits Summary: Refs T1048 Adding Differential Hovercard EventListener Adding People Hovercard EventListener Adding basic Diffusion hovercard Adding Conpherence Hovercard EventListener Test Plan: Used in a combo with working hovercards. So beautiful. Also visited test page. Works alright. awesometown Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1048 Differential Revision: https://secure.phabricator.com/D5576
2013-04-06 02:01:54 +02:00
'DifferentialHovercardEventListener' => 'PhutilEventListener',
Conduit: differential.creatediff
2011-01-24 20:01:53 +01:00
'DifferentialHunk' => 'DifferentialDAO',
re-factor DifferentialChangesetParser pass 3 / N Summary: introducing a new friend called DifferentialHunkParser. Sort of like the DifferentialChangesetParser but works with hunks only. tried to grab hunk parsing type things from across the code base and move them into this new class. Test Plan: unit tests and played around in Differential a bit. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4351
2013-01-09 22:11:17 +01:00
'DifferentialHunkParserTestCase' => 'PhabricatorTestCase',
Simplify DifferentialHunk::getAddedLines() Summary: I will also need `getRemovedLines()` so refactor this first. Test Plan: New test case. Viewed uncached diff. Verified that the only callsite of `getAddedLines()` trims lines. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D2875
2012-06-27 19:44:29 +02:00
'DifferentialHunkTestCase' => 'ArcanistPhutilTestCase',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'DifferentialInlineComment' =>
array(
0 => 'DifferentialDAO',
1 => 'PhabricatorInlineCommentInterface',
),
Add inline comments to Diffusion/Audit Summary: - Add inline comments to Audits, like Differential. - Creates new storage for the comments in the Audits database. - Creates a new PhabricatorAuditInlineComment class, similar to DifferentialInlineComment. - Defines an Interface which Differential and Audit comments conform to. - Makes consumers of DifferentialInlineComments consume objects which implement that interface instead. - Adds save NOTE: Some features are still missing! Wanted to cut this off before it got crazy: - Inline comments aren't shown in the main comment list. - Inline comments aren't shown in the emails. - Inline comments aren't previewed. I'll followup with those but this was getting pretty big. @vrana, does the SQL change look correct? Test Plan: - Created, edited, deleted, replied to, reloaded and saved inline comments in Diffusion, on the left and right side of diffs. - Created, edited, deleted, replied to, reloaded and saved inline comments in Differentila, on the left and right side of primary and diff-versus-diff diffs. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1898
2012-03-14 20:56:01 +01:00
'DifferentialInlineCommentEditController' => 'PhabricatorInlineCommentController',
Use an inline dialog element for inline comments in Differential Summary: The current approach of using a modal overlay dialog to create/edit inline comments is pretty silly. Use an inline textarea instead. This element isn't perfect and we have some mild modalness issues, but I think it's better than the silly thing we've got going on right now. We can keep poking it as people break it. Test Plan: - Created comments; submitted and undid them in empty and nonempty states. Used undo for nonempty states + cancel. - Edited comments; saved and canceled them. Used undo for changed state. - Replied to comments; yada yada as above. - Deleted comments. - Did various modal trickery where I clicked "Reply" on something else with a dialog already up, this very mildly glitches but I think it's not a big issue. Reviewers: vrana, btrahan, Makinde, nh Reviewed By: vrana CC: aran, epriestley Maniphest Tasks: T431 Differential Revision: https://secure.phabricator.com/D1716
2012-02-29 23:28:48 +01:00
'DifferentialInlineCommentEditView' => 'AphrontView',
Make inline comment preview work in Diffusion Summary: created a PhabricatorInlineCommentPreviewController so controllers in Diffusion and Differential respectively just have to handle the URI mapping and data loading like good little controllers. Test Plan: left inline comments on commits, deleted inline commits, submitted inline comments -- all worked well did the same on some diffs Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1176 Differential Revision: https://secure.phabricator.com/D3034
2012-07-23 20:01:28 +02:00
'DifferentialInlineCommentPreviewController' => 'PhabricatorInlineCommentPreviewController',
InlineComments
2011-02-02 01:42:36 +01:00
'DifferentialInlineCommentView' => 'AphrontView',
Move Differential's simple fields to the extensible field schema Summary: Differential has a bunch of display-only fields, implement them all as field specifications instead of hard-coded fields. Also add some more documentation and fix redundant string constants in blame rev/revert plan fields. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 807
2011-08-14 20:29:56 +02:00
'DifferentialLinesFieldSpecification' => 'DifferentialFieldSpecification',
Move Differential's remaining field views to extensble field schema Summary: Move all the rest of the fields into the custom field schema, for revision views. I left a couple of stubs in here (willWriteRevision, didWriteRevision) since I'd planned to do edits here too, but this diff is sort of big-ish already. I'll do all the edit fields in the next revision. Depends on D808. Test Plan: Viewed, edited and conduit'ed some revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 809
2011-08-14 22:55:30 +02:00
'DifferentialLintFieldSpecification' => 'DifferentialFieldSpecification',
Display local commit information in Differential Summary: After D857, we try to attach local commit information to revisions. If this information is available, display it on the revision. Design on this is a little rough, I might try to combine this into the revision update view or something like that since we're starting to take up a lot of real estate for metadata. Test Plan: Local diffed this and got some commit info. Reviewers: jungejason, tuomaspelkonen, aran Reviewed By: jungejason CC: aran, epriestley, jungejason Differential Revision: 872
2011-08-30 20:34:07 +02:00
'DifferentialLocalCommitsView' => 'AphrontView',
Require a viewer to load handles Summary: Unmuck almost all of the we-sort-of-have-viewers-some-of-the-time mess. There are a few notable cases here: - I used Omnipotent users when indexing objects for search. I think this is correct; we do policy filtering when showing results. - I cheated in a bad way in the Remarkup object rule, but fixing this requires fixing all the PhabricatorRemarkupEngine callsites (there are 85). I'll do that in the next diff. - I cheated in a few random places, like when sending mail about package edits. These aren't a big deal. Test Plan: - Grepped for all PhabricatorObjectHandleData references. - Gave them viewers. Reviewers: vrana Reviewed By: vrana CC: aran, edward Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D5151
2013-03-01 02:15:09 +01:00
'DifferentialMail' => 'PhabricatorMail',
Move Differential's read-only fields to the extensible field schema Summary: Move additional fields (which rely on loading handles) to the extensible field classes and out of hardcoding in the controller. Depends on D807. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 808
2011-08-14 21:33:54 +02:00
'DifferentialManiphestTasksFieldSpecification' => 'DifferentialFieldSpecification',
DifferentialRevisionEditor
2011-01-26 02:17:19 +01:00
'DifferentialNewDiffMail' => 'DifferentialReviewRequestMail',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialParseRenderTestCase' => 'PhabricatorTestCase',
Move Differential's simple fields to the extensible field schema Summary: Differential has a bunch of display-only fields, implement them all as field specifications instead of hard-coded fields. Also add some more documentation and fix redundant string constants in blame rev/revert plan fields. Test Plan: Viewed, edited, and hit conduit for revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 807
2011-08-14 20:29:56 +02:00
'DifferentialPathFieldSpecification' => 'DifferentialFieldSpecification',
Update PeopleMenu to only show integration with applications if they are installed Summary: do so via event engine. note different order now... Test Plan: toggled "show beta applications" to off and noted that Conpherence disappeared. Otherwise noted that links showed. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2424 Differential Revision: https://secure.phabricator.com/D4708
2013-02-05 22:46:02 +01:00
'DifferentialPeopleMenuEventListener' => 'PhutilEventListener',
make differential use fluid width for code layout Summary: assume at least 360px for a given code pane. that's about when the comment box starts fighting back anyway. we'll use the yet-to-be-built one page render for the narrow viewport cases. This address the cases as laid out in T2005. It fails the "MMMMM" case pretty horribly. However, if there is a space it works just fine and presumably folks are stretching out their windows on big glorious monitors at 160 characters wide or whatever. Re-factored things just a tad but figure I'll take a nice big chunk of "renderer" to move forward T2009 Test Plan: looked at all sorts of funky diffs Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2005 Differential Revision: https://secure.phabricator.com/D4083
2012-12-06 20:33:04 +01:00
'DifferentialPrimaryPaneView' => 'AphrontView',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'DifferentialReleephRequestFieldSpecification' => 'DifferentialFieldSpecification',
Missing change from D5120 which I incorrectly discarded in a merge. Auditors: vrana
2013-02-27 16:18:30 +01:00
'DifferentialRemarkupRule' => 'PhabricatorRemarkupRuleObject',
Support email multiplexing for private Reply-To addresses Summary: Provide a base PhabricatorMailReplyHandler class which handles the plumbing for multiplexing email if necessary and supporting public and private reply handler addressses. DifferentialReplyHandler now extends it, and a new ManiphestReplyHandler also does. The general approach here is that we have three supported cases: - no reply handler, default config, same as what we're doing now - public reply handler, requires overriding classes but just sets "reply-to" to some address the install generates and still sends only one email - private reply handler, provides a default generation mechanism or you can override it and splits mail apart so we send one to each recipient Test Plan: Sent email from Maniphest and Differential with and without reply-handler-domains set. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran CC: aran, epriestley Differential Revision: 254
2011-05-10 01:31:26 +02:00
'DifferentialReplyHandler' => 'PhabricatorMailReplyHandler',
Further improve unit/lint rendering Summary: I think this improves things, let me know if you have feedback. Also addresses T840. Test Plan: See screenshots... Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran, zeeg Maniphest Tasks: T840 Differential Revision: https://secure.phabricator.com/D2357
2012-05-01 19:15:56 +02:00
'DifferentialResultsTableView' => 'AphrontView',
Provide builtin definitions for "Blame Revision" and "Revert Plan" fields Summary: This is just to ease transitions for any installs which use these fields (e.g., Facebook). I'll write some docs and a migration script once this stuff is a little more solid, too. Depends on D800. Technically these are "better" than the current fields since they show up other places than the edit screen (derp derp). Test Plan: Created a field selector which provides these; verified they work by typing stuff into them and saving the revision. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, epriestley, jungejason Differential Revision: 801
2011-08-11 00:36:18 +02:00
'DifferentialRevertPlanFieldSpecification' => 'DifferentialFieldSpecification',
DifferentialRevisionEditor
2011-01-26 02:17:19 +01:00
'DifferentialReviewRequestMail' => 'DifferentialMail',
Drive revision update from Conduit via custom fields Summary: When we create or update a revision, we use a parsed commit message dictionary to edit its fields. Drive consumption of the dictionary through custom fields instead of hardcoding. This requires adding some fields which don't really do anything right now to cover fields which appear only in the commit message. Test Plan: "arc diff"'d this revision against localhost, "arc diff"'d again to update. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason Differential Revision: 811
2011-08-15 03:52:09 +02:00
'DifferentialReviewedByFieldSpecification' => 'DifferentialFieldSpecification',
Compute reviewer stats Summary: The final goal is to display reviewers response time on homepage. This is a building block for it. The algorithm is quite strict - it doesn't count simple comment as response because reviewers would be able to cheat with comments like "I'm overwhelmed right now and will review next week". We are more liberate in Phabricator where reviewers response with comments without changing the status quite often but I'm not trying to improve response times in Phabricator so this is irrelevant. Reviewers in Facebook changes status more often (to clean their queue) so I follow this approach. There is currently no way to track reviewers silently added and removed in Edit Revision but it's not a big deal. The algorithm doesn't track commandeered revision, there's a TODO for it. Response times are put in two buckets: `$reviewed` and `$not_reviewed`. `$reviewed` contains reviewers who took action, `$not_reviewed` contains reviewers who didn't respond on time. I will probably compute average time from `$reviewed` and raise it for those `$not_reviewed` that are higher than this average. The idea is to not favor reviewers who were only lucky for being in a group with someone fast. Test Plan: Passed test. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3062
2012-07-25 02:58:33 +02:00
'DifferentialReviewerStatsTestCase' => 'PhabricatorTestCase',
Move Differential's remaining field views to extensble field schema Summary: Move all the rest of the fields into the custom field schema, for revision views. I left a couple of stubs in here (willWriteRevision, didWriteRevision) since I'd planned to do edits here too, but this diff is sort of big-ish already. I'll do all the edit fields in the next revision. Depends on D808. Test Plan: Viewed, edited and conduit'ed some revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 809
2011-08-14 22:55:30 +02:00
'DifferentialReviewersFieldSpecification' => 'DifferentialFieldSpecification',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'DifferentialRevision' =>
array(
0 => 'DifferentialDAO',
1 => 'PhabricatorTokenReceiverInterface',
2 => 'PhabricatorPolicyInterface',
Implemented Phrequent time tracking functionality. Summary: This differential implements Phrequent's time tracking functionality for users and hooks it up to Maniphest. It also includes a basic "Time Tracked" list for the Phrequent application, where users can review what they've spent time working on. Test Plan: Apply the patch and track some things in Maniphest. They should appear in the "Time Tracked" view of Phrequent. There is also a `phrequent.show-prompt` option which toggles whether to display a prompt when tracking time. I'm unsure of whether the prompt is useful or is more likely to cause people to click "Track Time", go off and do the task and then come back to the prompt still waiting for them to confirm. A potential solution to the "accidentally clicking the button and recording 2 seconds of time" might be to show a prompt on stop if the total time is under 10 seconds, asking whether the user wants to keep or discard the tracked time. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2857 Differential Revision: https://secure.phabricator.com/D5479
2013-03-30 17:32:29 +01:00
3 => 'PhrequentTrackableInterface',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
),
Basic Differential revision feedback view.
2011-01-30 19:37:36 +01:00
'DifferentialRevisionCommentListView' => 'AphrontView',
'DifferentialRevisionCommentView' => 'AphrontView',
DifferentialRevisionView
2011-01-27 23:55:52 +01:00
'DifferentialRevisionDetailView' => 'AphrontView',
RevisionEdit
2011-01-25 22:26:09 +01:00
'DifferentialRevisionEditController' => 'DifferentialController',
If users are on the email to Phabricator, do not send them the Phabricator reply. Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email. Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected. Reviewers: epriestley, vrana Reviewed By: vrana CC: aran, Korvin, vrana Maniphest Tasks: T1676 Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 19:18:23 +02:00
'DifferentialRevisionEditor' => 'PhabricatorEditor',
Emit full URIs to identify Differential revisions Summary: - Previously, used IDs like "33" to match a commit to a Differential revision. This has a namespacing problem because we now have an arbitrarily large number of Phabricator installs in the world, and they may want to track commits from other installs. - In Differential, parse raw IDs or full URIs. Emit only full URIs. - In Repositories, parse only full URIs. - This might cause a few commits to not be picked up in rare circumstances. Users can fix them with "arc mark-committed". This should be exceedingly rare because of hash matching. - There are some caveats for reparsing older repositories, see comments inline. I don't think there's much broad impact here. Test Plan: - Created a new revision, got a full URI. - Updated revision, worked correctly. - Ran unit tests. - Monkeyed with "Differential Revision" field. - Reviewers: btrahan, jungejason Reviewers: btrahan, jungejason Reviewed By: jungejason CC: aran, epriestley, jungejason Maniphest Tasks: T54, T692 Differential Revision: 1250
2011-12-21 00:40:24 +01:00
'DifferentialRevisionIDFieldParserTestCase' => 'PhabricatorTestCase',
Drive revision update from Conduit via custom fields Summary: When we create or update a revision, we use a parsed commit message dictionary to edit its fields. Drive consumption of the dictionary through custom fields instead of hardcoding. This requires adding some fields which don't really do anything right now to cover fields which appear only in the commit message. Test Plan: "arc diff"'d this revision against localhost, "arc diff"'d again to update. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason Differential Revision: 811
2011-08-15 03:52:09 +02:00
'DifferentialRevisionIDFieldSpecification' => 'DifferentialFieldSpecification',
RevisionList
2011-01-26 00:19:06 +01:00
'DifferentialRevisionListController' => 'DifferentialController',
Separate revision list rendering logic into a RevisionListView Summary: I want to throw this in Diffusion as part of T262, but it's embedded in the controller right now. Split it out. Test Plan: Looked at various revision list views, no changes. Reviewers: jungejason, nh, tuomaspelkonen, aran Reviewed By: jungejason CC: aran, jungejason Differential Revision: 977
2011-10-02 20:42:41 +02:00
'DifferentialRevisionListView' => 'AphrontView',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'DifferentialRevisionMailReceiver' => 'PhabricatorObjectMailReceiver',
Various statistics about revisions at /differential/stats/revisions/ Summary: Show some statistics, like number of revisions, number of revisions per week, lines per revision, etc. for phrivolous amusement. Test Plan: - Went to /differential/stats/revisions/ Numbers seem right - Clicked 'Accepted' Again - Changed to another user with long history Load time was not too long though delay noticeable - Clicked 'Requested changes to' User was preserved, looks good Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1643
2012-02-19 05:16:35 +01:00
'DifferentialRevisionStatsController' => 'DifferentialController',
'DifferentialRevisionStatsView' => 'AphrontView',
Move Differential's remaining field views to extensble field schema Summary: Move all the rest of the fields into the custom field schema, for revision views. I left a couple of stubs in here (willWriteRevision, didWriteRevision) since I'd planned to do edits here too, but this diff is sort of big-ish already. I'll do all the edit fields in the next revision. Depends on D808. Test Plan: Viewed, edited and conduit'ed some revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 809
2011-08-14 22:55:30 +02:00
'DifferentialRevisionStatusFieldSpecification' => 'DifferentialFieldSpecification',
DifferentialRevisionView
2011-01-27 23:55:52 +01:00
'DifferentialRevisionUpdateHistoryView' => 'AphrontView',
'DifferentialRevisionViewController' => 'DifferentialController',
Improve Search architecture Summary: The search indexing API has several problems right now: - Always runs in-process. - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it. - Being able to use the task queue will also make rebuilding indexes faster. - Instead, make the API phid-oriented. - No uniform indexing API. - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird. - Instead, provide a uniform API. - No uniform CLI. - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers. - Instead, let indexers expose documents for indexing. - Not application-oriented. - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world. - Instead, move indexers to applications and load them with SymbolLoader. Test Plan: - `bin/search index` - Indexed one revision, one task. - Indexed `--type TASK`, `--type DREV`, etc., for all types. - Indexed `--all`. - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it. - Creating users is a pain; searched for a user after indexing. - Creating commits is a pain; searched for a commit after indexing. - Mocks aren't currently loadable in the result view, so their indexing is moot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: 20after4, aran Maniphest Tasks: T1991, T2104 Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
'DifferentialSearchIndexer' => 'PhabricatorSearchDocumentIndexer',
Make subscribe/unsubscribe work properly on Revisions. Summary: Test Plan: Reviewers: CC:
2011-02-19 23:36:13 +01:00
'DifferentialSubscribeController' => 'DifferentialController',
Detect tasks referenced in commit messages and either link or update the mentioned tasks. Refs T945 Summary: This takes the place of D2721 which I am going to abandon. Test Plan: * Make a commit with "Closes T###" in the summary field. See that the mentioned task gets closed. * Make a commit with "refs T###" in the summary. See that it gets added as a related commit via edges. Reviewers: 20after4 Reviewed By: epriestley CC: aran, Korvin, champo Maniphest Tasks: T945 Differential Revision: https://secure.phabricator.com/D3466
2012-09-11 19:37:30 +02:00
'DifferentialSummaryFieldSpecification' => 'DifferentialFreeformFieldSpecification',
Implement all field edit interfaces on the custom field schema Summary: Moves the revision edit controller to be completely schema-driven. Depends on D810. Test Plan: Edited revisions. Entered intentionally invalid values to trigger error conditions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 810
2011-08-14 23:28:08 +02:00
'DifferentialTestPlanFieldSpecification' => 'DifferentialFieldSpecification',
Detect tasks referenced in commit messages and either link or update the mentioned tasks. Refs T945 Summary: This takes the place of D2721 which I am going to abandon. Test Plan: * Make a commit with "Closes T###" in the summary field. See that the mentioned task gets closed. * Make a commit with "refs T###" in the summary. See that it gets added as a related commit via edges. Reviewers: 20after4 Reviewed By: epriestley CC: aran, Korvin, champo Maniphest Tasks: T945 Differential Revision: https://secure.phabricator.com/D3466
2012-09-11 19:37:30 +02:00
'DifferentialTitleFieldSpecification' => 'DifferentialFreeformFieldSpecification',
Move Differential's remaining field views to extensble field schema Summary: Move all the rest of the fields into the custom field schema, for revision views. I left a couple of stubs in here (willWriteRevision, didWriteRevision) since I'd planned to do edits here too, but this diff is sort of big-ish already. I'll do all the edit fields in the next revision. Depends on D808. Test Plan: Viewed, edited and conduit'ed some revisions. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 809
2011-08-14 22:55:30 +02:00
'DifferentialUnitFieldSpecification' => 'DifferentialFieldSpecification',
Branch view improvements. Summary: Sorting by last commit date Branch view limit to 25 branches All branches table page with pagination on Git Test Plan: * Check repository view for expected behavior on branch table view * Check all branches page & test pagination Reviewers: epriestley Reviewed By: epriestley CC: aran, Koolvin Maniphest Tasks: T1200 Differential Revision: https://secure.phabricator.com/D2442
2012-05-10 09:28:19 +02:00
'DiffusionBranchTableController' => 'DiffusionController',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionBranchTableView' => 'DiffusionView',
Diffusion: basic browse view Summary: Synthesizes elements of Diffusion's browse view, Confusion's git support and Phabricator's repository infrastructure to provide a basic browse view for Phabricator Diffusion. This is basically a straight port of Confusion but uses Phabricator's Repository object and uses a real data object instead of arrays. Test Plan: Browsed Javelin in Phabricator at a very basic level. Reviewed By: jwilson Reviewers: aran, jwilson CC: jwilson, epriestley Differential Revision: 58
2011-03-08 02:25:47 +01:00
'DiffusionBrowseController' => 'DiffusionController',
Diffusion: basic file browse capability Summary: Very rough cut of file browsing. Not terribly useful yet, but it does cause file data to appear in the browser window. Test Plan: viewed a file from a git repo Reviewed By: jwilson Reviewers: aran, jwilson CC: jwilson Differential Revision: 64
2011-03-08 18:54:55 +01:00
'DiffusionBrowseFileController' => 'DiffusionController',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionBrowseTableView' => 'DiffusionView',
Browse / git improvements.
2011-03-14 06:03:30 +01:00
'DiffusionChangeController' => 'DiffusionController',
Show audit comments on the Diffusion commit view Summary: We already allow you to create comments, but we don't show them on the commit page. After style / view unification this is easy; show comments on the commit page. Test Plan: Made comments on a commit using the audit too, saw them show up in Diffusion. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1687
2012-02-24 23:14:39 +01:00
'DiffusionCommentListView' => 'AphrontView',
'DiffusionCommentView' => 'AphrontView',
Load commit branches and tags by AJAX Summary: Each query takes over 2 seconds in FBCODE. I didn't find a way how to speed them up. There's also no easy way how to parallelize them at least. So AJAX is the last instance. Test Plan: Loaded commit with one branch and no tag. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3112
2012-08-01 01:27:48 +02:00
'DiffusionCommitBranchesController' => 'DiffusionController',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionCommitChangeTableView' => 'DiffusionView',
Increase parseriness of some parsery things. Summary: None of these are parsnips. Test Plan: Reviewers: CC:
2011-03-11 18:34:22 +01:00
'DiffusionCommitController' => 'DiffusionController',
Allow commits to be associated with projects and associated goodies Summary: - Commit detail view - List of projects - "edit" action which takes the user to a simple form where they can only add / remove projects. - Integrated the project relationship into the commit search indexer - fixed a bug from D790; it seems you must select the column if you're going to join against it later. Without this change searching for author or projectfails 100% for me. Test Plan: added and removed projects. verified appropriate projects showed up in detail and edit view. searched for commits by project and found the ones I was supposed to...! Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1614 Differential Revision: https://secure.phabricator.com/D3189
2012-08-08 19:03:41 +02:00
'DiffusionCommitEditController' => 'DiffusionController',
Show parent commits in Diffusion Summary: Show parent commit information to make it easier to understand merges. Test Plan: Looked at commits in SVN, hg, git. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T961 Differential Revision: https://secure.phabricator.com/D2021
2012-03-26 21:21:48 +02:00
'DiffusionCommitParentsQuery' => 'DiffusionQuery',
Prepare Diffusion for hovercards Summary: Move Diffusion to be hovercard-ready, and expand our ability to resolve commit references. - Link unqualified hashes of 7 characters or more which match a commit. - Link qualified hashes of 5 characters or more which match a commit. - Support `{...}` syntax. Test Plan: {F33896} Reviewers: chad, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5121
2013-02-27 17:04:54 +01:00
'DiffusionCommitQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Load commit branches and tags by AJAX Summary: Each query takes over 2 seconds in FBCODE. I didn't find a way how to speed them up. There's also no easy way how to parallelize them at least. So AJAX is the last instance. Test Plan: Loaded commit with one branch and no tag. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3112
2012-08-01 01:27:48 +02:00
'DiffusionCommitTagsController' => 'DiffusionController',
Rough version of DiffusionHomeController Summary: My strategy here is to synthesize Diffusion + Confusion (jwilson's git support for Diffusion) + Repository/Commit stuff into Phabricator and kill all birds with one stone. This probably involves the least total work since we have to do this port step anyway and a lot of the Phabricator primitives are in better shape than the trunk primitives. Test Plan: Looked at it in my sandbox, which has some parsed commits. Reviewers: jwilson, aran, jungejason CC: Differential Revision: 57
2011-03-08 00:13:36 +01:00
'DiffusionController' => 'PhabricatorController',
Rough cut of Diffusion change view.
2011-03-31 02:36:16 +02:00
'DiffusionDiffController' => 'DiffusionController',
Add remarkup.process conduit method Summary: This exposes a few remarkup engines over conduit. Test Plan: Local conduit console, and playing with 'cat example.json | arc call-conduit remarkup.process' Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1551
2012-02-03 01:42:29 +01:00
'DiffusionEmptyResultView' => 'DiffusionView',
Diffusion - move some DiffusionRequest queries to occur over Conduit Summary: Ref T2784. This one was a wee bit complicated. Had to add PhabricatorUser and concept of initFromConduit (or not) to DiffusionRequest. Test Plan: foreach repo, visited CALLSIGN and clicked a commit and verified they laoded correctly. Hacked code to hit NOT via Conduit and repeated tests to great success. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5928
2013-05-15 00:32:19 +02:00
'DiffusionExpandCommitQueryException' => 'Exception',
'DiffusionExpandShortNameQuery' => 'DiffusionQuery',
Improve Diffusion behavior for externals Summary: - Feature request from Airtime that I missed in the feedback notes, came up yesterday. - Identify git submodules as "FILE_SUBMODULE", not "FILE_NORMAL". - Link git submodules to an external resolver endpoint, which tries to find commits in tracked repositories. - Identify git symlinks as "FILE_SYMLINK", not "FILE_NORMAL". - Add folder, file, symlink and externals icons. Test Plan: - externals/javelin is now identified as a submoudule and links to Javelin, not identified as a file and links to error. - bin/phd is now identified as a symlink. - Interfaces have pretty icons. Reviewers: btrahan, cpiro, ddfisher, keebuhm, allenjohnashton Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1975
2012-03-21 22:01:20 +01:00
'DiffusionExternalController' => 'DiffusionController',
More Drydock Stuff Summary: - Still really really rough. - Adds a full synchronous mode for debugging. - Adds some logging. - It can now allocate EC2 machines and put webroots on them in a hacky, terrible way. - Adds a base query class. Test Plan: oh hey look a test page? http://ec2-50-18-65-151.us-west-1.compute.amazonaws.com:2011/ Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D2026
2012-03-27 05:54:26 +02:00
'DiffusionFileContentQuery' => 'DiffusionQuery',
DiffusionBranchQuery => Conduit Summary: ref T2784. This one had a few fun spots where I had to move data around. Also, is there some common object (or should I add it?) that can do this toDictionary newFromConduit stuff? Also, this assumes D5803 is largely correct at the time of this diff. Test Plan: browsed mercurial and git repository page. saw the branches i expected. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5810
2013-05-01 23:56:36 +02:00
'DiffusionGitBranchTestCase' => 'PhabricatorTestCase',
Show parent commits in Diffusion Summary: Show parent commit information to make it easier to understand merges. Test Plan: Looked at commits in SVN, hg, git. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T961 Differential Revision: https://secure.phabricator.com/D2021
2012-03-26 21:21:48 +02:00
'DiffusionGitCommitParentsQuery' => 'DiffusionCommitParentsQuery',
Diffusion - move some DiffusionRequest queries to occur over Conduit Summary: Ref T2784. This one was a wee bit complicated. Had to add PhabricatorUser and concept of initFromConduit (or not) to DiffusionRequest. Test Plan: foreach repo, visited CALLSIGN and clicked a commit and verified they laoded correctly. Hacked code to hit NOT via Conduit and repeated tests to great success. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5928
2013-05-15 00:32:19 +02:00
'DiffusionGitExpandShortNameQuery' => 'DiffusionExpandShortNameQuery',
Diffusion: basic file browse capability Summary: Very rough cut of file browsing. Not terribly useful yet, but it does cause file data to appear in the browser window. Test Plan: viewed a file from a git repo Reviewed By: jwilson Reviewers: aran, jwilson CC: jwilson Differential Revision: 64
2011-03-08 18:54:55 +01:00
'DiffusionGitFileContentQuery' => 'DiffusionFileContentQuery',
Add "DiffusionRawDiffQuery" Summary: - This is only slightly useful for updating Differential, since DiffQuery (vs RawDiffQuery) already gets you most of what you need. The only thing is that DiffQuery returns the diff for one path only right now(and the SVN version is very "special"). Should be easy to fix in the Git/HG cases at least, though (or maybe just use RawDiffQuery to avoid the SVN mess). - Added a "download raw diff" link. Test Plan: Viewed Diffusion and raw commits for SVN, Mercurial and Git repositories. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2350
2012-05-02 22:43:45 +02:00
'DiffusionGitRawDiffQuery' => 'DiffusionRawDiffQuery',
Diffusion: encapsulate request in DiffusionRequest Summary: Put an indirection layer between controllers and URI management, adding branches to git repositories. Test Plan: Looked at browse, history browse, file browse views, bad branches, bad commits Reviewed By: jwilson Reviewers: aran, jwilson CC: jwilson, epriestley Differential Revision: 65
2011-03-08 23:29:02 +01:00
'DiffusionGitRequest' => 'DiffusionRequest',
Diffusion - move querying for stable commit name to occur over conduit Summary: Ref T2784. This is a lower-level one from drequest so it gets the conditional initialization treatment. Consolidated SVN as well even though SVN is issuing database queries; I felt better about the code de-duplication despite the small performance hit when we could just query the DB directly in the SVN case. Test Plan: browsed around my Phabricator repositories in Mercurial, Git, and SVN flavors. Looked good. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5956
2013-05-17 23:12:46 +02:00
'DiffusionGitStableCommitNameQuery' => 'DiffusionStableCommitNameQuery',
Diffusion: rough cut of history view Summary: Very very rough approximation of history view. I left out all the log parsing stuff for now since we should be able to just look it up in a Repository table and I think that'll be a bit faster, although we can muck around and see. Test Plan: Looked at history of a path Reviewed By: jwilson Reviewers: aran, jwilson CC: epriestley, jwilson Differential Revision: 66
2011-03-09 02:31:44 +01:00
'DiffusionHistoryController' => 'DiffusionController',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionHistoryTableView' => 'DiffusionView',
Rough version of DiffusionHomeController Summary: My strategy here is to synthesize Diffusion + Confusion (jwilson's git support for Diffusion) + Repository/Commit stuff into Phabricator and kill all birds with one stone. This probably involves the least total work since we have to do this port step anyway and a lot of the Phabricator primitives are in better shape than the trunk primitives. Test Plan: Looked at it in my sandbox, which has some parsed commits. Reviewers: jwilson, aran, jungejason CC: Differential Revision: 57
2011-03-08 00:13:36 +01:00
'DiffusionHomeController' => 'DiffusionController',
Adding hovercard event listeners for Users, Revisions, Conpherence and Commits Summary: Refs T1048 Adding Differential Hovercard EventListener Adding People Hovercard EventListener Adding basic Diffusion hovercard Adding Conpherence Hovercard EventListener Test Plan: Used in a combo with working hovercards. So beautiful. Also visited test page. Works alright. awesometown Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1048 Differential Revision: https://secure.phabricator.com/D5576
2013-04-06 02:01:54 +02:00
'DiffusionHovercardEventListener' => 'PhutilEventListener',
Add inline comments to Diffusion/Audit Summary: - Add inline comments to Audits, like Differential. - Creates new storage for the comments in the Audits database. - Creates a new PhabricatorAuditInlineComment class, similar to DifferentialInlineComment. - Defines an Interface which Differential and Audit comments conform to. - Makes consumers of DifferentialInlineComments consume objects which implement that interface instead. - Adds save NOTE: Some features are still missing! Wanted to cut this off before it got crazy: - Inline comments aren't shown in the main comment list. - Inline comments aren't shown in the emails. - Inline comments aren't previewed. I'll followup with those but this was getting pretty big. @vrana, does the SQL change look correct? Test Plan: - Created, edited, deleted, replied to, reloaded and saved inline comments in Diffusion, on the left and right side of diffs. - Created, edited, deleted, replied to, reloaded and saved inline comments in Differentila, on the left and right side of primary and diff-versus-diff diffs. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1898
2012-03-14 20:56:01 +01:00
'DiffusionInlineCommentController' => 'PhabricatorInlineCommentController',
Make inline comment preview work in Diffusion Summary: created a PhabricatorInlineCommentPreviewController so controllers in Diffusion and Differential respectively just have to handle the URI mapping and data loading like good little controllers. Test Plan: left inline comments on commits, deleted inline commits, submitted inline comments -- all worked well did the same on some diffs Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1176 Differential Revision: https://secure.phabricator.com/D3034
2012-07-23 20:01:28 +02:00
'DiffusionInlineCommentPreviewController' => 'PhabricatorInlineCommentPreviewController',
Add more change metadata to SVN and git.
2011-03-31 08:27:06 +02:00
'DiffusionLastModifiedController' => 'DiffusionController',
Display lint overview in Diffusion Summary: I will add links from /diffusion/ARC/lint/ in future diff. Test Plan: /diffusion/ - clicked on lint messages link. /diffusion/ARC/ - clicked on lint messages link. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3926
2012-11-08 20:11:44 +01:00
'DiffusionLintController' => 'DiffusionController',
Display list of lint problems in Diffusion Test Plan: /diffusion/ARC/lint/master/, saw links. /diffusion/ARC/lint/master/?lint=SPELL0, saw two links. /diffusion/ARC/lint/master/src/lint/linter/ArcanistFilenameLinter.php?lint=SPELL0, saw link. Clicked on everything. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2038 Differential Revision: https://secure.phabricator.com/D3931
2012-11-09 01:13:21 +01:00
'DiffusionLintDetailsController' => 'DiffusionController',
Show parent commits in Diffusion Summary: Show parent commit information to make it easier to understand merges. Test Plan: Looked at commits in SVN, hg, git. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T961 Differential Revision: https://secure.phabricator.com/D2021
2012-03-26 21:21:48 +02:00
'DiffusionMercurialCommitParentsQuery' => 'DiffusionCommitParentsQuery',
Diffusion - move some DiffusionRequest queries to occur over Conduit Summary: Ref T2784. This one was a wee bit complicated. Had to add PhabricatorUser and concept of initFromConduit (or not) to DiffusionRequest. Test Plan: foreach repo, visited CALLSIGN and clicked a commit and verified they laoded correctly. Hacked code to hit NOT via Conduit and repeated tests to great success. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5928
2013-05-15 00:32:19 +02:00
'DiffusionMercurialExpandShortNameQuery' => 'DiffusionExpandShortNameQuery',
Basic support for Mercurial in Diffusion Summary: Change import script plus almost all the view stuff. Still some rough edges but this seems to mostly work. Blame is currently unsupported but I think everything else works properly. Test Plan: Imported the hg repository itself. It doesn't immediately seem completely broken. Here are some screens: https://secure.phabricator.com/file/view/PHID-FILE-1438b71cc7c4a2eb4569/ https://secure.phabricator.com/file/view/PHID-FILE-3cec4f72f39e7de2d041/ https://secure.phabricator.com/file/view/PHID-FILE-2ea4883f160e8e5098f9/ https://secure.phabricator.com/file/view/PHID-FILE-35f751a36ebf65399ade/ All the parsers were able to churn through it without errors. Ran the new "reparse.php" script in various one-commit and repository modes. Browsed/imported some git repos for good measure. NOTE: The hg repository is only 15,000 commits and around 1,000 files. Performance is okay but hg doesn't provide performant, native APIs to get some data efficiently so we have to do some dumb stuff. If some of these interfaces are cripplingly slow or whatever, let me know and we can start bundling some Mercurial extensions with Arcanist. Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran Reviewed By: Makinde CC: aran, Makinde, epriestley Differential Revision: 960
2011-09-26 20:07:38 +02:00
'DiffusionMercurialFileContentQuery' => 'DiffusionFileContentQuery',
Add "DiffusionRawDiffQuery" Summary: - This is only slightly useful for updating Differential, since DiffQuery (vs RawDiffQuery) already gets you most of what you need. The only thing is that DiffQuery returns the diff for one path only right now(and the SVN version is very "special"). Should be easy to fix in the Git/HG cases at least, though (or maybe just use RawDiffQuery to avoid the SVN mess). - Added a "download raw diff" link. Test Plan: Viewed Diffusion and raw commits for SVN, Mercurial and Git repositories. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2350
2012-05-02 22:43:45 +02:00
'DiffusionMercurialRawDiffQuery' => 'DiffusionRawDiffQuery',
Basic support for Mercurial in Diffusion Summary: Change import script plus almost all the view stuff. Still some rough edges but this seems to mostly work. Blame is currently unsupported but I think everything else works properly. Test Plan: Imported the hg repository itself. It doesn't immediately seem completely broken. Here are some screens: https://secure.phabricator.com/file/view/PHID-FILE-1438b71cc7c4a2eb4569/ https://secure.phabricator.com/file/view/PHID-FILE-3cec4f72f39e7de2d041/ https://secure.phabricator.com/file/view/PHID-FILE-2ea4883f160e8e5098f9/ https://secure.phabricator.com/file/view/PHID-FILE-35f751a36ebf65399ade/ All the parsers were able to churn through it without errors. Ran the new "reparse.php" script in various one-commit and repository modes. Browsed/imported some git repos for good measure. NOTE: The hg repository is only 15,000 commits and around 1,000 files. Performance is okay but hg doesn't provide performant, native APIs to get some data efficiently so we have to do some dumb stuff. If some of these interfaces are cripplingly slow or whatever, let me know and we can start bundling some Mercurial extensions with Arcanist. Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran Reviewed By: Makinde CC: aran, Makinde, epriestley Differential Revision: 960
2011-09-26 20:07:38 +02:00
'DiffusionMercurialRequest' => 'DiffusionRequest',
Diffusion - move querying for stable commit name to occur over conduit Summary: Ref T2784. This is a lower-level one from drequest so it gets the conditional initialization treatment. Consolidated SVN as well even though SVN is issuing database queries; I felt better about the code de-duplication despite the small performance hit when we could just query the DB directly in the SVN case. Test Plan: browsed around my Phabricator repositories in Mercurial, Git, and SVN flavors. Looked good. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5956
2013-05-17 23:12:46 +02:00
'DiffusionMercurialStableCommitNameQuery' => 'DiffusionStableCommitNameQuery',
Some owners read workflows.
2011-04-04 04:20:47 +02:00
'DiffusionPathCompleteController' => 'DiffusionController',
Fix a dirname() edge case in Diffusion Summary: dirname('x') returns '.', not '/'; this caused some issues for repositories with files at the root. There are some cases in the parsers where I should probably swap this out too but I'll wait until I'm doing some more rigorous testing since that stuff is a bit fragile and this fixes an immediate issue. Test Plan: Ran unit tests. Viewed a file at root level in a test repository. Reviewers: jungejason, nh, tuomaspelkonen, aran Reviewed By: nh CC: aran, nh Differential Revision: 932
2011-09-14 20:23:39 +02:00
'DiffusionPathQueryTestCase' => 'PhabricatorTestCase',
Some owners read workflows.
2011-04-04 04:20:47 +02:00
'DiffusionPathValidateController' => 'DiffusionController',
Update PeopleMenu to only show integration with applications if they are installed Summary: do so via event engine. note different order now... Test Plan: toggled "show beta applications" to off and noted that Conpherence disappeared. Otherwise noted that links showed. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2424 Differential Revision: https://secure.phabricator.com/D4708
2013-02-05 22:46:02 +01:00
'DiffusionPeopleMenuEventListener' => 'PhutilEventListener',
Make DiffusionQuery extend PhabricatorQuery Summary: Ref T2683. Provides access to `formatWhereClause()`, etc. I plan to eventually unify the various DiffusionQuery execute methods as well, which all have special names right now (`loadModifiedPaths()`, `loadWhateverBlah()`, etc). Test Plan: Ran EverythingImplemented test. Browsed Diffusion. Reviewers: vrana Reviewed By: vrana CC: aran Maniphest Tasks: T2683 Differential Revision: https://secure.phabricator.com/D5251
2013-04-30 19:54:02 +02:00
'DiffusionQuery' => 'PhabricatorQuery',
Add "DiffusionRawDiffQuery" Summary: - This is only slightly useful for updating Differential, since DiffQuery (vs RawDiffQuery) already gets you most of what you need. The only thing is that DiffQuery returns the diff for one path only right now(and the SVN version is very "special"). Should be easy to fix in the Git/HG cases at least, though (or maybe just use RawDiffQuery to avoid the SVN mess). - Added a "download raw diff" link. Test Plan: Viewed Diffusion and raw commits for SVN, Mercurial and Git repositories. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2350
2012-05-02 22:43:45 +02:00
'DiffusionRawDiffQuery' => 'DiffusionQuery',
Prepare Diffusion for hovercards Summary: Move Diffusion to be hovercard-ready, and expand our ability to resolve commit references. - Link unqualified hashes of 7 characters or more which match a commit. - Link qualified hashes of 5 characters or more which match a commit. - Support `{...}` syntax. Test Plan: {F33896} Reviewers: chad, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5121
2013-02-27 17:04:54 +01:00
'DiffusionRemarkupRule' => 'PhabricatorRemarkupRuleObject',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionRepositoryController' => 'DiffusionController',
Begin transacitonalizing repository edits and provide a more sensible edit interface Summary: Ref T2231, T603. Plan of attack here is pretty much: - Built out a new (currently not linked in the UI) edit interface in Diffusion which is transaction-based and has a sensible layout. - Build out a new create interface based on PagedForm which dumps into the new edit interface. - Throw the old stuff away. - Everyone lives happily ever after. Test Plan: {F44163} {F44164} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D6029
2013-05-24 21:37:42 +02:00
'DiffusionRepositoryEditBasicController' => 'DiffusionController',
'DiffusionRepositoryEditController' => 'DiffusionController',
Provide transaction-based edits of repository encoding Summary: Adds support for the "encoding" field to the new transactional interface. Test Plan: {F44189} {F44190} Some of the encodings in the second screen are from testing, and can no longer be set. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6035
2013-05-25 15:30:38 +02:00
'DiffusionRepositoryEditEncodingController' => 'DiffusionController',
Improve performance of repository discovery under Mercurial Summary: Prelminary, I want to test this a bit more when I'm better rested. Provide a "bulk" import mode for Mercurial so we can do initial discovery more quickly. Test Plan: Imported the Mercurial repository in 2m45s, blocked on MySQL I/O rather than Mercurial I/O. Reviewers: csilvers, btrahan Reviewed By: csilvers CC: aran Differential Revision: https://secure.phabricator.com/D2457
2012-05-12 03:29:14 +02:00
'DiffusionSetupException' => 'AphrontUsageException',
Diffusion - move querying for stable commit name to occur over conduit Summary: Ref T2784. This is a lower-level one from drequest so it gets the conditional initialization treatment. Consolidated SVN as well even though SVN is issuing database queries; I felt better about the code de-duplication despite the small performance hit when we could just query the DB directly in the SVN case. Test Plan: browsed around my Phabricator repositories in Mercurial, Git, and SVN flavors. Looked good. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5956
2013-05-17 23:12:46 +02:00
'DiffusionStableCommitNameQuery' => 'DiffusionQuery',
Show parent commits in Diffusion Summary: Show parent commit information to make it easier to understand merges. Test Plan: Looked at commits in SVN, hg, git. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T961 Differential Revision: https://secure.phabricator.com/D2021
2012-03-26 21:21:48 +02:00
'DiffusionSvnCommitParentsQuery' => 'DiffusionCommitParentsQuery',
Browse / git improvements.
2011-03-14 06:03:30 +01:00
'DiffusionSvnFileContentQuery' => 'DiffusionFileContentQuery',
Add "DiffusionRawDiffQuery" Summary: - This is only slightly useful for updating Differential, since DiffQuery (vs RawDiffQuery) already gets you most of what you need. The only thing is that DiffQuery returns the diff for one path only right now(and the SVN version is very "special"). Should be easy to fix in the Git/HG cases at least, though (or maybe just use RawDiffQuery to avoid the SVN mess). - Added a "download raw diff" link. Test Plan: Viewed Diffusion and raw commits for SVN, Mercurial and Git repositories. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2350
2012-05-02 22:43:45 +02:00
'DiffusionSvnRawDiffQuery' => 'DiffusionRawDiffQuery',
Add syntax highlight to diffusion. Summary: use XHPAST parser to parse the file, and generate a table for the code to highlight it. This is part of the task of "Port Diffusion's Browse File view to Phabricator". Test Plan: browse file, try commit version, line number functionality. Reviewed By: epriestley Reviewers: epriestley CC: epriestley Differential Revision: 83
2011-03-23 03:34:47 +01:00
'DiffusionSvnRequest' => 'DiffusionRequest',
Diffusion - move querying for stable commit name to occur over conduit Summary: Ref T2784. This is a lower-level one from drequest so it gets the conditional initialization treatment. Consolidated SVN as well even though SVN is issuing database queries; I felt better about the code de-duplication despite the small performance hit when we could just query the DB directly in the SVN case. Test Plan: browsed around my Phabricator repositories in Mercurial, Git, and SVN flavors. Looked good. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5956
2013-05-17 23:12:46 +02:00
'DiffusionSvnStableCommitNameQuery' => 'DiffusionStableCommitNameQuery',
Add a simple symbol lookup interface for cross-references Summary: This will get fancier, but here's a basic interface for doing symbol lookups. Still all pretty tentative. Test Plan: Looked up various things, got some sensible results. Reviewers: jungejason, nh, tuomaspelkonen, aran Reviewed By: tuomaspelkonen CC: aran, tuomaspelkonen Differential Revision: 900
2011-09-05 19:43:24 +02:00
'DiffusionSymbolController' => 'DiffusionController',
Include symbols in main typeahead Summary: - Include symbols in main typeahead results. - Simplify the symbol query a bit and extend PhabricatorOffsetPagedQuery. There was some stuff around language ranking that I got rid of, I think the theory there was that mapping file extensions to languages might not work in general but I think it works fine in practice, and we have more config stuff now around guessing languages and getting the mappings right. - Make it easier to debug the typeahead by showing the results in page format for non-ajax requests. - When we have too many results, show only the top few of each type. Depends on D3116, D3117 Test Plan: Used typeahead, got symbols in results. Hit endpoint with non-ajax, got useful debug view. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3118
2012-08-01 21:36:47 +02:00
'DiffusionSymbolQuery' => 'PhabricatorOffsetPagedQuery',
Add a paginated list of all repository tags to Diffusion Summary: Now supports more than 25 tags! Test Plan: Set page size to 1, paginated. Verified SVN / Hg don't break/explode. Reviewers: davidreuss, vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1130 Differential Revision: https://secure.phabricator.com/D2268
2012-04-19 18:39:19 +02:00
'DiffusionTagListController' => 'DiffusionController',
Add very basic tag support to Diffusion Summary: Lists the 25 most recent tags on the "Repository" page. Test Plan: Looked at a git repository with a tag, saw it. Looked at HG/SVN repos, they didn't break. Reviewers: davidreuss, 20after4, btrahan, vrana, jungejason Reviewed By: davidreuss CC: aran Maniphest Tasks: T1130 Differential Revision: https://secure.phabricator.com/D2255
2012-04-18 17:02:08 +02:00
'DiffusionTagListView' => 'DiffusionView',
Fix many encoding and architecture problems in Diffusion request and URI handling Summary: Diffusion request/uri handling is currently a big, hastily ported mess. In particular, it has: - Tons and tons of duplicated code. - Bugs with handling unusual branch and file names. - An excessively large (and yet insufficiently expressive) API on DiffusionRequest, including a nonsensical concrete base class. - Other tools were doing hacky things like passing ":" branch names. This diff attempts to fix these issues. - Make the base class abstract (it was concrete ONLY for "/diffusion/"). - Move all URI generation to DiffusionRequest. Make the core static. Add unit tests. - Delete the 300 copies of URI generation code throughout Diffusion. - Move all URI parsing to DiffusionRequest. Make the core static. Add unit tests. - Add an appropriate static initializer for other callers. - Convert all code calling `newFromAphrontRequestDictionary` outside of Diffusion to the new `newFromDictionary` API. - Refactor static initializers to be sensibly-sized. - Refactor derived DiffusionRequest classes to remove duplicated code. - Properly encode branch names (fixes branches with "/", see <https://github.com/facebook/phabricator/issues/100>). - Properly encode path names (fixes issues in D1742). - Properly escape delimiter characters ";" and "$" in path names so files like "$100" are not interpreted as "line 100". - Fix a couple warnings. - Fix a couple lint issues. - Fix a bug where we would not parse filenames with spaces in them correctly in the Git browse query. - Fix a bug where Git change queries would fail unnecessarily. - Provide or improve some documentation. This thing is pretty gigantic but also kind of hard to split up. If it's unreasonably difficult to review, let me know and I can take a stab at it though. This supplants D1742. Test Plan: - Used home, repository, branch, browse, change, history, diff (ajax), lastmodified (ajax) views of Diffusion. - Used Owners typeaheads and search. - Used diffusion.getrecentcommitsbypath method. - Pushed a change to an absurdly-named file on an absurdly-named branch, everything worked properly. {F9185} Reviewers: nh, vrana, btrahan Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1921
2012-03-20 03:52:14 +01:00
'DiffusionURITestCase' => 'ArcanistPhutilTestCase',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionView' => 'AphrontView',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerArticleAtomizer' => 'DivinerAtomizer',
Add a publish cache for the Diviner static publisher Summary: Keep track of what we've written to disk, and regenerate only new documents. Test Plan: Changed a small number of files, saw that number of files get regenerated. Ran with "--clean" and saw everything regenerate. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4897
2013-02-18 00:40:00 +01:00
'DivinerAtomCache' => 'DivinerDiskCache',
Add an Atom controller to Diviner Summary: Ref T988. Lots of rough edges still, but this pulls the right data and dumps it into a reasonable-looking shell. Test Plan: {F44883} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6104
2013-06-01 00:14:39 +02:00
'DivinerAtomController' => 'DivinerController',
Use ApplicationSearch in Diviner Summary: Ref T988. Ref T2625. Rough cut of ApplicationSearch in Diviner, for detailed Atom queries. This isn't useful yet, and isn't linked in the UI. Test Plan: {F44836} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T2625 Differential Revision: https://secure.phabricator.com/D6094
2013-05-31 19:52:25 +02:00
'DivinerAtomListController' =>
array(
0 => 'DivinerController',
1 => 'PhabricatorApplicationSearchResultsControllerInterface',
),
'DivinerAtomQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'DivinerAtomSearchEngine' => 'PhabricatorApplicationSearchEngine',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerAtomizeWorkflow' => 'DivinerWorkflow',
Add a book controller and various amenities to Diviner's live view Summary: Ref T988. Mostly backend changes, with a very rough frontend on top of them. See Conpherence discussion. Test Plan: {F45010} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6113
2013-06-04 20:15:34 +02:00
'DivinerBookController' => 'DivinerController',
Use ApplicationSearch in Diviner Summary: Ref T988. Ref T2625. Rough cut of ApplicationSearch in Diviner, for detailed Atom queries. This isn't useful yet, and isn't linked in the UI. Test Plan: {F44836} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T2625 Differential Revision: https://secure.phabricator.com/D6094
2013-05-31 19:52:25 +02:00
'DivinerBookQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'DivinerController' => 'PhabricatorController',
Add "live" publisher and storage to Diviner Summary: Ref T988. This adds basics for the non-static publishing target: - Storage (called "Live", e.g. `DivinerLiveAtom` to distinguish it from shared classes like `DivinerAtom`). - Mostly populate the storage. - Some minor fixes and improvements. Test Plan: Generated docs, looked at DB, saw mostly-sensible output. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D5973
2013-05-20 19:18:26 +02:00
'DivinerDAO' => 'PhabricatorLiskDAO',
Move Diviner further toward usability Summary: - Complete the "project" -> "book" stuff. This is cleaner conceptually and keeps us from having yet another meaning for the word "project". - Normalize symbols during atomization. This simplifies publishing a great deal, and allows static documentation to link to dynamic documentation and vice versa, because the canonical names of symbols are agreed upon (we can tweak the actual algorithm). - Give articles a specifiable name distinct from the title, and default to something like "support" instead of "Get Help! Get Support!" so URIs end up more readable (not "Get_Help!_Get_Support!"). - Have the atomizers set book information on atoms. - Implement very basic publishers. Publishers are basically glue code between the atomization process and the rendering process -- the two we'll have initially are "static" (publish to files on disk) and "phabricator" (or similar -- publish into the database). - Handle duplicate symbol definitions in the atomize and publish pipelines. This fixes the issue where a project defines two functions named "idx()" and we currently tell them not to do that and break. Realistically, this is common in the real world and we should just roll our eyes and do the legwork to generate documentation as best we can. - Particularly, dirty all atoms with the same name as a dirty atom (e.g., if 'function f()' is updated, regnerate the documentation for all functions named f() in the book). - When publishing, we publish these at "function/f/@1", "function/f/@2". The base page will offer to disambiguate ("There are 8 functions named 'f' in this codebase, which one do you want?"). - Implement a very very basic renderer. This generates the actual HTML (or text, or XML, or whatever else) for the documentation, which the publisher dumps onto disk or into a database or whatever. - The atomize workflow actually needs to depend on books, at least sort of, so make it load config and use it properly. - Propagate multilevel dirties through the graph. If "C extends B" and "B extends A", we should regenerate C when A changes. Prior to this diff, we would regnerate B only. Test Plan: Generated some documentation. Named two articles "feedback", generated docs, saw "article/feedback/@1/" and "article/feedback/@2/" created. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4896
2013-02-18 00:39:36 +01:00
'DivinerDefaultRenderer' => 'DivinerRenderer',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerFileAtomizer' => 'DivinerAtomizer',
'DivinerGenerateWorkflow' => 'DivinerWorkflow',
Use ApplicationSearch in Diviner Summary: Ref T988. Ref T2625. Rough cut of ApplicationSearch in Diviner, for detailed Atom queries. This isn't useful yet, and isn't linked in the UI. Test Plan: {F44836} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T2625 Differential Revision: https://secure.phabricator.com/D6094
2013-05-31 19:52:25 +02:00
'DivinerLegacyController' => 'DivinerController',
Add another pattern to quoted email body stripping Summary: Ref T3217. @hlau has an email client which quotes text with: ________________________________________ From: ... Add a regular expression to correctly detect this as quoted body text. Test Plan: Add unit test; executed unit test. Reviewers: btrahan, chad Reviewed By: chad CC: hlau, aran Maniphest Tasks: T3217 Differential Revision: https://secure.phabricator.com/D5986
2013-05-21 00:52:54 +02:00
'DivinerLiveAtom' => 'DivinerDAO',
Add "live" publisher and storage to Diviner Summary: Ref T988. This adds basics for the non-static publishing target: - Storage (called "Live", e.g. `DivinerLiveAtom` to distinguish it from shared classes like `DivinerAtom`). - Mostly populate the storage. - Some minor fixes and improvements. Test Plan: Generated docs, looked at DB, saw mostly-sensible output. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D5973
2013-05-20 19:18:26 +02:00
'DivinerLiveBook' =>
array(
0 => 'DivinerDAO',
1 => 'PhabricatorPolicyInterface',
),
'DivinerLivePublisher' => 'DivinerPublisher',
Use ApplicationSearch in Diviner Summary: Ref T988. Ref T2625. Rough cut of ApplicationSearch in Diviner, for detailed Atom queries. This isn't useful yet, and isn't linked in the UI. Test Plan: {F44836} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T2625 Differential Revision: https://secure.phabricator.com/D6094
2013-05-31 19:52:25 +02:00
'DivinerLiveSymbol' =>
array(
0 => 'DivinerDAO',
1 => 'PhabricatorPolicyInterface',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
2 => 'PhabricatorMarkupInterface',
Use ApplicationSearch in Diviner Summary: Ref T988. Ref T2625. Rough cut of ApplicationSearch in Diviner, for detailed Atom queries. This isn't useful yet, and isn't linked in the UI. Test Plan: {F44836} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T2625 Differential Revision: https://secure.phabricator.com/D6094
2013-05-31 19:52:25 +02:00
),
Add a publish cache for the Diviner static publisher Summary: Keep track of what we've written to disk, and regenerate only new documents. Test Plan: Changed a small number of files, saw that number of files get regenerated. Ran with "--clean" and saw everything regenerate. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4897
2013-02-18 00:40:00 +01:00
'DivinerPublishCache' => 'DivinerDiskCache',
Improve Diviner handling of paths and remarkup Summary: - Currently, the atomizers don't emit atoms with the right file in all cases. Make them always emit it correctly. - Currently, we use absolute paths in some cases and relative paths in other cases. Use them consistently: relative when storing/presenting, absolute when accessing data. - Don't preserve linebreaks when marking up documentation (documentation is generally wrapped at 80col, but should not be wrapped in this way when displayed). - Markup Diviner link rules (albeit uselesly). Test Plan: Before: {F33044} After: {F33045} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4992
2013-02-18 00:40:44 +01:00
'DivinerRemarkupRuleSymbol' => 'PhutilRemarkupRule',
Move Diviner further toward usability Summary: - Complete the "project" -> "book" stuff. This is cleaner conceptually and keeps us from having yet another meaning for the word "project". - Normalize symbols during atomization. This simplifies publishing a great deal, and allows static documentation to link to dynamic documentation and vice versa, because the canonical names of symbols are agreed upon (we can tweak the actual algorithm). - Give articles a specifiable name distinct from the title, and default to something like "support" instead of "Get Help! Get Support!" so URIs end up more readable (not "Get_Help!_Get_Support!"). - Have the atomizers set book information on atoms. - Implement very basic publishers. Publishers are basically glue code between the atomization process and the rendering process -- the two we'll have initially are "static" (publish to files on disk) and "phabricator" (or similar -- publish into the database). - Handle duplicate symbol definitions in the atomize and publish pipelines. This fixes the issue where a project defines two functions named "idx()" and we currently tell them not to do that and break. Realistically, this is common in the real world and we should just roll our eyes and do the legwork to generate documentation as best we can. - Particularly, dirty all atoms with the same name as a dirty atom (e.g., if 'function f()' is updated, regnerate the documentation for all functions named f() in the book). - When publishing, we publish these at "function/f/@1", "function/f/@2". The base page will offer to disambiguate ("There are 8 functions named 'f' in this codebase, which one do you want?"). - Implement a very very basic renderer. This generates the actual HTML (or text, or XML, or whatever else) for the documentation, which the publisher dumps onto disk or into a database or whatever. - The atomize workflow actually needs to depend on books, at least sort of, so make it load config and use it properly. - Propagate multilevel dirties through the graph. If "C extends B" and "B extends A", we should regenerate C when A changes. Prior to this diff, we would regnerate B only. Test Plan: Generated some documentation. Named two articles "feedback", generated docs, saw "article/feedback/@1/" and "article/feedback/@2/" created. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4896
2013-02-18 00:39:36 +01:00
'DivinerStaticPublisher' => 'DivinerPublisher',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerWorkflow' => 'PhutilArgumentWorkflow',
Move resource allocation to task queue Summary: Run the actual resource allocation for Drydock out-of-process via the task queue. Test Plan: Ran "drydock_control.php", saw it insert a task and wait for task completion. Ran "phd debug taskmaster" and saw it run the task. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1470
2012-01-24 01:58:38 +01:00
'DrydockAllocatorWorker' => 'PhabricatorWorker',
More Drydock Stuff Summary: - Still really really rough. - Adds a full synchronous mode for debugging. - Adds some logging. - It can now allocate EC2 machines and put webroots on them in a hacky, terrible way. - Adds a base query class. Test Plan: oh hey look a test page? http://ec2-50-18-65-151.us-west-1.compute.amazonaws.com:2011/ Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D2026
2012-03-27 05:54:26 +02:00
'DrydockApacheWebrootInterface' => 'DrydockWebrootInterface',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockCommandInterface' => 'DrydockInterface',
'DrydockController' => 'PhabricatorController',
'DrydockDAO' => 'PhabricatorLiskDAO',
'DrydockLease' => 'DrydockDAO',
'DrydockLeaseListController' => 'DrydockController',
Show Drydock resource leases, add DrydockLeaseQuery, allow reuse of working copies Summary: Minor updates to Drydock things to make them work better. In particular, after this patch working copies are correctly allocated or reused. Test Plan: Ran "reparse.php --harbormaster <derp derp>", saw reuse of working copies when unleased resources were avilable. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D4216
2012-12-17 22:53:32 +01:00
'DrydockLeaseQuery' => 'PhabricatorOffsetPagedQuery',
Allow leases to be explicitly released via web or CLI Summary: Permit the forcible release of Drydock leases. The implementation isn't very exciting for now. Test Plan: Released leases via web and CLI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D4181
2012-12-15 00:42:58 +01:00
'DrydockLeaseReleaseController' => 'DrydockController',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockLeaseStatus' => 'DrydockConstants',
Make minor improvements to Drydock web interface Summary: Consolidate some code and start on lease detail pages. Test Plan: {F22783} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3901
2012-11-07 00:28:33 +01:00
'DrydockLeaseViewController' => 'DrydockController',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockLocalCommandInterface' => 'DrydockCommandInterface',
'DrydockLocalHostBlueprint' => 'DrydockBlueprint',
More Drydock Stuff Summary: - Still really really rough. - Adds a full synchronous mode for debugging. - Adds some logging. - It can now allocate EC2 machines and put webroots on them in a hacky, terrible way. - Adds a base query class. Test Plan: oh hey look a test page? http://ec2-50-18-65-151.us-west-1.compute.amazonaws.com:2011/ Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D2026
2012-03-27 05:54:26 +02:00
'DrydockLog' => 'DrydockDAO',
'DrydockLogController' => 'DrydockController',
'DrydockLogQuery' => 'PhabricatorOffsetPagedQuery',
Add a "close" action to Drydock resources Summary: This does nothing fancy, just closes the resource and releases/breaks leases. They'll get cleaned up in some to-be-written GC process. Test Plan: Closed resources from web UI and CLI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3998
2012-11-27 21:48:03 +01:00
'DrydockManagementCloseWorkflow' => 'DrydockManagementWorkflow',
Modernize the `drydock` script Summary: Add a bin/drydock symlink and break it into workflows. Nothing too special here. Test Plan: Ran `bin/drydock wait-for-lease`, `bin/drydock lease`, `bin/drydock help`, etc. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3867
2012-11-01 23:30:14 +01:00
'DrydockManagementLeaseWorkflow' => 'DrydockManagementWorkflow',
Allow leases to be explicitly released via web or CLI Summary: Permit the forcible release of Drydock leases. The implementation isn't very exciting for now. Test Plan: Released leases via web and CLI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D4181
2012-12-15 00:42:58 +01:00
'DrydockManagementReleaseWorkflow' => 'DrydockManagementWorkflow',
Modernize the `drydock` script Summary: Add a bin/drydock symlink and break it into workflows. Nothing too special here. Test Plan: Ran `bin/drydock wait-for-lease`, `bin/drydock lease`, `bin/drydock help`, etc. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3867
2012-11-01 23:30:14 +01:00
'DrydockManagementWaitForLeaseWorkflow' => 'DrydockManagementWorkflow',
'DrydockManagementWorkflow' => 'PhutilArgumentWorkflow',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockResource' => 'DrydockDAO',
Add a "close" action to Drydock resources Summary: This does nothing fancy, just closes the resource and releases/breaks leases. They'll get cleaned up in some to-be-written GC process. Test Plan: Closed resources from web UI and CLI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3998
2012-11-27 21:48:03 +01:00
'DrydockResourceCloseController' => 'DrydockController',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockResourceListController' => 'DrydockController',
Make most Drydock web interfaces work with mobile Summary: The logs bits still need some work but add crumbs/lists to everything else. Also build a propery DrydockResourceQuery. Test Plan: Looked at lease list/detail; resource list/detail. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D4221
2012-12-17 23:47:21 +01:00
'DrydockResourceQuery' => 'PhabricatorOffsetPagedQuery',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockResourceStatus' => 'DrydockConstants',
Add a detail view for resources in Drydock Summary: Nothing fancy here, just add a detail page. Test Plan: Looked at detail page. {F24808} Reviewers: btrahan Reviewed By: btrahan CC: aran, vrana Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3995
2012-11-20 22:25:22 +01:00
'DrydockResourceViewController' => 'DrydockController',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockSSHCommandInterface' => 'DrydockCommandInterface',
More Drydock Stuff Summary: - Still really really rough. - Adds a full synchronous mode for debugging. - Adds some logging. - It can now allocate EC2 machines and put webroots on them in a hacky, terrible way. - Adds a base query class. Test Plan: oh hey look a test page? http://ec2-50-18-65-151.us-west-1.compute.amazonaws.com:2011/ Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D2026
2012-03-27 05:54:26 +02:00
'DrydockWebrootInterface' => 'DrydockInterface',
Allow Drydock to allocate (very basic) working copy resources Summary: This is missing a lot of features, but technically allows working copy allocation. Test Plan: Ran `drydock lease --type working-copy --attributes repositoryID=12`, got a working copy of Phabricator allocated on disk. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3999
2012-11-27 21:48:14 +01:00
'DrydockWorkingCopyBlueprint' => 'DrydockBlueprint',
post feed stories to arbitrary uris via a new Worker Summary: so folks can write applications and whatnot. Test Plan: set feed.http-hooks to local dev instance (200) and localhost (500) in my conf. Verified succcess and retrying respectively. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T305 Differential Revision: https://secure.phabricator.com/D3874
2012-11-02 21:34:18 +01:00
'FeedPublisherWorker' => 'PhabricatorWorker',
Remove PHID database, add Harbormaster database Summary: - We currently write every PHID we generate to a table. This was motivated by two concerns: - **Understanding Data**: At Facebook, the data was sometimes kind of a mess. You could look at a random user in the ID tool and see 9000 assocs with random binary data attached to them, pointing at a zillion other objects with no idea how any of it got there. I originally created this table to have a canonical source of truth about PHID basics, at least. In practice, our data model has been really tidy and consistent, and we don't use any of the auxiliary data in this table (or even write it). The handle abstraction is powerful and covers essentially all of the useful data in the app, and we have human-readable types in the keys. So I don't think we have a real need here, and this table isn't serving it if we do. - **Uniqueness**: With a unique key, we can be sure they're unique, even if we get astronomically unlucky and get a collision. But every table we use them in has a unique key anyway. So we actually get pretty much nothing here, except maybe some vague guarantee that we won't reallocate a key later if the original object is deleted. But it's hard to imagine any install will ever have a collision, given that the key space is 36^20 per object type. - We also currently use PHIDs and Users in tests sometimes. This is silly and can break (see D2461). - Drop the PHID database. - Introduce a "Harbormaster" database (the eventual CI tool, after Drydock). - Add a scratch table to the Harbormaster database for doing unit test meta-tests. - Now, PHID generation does no writes, and unit tests are isolated from the application. - @csilvers: This should slightly improve the performance of the large query-bound tail in D2457. Test Plan: Ran unit tests. Ran storage upgrade. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: csilvers, aran, nh, edward Differential Revision: https://secure.phabricator.com/D2466
2012-05-20 23:46:01 +02:00
'HarbormasterDAO' => 'PhabricatorLiskDAO',
Add a generic object for unit tests Summary: A later diff adds unit tests against edges, but we need real objects to connect with edges. Add some trivial objects to the Harbormaster database to compliment the similar HarbormasterScratchTable. On its own, this does nothing interesting. Test Plan: Built unit tests on this in a followup. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D2937
2012-07-09 19:39:14 +02:00
'HarbormasterObject' => 'HarbormasterDAO',
Add HarbormasterRunnerWorker, for running CI tests Summary: This is very preliminary and doesn't actually do anything useful. In theory, it uses Drydock to check out a working copy and run tests. In practice, it's not actually capable of running any of our tests (because of complicated interdependency stuff), but does check out a working copy and //try// to run tests there. Adds various sorts of utility methods to various things as well. Test Plan: Ran `reparse.php --harbormaster --trace <commit>`, observed attempt to run tests via Drydock. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015, T1049 Differential Revision: https://secure.phabricator.com/D4215
2012-12-17 22:43:26 +01:00
'HarbormasterRunnerWorker' => 'PhabricatorWorker',
Remove PHID database, add Harbormaster database Summary: - We currently write every PHID we generate to a table. This was motivated by two concerns: - **Understanding Data**: At Facebook, the data was sometimes kind of a mess. You could look at a random user in the ID tool and see 9000 assocs with random binary data attached to them, pointing at a zillion other objects with no idea how any of it got there. I originally created this table to have a canonical source of truth about PHID basics, at least. In practice, our data model has been really tidy and consistent, and we don't use any of the auxiliary data in this table (or even write it). The handle abstraction is powerful and covers essentially all of the useful data in the app, and we have human-readable types in the keys. So I don't think we have a real need here, and this table isn't serving it if we do. - **Uniqueness**: With a unique key, we can be sure they're unique, even if we get astronomically unlucky and get a collision. But every table we use them in has a unique key anyway. So we actually get pretty much nothing here, except maybe some vague guarantee that we won't reallocate a key later if the original object is deleted. But it's hard to imagine any install will ever have a collision, given that the key space is 36^20 per object type. - We also currently use PHIDs and Users in tests sometimes. This is silly and can break (see D2461). - Drop the PHID database. - Introduce a "Harbormaster" database (the eventual CI tool, after Drydock). - Add a scratch table to the Harbormaster database for doing unit test meta-tests. - Now, PHID generation does no writes, and unit tests are isolated from the application. - @csilvers: This should slightly improve the performance of the large query-bound tail in D2457. Test Plan: Ran unit tests. Ran storage upgrade. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: csilvers, aran, nh, edward Differential Revision: https://secure.phabricator.com/D2466
2012-05-20 23:46:01 +02:00
'HarbormasterScratchTable' => 'HarbormasterDAO',
Herald skeleton.
2011-03-22 21:22:40 +01:00
'HeraldAction' => 'HeraldDAO',
'HeraldApplyTranscript' => 'HeraldDAO',
HeraldCommitAdapter and some related junk.
2011-04-04 08:23:36 +02:00
'HeraldCommitAdapter' => 'HeraldObjectAdapter',
Herald skeleton.
2011-03-22 21:22:40 +01:00
'HeraldCondition' => 'HeraldDAO',
Rough cut of Herald home controller.
2011-03-22 21:49:46 +01:00
'HeraldController' => 'PhabricatorController',
Herald skeleton.
2011-03-22 21:22:40 +01:00
'HeraldDAO' => 'PhabricatorLiskDAO',
Herald CSS, plus edit/save/delete.
2011-03-24 19:07:36 +01:00
'HeraldDeleteController' => 'HeraldController',
Rough cut of herald transcripts and Differential adapter.
2011-03-25 05:32:26 +01:00
'HeraldDifferentialRevisionAdapter' => 'HeraldObjectAdapter',
Very rough cut at Herald test console.
2011-03-24 21:49:21 +01:00
'HeraldDryRunAdapter' => 'HeraldObjectAdapter',
General Herald refactoring pass Summary: **Who can delete global rules?**: I discussed this with @jungejason. The current behavior is that the rule author or any administrator can delete a global rule, but this isn't consistent with who can edit a rule (anyone) and doesn't really make much sense (it's an artifact of the global/personal split). I proposed that anyone can delete a rule but we don't actually delete them, and log the deletion. However, when it came time to actually write the code for this I backed off a bit and continued actually deleting the rules -- I think this does a reasonable job of balancing accountability with complexity. So the new impelmentation is: - Personal rules can be deleted only by their owners. - Global rules can be deleted by any user. - All deletes are logged. - Logs are more detailed. - All logged actions can be viewed in aggregate. **Minor Cleanup** - Merged `HomeController` and `AllController`. - Moved most queries to Query classes. - Use AphrontFormSelectControl::renderSelectTag() where appropriate (this is a fairly recent addition). - Use an AphrontErrorView to render the dry run notice (this didn't exist when I ported). - Reenable some transaction code (this works again now). - Removed the ability for admins to change rule authors (this was a little buggy, messy, and doesn't make tons of sense after the personal/global rule split). - Rules which depend on other rules now display the right options (all global rules, all your personal rules for personal rules). - Fix a bug in AphrontTableView where the "no data" cell would be rendered too wide if some columns are not visible. - Allow selectFilter() in AphrontNavFilterView to be called without a 'default' argument. Test Plan: - Browsed, created, edited, deleted personal and gules. - Verified generated logs. - Did some dry runs. - Verified transcript list and transcript details. - Created/edited all/any rules; created/edited once/every time rules. - Filtered admin views by users. Reviewers: jungejason, btrahan Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D2040
2012-03-30 19:49:55 +02:00
'HeraldEditLogQuery' => 'PhabricatorOffsetPagedQuery',
Rough cut of Herald home controller.
2011-03-22 21:49:46 +01:00
'HeraldHomeController' => 'HeraldController',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'HeraldInvalidConditionException' => 'Exception',
'HeraldInvalidFieldException' => 'Exception',
Herald 'new rule type' interface.
2011-03-22 22:34:38 +01:00
'HeraldNewController' => 'HeraldController',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'HeraldRecursiveConditionsException' => 'Exception',
Herald skeleton.
2011-03-22 21:22:40 +01:00
'HeraldRule' => 'HeraldDAO',
Horrendously rough cut of Herald rule editor.
2011-03-22 23:27:52 +01:00
'HeraldRuleController' => 'HeraldController',
Add basic edit history to herald rules Summary: Add a very basic edit history table to herald rules. This table is updated whenever saving a herald rule. The contents of the save are not examined, and the edit history contains no information about the rule itself *yet*. Edit history can be viewed by anyone through /herald/history/<rule id>/. Task ID: # Blame Rev: Test Plan: Made a test rule, saved some stuff. Revert Plan: Tags: Reviewers: epriestley, jungejason Reviewed By: epriestley CC: zizzy, aran, xela, epriestley Differential Revision: https://secure.phabricator.com/D1387
2012-01-30 20:51:23 +01:00
'HeraldRuleEdit' => 'HeraldDAO',
'HeraldRuleEditHistoryController' => 'HeraldController',
'HeraldRuleEditHistoryView' => 'AphrontView',
Enable admin to view and delete other users' herald rules Summary: enable admin to delete user's herald rules. This is useful for managing non-active users' rules. For example, ex-employees' rules. The code change includes: - Added a 'All' tab which is only accessible to admin. - Refactor out a HeraldRuleListView which is used by both the home controller and the all rule controller Test Plan: delete an ex-employee rule as an admin; disable myself as admin and verified that I don't have access to view other user's rules and I'am not be able to delete them; also verified that as a non-admin, I can still view, create and delete my own rules. Reviewers: epriestley, nh Reviewed By: epriestley CC: aran, epriestley, jungejason Differential Revision: 1064
2011-11-06 09:07:04 +01:00
'HeraldRuleListView' => 'AphrontView',
General Herald refactoring pass Summary: **Who can delete global rules?**: I discussed this with @jungejason. The current behavior is that the rule author or any administrator can delete a global rule, but this isn't consistent with who can edit a rule (anyone) and doesn't really make much sense (it's an artifact of the global/personal split). I proposed that anyone can delete a rule but we don't actually delete them, and log the deletion. However, when it came time to actually write the code for this I backed off a bit and continued actually deleting the rules -- I think this does a reasonable job of balancing accountability with complexity. So the new impelmentation is: - Personal rules can be deleted only by their owners. - Global rules can be deleted by any user. - All deletes are logged. - Logs are more detailed. - All logged actions can be viewed in aggregate. **Minor Cleanup** - Merged `HomeController` and `AllController`. - Moved most queries to Query classes. - Use AphrontFormSelectControl::renderSelectTag() where appropriate (this is a fairly recent addition). - Use an AphrontErrorView to render the dry run notice (this didn't exist when I ported). - Reenable some transaction code (this works again now). - Removed the ability for admins to change rule authors (this was a little buggy, messy, and doesn't make tons of sense after the personal/global rule split). - Rules which depend on other rules now display the right options (all global rules, all your personal rules for personal rules). - Fix a bug in AphrontTableView where the "no data" cell would be rendered too wide if some columns are not visible. - Allow selectFilter() in AphrontNavFilterView to be called without a 'default' argument. Test Plan: - Browsed, created, edited, deleted personal and gules. - Verified generated logs. - Did some dry runs. - Verified transcript list and transcript details. - Created/edited all/any rules; created/edited once/every time rules. - Filtered admin views by users. Reviewers: jungejason, btrahan Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D2040
2012-03-30 19:49:55 +02:00
'HeraldRuleQuery' => 'PhabricatorOffsetPagedQuery',
Very rough cut at Herald test console.
2011-03-24 21:49:21 +01:00
'HeraldTestConsoleController' => 'HeraldController',
Herald skeleton.
2011-03-22 21:22:40 +01:00
'HeraldTranscript' => 'HeraldDAO',
Rough cut of herald transcripts and Differential adapter.
2011-03-25 05:32:26 +01:00
'HeraldTranscriptController' => 'HeraldController',
'HeraldTranscriptListController' => 'HeraldController',
Examples using JX.View Summary: Provide a dirt-simple working example of client-side templating and reactive programming. Test Plan: Load the examples Reviewers: epriestley, mroch, tomo Reviewed By: epriestley CC: ide, schrockn, aran, rzadorozny, epriestley Differential Revision: 908
2011-09-07 23:01:13 +02:00
'JavelinReactorExample' => 'PhabricatorUIExample',
Add support for placeholders Summary: Support placeholder text for inputs. We currently don't use this because it requires JS and doesn't degrade (no JS means you have zero idea what the input is for if it isn't separately labeled) but there are some cases where intent is obvious from context (for example, the search input in the menu bar, which is fairly obvious on its own and will soon have a magnifying glass icon) and in such cases it's much prettier and saves a bunch of space over an explicit label. Add a behavior so we can add placeholders where they make sense. This implementation is somewhat sanity-checked agianst the two jQuery placeholder implementations I was able to google: https://github.com/danielstocks/jQuery-Placeholder/ https://github.com/mathiasbynens/jquery-placeholder Since we don't currently have any uses cases, I haven't included support for making JS access to the `value` work, for password inputs, or for dynamically altering the placeholder. Test Plan: Played around with the placeholder in the UI example in various browsers and couldn't break it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3103
2012-07-31 01:08:10 +02:00
'JavelinUIExample' => 'PhabricatorUIExample',
Examples using JX.View Summary: Provide a dirt-simple working example of client-side templating and reactive programming. Test Plan: Load the examples Reviewers: epriestley, mroch, tomo Reviewed By: epriestley CC: ide, schrockn, aran, rzadorozny, epriestley Differential Revision: 908
2011-09-07 23:01:13 +02:00
'JavelinViewExample' => 'PhabricatorUIExample',
'JavelinViewExampleServerView' => 'AphrontView',
Implement a more compact, general database-backed key-value cache Summary: See discussion in D4204. Facebook currently has a 314MB remarkup cache with a 55MB index, which is slow to access. Under the theory that this is an index size/quality problem (the current index is on a potentially-384-byte field, with many keys sharing prefixes), provide a more general index with fancy new features: - It implements PhutilKeyValueCache, so it can be a component in cache stacks and supports TTL. - It has a 12-byte hash-based key. - It automatically compresses large blocks of data (most of what we store is highly-compressible HTML). Test Plan: - Basics: - Loaded /paste/, saw caches generate and save. - Reloaded /paste/, saw the page hit cache. - GC: - Ran GC daemon, saw nothing. - Set maximum lifetime to 1 second, ran GC daemon, saw it collect the entire cache. - Deflate: - Selected row formats from the database, saw a mixture of 'raw' and 'deflate' storage. - Used profiler to verify that 'deflate' is fast (12 calls @ 220us on my paste list). - Ran unit tests Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D4259
2012-12-21 23:17:56 +01:00
'LiskChunkTestCase' => 'PhabricatorTestCase',
Add regression test for LiskDAO::__call() Summary: D3606 Test Plan: Deleted `call()`, ran the test. Reviewers: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3814
2012-10-24 21:47:53 +02:00
'LiskDAOTestCase' => 'PhabricatorTestCase',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'LiskEphemeralObjectException' => 'Exception',
Provide isolated, read/write storage fixtures for unit tests Summary: - Unit tests can request storage fixtures. - We build one fixture across all tests in the process, which can quickstart (takes roughly 1s to build, 200ms to destroy for me). This is a one-time cost for running an arbitrary number of fixture-based tests. - We isolate all the connections inside transactions for each test, so individual tests don't affect one another. Test Plan: Ran unit tests, which cover the important properties of fixtures. Reviewers: btrahan, vrana, jungejason, edward Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T140 Differential Revision: https://secure.phabricator.com/D2345
2012-05-02 21:42:23 +02:00
'LiskFixtureTestCase' => 'PhabricatorTestCase',
Provide connection isolation to Lisk and enable it by default in tests Summary: Allow Lisk to be put into process-isolated mode which establishes only isolated connections. By default, put it into this mode when running unit tests. Build some simple unit tests around object insertion and updating. NOTE: The one flaw in this is that $dao->establishConnection() still punches through the isolation layer. I need to do an API change to fix this though so I'm holding it for now. It will probably just rename getConnection() to establishConnection() and then rename establishConnection() to something scary like establishLiveExternalConnection(). Test Plan: Ran unit tests. Reviewed By: aran Reviewers: aran, tuomaspelkonen, jungejason CC: aran, epriestley Differential Revision: 194
2011-04-30 19:11:59 +02:00
'LiskIsolationTestCase' => 'PhabricatorTestCase',
'LiskIsolationTestDAO' => 'LiskDAO',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'LiskIsolationTestDAOException' => 'Exception',
Add PhutilFactsUpateIterator Summary: This iterator processes objects that have been updated. Test Plan: Ran this test script: $cursor = null; $table = new DifferentialRevision(); while (true) { $iterator = new PhabricatorFactsUpdateIterator($table, $cursor); foreach ($iterator as $new_cursor => $update) { echo "{$new_cursor} => D".$update->getID()."\n"; $cursor = $new_cursor; } echo "Zzz...\n"; sleep(5); } Verified it iterated over every object and then stopped. Made a comment on a differenial revision, verified it iterated over the object after 15 seconds. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3077
2012-07-26 22:09:36 +02:00
'LiskMigrationIterator' => 'PhutilBufferedIterator',
Extend ManiphestAction from ManiphestConstants, not PhrictionConstants Summary: Bad copy/paste. Test Plan: arc liberate Reviewers: svemir, allenjohnashton Reviewed By: svemir CC: aran Differential Revision: https://secure.phabricator.com/D2738
2012-06-13 23:41:43 +02:00
'ManiphestAction' => 'ManiphestConstants',
Support for config-based custom fields in Maniphest Test Plan: Add fields to config based on specification on T335. View on Task Edit and Task Detail. Supported types are string, int and select Reviewed By: epriestley Reviewers: epriestley CC: aran, epriestley, hunterbridges Differential Revision: 753
2011-07-27 18:49:50 +02:00
'ManiphestAuxiliaryFieldDefaultSpecification' => 'ManiphestAuxiliaryFieldSpecification',
Implement remarkup custom control Summary: Ref T2575. Adds "remarkup" control, which displays a remarkup control and uses the remarkup cache. Grants fields access to remarkup pipeline. Test Plan: {F35067} {F35068} Used DarkConsole to verify cache interaction with services. Reviewers: hach-que, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2575 Differential Revision: https://secure.phabricator.com/D5286
2013-03-08 02:24:33 +01:00
'ManiphestAuxiliaryFieldSpecification' => 'PhabricatorMarkupInterface',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'ManiphestAuxiliaryFieldTypeException' => 'Exception',
'ManiphestAuxiliaryFieldValidationException' => 'Exception',
Rough batch editor for Maniphest Summary: First stab at a batch editor for Maniphest. Basically, you can select a group of tasks and then import them into the "batch" interface, where you can edit all of them at once. High level goal is to make it easier for users in PM/filer/support/QA roles to deal with large numbers of tasks quickly. This implementation has a few major limitations: - The only available actions are "add projects" and "remove projects". - There is no review / undo / log stuff. - All the changes are applied in-process, which may not scale terribly well. However, the immediate need is just around projects and this seemed like a reasonable place to draw the line for a minimal useful version of the tool. Test Plan: Used batch editor to add and remove projects from groups of tasks. Reviewers: btrahan, yairlivne Reviewed By: btrahan CC: aran, epriestley, sandra Maniphest Tasks: T441 Differential Revision: https://secure.phabricator.com/D1680
2012-02-24 22:00:48 +01:00
'ManiphestBatchEditController' => 'ManiphestController',
Maniphest wireframes Summary: Test Plan: Reviewers: CC:
2011-02-08 19:53:59 +01:00
'ManiphestController' => 'PhabricatorController',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ManiphestCreateMailReceiver' => 'PhabricatorMailReceiver',
Maniphest wireframes Summary: Test Plan: Reviewers: CC:
2011-02-08 19:53:59 +01:00
'ManiphestDAO' => 'PhabricatorLiskDAO',
Tweak Maniphest custom fields Summary: - Fix a bug where 'caption' didn't do anything. - Provide an abstract base implementation for extensions. - Add some documentation. - Expose aux fields via conduit. Test Plan: Added some fields like "Dinosaur", "Kilograms" and "derp" on my local install. Read documentation. Reviewed By: jungejason Reviewers: hunterbridges, jungejason, tuomaspelkonen, aran CC: aran, philc, jungejason Differential Revision: 785
2011-08-05 18:44:43 +02:00
'ManiphestDefaultTaskExtensions' => 'ManiphestTaskExtensions',
Insert Maniphest transactions when edges are edited Summary: - See D2741. - When EdgeEditor performs edits, emit events. - Listen for Maniphest edge events and save the changes as transactions. - Do all this in a reasonably generic way that won't take too much rewriting as we use edges more generally. Test Plan: Attached and detached commits from tasks, saw reasonable-looking transactions spring into existence. Reviewers: btrahan, davidreuss Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2906
2012-07-03 00:42:06 +02:00
'ManiphestEdgeEventListener' => 'PhutilEventListener',
Implemented support for different export formats. Summary: This adds support for different export formats to Excel via a drop-down on the Export page as per the discussion in D5443. Test Plan: Export some things from Maniphest. Do a simple implementation of ManiphestExcelFormat just for testing and make sure that it appears in the list after you run `arc liberate`. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2575 Differential Revision: https://secure.phabricator.com/D5642 Conflicts: src/applications/maniphest/controller/ManiphestExportController.php
2013-04-11 20:22:06 +02:00
'ManiphestExcelDefaultFormat' => 'ManiphestExcelFormat',
Add excel export to Maniphest Summary: Allow Maniphest result sets to be exported to Excel. Spreadsheet_Excel_Writer is awful but comparatively easy to get working. There's also a "PHPExcel" package but it has some autoload conflicts right now and this seems good-enough. Test Plan: Exported a bunch of tasks to Excel. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T923 Differential Revision: https://secure.phabricator.com/D1721
2012-02-29 06:07:12 +01:00
'ManiphestExportController' => 'ManiphestController',
Add Maniphest Hovercard event listener Summary: Refs T1048 badassery Test Plan: Used in a future diff. Verified correct appearance of hovercard Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1048 Differential Revision: https://secure.phabricator.com/D5544
2013-04-03 19:05:48 +02:00
'ManiphestHovercardEventListener' => 'PhutilEventListener',
Update PeopleMenu to only show integration with applications if they are installed Summary: do so via event engine. note different order now... Test Plan: toggled "show beta applications" to off and noted that Conpherence disappeared. Otherwise noted that links showed. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2424 Differential Revision: https://secure.phabricator.com/D4708
2013-02-05 22:46:02 +01:00
'ManiphestPeopleMenuEventListener' => 'PhutilEventListener',
Missing change from D5120 which I incorrectly discarded in a merge. Auditors: vrana
2013-02-27 16:18:30 +01:00
'ManiphestRemarkupRule' => 'PhabricatorRemarkupRuleObject',
Support email multiplexing for private Reply-To addresses Summary: Provide a base PhabricatorMailReplyHandler class which handles the plumbing for multiplexing email if necessary and supporting public and private reply handler addressses. DifferentialReplyHandler now extends it, and a new ManiphestReplyHandler also does. The general approach here is that we have three supported cases: - no reply handler, default config, same as what we're doing now - public reply handler, requires overriding classes but just sets "reply-to" to some address the install generates and still sends only one email - private reply handler, provides a default generation mechanism or you can override it and splits mail apart so we send one to each recipient Test Plan: Sent email from Maniphest and Differential with and without reply-handler-domains set. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran CC: aran, epriestley Differential Revision: 254
2011-05-10 01:31:26 +02:00
'ManiphestReplyHandler' => 'PhabricatorMailReplyHandler',
Add very very basic reporting to Maniphest Summary: Rough cut for Quora, we want this too eventually but it's super basic right now so I'm not linking it anywhere. Once we get a couple more iterations I'll put it in the UI. Test Plan: Looked at stats for test data. Reviewers: btrahan Reviewed By: btrahan CC: anjali, aran, epriestley Differential Revision: https://secure.phabricator.com/D1594
2012-02-08 18:47:14 +01:00
'ManiphestReportController' => 'ManiphestController',
Allow Maniphest queries to be saved Summary: There have been a couple of requests for this since bookmarks are "out this year like woah" and "totally uncool dude". Allow users to save named custom queries and make them the /maniphest/ default if they so desire. A little messy. :/ Test Plan: Saved, edited, deleted custom queries. Made custom query default; made 'no default' default. Verified default behavior. Issued a modified search from a custom query. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley, 20after4 Maniphest Tasks: T923, T1034 Differential Revision: https://secure.phabricator.com/D1964
2012-04-10 18:46:04 +02:00
'ManiphestSavedQuery' => 'ManiphestDAO',
'ManiphestSavedQueryDeleteController' => 'ManiphestController',
'ManiphestSavedQueryEditController' => 'ManiphestController',
'ManiphestSavedQueryListController' => 'ManiphestController',
Improve Search architecture Summary: The search indexing API has several problems right now: - Always runs in-process. - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it. - Being able to use the task queue will also make rebuilding indexes faster. - Instead, make the API phid-oriented. - No uniform indexing API. - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird. - Instead, provide a uniform API. - No uniform CLI. - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers. - Instead, let indexers expose documents for indexing. - Not application-oriented. - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world. - Instead, move indexers to applications and load them with SymbolLoader. Test Plan: - `bin/search index` - Indexed one revision, one task. - Indexed `--type TASK`, `--type DREV`, etc., for all types. - Indexed `--all`. - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it. - Creating users is a pain; searched for a user after indexing. - Creating commits is a pain; searched for a commit after indexing. - Mocks aren't currently loadable in the result view, so their indexing is moot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: 20after4, aran Maniphest Tasks: T1991, T2104 Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
'ManiphestSearchIndexer' => 'PhabricatorSearchDocumentIndexer',
Allow tasks to be subprioritized by drag-and-drop Summary: Like the title says, similar to Facebook Tasks. Not sure how I really feel about this, but I guess it's kind of OK? I never used this feature in Facebook Tasks but I think some people like it. The drag-and-drop to repri across priorities feels okayish. Because subpriority is a double and we just split the difference when reprioritizing, you lose ~a bit of precision every time you repri two tasks against each other and so you can break it by swapping the priorities of two tasks ~50 times. This case is pretty silly and pathological. We can add some code to deal with this at some point if necessary. I think this also fixes the whacky task layout widths once and for all. (There are a couple of minor UI glitches like headers not vanishing and header counts not updating that I'm not fixing because I am lazy.) Test Plan: Dragged and dropped tasks around. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley, mgummelt Maniphest Tasks: T859 Differential Revision: https://secure.phabricator.com/D1731
2012-04-02 21:12:04 +02:00
'ManiphestSubpriorityController' => 'ManiphestController',
Countdown revamp Summary: countdown_timer table named to countdown. datepoint and related stuff renamed to epoch. Countdowns now have phids. Various UI items changed from timer to countdown. Test Plan: Did run storage upgrade and added some countdowns. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2624 Differential Revision: https://secure.phabricator.com/D5812
2013-05-04 00:49:29 +02:00
'ManiphestSubscribeController' => 'ManiphestController',
Add a differential.createinline method to Conduit Summary: a silly thing because I was bored Test Plan: and I said "arc call-conduit", and there were comments Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1500 Differential Revision: https://secure.phabricator.com/D2971
2012-07-16 20:49:06 +02:00
'ManiphestTask' =>
array(
0 => 'ManiphestDAO',
1 => 'PhabricatorMarkupInterface',
Renders the last 100 conpherence transactions only Summary: Fixed T2428 a little bit Test Plan: On trial, only the last n transactions loaded as hardcoded in ConpherenceViewController.php. Button was rendered. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2428 Differential Revision: https://secure.phabricator.com/D4898
2013-02-15 23:01:27 +01:00
2 => 'PhabricatorPolicyInterface',
3 => 'PhabricatorTokenReceiverInterface',
Implemented Phrequent time tracking functionality. Summary: This differential implements Phrequent's time tracking functionality for users and hooks it up to Maniphest. It also includes a basic "Time Tracked" list for the Phrequent application, where users can review what they've spent time working on. Test Plan: Apply the patch and track some things in Maniphest. They should appear in the "Time Tracked" view of Phrequent. There is also a `phrequent.show-prompt` option which toggles whether to display a prompt when tracking time. I'm unsure of whether the prompt is useful or is more likely to cause people to click "Track Time", go off and do the task and then come back to the prompt still waiting for them to confirm. A potential solution to the "accidentally clicking the button and recording 2 seconds of time" might be to show a prompt on stop if the total time is under 10 seconds, asking whether the user wants to keep or discard the tracked time. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2857 Differential Revision: https://secure.phabricator.com/D5479
2013-03-30 17:32:29 +01:00
4 => 'PhrequentTrackableInterface',
Add a differential.createinline method to Conduit Summary: a silly thing because I was bored Test Plan: and I said "arc call-conduit", and there were comments Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1500 Differential Revision: https://secure.phabricator.com/D2971
2012-07-16 20:49:06 +02:00
),
Key Value Store for ManiphestTask Test Plan: Look at a task detail. Some dummy attributes are automatically added in ManiphestTaskDetailController. Reviewed By: epriestley Differential Revision: 730
2011-07-26 00:34:56 +02:00
'ManiphestTaskAuxiliaryStorage' => 'ManiphestDAO',
Show description changes in Maniphest Summary: When a task description is updated, there's currently no way to see the change. Build an "expanded summary" mode for transactions that shows description change details. Also include changes in the email. Test Plan: Changed task descriptions, clicked "show details", read email. Reviewed By: aran Reviewers: tuomaspelkonen, jungejason, aran CC: anjali, aran, epriestley Differential Revision: 320
2011-05-21 03:56:18 +02:00
'ManiphestTaskDescriptionChangeController' => 'ManiphestController',
Add a description preview to maniphest create / edit panel Summary: also fixes a small bug where the page title was always "Create Task". switch it to the header name which is much more descriptive / correct IMO. Test Plan: created a new task and watched the description preview update. edited an old task and saw the description preview populate with the correct existing data. edited an old task and edited the description and saw the description preview update Reviewers: epriestley CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1489
2012-01-25 20:23:00 +01:00
'ManiphestTaskDescriptionPreviewController' => 'ManiphestController',
Maniphest wireframes Summary: Test Plan: Reviewers: CC:
2011-02-08 19:53:59 +01:00
'ManiphestTaskDetailController' => 'ManiphestController',
Enable task editing in Maniphest. Summary: Test Plan: Reviewers: CC:
2011-02-20 23:15:53 +01:00
'ManiphestTaskEditController' => 'ManiphestController',
Maniphest wireframes Summary: Test Plan: Reviewers: CC:
2011-02-08 19:53:59 +01:00
'ManiphestTaskListController' => 'ManiphestController',
Slightly improve Maniphest documentation.
2011-07-04 22:04:22 +02:00
'ManiphestTaskListView' => 'ManiphestView',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ManiphestTaskMailReceiver' => 'PhabricatorObjectMailReceiver',
Slightly improve Maniphest documentation.
2011-07-04 22:04:22 +02:00
'ManiphestTaskOwner' => 'ManiphestConstants',
'ManiphestTaskPriority' => 'ManiphestConstants',
Allow Maniphest tasks to be filtered by Project Summary: Major things taking place here: - A new table for storing <task, project> relationships. - Moved all task query logic into a dedicated class. - Added a "projects" filter to the UI. I was originally going to try to drive this off the main search index but the perf benefits of a custom schema make an overwhelming argument in favor of doing it this way. Test Plan: Filtered tasks by author and owner and zero, one, and more than one project. Exercised all the group/sort options. Ran the index script over my 100k task corpus. Edited task-project membership and verified the index updated. Reviewed By: cadamo Reviewers: gc3, jungejason, cadamo, tuomaspelkonen, aran CC: aran, cadamo, epriestley Differential Revision: 556
2011-06-30 01:16:33 +02:00
'ManiphestTaskProject' => 'ManiphestDAO',
Show projects on Maniphest tasks Summary: - Remove the "Priority" column, since this is indicated by the color swatch, to save space. - Reduce the "Updated" column from datetime to date only, since time isn't incredibly useful, to save space. - Show the first two projects a task is associated with, and "..." if there are more. - Show "None" (for "no owner") in a lighter color. Test Plan: Looked at tasks on homepage and in Maniphest. Reviewers: btrahan, 20after4 Reviewed By: btrahan CC: aran, edward Maniphest Tasks: T967 Differential Revision: https://secure.phabricator.com/D2065
2012-04-02 19:27:31 +02:00
'ManiphestTaskProjectsView' => 'ManiphestView',
Add basic "Subscriptions" application Summary: Basic infrastructure for generalizing subscriptions/CCs for T1808, T1514 and T1663. - Implement `PhabricatorSubscribableInterface` and you'll get a subscribe/unsubscribe button for free. - If there are any auto-subscribed users (like the question author) you can specify them; this makes more sense for Tasks and Revisions than Ponder probably, but maybe the author should be auto-subscribed. - Subscriptions are either "explicit" (the user clicked 'subscribe') or "implicit" (the user did something which causes them to become subscribed naturally). If a user unsubscribes, they'll no longer be added by implicit subscriptions. This may or may not be relevant to Ponder but is an existing Herald feature in Differential. - Helper method on PhabricatorSubscribersQuery to load subscribers. - This doesn't handle actually sending email, etc. I think that's all so application-specific that it doesn't belong here. - Now seems to work. Test Plan: {F20552} {F20553} Reviewers: pieter, btrahan Reviewed By: pieter CC: aran Maniphest Tasks: T1663, T1514, T1808 Differential Revision: https://secure.phabricator.com/D3637
2012-10-05 22:18:05 +02:00
'ManiphestTaskQuery' => 'PhabricatorQuery',
Slightly improve Maniphest documentation.
2011-07-04 22:04:22 +02:00
'ManiphestTaskStatus' => 'ManiphestConstants',
Added subscriber view to Maniphest. Summary: People want to see all the tasks they have subscribed to in one view. A new table was added for this to make queries faster. Test Plan: Tested that the view was initially empty. After running the reindex_maniphest.php script, I saw the correct tasks there. Added myself as a subscriber to one task and made sure the view was updated. Removed myself as a subscriber from one task and made sure the view was updated again. Reviewed By: epriestley Reviewers: epriestley, jungejason, codeblock CC: aran, rm, epriestley Differential Revision: 603
2011-07-07 19:24:49 +02:00
'ManiphestTaskSubscriber' => 'ManiphestDAO',
Add a differential.createinline method to Conduit Summary: a silly thing because I was bored Test Plan: and I said "arc call-conduit", and there were comments Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1500 Differential Revision: https://secure.phabricator.com/D2971
2012-07-16 20:49:06 +02:00
'ManiphestTransaction' =>
array(
0 => 'ManiphestDAO',
1 => 'PhabricatorMarkupInterface',
),
Slightly improve Maniphest documentation.
2011-07-04 22:04:22 +02:00
'ManiphestTransactionDetailView' => 'ManiphestView',
If users are on the email to Phabricator, do not send them the Phabricator reply. Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email. Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected. Reviewers: epriestley, vrana Reviewed By: vrana CC: aran, Korvin, vrana Maniphest Tasks: T1676 Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 19:18:23 +02:00
'ManiphestTransactionEditor' => 'PhabricatorEditor',
Slightly improve Maniphest documentation.
2011-07-04 22:04:22 +02:00
'ManiphestTransactionListView' => 'ManiphestView',
Add comment previews to Maniphest Summary: Moves shared code from Differential and Maniphest comment previews into PhabricatorShapedRequest, and then implements Maniphest previews. This doesn't implement comment drafts, I'll follow up with that but it requires this and is completely separable. This also always shows the preview as "commented" rather than previewing the actual transaction. I'll follow up with that but I think it will require a little factoring and this is useful even without transaction details. I need to tweak the styling a bit too. Test Plan: Typed text in Maniphest and Differential. Toggled Differential action. Made comments. Reviewed By: rm Reviewers: rm, tuomaspelkonen, jungejason, aran CC: aran, rm Differential Revision: 258
2011-05-10 17:29:28 +02:00
'ManiphestTransactionPreviewController' => 'ManiphestController',
Maniphest wireframes Summary: Test Plan: Reviewers: CC:
2011-02-08 19:53:59 +01:00
'ManiphestTransactionSaveController' => 'ManiphestController',
Slightly improve Maniphest documentation.
2011-07-04 22:04:22 +02:00
'ManiphestTransactionType' => 'ManiphestConstants',
'ManiphestView' => 'AphrontView',
Add email preferences to receive fewer less-important notifications Summary: A few similar requests have come in across several tools and use cases that I think this does a reasonable job of resolving. We currently send one email for each update an object receives, but these aren't always appreciated: - Asana does post-commit review via Differential, so the "committed" mails are useless. - Quora wants to make project category edits to bugs without spamming people attached to them. - Some users in general are very sensitive to email volumes, and this gives us a good way to reduce the volumes without incurring the complexity of delayed-send-batching. The technical mechanism is basically: - Mail may optionally have "mail tags", which indicate content in the mail (e.g., "maniphest-priority, maniphest-cc, maniphest-comment" for a mail which contains a priority change, a CC change, and a comment). - If a mail has tags, remove any recipients who have opted out of all the tags. - Some tags can't be opted out of via the UI, so this ensures that important email is still delivered (e.g., cc + assign + comment is always delivered because you can't opt out of "assign" or "comment"). Test Plan: - Disabled all mail tags in the web UI. - Used test console to send myself mail with an opt-outable tag, it was immediately dropped. - Used test console to send myself mail with an opt-outable tag and a custom tag, it was delivered. - Made Differential updates affecting CCs with and without comments, got appropriate delivery. - Made Maniphest updates affecting project, priority and CCs with and without comments, got appropriate delivery. - Verified mail headers in all cases. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley, moskov Maniphest Tasks: T616, T855 Differential Revision: https://secure.phabricator.com/D1635
2012-02-18 07:57:07 +01:00
'MetaMTANotificationType' => 'MetaMTAConstants',
Begin improving the soundness of received mail Summary: We/I broke a couple of things here recently (see D5911) and are doing some work here in general (see D5912, etc.). Generally, this code is pretty oldschool and not especially well architected for modern application-oriented Phabricator. It hardcodes a lot of stuff which should be applications' responsibilites. Take the first steps toward making it more solid to reduce the risk here. In particular: - Factor out the "self mail" and "duplicate mail" checks and add unit tests. - Make Message-ID hash handling automatic. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5915
2013-05-14 01:32:19 +02:00
'MetaMTAReceivedMailStatus' => 'MetaMTAConstants',
Detect package change and send out email Summary: For package creation and deletion, send email to all the owners For package modification, detect important fields such as owners and paths, and then send out emails to all owners (including deleted owners and current owners) Also start using transaction for package creation/deletion/modification. Test Plan: - tested mail creation and deletion - tested modification to auditing enabled, primary owners, owners, paths Reviewers: epriestley, nh, vrana Reviewed By: epriestley CC: prithvi, aran, Koolvin Differential Revision: https://secure.phabricator.com/D2470
2012-05-07 09:19:44 +02:00
'OwnersPackageReplyHandler' => 'PhabricatorMailReplyHandler',
PHUIBoxView Summary: Adds a basic div box that takes some styles. Not sure this is the best approach for the spacing, but overall hoping people can spend less time in CSS and just use this class. Test Plan: UIExamples Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin, AnhNhan Differential Revision: https://secure.phabricator.com/D5723
2013-04-18 20:34:02 +02:00
'PHUIBoxExample' => 'PhabricatorUIExample',
'PHUIBoxView' => 'AphrontTagView',
PHUIButtonView class Summary: Rough pass at a PHUIButtonView Class. Keeps phutil_tag intact and adds some image features if you use the class. Test Plan: UIExamples Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6192
2013-06-13 03:23:35 +02:00
'PHUIButtonExample' => 'PhabricatorUIExample',
'PHUIButtonView' => 'AphrontTagView',
PHUIList, PHUIDocument updates Summary: This diff covers a bit of ground. - PHUIDocumentExample has been added - PHUIDocument has been extended with new features - PhabricatorMenuView is now PHUIListView - PhabricatorMenuItemView is now PHUIItemListView Overall - I think I've gotten all the edges covered here. There is some derpi-ness that we can talk about, comments in the code. Responsive design is missing from the new features on PHUIDocument, will follow up later. Test Plan: Tested mobile and desktop menus, old phriction layout, new document views, new lists, and object lists. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6130
2013-06-05 17:41:43 +02:00
'PHUIDocumentExample' => 'PhabricatorUIExample',
Separate Phriction style into PHUIDocumentView Summary: Ref T988. Fixes T3150. I want to use this element in Diviner, so separate it from Phriction. This makes no changes to the actual display except for fixing {T3150} by adding `overflow: hidden;`. Test Plan: Viewed Phriction documents in mobile and desktop views. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T3150 Differential Revision: https://secure.phabricator.com/D6101
2013-06-01 00:03:59 +02:00
'PHUIDocumentView' => 'AphrontTagView',
Feed Story UI Examples. Summary: This provides some new display methods and examples to PHUIFeedStory. Test Plan: Tested UIExamples Page, mobile layouts, and existing Feed Pages (feed, profile, etc). I want to add a bit more but am stopping here since it's not a priority. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5749
2013-04-25 00:18:58 +02:00
'PHUIFeedStoryExample' => 'PhabricatorUIExample',
PHUIFeedStoryView, Update Profile Summary: This moves Feed's rendering over to a PHUI class. I want to build it out and have it power Ponder, Phame, Feed, as well as Profiles and Projects in some fashion. It also provides some more data depth over ObjectItemView. Also updated Profile for mobile and fixed some other display issues there. Test Plan: Tested Feed, Profile. Used iOS and Chrome. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin, AnhNhan Differential Revision: https://secure.phabricator.com/D5687
2013-04-15 04:32:26 +02:00
'PHUIFeedStoryView' => 'AphrontView',
Add instructions about READMEs to new Diffusion basic editor Summary: Provide contextual, in-app documentation about README files. Test Plan: {F44181} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6033
2013-05-24 21:38:27 +02:00
'PHUIFormDividerControl' => 'AphrontFormControl',
Add a date range query to Macros Summary: Ref T1163. Ref T2625. This could probably use some tweaks, but I kept things mostly-generic. I added a new control for freeform dates so we can have it render help or whatever later on. Test Plan: See screenshots. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625, T1163 Differential Revision: https://secure.phabricator.com/D6084
2013-05-31 02:32:12 +02:00
'PHUIFormFreeformDateControl' => 'AphrontFormControl',
Add a basic multipage form Summary: Ref T2232. Very busy day on IRC so I feel like I've made 20 minutes of progress in 1-minute spurts here, but this adds the basics for a form that can have multiple pages and automatically handle pagination and reading to/from the request, objects and responses. The UIExample is reasonably instructive. Basically, you make a form, add pages to the form, and add controls to the pages. The core flow control looks like this: if ($request->isFormPost()) { $form->readFromRequest($request); // (1) if ($form->isComplete()) { // (2) $response = $form->writeToResponse($response); // (3) // Process result here. // (4) } } else { $form->readFromObject($object); // (5) } The key parts are: # This reads the form state from the request, including reading all the inactive pages. # This tests if all pages are valid and the user just clicked "Done" on the last page. # This produces a "response", which might be writing to an object (for simpler forms) or creating a transaction record (for more complex forms). # Here, we would save the object or apply the transactions. # When the user views the form for the first time, we preload all the values from some object (which might just be empty). Ultimate goal here is to fix repository creation to not be a terrible pit of awfulness. There are probably a lot of rough edges and missing features still, but this seems to not be totally crazy. I'm using two submit buttons with different names which doesn't work on IE7 or something, but we can JS our way out of that if we need to. Test Plan: Paged forward and backward through the form. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2232 Differential Revision: https://secure.phabricator.com/D6003
2013-05-23 23:39:01 +02:00
'PHUIFormMultiSubmitControl' => 'AphrontFormControl',
'PHUIFormPageView' => 'AphrontView',
PHUIIconView Summary: Adds a base class for displaying images and icons. Test Plan: Tested giving and taking tokens, viewed action headers, uiexamples for icons, workboards. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5736
2013-04-20 02:44:20 +02:00
'PHUIIconExample' => 'PhabricatorUIExample',
Make PHUIIconView extend AprontTagView Summary: Less code, more options. Test Plan: Test UIExamples page (action headers, tokens, icons and images). No visible difference. Reviewers: epriestley, btrahan, vrana Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5742
2013-04-22 18:49:06 +02:00
'PHUIIconView' => 'AphrontTagView',
PHUIListView Examples, CSS Summary: This adds examples and abstracts out CSS for common nav re-use. Test Plan: Tested DocumentExample and ListExample Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6138
2013-06-06 00:03:56 +02:00
'PHUIListExample' => 'PhabricatorUIExample',
PHUIList, PHUIDocument updates Summary: This diff covers a bit of ground. - PHUIDocumentExample has been added - PHUIDocument has been extended with new features - PhabricatorMenuView is now PHUIListView - PhabricatorMenuItemView is now PHUIItemListView Overall - I think I've gotten all the edges covered here. There is some derpi-ness that we can talk about, comments in the code. Responsive design is missing from the new features on PHUIDocument, will follow up later. Test Plan: Tested mobile and desktop menus, old phriction layout, new document views, new lists, and object lists. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6130
2013-06-05 17:41:43 +02:00
'PHUIListItemView' => 'AphrontTagView',
'PHUIListView' => 'AphrontTagView',
'PHUIListViewTestCase' => 'PhabricatorTestCase',
Add a basic multipage form Summary: Ref T2232. Very busy day on IRC so I feel like I've made 20 minutes of progress in 1-minute spurts here, but this adds the basics for a form that can have multiple pages and automatically handle pagination and reading to/from the request, objects and responses. The UIExample is reasonably instructive. Basically, you make a form, add pages to the form, and add controls to the pages. The core flow control looks like this: if ($request->isFormPost()) { $form->readFromRequest($request); // (1) if ($form->isComplete()) { // (2) $response = $form->writeToResponse($response); // (3) // Process result here. // (4) } } else { $form->readFromObject($object); // (5) } The key parts are: # This reads the form state from the request, including reading all the inactive pages. # This tests if all pages are valid and the user just clicked "Done" on the last page. # This produces a "response", which might be writing to an object (for simpler forms) or creating a transaction record (for more complex forms). # Here, we would save the object or apply the transactions. # When the user views the form for the first time, we preload all the values from some object (which might just be empty). Ultimate goal here is to fix repository creation to not be a terrible pit of awfulness. There are probably a lot of rough edges and missing features still, but this seems to not be totally crazy. I'm using two submit buttons with different names which doesn't work on IE7 or something, but we can JS our way out of that if we need to. Test Plan: Paged forward and backward through the form. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2232 Differential Revision: https://secure.phabricator.com/D6003
2013-05-23 23:39:01 +02:00
'PHUIPagedFormView' => 'AphrontTagView',
PHUI Text View Summary: Adds basic colors and text styles for shorthand use. Test Plan: UIExamples Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5751
2013-04-22 23:28:23 +02:00
'PHUITextExample' => 'PhabricatorUIExample',
'PHUITextView' => 'AphrontTagView',
Detect package change and send out email Summary: For package creation and deletion, send email to all the owners For package modification, detect important fields such as owners and paths, and then send out emails to all owners (including deleted owners and current owners) Also start using transaction for package creation/deletion/modification. Test Plan: - tested mail creation and deletion - tested modification to auditing enabled, primary owners, owners, paths Reviewers: epriestley, nh, vrana Reviewed By: epriestley CC: prithvi, aran, Koolvin Differential Revision: https://secure.phabricator.com/D2470
2012-05-07 09:19:44 +02:00
'PackageCreateMail' => 'PackageMail',
'PackageDeleteMail' => 'PackageMail',
Require a viewer to load handles Summary: Unmuck almost all of the we-sort-of-have-viewers-some-of-the-time mess. There are a few notable cases here: - I used Omnipotent users when indexing objects for search. I think this is correct; we do policy filtering when showing results. - I cheated in a bad way in the Remarkup object rule, but fixing this requires fixing all the PhabricatorRemarkupEngine callsites (there are 85). I'll do that in the next diff. - I cheated in a few random places, like when sending mail about package edits. These aren't a big deal. Test Plan: - Grepped for all PhabricatorObjectHandleData references. - Gave them viewers. Reviewers: vrana Reviewed By: vrana CC: aran, edward Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D5151
2013-03-01 02:15:09 +01:00
'PackageMail' => 'PhabricatorMail',
Detect package change and send out email Summary: For package creation and deletion, send email to all the owners For package modification, detect important fields such as owners and paths, and then send out emails to all owners (including deleted owners and current owners) Also start using transaction for package creation/deletion/modification. Test Plan: - tested mail creation and deletion - tested modification to auditing enabled, primary owners, owners, paths Reviewers: epriestley, nh, vrana Reviewed By: epriestley CC: prithvi, aran, Koolvin Differential Revision: https://secure.phabricator.com/D2470
2012-05-07 09:19:44 +02:00
'PackageModifyMail' => 'PackageMail',
Paste embeds look super cool Summary: Make Paste embeds look super cool Test Plan: {F35387} Reviewers: epriestley CC: aran, Korvin, chad, btrahan, AnhNhan Maniphest Tasks: T1770 Differential Revision: https://secure.phabricator.com/D5323
2013-03-13 14:44:27 +01:00
'PasteEmbedView' => 'AphrontView',
I guess this can support JS too.
2011-01-30 01:16:09 +01:00
'Phabricator404Controller' => 'PhabricatorController',
Add Disqus, Facebook, Google, GitHub auth config; AWS config Summary: Also improve behavior for the "unknown config" warning. Test Plan: Looked at configs, went through unknown config workflow. Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4310
2013-01-01 23:09:29 +01:00
'PhabricatorAWSConfigOptions' => 'PhabricatorApplicationConfigOptions',
Add "Developer" and "Access Log" config option groups, some types Summary: - Add a "developer" option group. - Add an "access log" option group. - Render the types "bool", "int" and "string" in a more tailored way. - Add a config check for dead config. Right now this serves as a "TODO" list of things that need to be migrated. Test Plan: Looked at config options, setup issues. Edited bool, int, string options. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4308
2013-01-01 23:09:17 +01:00
'PhabricatorAccessLogConfigOptions' => 'PhabricatorApplicationConfigOptions',
PhabricatorActionHeaderView v0 Summary: Initial pass at an action header. The idea is to support current and future planned needs in 'headers' with various colors and icons. The overall goal here is to keep markup light and allow other classes to wrap and extend with more specific features. Test Plan: Tested UIExamples and Workboards. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin, AnhNhan Differential Revision: https://secure.phabricator.com/D5585
2013-04-05 16:40:27 +02:00
'PhabricatorActionHeaderExample' => 'PhabricatorUIExample',
'PhabricatorActionHeaderView' => 'AphrontView',
Allow action list items to render as forms Summary: In some cases, we want an action item (like "Subscribe") to effect a write that needs a CSRF check. Allow such items to render as forms so they gracefully degrade if JS is FUBAR'd. D3499 has a specific example. Test Plan: Loaded new UI example page, clicked all the actions. Reviewers: btrahan, vrana, avivey Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3596
2012-10-03 19:21:39 +02:00
'PhabricatorActionListExample' => 'PhabricatorUIExample',
Modernize Paste Summary: - Add a PhabricatorApplication. - Make most of the views work well on tablets / phones. The actual "Create" form doesn't, but everything else is good -- need to make device-friendly form layouts before I can do the form. Test Plan: Will attach screenshots. Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3293
2012-08-15 19:45:06 +02:00
'PhabricatorActionListView' => 'AphrontView',
'PhabricatorActionView' => 'AphrontView',
Adds ALL CAPS language. Summary: Adds an ALL CAPs language, requires changes from libphutil as well. Test Plan: Turn on AC, get caps back. Turn it back to English, stuff went away. Reviewers: epriestley, btrahan, vrana Reviewed By: vrana CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4627
2013-01-25 01:11:30 +01:00
'PhabricatorAllCapsTranslation' => 'PhabricatorTranslation',
Add local navigation to Differential Summary: Adds a flexible navigation menu to diffs that shows you your current position in the diff. Anticipating some "this is the best thing ever" and some "this is the wosrt thing ever" on this, but let's see how much pushback we get? It seems pretty good to me. Test Plan: Will attach screenshots. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1633, T1591 Differential Revision: https://secure.phabricator.com/D3355
2012-08-22 00:01:20 +02:00
'PhabricatorAnchorView' => 'AphrontView',
AphrontBars Summary: Aphront widgets that render the either a discrete or continuous value as a horizontal shape. Like a progress bar, or a five-star rating bar. Test Plan: `/uiexample/view/PhabricatorAphrontBarExample/` ...which shows this, amongst other things: {F33898} Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5122
2013-03-05 17:46:09 +01:00
'PhabricatorAphrontBarExample' => 'PhabricatorUIExample',
Add a meta-application Summary: - Adds a new "Applications" application. - Builds an application list via application config instead of via hard-coding, so we can move toward better concepts of installing/uninstalling applications, etc. - Applications indicate that they need attention with notice counts and brief status messages rathern than 50 giant tables of all sorts of app data. I want to try replacing the home screen with this screen, pretty much. Not sure if this is totally crazy or not. What does everyone else think? Test Plan: Will add screenshots. Reviewers: btrahan, chad, vrana, alanh Reviewed By: vrana CC: aran, davidreuss, champo Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3129
2012-08-02 23:07:21 +02:00
'PhabricatorApplicationApplications' => 'PhabricatorApplication',
'PhabricatorApplicationAudit' => 'PhabricatorApplication',
Drive menu icons from Applications Summary: This makes no changes, it just moves the menu icons to the applications instead of hard-coded on the page. I'm going to try to address some of the angst in T1593 next... Test Plan: Loaded logged-in / logged out pages. Clicked menu items. Looked at /applications/. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1593, T1569 Differential Revision: https://secure.phabricator.com/D3146
2012-08-05 23:12:43 +02:00
'PhabricatorApplicationAuth' => 'PhabricatorApplication',
Create a status tool by giving /calendar/ some teeth Summary: you can now add, edit, and delete status events. also added a "description" to status events and surface it in the big calendar view on mouse hover. some refactoring changes as well to make validation logic centralized within the storage class. Test Plan: added, edited, deleted. yay. Reviewers: epriestley, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T407 Differential Revision: https://secure.phabricator.com/D3810
2012-10-24 22:22:24 +02:00
'PhabricatorApplicationCalendar' => 'PhabricatorApplication',
Created Chat log application class Summary: Created a chat log application which displays on the home page. Test Plan: Loaded the home page to see if the chat log application really shows up on the home page. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4930
2013-02-13 16:28:14 +01:00
'PhabricatorApplicationChatLog' => 'PhabricatorApplication',
Add Conduit and Herald applications Summary: See D3572. Adds applications for Conduit and Herald. Test Plan: Viewed `/applications/`, saw applications. Clicked buttons, got to applications. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D3578
2012-10-01 21:56:10 +02:00
'PhabricatorApplicationConduit' => 'PhabricatorApplication',
Start of a config web interface. Summary: This is somewhat clowny, particularly in how it handles JSON encode/decode, but I've commented why I did things the way I did. The goal is to store minified JSON but show pretty-printed JSON where possible, to the user editing it. Test Plan: * Went to /config/ and saw a list of keys from the `default` config. * Clicked on one of them, submitted the default value successfully. * Changed the value to invalid JSON and got a decent error. * Changed the value to valid JSON and checked the DB to confirm it saved. * Confirmed the DB values were minified. * Confirmed the user-facing values were pretty-printed where they could be. * Confirmed that PHIDs were getting assigned properly and that isDeleted properly defaulted to false/0. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2246 Differential Revision: https://secure.phabricator.com/D4290
2012-12-28 00:20:09 +01:00
'PhabricatorApplicationConfig' => 'PhabricatorApplication',
Begin moving Phabricator configuration into PHP Summary: Ref T2255. Ref T2221. Lay the groundwork to move configuration into PHP, so we can show descriptions in the web UI, do typechecking, disable application options when an application is uninstalled, etc. Test Plan: {F28421} {F28420} {F28422} Reviewers: codeblock, btrahan, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221, T2255 Differential Revision: https://secure.phabricator.com/D4306
2012-12-31 00:36:06 +01:00
'PhabricatorApplicationConfigOptions' => 'Phobject',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'PhabricatorApplicationConpherence' => 'PhabricatorApplication',
Add Slowvote and Countdown applications Summary: See D3572. Test Plan: Loaded /applications/, saw applications. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D3577
2012-10-01 21:56:02 +02:00
'PhabricatorApplicationCountdown' => 'PhabricatorApplication',
Modernize daemon application Summary: Make it possible to get to stuff that used to be in tabs. Test Plan: Clicked links and such. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3264
2012-08-14 00:27:45 +02:00
'PhabricatorApplicationDaemons' => 'PhabricatorApplication',
Application Detail View Summary: Added Applications Details View Applications Detail View Test Plan: In "Applications" application, clicked on each application to check whether the each application detail view is displayed. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4615
2013-01-24 21:13:31 +01:00
'PhabricatorApplicationDetailViewController' => 'PhabricatorApplicationsController',
Add FactCursors and application fact datasources Summary: - Add PhabricatorApplication. This is a general class that I have grand designs for, but used here to allow applications to provide objects for analysis by the facts appliction. - Add FactCursors, to keep track of where iterators are. - Make the daemon do something sort of useful. - Add `bin/fact cursors` for showing and managing objects and cursors. - Add some options to `bin/fact analyze`. Test Plan: - `bin/fact cursors`, `bin/fact cursors --reset DifferentialRevision`, `bin/fact cursors --reset X` - `bin/fact analyze`, `bin/fact analyze --all`, `bin/fact analyze --iterator DifferentialRevision --skip-aggregates` - `bin/phd debug fact` Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3098
2012-07-30 19:43:49 +02:00
'PhabricatorApplicationDifferential' => 'PhabricatorApplication',
Add a meta-application Summary: - Adds a new "Applications" application. - Builds an application list via application config instead of via hard-coding, so we can move toward better concepts of installing/uninstalling applications, etc. - Applications indicate that they need attention with notice counts and brief status messages rathern than 50 giant tables of all sorts of app data. I want to try replacing the home screen with this screen, pretty much. Not sure if this is totally crazy or not. What does everyone else think? Test Plan: Will add screenshots. Reviewers: btrahan, chad, vrana, alanh Reviewed By: vrana CC: aran, davidreuss, champo Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3129
2012-08-02 23:07:21 +02:00
'PhabricatorApplicationDiffusion' => 'PhabricatorApplication',
Remove all code referencing old tab navigation Summary: - Add getHelpURI() to PhabricatorApplication for application user guides. - Add a new "help" icon menu item and skeletal Diviner application. - Move help tabs to Applications where they exist, document the other ones that don't exist yet. - Grep for all tab-related stuff and delete it. Test Plan: Clicked "help" for some apps. Clicked around randomly in a bunch of other apps. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3267
2012-08-14 00:28:41 +02:00
'PhabricatorApplicationDiviner' => 'PhabricatorApplication',
Add Drydock Application Summary: Add an Application class for Drydock and move routing rules there. Test Plan: Looked at /applications/, clicked around drydock. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3847
2012-10-31 17:57:57 +01:00
'PhabricatorApplicationDrydock' => 'PhabricatorApplication',
Allow Fact app to draw charts Summary: For any count fact, allow a chart to be drawn. INCREDIBLY POWERFUL DATA ANALYSIS PLATFORM. Test Plan: Drew a chart of object counts. Drew the Maniphest burn chart. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3099
2012-07-30 19:44:08 +02:00
'PhabricatorApplicationFact' => 'PhabricatorApplication',
Make feed its own application Summary: Fixes the two-level nav issue introduced by D4376. (My claim that this page is device ready in the code is something of a lie, but it's fairly close.) (@chad, this could use an icon at some point, or you can point me at which one you want and I can take a stab at slicing it.) Test Plan: Looked at feed; saw it not-broken. Also checked public feed (which should just merge at some point). Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D4381
2013-01-11 01:06:29 +01:00
'PhabricatorApplicationFeed' => 'PhabricatorApplication',
Add a PhabricatorApplication for files Summary: Basic step toward modernizing Files, makes it appear on /applications/ and in typeahead. Test Plan: Looked at /applications/. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D3575
2012-10-01 23:05:12 +02:00
'PhabricatorApplicationFiles' => 'PhabricatorApplication',
Add a meta-application Summary: - Adds a new "Applications" application. - Builds an application list via application config instead of via hard-coding, so we can move toward better concepts of installing/uninstalling applications, etc. - Applications indicate that they need attention with notice counts and brief status messages rathern than 50 giant tables of all sorts of app data. I want to try replacing the home screen with this screen, pretty much. Not sure if this is totally crazy or not. What does everyone else think? Test Plan: Will add screenshots. Reviewers: btrahan, chad, vrana, alanh Reviewed By: vrana CC: aran, davidreuss, champo Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3129
2012-08-02 23:07:21 +02:00
'PhabricatorApplicationFlags' => 'PhabricatorApplication',
Add Conduit and Herald applications Summary: See D3572. Adds applications for Conduit and Herald. Test Plan: Viewed `/applications/`, saw applications. Clicked buttons, got to applications. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D3578
2012-10-01 21:56:10 +02:00
'PhabricatorApplicationHerald' => 'PhabricatorApplication',
Add a meta-application Summary: - Adds a new "Applications" application. - Builds an application list via application config instead of via hard-coding, so we can move toward better concepts of installing/uninstalling applications, etc. - Applications indicate that they need attention with notice counts and brief status messages rathern than 50 giant tables of all sorts of app data. I want to try replacing the home screen with this screen, pretty much. Not sure if this is totally crazy or not. What does everyone else think? Test Plan: Will add screenshots. Reviewers: btrahan, chad, vrana, alanh Reviewed By: vrana CC: aran, davidreuss, champo Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3129
2012-08-02 23:07:21 +02:00
'PhabricatorApplicationLaunchView' => 'AphrontView',
Move "Macros" to a first-class application Summary: This is mostly to unblock D3547. - Move "Macros" to a first-class application called "Macros". - After D3547, this application will also house "Memes" (macros with text on them). - This will also make them easier to find; the top navigational query I field is "where are image macros?" nowadays, since it's not intuitive they're part of files. - This makes some of the UI mobile-aware but doesn't set the `device` flag yet, since there are still some missing pieces. - I'll separate storage out and continue modernizing the UI as we unblock and integrate D3547. Test Plan: Created, edited and deleted macros. Viewed files. Reviewers: btrahan, vrana, teisenbe Reviewed By: vrana CC: aran Maniphest Tasks: T175 Differential Revision: https://secure.phabricator.com/D3572
2012-10-01 23:04:03 +02:00
'PhabricatorApplicationMacro' => 'PhabricatorApplication',
Move "Mailing Lists" to a separate application Summary: There's currently no way to get here from the UI since nav tabs don't exist anymore. It's also always been hard to find this feature even when we had the tabs, since it's surprising that it's inside "MetaMTA". - Move mailing lists to a separate application. - Add `buildApplicationPage()`, since we don't really need `buildStandardPageResponse()` any more -- we can infer all the information from `PhabricatorApplication`. This will let us get rid of a lot of the `PhabricatorXXXController` classes which just define application information. - Add `getApplicationURI()` to reduce code duplication, and in case we want to let you move applications around some day. Test Plan: Looked/edited/saved mailing lists. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T631 Differential Revision: https://secure.phabricator.com/D3248
2012-08-13 04:19:46 +02:00
'PhabricatorApplicationMailingLists' => 'PhabricatorApplication',
Add FactCursors and application fact datasources Summary: - Add PhabricatorApplication. This is a general class that I have grand designs for, but used here to allow applications to provide objects for analysis by the facts appliction. - Add FactCursors, to keep track of where iterators are. - Make the daemon do something sort of useful. - Add `bin/fact cursors` for showing and managing objects and cursors. - Add some options to `bin/fact analyze`. Test Plan: - `bin/fact cursors`, `bin/fact cursors --reset DifferentialRevision`, `bin/fact cursors --reset X` - `bin/fact analyze`, `bin/fact analyze --all`, `bin/fact analyze --iterator DifferentialRevision --skip-aggregates` - `bin/phd debug fact` Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3098
2012-07-30 19:43:49 +02:00
'PhabricatorApplicationManiphest' => 'PhabricatorApplication',
Modernize MetaMTA Summary: - Add an Application. - Move routes to the application. - Move nav out of tabs (which no longer exist). - Fix a couple of random things. Test Plan: Viewed sent/received mail logs. Performed send/receive tests. Viewed email details. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T631, T1569 Differential Revision: https://secure.phabricator.com/D3255
2012-08-13 21:37:06 +02:00
'PhabricatorApplicationMetaMTA' => 'PhabricatorApplication',
Add applications for Owners, Repositories, PHID manager, PHPAST Summary: See D3572. Test Plan: Viewed /applications/, saw all these applications. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3579
2012-10-01 21:56:33 +02:00
'PhabricatorApplicationOwners' => 'PhabricatorApplication',
'PhabricatorApplicationPHID' => 'PhabricatorApplication',
'PhabricatorApplicationPHPAST' => 'PhabricatorApplication',
Modernize Paste Summary: - Add a PhabricatorApplication. - Make most of the views work well on tablets / phones. The actual "Create" form doesn't, but everything else is good -- need to make device-friendly form layouts before I can do the form. Test Plan: Will attach screenshots. Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3293
2012-08-15 19:45:06 +02:00
'PhabricatorApplicationPaste' => 'PhabricatorApplication',
Drive menu icons from Applications Summary: This makes no changes, it just moves the menu icons to the applications instead of hard-coded on the page. I'm going to try to address some of the angst in T1593 next... Test Plan: Loaded logged-in / logged out pages. Clicked menu items. Looked at /applications/. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1593, T1569 Differential Revision: https://secure.phabricator.com/D3146
2012-08-05 23:12:43 +02:00
'PhabricatorApplicationPeople' => 'PhabricatorApplication',
Modernize phame and add concept of "blog style" to blog post list view Summary: "blog style" for now is just "true" to make this UI render better for the blog LATER it will be a string which will choose the larger template. this will also have to do some messing around with links; when viewing on a phabricator instance links need to be a bit dirtier to carry around the blog whereas when viewing offsite we can tell what blog it is based on the host domain. anyhoo, this is future diff work Test Plan: looked at blog - less ugly. resized blog to smaller sizes - became a "single list" of goodness for quality reading quite quickly. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3587
2012-10-02 00:37:02 +02:00
'PhabricatorApplicationPhame' => 'PhabricatorApplication',
Phlux v0 Summary: Yup, it's sitevars. No conduit or caching or fancy stuff yet. Ref T2793. Test Plan: {F36525} {F36526} {F36527} {F36528} {F36529} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2793 Differential Revision: https://secure.phabricator.com/D5397
2013-03-21 02:01:52 +01:00
'PhabricatorApplicationPhlux' => 'PhabricatorApplication',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PhabricatorApplicationPholio' => 'PhabricatorApplication',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhabricatorApplicationPhortune' => 'PhabricatorApplication',
Implemented Phrequent time tracking functionality. Summary: This differential implements Phrequent's time tracking functionality for users and hooks it up to Maniphest. It also includes a basic "Time Tracked" list for the Phrequent application, where users can review what they've spent time working on. Test Plan: Apply the patch and track some things in Maniphest. They should appear in the "Time Tracked" view of Phrequent. There is also a `phrequent.show-prompt` option which toggles whether to display a prompt when tracking time. I'm unsure of whether the prompt is useful or is more likely to cause people to click "Track Time", go off and do the task and then come back to the prompt still waiting for them to confirm. A potential solution to the "accidentally clicking the button and recording 2 seconds of time" might be to show a prompt on stop if the total time is under 10 seconds, asking whether the user wants to keep or discard the tracked time. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2857 Differential Revision: https://secure.phabricator.com/D5479
2013-03-30 17:32:29 +01:00
'PhabricatorApplicationPhrequent' => 'PhabricatorApplication',
Add a meta-application Summary: - Adds a new "Applications" application. - Builds an application list via application config instead of via hard-coding, so we can move toward better concepts of installing/uninstalling applications, etc. - Applications indicate that they need attention with notice counts and brief status messages rathern than 50 giant tables of all sorts of app data. I want to try replacing the home screen with this screen, pretty much. Not sure if this is totally crazy or not. What does everyone else think? Test Plan: Will add screenshots. Reviewers: btrahan, chad, vrana, alanh Reviewed By: vrana CC: aran, davidreuss, champo Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3129
2012-08-02 23:07:21 +02:00
'PhabricatorApplicationPhriction' => 'PhabricatorApplication',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PhabricatorApplicationPonder' => 'PhabricatorApplication',
Add a "Project" application Summary: Move routes into a formal application class. Test Plan: Checked /applications/, browsed various routes. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, floatinglomas Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3181
2012-08-07 20:54:49 +02:00
'PhabricatorApplicationProject' => 'PhabricatorApplication',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'PhabricatorApplicationReleeph' => 'PhabricatorApplication',
'PhabricatorApplicationReleephConfigOptions' => 'PhabricatorApplicationConfigOptions',
Add applications for Owners, Repositories, PHID manager, PHPAST Summary: See D3572. Test Plan: Viewed /applications/, saw all these applications. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3579
2012-10-01 21:56:33 +02:00
'PhabricatorApplicationRepositories' => 'PhabricatorApplication',
Adding an own application for search Summary: Refs T2989 Renamed file Libery Test Plan: Nothing broken, that's always a good sign. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2989 Differential Revision: https://secure.phabricator.com/D5697 Conflicts: src/__phutil_library_map__.php
2013-04-15 15:43:39 +02:00
'PhabricatorApplicationSearch' => 'PhabricatorApplication',
Use delegation to generalize application search controllers Summary: Ref T2625. Lifts almost all of the search logic out of Paste controllers and into Search. This uses controller delegation for generalization. We use this in a few places, but don't use it very much yet. I think it's pretty reasonable as-is, but I might be able to make even more stuff free. There are some slightly rough edges around routes, still, but I want to hit Phame and Differential (which both have multiple application search engines) before trying to generalize that. Test Plan: Executed, browsed and managed Paste searches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6073
2013-05-30 23:09:02 +02:00
'PhabricatorApplicationSearchController' => 'PhabricatorSearchBaseController',
Drive menu icons from Applications Summary: This makes no changes, it just moves the menu icons to the applications instead of hard-coded on the page. I'm going to try to address some of the angst in T1593 next... Test Plan: Loaded logged-in / logged out pages. Clicked menu items. Looked at /applications/. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1593, T1569 Differential Revision: https://secure.phabricator.com/D3146
2012-08-05 23:12:43 +02:00
'PhabricatorApplicationSettings' => 'PhabricatorApplication',
Add Slowvote and Countdown applications Summary: See D3572. Test Plan: Loaded /applications/, saw applications. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D3577
2012-10-01 21:56:02 +02:00
'PhabricatorApplicationSlowvote' => 'PhabricatorApplication',
Add a meta-application Summary: - Adds a new "Applications" application. - Builds an application list via application config instead of via hard-coding, so we can move toward better concepts of installing/uninstalling applications, etc. - Applications indicate that they need attention with notice counts and brief status messages rathern than 50 giant tables of all sorts of app data. I want to try replacing the home screen with this screen, pretty much. Not sure if this is totally crazy or not. What does everyone else think? Test Plan: Will add screenshots. Reviewers: btrahan, chad, vrana, alanh Reviewed By: vrana CC: aran, davidreuss, champo Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3129
2012-08-02 23:07:21 +02:00
'PhabricatorApplicationStatusView' => 'AphrontView',
Add basic "Subscriptions" application Summary: Basic infrastructure for generalizing subscriptions/CCs for T1808, T1514 and T1663. - Implement `PhabricatorSubscribableInterface` and you'll get a subscribe/unsubscribe button for free. - If there are any auto-subscribed users (like the question author) you can specify them; this makes more sense for Tasks and Revisions than Ponder probably, but maybe the author should be auto-subscribed. - Subscriptions are either "explicit" (the user clicked 'subscribe') or "implicit" (the user did something which causes them to become subscribed naturally). If a user unsubscribes, they'll no longer be added by implicit subscriptions. This may or may not be relevant to Ponder but is an existing Herald feature in Differential. - Helper method on PhabricatorSubscribersQuery to load subscribers. - This doesn't handle actually sending email, etc. I think that's all so application-specific that it doesn't belong here. - Now seems to work. Test Plan: {F20552} {F20553} Reviewers: pieter, btrahan Reviewed By: pieter CC: aran Maniphest Tasks: T1663, T1514, T1808 Differential Revision: https://secure.phabricator.com/D3637
2012-10-05 22:18:05 +02:00
'PhabricatorApplicationSubscriptions' => 'PhabricatorApplication',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorApplicationTokens' => 'PhabricatorApplication',
Add feed integration to generic transactions Summary: Publish feed stories, including from Pholio. Actual stories are somewhat garbage but it's all display-time; I'm going to do a pass on feed in general. Test Plan: {F26832} Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4140
2012-12-11 23:00:21 +01:00
'PhabricatorApplicationTransaction' =>
array(
0 => 'PhabricatorLiskDAO',
1 => 'PhabricatorPolicyInterface',
),
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionComment' =>
array(
0 => 'PhabricatorLiskDAO',
1 => 'PhabricatorMarkupInterface',
Add feed integration to generic transactions Summary: Publish feed stories, including from Pholio. Actual stories are somewhat garbage but it's all display-time; I'm going to do a pass on feed in general. Test Plan: {F26832} Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4140
2012-12-11 23:00:21 +01:00
2 => 'PhabricatorPolicyInterface',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
),
Allow ApplicationTransaction comments to be edited and deleted Summary: Allows you to edit or delete comments in appplications which support ApplicationTransactions. UI/UX stuff: - The dialogs are rough but I want to do a dialog design pass more generally, @chad has some mocks. - When you add new mentions via edit, they don't currently count as mentions. I'm not sure what I want to do about this. - When you edit or delete a comment, we do not publish any notifications about it. I think this is reasonable. - I didn't separate "delete" out versus "edit"; I assume it will be reasonably intuitive that deleting all the text deletes effectively deletes the comment. I also want to discourage deletion somewhat (we still show the transaction, just show that the comment has been deleted). Test Plan: Transaction view, note "Edit" and "Edited" links: {F26914} Edit view, has some design issues but I want to do a pass on dialogs in general: {F26915} History view: {F26913} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1082 Differential Revision: https://secure.phabricator.com/D4149
2012-12-11 23:01:51 +01:00
'PhabricatorApplicationTransactionCommentEditController' => 'PhabricatorApplicationTransactionController',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionCommentEditor' => 'PhabricatorEditor',
Allow ApplicationTransaction comments to be edited and deleted Summary: Allows you to edit or delete comments in appplications which support ApplicationTransactions. UI/UX stuff: - The dialogs are rough but I want to do a dialog design pass more generally, @chad has some mocks. - When you add new mentions via edit, they don't currently count as mentions. I'm not sure what I want to do about this. - When you edit or delete a comment, we do not publish any notifications about it. I think this is reasonable. - I didn't separate "delete" out versus "edit"; I assume it will be reasonably intuitive that deleting all the text deletes effectively deletes the comment. I also want to discourage deletion somewhat (we still show the transaction, just show that the comment has been deleted). Test Plan: Transaction view, note "Edit" and "Edited" links: {F26914} Edit view, has some design issues but I want to do a pass on dialogs in general: {F26915} History view: {F26913} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1082 Differential Revision: https://secure.phabricator.com/D4149
2012-12-11 23:01:51 +01:00
'PhabricatorApplicationTransactionCommentHistoryController' => 'PhabricatorApplicationTransactionController',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionCommentQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add previews to ApplicationTransaction Summary: Implements previews for Macros and Pholio. (Design is nonfinal -- kind of split the difference between `diff_full_view.png`, laziness, and space concerns. Next couple diffs will add more stuff here.) Test Plan: {F28055} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, vrana Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4246
2012-12-21 14:51:33 +01:00
'PhabricatorApplicationTransactionCommentView' => 'AphrontView',
Allow ApplicationTransaction comments to be edited and deleted Summary: Allows you to edit or delete comments in appplications which support ApplicationTransactions. UI/UX stuff: - The dialogs are rough but I want to do a dialog design pass more generally, @chad has some mocks. - When you add new mentions via edit, they don't currently count as mentions. I'm not sure what I want to do about this. - When you edit or delete a comment, we do not publish any notifications about it. I think this is reasonable. - I didn't separate "delete" out versus "edit"; I assume it will be reasonably intuitive that deleting all the text deletes effectively deletes the comment. I also want to discourage deletion somewhat (we still show the transaction, just show that the comment has been deleted). Test Plan: Transaction view, note "Edit" and "Edited" links: {F26914} Edit view, has some design issues but I want to do a pass on dialogs in general: {F26915} History view: {F26913} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1082 Differential Revision: https://secure.phabricator.com/D4149
2012-12-11 23:01:51 +01:00
'PhabricatorApplicationTransactionController' => 'PhabricatorController',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionEditor' => 'PhabricatorEditor',
Add feed integration to generic transactions Summary: Publish feed stories, including from Pholio. Actual stories are somewhat garbage but it's all display-time; I'm going to do a pass on feed in general. Test Plan: {F26832} Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4140
2012-12-11 23:00:21 +01:00
'PhabricatorApplicationTransactionFeedStory' => 'PhabricatorFeedStory',
Add ApplicationTransaction handling for transactions with no effect Summary: When a user submits an action with no effect (like an empty comment, an "abandon" on an already-accepted revision, or a "close, resolved" on a closed task) we want to alert them that their action isn't effective. These warnings fall into two general buckets: - User is submitting two or more actions, and some aren't effective but some are. Prompt them to apply the effective actions only. - A special case of this is where the only effective action is a comment. We provide tailored text ("Post Comment") in this case. - User is submitting one action, which isn't effective. Tell them they're out of luck. - A special case of this is an empty comment. We provide tailored text in this case. By default, the transaction editor throws when transactions have no effect. The caller can then deal with this, or use `PhabricatorApplicationTransactionNoEffectResponse` to provide a standard dialog that gives the user information as above. For cases where we expect transactions to have no effect (notably, "edit" forms) we just continue on no-effect unconditionally. Also fix an issue where new, combined or filtered transactions would not be represented properly in the Ajax response (i.e., return final transactions from `applyTransactions()`), and translate some strings. Test Plan: - Submitted empty and nonempy comments in Macro and Pholio. - Submitted comments with new and existing "@mentions". - Submitted edits in both applications. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T912, T2104 Differential Revision: https://secure.phabricator.com/D4160
2012-12-12 02:27:40 +01:00
'PhabricatorApplicationTransactionNoEffectException' => 'Exception',
'PhabricatorApplicationTransactionNoEffectResponse' => 'AphrontProxyResponse',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Render application transactions via Ajax Summary: When possible, render application transactions via Ajax. Instead of reloading the page when the response returns, append new transactions to the transaction view. Scroll the window to the new transactions, animate them in, and clear the form to make this interaction feel reasonable. When editing transactions, fade them in but do not scroll to them (i.e., don't disrupt the user's position). Test Plan: Edited and appended transactions via Ajax. Observed fade in animations and scroll behavior. Clicked anchors to verify proper anchor accounting. Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1960 Differential Revision: https://secure.phabricator.com/D4151
2012-12-11 23:02:29 +01:00
'PhabricatorApplicationTransactionResponse' => 'AphrontProxyResponse',
Implement basic transaction detail blocks Summary: Some transactions (like editing configuration values, task descriptions, or Conpherence images) can't be simply explained and need an additional larger element to show them fully (like a text diff). Support change details like this in ApplicationTransactions. Implements the element in Config, so you can see changes. Test Plan: {F32974} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2213 Differential Revision: https://secure.phabricator.com/D4984
2013-02-17 15:37:02 +01:00
'PhabricatorApplicationTransactionTextDiffDetailView' => 'AphrontView',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorApplicationTransactionView' => 'AphrontView',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactions' => 'PhabricatorApplication',
Modernize UIExamples Summary: - Get rid of an AphrontSideNavView callsite. - Modernize and simplify the application implementation. - Doesn't work perfectly on tablet/phone but that's because not all the UI examples work there yet. Test Plan: Looked at /applications/ and /uiexample/. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3431
2012-09-11 18:56:40 +02:00
'PhabricatorApplicationUIExamples' => 'PhabricatorApplication',
Installation & Uninstallion of Applications Summary: Created Applications application which allows uninstallation & installation of application. Test Plan: In "Applications" application, clicked on uninstalled the application by cliking Uninstall and chekcing whether they are really uninstalled(Disabling URI & in appearance in the side pane). Then Clicked on the install button of the uninstalled application to check whether they are installed. Reviewers: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4715
2013-01-29 18:14:03 +01:00
'PhabricatorApplicationUninstallController' => 'PhabricatorApplicationsController',
Fix XHProf index page Summary: Ref T2870. This resolves a few issues: - No proper Application. Define one. - Routes are in the default controller. Move them to the application. - UI doesn't work on mobile. - Overescaping in the link column. Test Plan: Old page: {F38444} New page: {F38445} Reviewers: btrahan, chad Reviewed By: chad CC: aran, AnhNhan, edward Maniphest Tasks: T2870 Differential Revision: https://secure.phabricator.com/D5531
2013-04-02 18:52:52 +02:00
'PhabricatorApplicationXHProf' => 'PhabricatorApplication',
Initial Commint Summary: Created "Applications" application which lists all the installed applications in phabricator. Test Plan: Navigated to localphabricatorinstall.com/applications and check whether it actually shows the list of all installed applications. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2352 Differential Revision: https://secure.phabricator.com/D4548
2013-01-19 22:46:48 +01:00
'PhabricatorApplicationsController' => 'PhabricatorController',
'PhabricatorApplicationsListController' => 'PhabricatorApplicationsController',
Allow audit comments to be added from Diffusion Summary: This is intended to supplant the existing "audit edit" interface. I've changed them to both drive down the same write pathway, but the UIs are still different. I'll fully merge them in a future diff. Add a comment box (like Maniphest and Differential) to Diffusion. When users make comments, their comments appear on the commit. Any audits triggers they are responsible for are updated to reflect actions they take, as well. Currently, audits can only be triggered by packages, but I intend to allow them to be triggered by users and projects (via herald rules) in an upcoming diff. Thus some of the language like "projects, users or packages" when the code is clearly dealing only with "packagePHID". Test Plan: Made audit updates via commit interface and via existing edit interface. Verified both interfaces updated correctly, and that audit responsibility rules were applied properly. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1688
2012-02-25 00:04:53 +01:00
'PhabricatorAuditAddCommentController' => 'PhabricatorAuditController',
Create a status tool by giving /calendar/ some teeth Summary: you can now add, edit, and delete status events. also added a "description" to status events and surface it in the big calendar view on mouse hover. some refactoring changes as well to make validation logic centralized within the storage class. Test Plan: added, edited, deleted. yay. Reviewers: epriestley, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T407 Differential Revision: https://secure.phabricator.com/D3810
2012-10-24 22:22:24 +02:00
'PhabricatorAuditComment' =>
array(
0 => 'PhabricatorAuditDAO',
1 => 'PhabricatorMarkupInterface',
),
If users are on the email to Phabricator, do not send them the Phabricator reply. Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email. Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected. Reviewers: epriestley, vrana Reviewed By: vrana CC: aran, Korvin, vrana Maniphest Tasks: T1676 Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 19:18:23 +02:00
'PhabricatorAuditCommentEditor' => 'PhabricatorEditor',
Show commits in /audit/ Summary: The general idea here is to build a Differential-like dashboard which shows all the things you need to audit and all the things that other people have raised issues with, so you have a one-stop "what do I need to deal with?" interface. - Add problem commits to the "active" view of /audit/. - Add problem commits to homepage. - Add commit browsing interfaces to /audit/. - Add an "Audit" app button. Test Plan: Looked at homepage, commit filters. Audited commits, verified state changes reflected properly. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1712
2012-02-29 06:10:39 +01:00
'PhabricatorAuditCommitListView' => 'AphrontView',
Add Basic Auditing Functionalities Summary: add basic auditing functionalities. For the related commits for a package, we detect the following conditions which might be suspicious to the owners of the package: * no revision specified * revision not found * author not match * reviewedby not match * owners not involved * commit author not recognized The owners of the package can change the status of the audit entries by accepting it or specify concern. The owner can turn on/off the auditing for a package. Test Plan: * verified that non-owner cannot see the details of the audit and cannot modify it * verified that all the audit reasons can be detected * tested dropdown filtering and package search * verified really normal change not detected * verified accept/concern a commit * tested enable/disable a package for auditing * verified one audit applies to all <commit, packages> to the packages the auditor owns * verified that re-parsing a commit won't have effect if there exists a relationship for <commit, package> already Reviewers: epriestley, nh Reviewed By: epriestley CC: aran, benmathews, btrahan, mpodobnik, prithvi, TomL, epriestley Differential Revision: 1242
2011-12-18 00:52:54 +01:00
'PhabricatorAuditController' => 'PhabricatorController',
'PhabricatorAuditDAO' => 'PhabricatorLiskDAO',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'PhabricatorAuditInlineComment' =>
array(
0 => 'PhabricatorAuditDAO',
1 => 'PhabricatorInlineCommentInterface',
),
Add a basic first-class audit UI Summary: Currently, audits are only accessible through the Owners tool. Start moving them to their own first-class tool in preparation for broader audit integration. - Lay some infrastructure groundwork (e.g. AuditQuery). - Build a basic /audit/ view. - Show audits on the commit page in Diffusion. This has some code duplication with stuff we've already got, but I'll merge everything together as we move forward on this. Test Plan: Looked at /audit/ and a commit. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1685
2012-02-24 22:02:14 +01:00
'PhabricatorAuditListController' => 'PhabricatorAuditController',
'PhabricatorAuditListView' => 'AphrontView',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorAuditMailReceiver' => 'PhabricatorObjectMailReceiver',
Add preview and drafts to audits Summary: Add comment previews and saved drafts to audits, like Maniphest / Differential. Test Plan: Typed stuff into the box. Got a preview. Reloaded page. Stuff was still there. Submitted comment. Stuff is gone. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1699
2012-02-27 22:00:23 +01:00
'PhabricatorAuditPreviewController' => 'PhabricatorAuditController',
Enable email for audits Summary: When users submit an audit, send email to relevant parties informing them. Allow email to be replied to. Just basic support so far; no "!raise" stuff and no threading with the Herald commit notification. Test Plan: Made comments, got email. Replied to email, got comments. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1698
2012-02-27 21:57:57 +01:00
'PhabricatorAuditReplyHandler' => 'PhabricatorMailReplyHandler',
Authentication
2011-01-26 22:21:12 +01:00
'PhabricatorAuthController' => 'PhabricatorController',
Generalize login flows for new registration Summary: Ref T1536. None of this code is reachable. `PhabricatorAuthLoginController` provides a completely generic login/link flow, similar to how D6155 provides a generic registration flow. `PhabricatorAuthProvider` wraps a `PhutilAuthAdapter` and glues the generic top-level flow to a concrete authentication provider. Test Plan: Static only, code isn't meaningfully reachable. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6159
2013-06-16 19:14:07 +02:00
'PhabricatorAuthLoginController' => 'PhabricatorAuthController',
Move LDAP to new registration flow Summary: Ref T1536. LDAP is very likely the worst thing in existence. This has some rough edges (error handling isn't perfect) but is already better than the current LDAP experience! durrr Test Plan: Registered and logged in using LDAP. Reviewers: btrahan Reviewed By: btrahan CC: aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6177
2013-06-16 19:18:34 +02:00
'PhabricatorAuthProviderLDAP' => 'PhabricatorAuthProvider',
Provide start screen and full registration flow on the new auth stuff Summary: Ref T1536. Code is intentionally made unreachable (see PhabricatorAuthProviderOAuthFacebook->isEnabled()). This adds: - A provider-driven "start" screen (this has the list of ways you can login/register). - Registration actually works. - Facebook OAuth works. @chad, do you have any design ideas on the start screen? I think we poked at it before, but the big issue was that there were a limitless number of providers. Today, we have: - Password - LDAP - Facebook - GitHub - Phabricator - Disqus - Google We plan to add: - Asana - An arbitrary number of additional instances of Phabricator Users want to add: - OpenID - Custom providers And I'd like to have these at some point: - Stripe - WePay - Amazon - Bitbucket So basically any UI for this has to accommodate 300 zillion auth options. I don't think we need to solve any UX problems here (realistically, installs enable 1-2 auth options and users don't actually face an overwhelming number of choices) but making the login forms less ugly would be nice. No combination of prebuilt elements seems to look very good for this use case. Test Plan: Registered a new acount with Facebook. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6161
2013-06-16 19:15:16 +02:00
'PhabricatorAuthProviderOAuth' => 'PhabricatorAuthProvider',
Add Disqus OAuth to new flows Summary: Ref T1536. Adds Disqus as a Provider. Test Plan: Registered and logged in with Disqus. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6165
2013-06-16 19:16:14 +02:00
'PhabricatorAuthProviderOAuthDisqus' => 'PhabricatorAuthProviderOAuth',
Provide start screen and full registration flow on the new auth stuff Summary: Ref T1536. Code is intentionally made unreachable (see PhabricatorAuthProviderOAuthFacebook->isEnabled()). This adds: - A provider-driven "start" screen (this has the list of ways you can login/register). - Registration actually works. - Facebook OAuth works. @chad, do you have any design ideas on the start screen? I think we poked at it before, but the big issue was that there were a limitless number of providers. Today, we have: - Password - LDAP - Facebook - GitHub - Phabricator - Disqus - Google We plan to add: - Asana - An arbitrary number of additional instances of Phabricator Users want to add: - OpenID - Custom providers And I'd like to have these at some point: - Stripe - WePay - Amazon - Bitbucket So basically any UI for this has to accommodate 300 zillion auth options. I don't think we need to solve any UX problems here (realistically, installs enable 1-2 auth options and users don't actually face an overwhelming number of choices) but making the login forms less ugly would be nice. No combination of prebuilt elements seems to look very good for this use case. Test Plan: Registered a new acount with Facebook. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6161
2013-06-16 19:15:16 +02:00
'PhabricatorAuthProviderOAuthFacebook' => 'PhabricatorAuthProviderOAuth',
Add GitHub auth to new flows Summary: Ref T1536. Support for GitHub on new flows. Test Plan: Registered and logged in with GitHub. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6166
2013-06-16 19:17:29 +02:00
'PhabricatorAuthProviderOAuthGitHub' => 'PhabricatorAuthProviderOAuth',
Add Google support to new registration flow Summary: Ref T1536. Adds Google support. Test Plan: Registered and logged in with Google. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6167
2013-06-16 19:18:04 +02:00
'PhabricatorAuthProviderOAuthGoogle' => 'PhabricatorAuthProviderOAuth',
Add password authentication and registration to new registration Summary: Ref T1536. Ref T1930. Code is not reachable. This provides password authentication and registration on the new provider/adapter framework. I sort of cheated a little bit and don't really route any password logic through the adapter (instead, this provider uses an empty adapter and just sets the type/domain on it). I think the right way to do this //conceptually// is to treat username/passwords as an external black box which the adapter communicates with. However, this creates a lot of practical implementation and UX problems: - There would basically be two steps -- in the first one, you interact with the "password black box", which behaves like an OAuth provider. This produces some ExternalAccount associated with the username/password pair, then we go into normal registration. - In normal registration, we'd proceed normally. This means: - The registration flow would be split into two parts, one where you select a username/password (interacting with the black box) and one where you actually register (interacting with the generic flow). This is unusual and probably confusing for users. - We would need to do a lot of re-hashing of passwords, since passwords currently depend on the username and user PHID, which won't exist yet during registration or the "black box" phase. This is a big mess I don't want to deal with. - We hit a weird condition where two users complete step 1 with the same username but don't complete step 2 yet. The box knows about two different copies of the username, with two different passwords. When we arrive at step 2 the second time we have a lot of bad choices about how to reoslve it, most of which create security problems. The most stragihtforward and "pure" way to resolve the issues is to put password-auth usernames in a separate space, but this would be incredibly confusuing to users (your login name might not be the same as your username, which is bizarre). - If we change this, we need to update all the other password-related code, which I don't want to bother with (at least for now). Instead, let registration know about a "default" registration controller (which is always password, if enabled), and let it require a password. This gives us a much simpler (albeit slightly less pure) implementation: - All the fields are on one form. - Password adapter is just a shell. - Password provider does the heavy lifting. We might make this more pure at some point, but I'm generally pretty satisfied with this. This doesn't implement the brute-force CAPTCHA protection, that will be coming soon. Test Plan: Registered with password only and logged in with a password. Hit various error conditions. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1536, T1930 Differential Revision: https://secure.phabricator.com/D6164
2013-06-16 19:15:49 +02:00
'PhabricatorAuthProviderPassword' => 'PhabricatorAuthProvider',
New Registration Workflow Summary: Currently, registration and authentication are pretty messy. Two concrete problems: - The `PhabricatorLDAPRegistrationController` and `PhabricatorOAuthDefaultRegistrationController` controllers are giant copy/pastes of one another. This is really bad. - We can't practically implement OpenID because we can't reissue the authentication request. Additionally, the OAuth registration controller can be replaced wholesale by config, which is a huge API surface area and a giant mess. Broadly, the problem right now is that registration does too much: we hand it some set of indirect credentials (like OAuth tokens) and expect it to take those the entire way to a registered user. Instead, break registration into smaller steps: - User authenticates with remote service. - Phabricator pulls information (remote account ID, username, email, real name, profile picture, etc) from the remote service and saves it as `PhabricatorUserCredentials`. - Phabricator hands the `PhabricatorUserCredentials` to the registration form, which is agnostic about where they originate from: it can process LDAP credentials, OAuth credentials, plain old email credentials, HTTP basic auth credentials, etc. This doesn't do anything yet -- there is no way to create credentials objects (and no storage patch), but I wanted to get any initial feedback, especially about the event call for T2394. In particular, I think the implementation would look something like this: $profile = $event->getValue('profile') $username = $profile->getDefaultUsername(); $is_employee = is_this_a_facebook_employee($username); if (!$is_employee) { throw new Exception("You are not employed at Facebook."); } $fbid = get_fbid_for_facebook_username($username); $profile->setDefaultEmail($fbid); $profile->setCanEditUsername(false); $profile->setCanEditEmail(false); $profile->setCanEditRealName(false); $profile->setShouldVerifyEmail(true); Seem reasonable? Test Plan: N/A yet, probably fatals. Reviewers: vrana, btrahan, codeblock, chad Reviewed By: btrahan CC: aran, asherkin, nh, wez Maniphest Tasks: T1536, T2394 Differential Revision: https://secure.phabricator.com/D4647
2013-06-16 19:13:49 +02:00
'PhabricatorAuthRegisterController' => 'PhabricatorAuthController',
Provide start screen and full registration flow on the new auth stuff Summary: Ref T1536. Code is intentionally made unreachable (see PhabricatorAuthProviderOAuthFacebook->isEnabled()). This adds: - A provider-driven "start" screen (this has the list of ways you can login/register). - Registration actually works. - Facebook OAuth works. @chad, do you have any design ideas on the start screen? I think we poked at it before, but the big issue was that there were a limitless number of providers. Today, we have: - Password - LDAP - Facebook - GitHub - Phabricator - Disqus - Google We plan to add: - Asana - An arbitrary number of additional instances of Phabricator Users want to add: - OpenID - Custom providers And I'd like to have these at some point: - Stripe - WePay - Amazon - Bitbucket So basically any UI for this has to accommodate 300 zillion auth options. I don't think we need to solve any UX problems here (realistically, installs enable 1-2 auth options and users don't actually face an overwhelming number of choices) but making the login forms less ugly would be nice. No combination of prebuilt elements seems to look very good for this use case. Test Plan: Registered a new acount with Facebook. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6161
2013-06-16 19:15:16 +02:00
'PhabricatorAuthStartController' => 'PhabricatorAuthController',
Implement new auth login flow and login validation controller Summary: Ref T1536. None of this code is reachable. Implements new-auth login (so you can actually login) and login validation (which checks that cookies were set correctly). Test Plan: Manually enabled FB auth, went through the auth flow to login/logout. Manually hit most of the validation errors. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6162
2013-06-16 19:15:33 +02:00
'PhabricatorAuthValidateController' => 'PhabricatorAuthController',
First go at Authentication config options. Test Plan: Looked at them in the web UI. Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4355
2013-01-07 21:48:39 +01:00
'PhabricatorAuthenticationConfigOptions' => 'PhabricatorApplicationConfigOptions',
Separate "PhabricatorBarePageView" out of "PhabricatorStandardPageView" Summary: For Phame, we really want more than a chromeless page -- it shouldn't have Javelin or Phabricator styles on it. Pull the bare infrastructure out of StandardPageView and make it available as BarePageView. Test Plan: Viewed bare page in UIExamples, various non-bare pages. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3711
2012-10-16 19:33:47 +02:00
'PhabricatorBarePageExample' => 'PhabricatorUIExample',
'PhabricatorBarePageView' => 'AphrontPageView',
Allow extending English translation Test Plan: Displayed home. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D2759
2012-06-15 04:01:57 +02:00
'PhabricatorBaseEnglishTranslation' => 'PhabricatorTranslation',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorBot' => 'PhabricatorDaemon',
Added Flowdock protocol adapter for the bot. Refactored campfire bot into a base streaming protocol adapter for common functionality. Summary: First pass. Flowdock supports interesting message types (like replies to messages), but for now implementing a standard messaging interface. Test Plan: Ran both a Flowdock bot and a Campfire bot. Made sure both still connected and responded properly to the Object Handler. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4983
2013-02-16 05:24:23 +01:00
'PhabricatorBotBaseStreamingProtocolAdapter' => 'PhabricatorBaseProtocolAdapter',
Formalize targets (users and channel) into objects Summary: Make users/channels/rooms into objects, so we can later sort out stuff like Campfire user IDs, Phabricator vs chat accounts, etc. The only change here is that I removed output buffering from the macro handler. We should move throttling/buffering to adapters instead and have it apply globally. Test Plan: Ran IRC and Campfire bots and interacted with them. Reviewers: indiefan Reviewed By: indiefan CC: aran Differential Revision: https://secure.phabricator.com/D4924
2013-02-14 14:13:38 +01:00
'PhabricatorBotChannel' => 'PhabricatorBotTarget',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorBotDebugLogHandler' => 'PhabricatorBotHandler',
'PhabricatorBotDifferentialNotificationHandler' => 'PhabricatorBotHandler',
'PhabricatorBotFeedNotificationHandler' => 'PhabricatorBotHandler',
Added Flowdock protocol adapter for the bot. Refactored campfire bot into a base streaming protocol adapter for common functionality. Summary: First pass. Flowdock supports interesting message types (like replies to messages), but for now implementing a standard messaging interface. Test Plan: Ran both a Flowdock bot and a Campfire bot. Made sure both still connected and responded properly to the Object Handler. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4983
2013-02-16 05:24:23 +01:00
'PhabricatorBotFlowdockProtocolAdapter' => 'PhabricatorBotBaseStreamingProtocolAdapter',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorBotLogHandler' => 'PhabricatorBotHandler',
'PhabricatorBotMacroHandler' => 'PhabricatorBotHandler',
'PhabricatorBotObjectNameHandler' => 'PhabricatorBotHandler',
'PhabricatorBotSymbolHandler' => 'PhabricatorBotHandler',
Formalize targets (users and channel) into objects Summary: Make users/channels/rooms into objects, so we can later sort out stuff like Campfire user IDs, Phabricator vs chat accounts, etc. The only change here is that I removed output buffering from the macro handler. We should move throttling/buffering to adapters instead and have it apply globally. Test Plan: Ran IRC and Campfire bots and interacted with them. Reviewers: indiefan Reviewed By: indiefan CC: aran Differential Revision: https://secure.phabricator.com/D4924
2013-02-14 14:13:38 +01:00
'PhabricatorBotUser' => 'PhabricatorBotTarget',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorBotWhatsNewHandler' => 'PhabricatorBotHandler',
Make SQL patch management DAG-based and provide namespace support Summary: This addresses three issues with the current patch management system: # Two people developing at the same time often pick the same SQL patch number, and then have to go rename it. The system catches this, but it's silly. # Second/third-party developers can't use the same system to manage auxiliary storage they may want to add. # There's no way to build mock databases for unit tests that need to do reads. To resolve these things, you can now name your patches whatever you want and conflicts are just merge conflicts, which are less of a pain to fix than filename conflicts. Dependencies are now a DAG, with implicit dependencies created on the prior patch if no dependencies are specified. Developers can add new concrete subclasses of `PhabricatorSQLPatchList` to add storage management, and define the dependency branchpoint of their patches so they apply in the correct order (although, generally, they should not depend on the mainline patches, presumably). The commands `storage upgrade --namespace test1234` and `storage destroy --namespace test1234` will allow unit tests to build and destroy MySQL storage. A "quickstart" mode allows an upgrade from scratch in ~1200ms. Destruction takes about 200ms. These seem like fairily reasonable costs to actually use in tests. Building from scratch patch-by-patch takes about 6000ms. Test Plan: - Created new databases from scratch with and without quickstart in a separate test namespace. Pointed the webapp at the test namespaces, browsed around, everything looked good. - Compared quickstart and no-quickstart dump states, they're identical except for mysqldump timestamps and a few similar things. - Upgraded a legacy database to the new storage format. - Destroyed / dumped storage. Reviewers: edward, vrana, btrahan, jungejason Reviewed By: btrahan CC: aran, nh Maniphest Tasks: T140, T345 Differential Revision: https://secure.phabricator.com/D2323
2012-04-30 16:54:00 +02:00
'PhabricatorBuiltinPatchList' => 'PhabricatorSQLPatchList',
Add a generic multistep Markup cache Summary: The immediate issue this addresses is T1366, adding a rendering cache to Phriction. For wiki pages with code blocks especially, rerendering them each time is expensive. The broader issue is that out markup caches aren't very good right now. They have three major problems: **Problem 1: the data is stored in the wrong place.** We currently store remarkup caches on objects. This means we're always loading it and passing it around even when we don't need it, can't genericize cache management code (e.g., have one simple script to drop/GC caches), need to update authoritative rows to clear caches, and can't genericize rendering code since each object is different. To solve this, I created a dedicated cache database that I plan to move all markup caches to use. **Problem 2: time-variant rules break when cached.** Some rules like `**bold**` are time-invariant and always produce the same output, but some rules like `{Tnnn}` and `@username` are variant and may render differently (because a task was closed or a user is on vacation). Currently, we cache the raw output, so these time-variant rules get locked at whatever values they had when they were first rendered. This is the main reason Phriction doesn't have a cache right now -- I wanted `{Tnnn}` rules to reflect open/closed tasks. To solve this, I split markup into a "preprocessing" phase (which does all the parsing and evaluates all time-invariant rules) and a "postprocessing" phase (which evaluates time-variant rules only). The preprocessing phase is most of the expense (and, notably, includes syntax highlighting) so this is nearly as good as caching the final output. I did most of the work here in D737 / D738, but we never moved to use it in Phabricator -- we currently just do the two operations serially in all cases. This diff splits them apart and caches the output of preprocessing only, so we benefit from caching but also get accurate time-variant rendering. **Problem 3: cache access isn't batched/pipelined optimally.** When we're rendering a list of markup blocks, we should be able to batch datafetching better than we do. D738 helped with this (fetching is batched within a single hunk of markup) and this improves batching on cache access. We could still do better here, but this is at least a step forward. Also fixes a bug with generating a link in the Phriction history interface ($uri gets clobbered). I'm using PHP serialization instead of JSON serialization because Remarkup does some stuff with non-ascii characters that might not survive JSON. Test Plan: - Created a Phriction document and verified that previews don't go to cache (no rows appear in the cache table). - Verified that published documents come out of cache. - Verified that caches generate/regenerate correctly, time-variant rules render properly and old documents hit the right caches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1366 Differential Revision: https://secure.phabricator.com/D2945
2012-07-10 00:20:56 +02:00
'PhabricatorCacheDAO' => 'PhabricatorLiskDAO',
Provide 'bin/cache', for managing caches Summary: See <https://github.com/facebook/phabricator/issues/323>. We have a very old cache management script which doesn't purge all the modern caches (and does purge some caches which are no longer in use). Update it so it purges all the modern caches (remarkup, general, changeset), no longer purges outdated caches, and is easier to use. Also delete a lot of "this script has moved" scripts from the last few rounds of similar cleanup, I believe all of these have been in master for at least several months, which should be enough time for users to get used to the new stuff. Test Plan: Ran `bin/cache` with various arguments. Verified caches were purged. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5978
2013-05-20 19:16:35 +02:00
'PhabricatorCacheManagementPurgeWorkflow' => 'PhabricatorSearchManagementWorkflow',
'PhabricatorCacheManagementWorkflow' => 'PhutilArgumentWorkflow',
Build a basic calendar view Summary: This is a very small step toward building a Status and possibly an Oncall tool. Build a calendar view which renders months. Much of my hesitance to bang these tools out is that dealing with dates/calendaring is basically horrible, so I'm trying to ease into it. This calendar is locale-aware and all that jazz. Test Plan: - See: https://secure.phabricator.com/file/view/PHID-FILE-c07a9c663a7d040d2529/ - Verified that months have the right number of days, today is the right day of the week, months begin on the day after previous months end on, etc. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran Commenters: cwbeck, jungejason CC: blair, aran, epriestley, cwbeck, jungejason Differential Revision: 791
2011-08-08 03:26:31 +02:00
'PhabricatorCalendarBrowseController' => 'PhabricatorCalendarController',
'PhabricatorCalendarController' => 'PhabricatorController',
Display holidays Summary: We will need it for two purposes: - Status tool. - Nagging tool - @aran suggested using "3 business days" and I don't want it to fall on New Year's Eve or such. I don't plan working on any interface for editing this as this kind of data should be always imported. Test Plan: `bin/storage upgrade` `scripts/calendar/import_us_holidays.php` /calendar/ Reviewers: epriestley Reviewed By: epriestley CC: aran, Koolvin Differential Revision: https://secure.phabricator.com/D2375
2012-05-03 09:21:47 +02:00
'PhabricatorCalendarDAO' => 'PhabricatorLiskDAO',
Create a status tool by giving /calendar/ some teeth Summary: you can now add, edit, and delete status events. also added a "description" to status events and surface it in the big calendar view on mouse hover. some refactoring changes as well to make validation logic centralized within the storage class. Test Plan: added, edited, deleted. yay. Reviewers: epriestley, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T407 Differential Revision: https://secure.phabricator.com/D3810
2012-10-24 22:22:24 +02:00
'PhabricatorCalendarDeleteStatusController' => 'PhabricatorCalendarController',
'PhabricatorCalendarEditStatusController' => 'PhabricatorCalendarController',
Display holidays Summary: We will need it for two purposes: - Status tool. - Nagging tool - @aran suggested using "3 business days" and I don't want it to fall on New Year's Eve or such. I don't plan working on any interface for editing this as this kind of data should be always imported. Test Plan: `bin/storage upgrade` `scripts/calendar/import_us_holidays.php` /calendar/ Reviewers: epriestley Reviewed By: epriestley CC: aran, Koolvin Differential Revision: https://secure.phabricator.com/D2375
2012-05-03 09:21:47 +02:00
'PhabricatorCalendarHoliday' => 'PhabricatorCalendarDAO',
Implement getNthBusinessDay() Summary: I will need it for nagging tool. Test Plan: None yet. Please suggest me how to create a testing database (I need to insert some data in the table). I guess that it is now possible? There is also probably some bug in `arc unit` - `setEnvConfig()` is not called before `getEnvConfig()` resulting in fatal error. Reviewers: epriestley Reviewed By: epriestley CC: aran, Koolvin Differential Revision: https://secure.phabricator.com/D2376
2012-05-03 21:16:09 +02:00
'PhabricatorCalendarHolidayTestCase' => 'PhabricatorTestCase',
Create a status tool by giving /calendar/ some teeth Summary: you can now add, edit, and delete status events. also added a "description" to status events and surface it in the big calendar view on mouse hover. some refactoring changes as well to make validation logic centralized within the storage class. Test Plan: added, edited, deleted. yay. Reviewers: epriestley, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T407 Differential Revision: https://secure.phabricator.com/D3810
2012-10-24 22:22:24 +02:00
'PhabricatorCalendarViewStatusController' => 'PhabricatorCalendarController',
Implement basic transaction detail blocks Summary: Some transactions (like editing configuration values, task descriptions, or Conpherence images) can't be simply explained and need an additional larger element to show them fully (like a text diff). Support change details like this in ApplicationTransactions. Implements the element in Config, so you can see changes. Test Plan: {F32974} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2213 Differential Revision: https://secure.phabricator.com/D4984
2013-02-17 15:37:02 +01:00
'PhabricatorCampfireProtocolAdapter' => 'PhabricatorBotBaseStreamingProtocolAdapter',
Minor, formalize changeset response class.
2012-03-13 05:39:05 +01:00
'PhabricatorChangesetResponse' => 'AphrontProxyResponse',
Added a new storage object Summary: Added a new storage object. Created PhabricatorChagLogChannel Test Plan: Will be specified by Evan :P Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4943
2013-02-14 13:10:42 +01:00
'PhabricatorChatLogChannel' =>
array(
0 => 'PhabricatorChatLogDAO',
1 => 'PhabricatorPolicyInterface',
),
Add a basic chatlog Summary: This is pretty simple and unpolished, but it's getting pretty big and it seems like a reasonable starting point. - Log chat in various "channels". - Conduit record and query methods. - IRCBot integration for IRC logging Major TODO: - Web UI is really unpolished and has no search, paging, anchor-linking, etc. Basically all presentation stuff, though. - I think the bot should have a map of channels to log with channel aliases? - The "channels" should probably be in a separate table. - The "authors" should probably be correlated to Phabricator accounts somehow, where possible. Test Plan: Used phabotlocal to log #phabricator. Reviewers: kdeggelman, btrahan, Koolvin Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T837 Differential Revision: https://secure.phabricator.com/D1625
2012-02-17 19:21:38 +01:00
'PhabricatorChatLogChannelListController' => 'PhabricatorChatLogController',
'PhabricatorChatLogChannelLogController' => 'PhabricatorChatLogController',
Moving code off channel Summary: Deleted code which used channel. Created PhabricatorChatLogChannelQuery.php Test Plan: By manually checking in the chatlog application. Reviewers: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5010
2013-02-22 15:59:17 +01:00
'PhabricatorChatLogChannelQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add a basic chatlog Summary: This is pretty simple and unpolished, but it's getting pretty big and it seems like a reasonable starting point. - Log chat in various "channels". - Conduit record and query methods. - IRCBot integration for IRC logging Major TODO: - Web UI is really unpolished and has no search, paging, anchor-linking, etc. Basically all presentation stuff, though. - I think the bot should have a map of channels to log with channel aliases? - The "channels" should probably be in a separate table. - The "authors" should probably be correlated to Phabricator accounts somehow, where possible. Test Plan: Used phabotlocal to log #phabricator. Reviewers: kdeggelman, btrahan, Koolvin Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T837 Differential Revision: https://secure.phabricator.com/D1625
2012-02-17 19:21:38 +01:00
'PhabricatorChatLogController' => 'PhabricatorController',
'PhabricatorChatLogDAO' => 'PhabricatorLiskDAO',
Make chatlog a bit less awful Summary: - Default to showing the newest page of chat. - Reformat for greater readability. - Add permalinks to specific lines. - Enable jump-to-date. Test Plan: {F12200} Reviewers: Koolvin, vrana, btrahan Reviewed By: btrahan CC: kdeggelman, aran Maniphest Tasks: T837, T1065 Differential Revision: https://secure.phabricator.com/D2641
2012-06-02 23:00:08 +02:00
'PhabricatorChatLogEvent' =>
array(
0 => 'PhabricatorChatLogDAO',
1 => 'PhabricatorPolicyInterface',
),
Add a basic chatlog Summary: This is pretty simple and unpolished, but it's getting pretty big and it seems like a reasonable starting point. - Log chat in various "channels". - Conduit record and query methods. - IRCBot integration for IRC logging Major TODO: - Web UI is really unpolished and has no search, paging, anchor-linking, etc. Basically all presentation stuff, though. - I think the bot should have a map of channels to log with channel aliases? - The "channels" should probably be in a separate table. - The "authors" should probably be correlated to Phabricator accounts somehow, where possible. Test Plan: Used phabotlocal to log #phabricator. Reviewers: kdeggelman, btrahan, Koolvin Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T837 Differential Revision: https://secure.phabricator.com/D1625
2012-02-17 19:21:38 +01:00
'PhabricatorChatLogEventType' => 'PhabricatorChatLogConstants',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorChatLogQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Conduit server-side basics.
2011-01-24 18:00:29 +01:00
'PhabricatorConduitAPIController' => 'PhabricatorConduitController',
"arc install-certificate", server-side components Summary: Provides a new workflow for making it non-horrible to install certificates. Basically you run "arc install-certificate" and then copy/paste a short token off a webpage and it does the ~/.arcrc edits for you. Test Plan: Installed certificates, used bad tokens, hit rate limiting. Reviewed By: aran Reviewers: aran, jungejason, tuomaspelkonen CC: aran Differential Revision: 460
2011-06-14 21:17:14 +02:00
'PhabricatorConduitCertificateToken' => 'PhabricatorConduitDAO',
Route internal conduit calls if other hosts available Summary: Ref T2785 Looks for hosts in `conduit.servers` config and if any exist route any conduit calls through any one of the hosts. Test Plan: Make some curl calls to public methods (`conduit.ping`), watch the access log for two requests. Make some calls from the UI that require authentication, watch the access log a bit more. Also ran the unit tests. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2785 Differential Revision: https://secure.phabricator.com/D5970
2013-05-19 13:16:09 +02:00
'PhabricatorConduitConfigOptions' => 'PhabricatorApplicationConfigOptions',
Conduit server-side basics.
2011-01-24 18:00:29 +01:00
'PhabricatorConduitConnectionLog' => 'PhabricatorConduitDAO',
'PhabricatorConduitConsoleController' => 'PhabricatorConduitController',
'PhabricatorConduitController' => 'PhabricatorController',
'PhabricatorConduitDAO' => 'PhabricatorLiskDAO',
Create overview of Conduit methods Summary: Also couple of small changes: - Add method name to title. - 404 for /conduit/method/x/. - Remove utilities from side panel. - Remove side panel from log. Test Plan: /conduit/ /conduit/method/x/ /conduit/method/user.whoami/ /conduit/log/ Reviewers: btrahan, epriestley Reviewed By: epriestley CC: aran, Koolvin Differential Revision: https://secure.phabricator.com/D2326
2012-04-27 07:25:05 +02:00
'PhabricatorConduitListController' => 'PhabricatorConduitController',
Conduit server-side basics.
2011-01-24 18:00:29 +01:00
'PhabricatorConduitLogController' => 'PhabricatorConduitController',
'PhabricatorConduitMethodCallLog' => 'PhabricatorConduitDAO',
"arc install-certificate", server-side components Summary: Provides a new workflow for making it non-horrible to install certificates. Basically you run "arc install-certificate" and then copy/paste a short token off a webpage and it does the ~/.arcrc edits for you. Test Plan: Installed certificates, used bad tokens, hit rate limiting. Reviewed By: aran Reviewers: aran, jungejason, tuomaspelkonen CC: aran Differential Revision: 460
2011-06-14 21:17:14 +02:00
'PhabricatorConduitTokenController' => 'PhabricatorConduitController',
Move "show all config" from DarkConsole to /config/ Summary: Currently, we have a "config" panel in DarkConsole. It's useful to have a table of all effective config values, but it doesn't need to be in DarkConsole. Move it to Config instead. Basically: - You don't need to activate DarkConsole to see it anymore; - now visible only to admins; - respects config mask/hide; - somewhat prettier; - links to config edit; - no longer ships down on every DarkConsole request with a giant table of rarely-used data. Test Plan: Looked at the table. Looked at lack of table in darkconsole. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4473
2013-01-16 20:10:41 +01:00
'PhabricatorConfigAllController' => 'PhabricatorConfigController',
Start of a config web interface. Summary: This is somewhat clowny, particularly in how it handles JSON encode/decode, but I've commented why I did things the way I did. The goal is to store minified JSON but show pretty-printed JSON where possible, to the user editing it. Test Plan: * Went to /config/ and saw a list of keys from the `default` config. * Clicked on one of them, submitted the default value successfully. * Changed the value to invalid JSON and got a decent error. * Changed the value to valid JSON and checked the DB to confirm it saved. * Confirmed the DB values were minified. * Confirmed the user-facing values were pretty-printed where they could be. * Confirmed that PHIDs were getting assigned properly and that isDeleted properly defaulted to false/0. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2246 Differential Revision: https://secure.phabricator.com/D4290
2012-12-28 00:20:09 +01:00
'PhabricatorConfigController' => 'PhabricatorController',
Add database configuration source to the source stack Summary: Read configuration from the new database source. This adds an extra MySQL connect + query to every page. They're very cheap so I think we can suffer them for now, but I'd like to put cache in front of this at some point. The difficulties are: - If we use APC, multi-frontend installs (Facebook) can't dirty it (major problem), and the CLI can't dirty it (fine for now, maybe a major problem later). - If we use Memcache, we need to add config stuff. - We could use APC in all non-Facebook installs if we can make it dirtyable from the CLI, but I don't see a reasonable way to do that. - We don't have any other caches which are faster than the database. So I'll probably implement Memcache support at some point, although this is a lame excuse for it. Test Plan: Added some config values via web UI, saw them active on the install. Reviewers: btrahan, codeblock, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221 Differential Revision: https://secure.phabricator.com/D4296
2013-01-18 00:10:21 +01:00
'PhabricatorConfigDatabaseSource' => 'PhabricatorConfigProxySource',
Show all configuration defaults when editing configuration Summary: Show the value for all loaded configuration sources. Test Plan: {F28469} {F28470} {F28471} Reviewers: btrahan, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4312
2013-01-01 23:10:33 +01:00
'PhabricatorConfigDefaultSource' => 'PhabricatorConfigProxySource',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorConfigDictionarySource' => 'PhabricatorConfigSource',
Start of a config web interface. Summary: This is somewhat clowny, particularly in how it handles JSON encode/decode, but I've commented why I did things the way I did. The goal is to store minified JSON but show pretty-printed JSON where possible, to the user editing it. Test Plan: * Went to /config/ and saw a list of keys from the `default` config. * Clicked on one of them, submitted the default value successfully. * Changed the value to invalid JSON and got a decent error. * Changed the value to valid JSON and checked the DB to confirm it saved. * Confirmed the DB values were minified. * Confirmed the user-facing values were pretty-printed where they could be. * Confirmed that PHIDs were getting assigned properly and that isDeleted properly defaulted to false/0. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2246 Differential Revision: https://secure.phabricator.com/D4290
2012-12-28 00:20:09 +01:00
'PhabricatorConfigEditController' => 'PhabricatorConfigController',
Use transactions to show edit history for Configuration Summary: Use ApplicationTransactions in Config to create an edit history. Resolves T2256. Test Plan: {F28477} Reviewers: btrahan, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2256 Differential Revision: https://secure.phabricator.com/D4314
2013-01-02 03:14:41 +01:00
'PhabricatorConfigEditor' => 'PhabricatorApplicationTransactionEditor',
Start of a config web interface. Summary: This is somewhat clowny, particularly in how it handles JSON encode/decode, but I've commented why I did things the way I did. The goal is to store minified JSON but show pretty-printed JSON where possible, to the user editing it. Test Plan: * Went to /config/ and saw a list of keys from the `default` config. * Clicked on one of them, submitted the default value successfully. * Changed the value to invalid JSON and got a decent error. * Changed the value to valid JSON and checked the DB to confirm it saved. * Confirmed the DB values were minified. * Confirmed the user-facing values were pretty-printed where they could be. * Confirmed that PHIDs were getting assigned properly and that isDeleted properly defaulted to false/0. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2246 Differential Revision: https://secure.phabricator.com/D4290
2012-12-28 00:20:09 +01:00
'PhabricatorConfigEntry' => 'PhabricatorConfigEntryDAO',
'PhabricatorConfigEntryDAO' => 'PhabricatorLiskDAO',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorConfigFileSource' => 'PhabricatorConfigProxySource',
Begin moving Phabricator configuration into PHP Summary: Ref T2255. Ref T2221. Lay the groundwork to move configuration into PHP, so we can show descriptions in the web UI, do typechecking, disable application options when an application is uninstalled, etc. Test Plan: {F28421} {F28420} {F28422} Reviewers: codeblock, btrahan, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221, T2255 Differential Revision: https://secure.phabricator.com/D4306
2012-12-31 00:36:06 +01:00
'PhabricatorConfigGroupController' => 'PhabricatorConfigController',
Button to ignore setup issues + refractoring Summary: T2381 Test Plan: Click on the ignore link in /config/issue/ and respond to the dialog box. Also, test uninstalling and reinstalling an application in the web UI (to verify that refractoring didn't break anything). Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2381 Differential Revision: https://secure.phabricator.com/D5234
2013-03-06 23:14:09 +01:00
'PhabricatorConfigIgnoreController' => 'PhabricatorApplicationsController',
Detect and raise setup warnings from within Phabricator Summary: This is basicaly a light version of D4286. The major problem with D4286 is that it's a huge leap and completely replaces the setup process in one step. Instead, I want to do this: - Add the post-setup warnings (yellow bar with "6 unresolved warnings..."). - Copy all setup checks into post-setup warnings (so every check has an old-style check and a new-style check). - Run that for a little bit and make sure it's stable. - Implement fatal post-setup checks (the red screen, vs the yellow bar). - Run that for a little bit. - Nuke setup mode and delete all the old checks. This should give us a bunch of very gradual steps toward the brave new world of simpler setup. Test Plan: - Faked APC setup failures, saw warnings raise. - Verified that this runs after restart (get + set). - Verified that this costs us only one cache hit after first-run (get only). Reviewers: btrahan, codeblock, vrana, chad Reviewed By: codeblock CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4295
2012-12-30 15:37:49 +01:00
'PhabricatorConfigIssueListController' => 'PhabricatorConfigController',
'PhabricatorConfigIssueViewController' => 'PhabricatorConfigController',
Start of a config web interface. Summary: This is somewhat clowny, particularly in how it handles JSON encode/decode, but I've commented why I did things the way I did. The goal is to store minified JSON but show pretty-printed JSON where possible, to the user editing it. Test Plan: * Went to /config/ and saw a list of keys from the `default` config. * Clicked on one of them, submitted the default value successfully. * Changed the value to invalid JSON and got a decent error. * Changed the value to valid JSON and checked the DB to confirm it saved. * Confirmed the DB values were minified. * Confirmed the user-facing values were pretty-printed where they could be. * Confirmed that PHIDs were getting assigned properly and that isDeleted properly defaulted to false/0. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2246 Differential Revision: https://secure.phabricator.com/D4290
2012-12-28 00:20:09 +01:00
'PhabricatorConfigListController' => 'PhabricatorConfigController',
Add a local configuration source and a non-environmental ENV config source Summary: See discussion in T2221. Before we can move configuration to the database, we have a bootstrapping problem: we need database credentials to live //somewhere// if we can't guess them (and we can only really guess localhost / root / no password). Some options for this are: - Have them live in ENV variables. - These are often somewhat unfamiliar to users. - Scripts would become a huge pain -- you'd have to dump a bunch of stuff into ENV. - Some environments have limited ability to set ENV vars. - SSH is also a pain. - Have them live in a normal config file. - This probably isn't really too awful, but: - Since we deploy/upgrade with git, we can't currently let them edit a file which already exists, or their working copy will become dirty. - So they have to copy or create a file, then edit it. - The biggest issue I have with this is that it will be difficult to give specific, easily-followed directions from Setup. The instructions need to be like "Copy template.conf.php to real.conf.php, then edit these keys: x, y, z". This isn't as easy to follow as "run script Y". - Have them live in an abnormal config file with script access (this diff). - I think this is a little better than a normal config file, because we can tell users 'run phabricator/bin/config set mysql.user phabricator' and such, which is easier to follow than editing a config file. I think this is only a marginal improvement over a normal config file and am open to arguments against this approach, but I think it will be a little easier for users to deal with than a normal config file. In most cases they should only need to store three values in this file -- db user/host/pass -- since once we have those we can bootstrap everything else. Normal config files also aren't going away for more advanced users, we're just offering a simple alternative for most users. This also adds an ENVIRONMENT file as an alternative to PHABRICATOR_ENV. This is just a simple way to specify the environment if you don't have convenient access to env vars. Test Plan: Ran `config set x y`, verified writes. Wrote to ENVIRONMENT, ran `PHABRICATOR_ENV= ./bin/repository`. Reviewers: btrahan, vrana, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2221 Differential Revision: https://secure.phabricator.com/D4294
2012-12-30 15:16:15 +01:00
'PhabricatorConfigLocalSource' => 'PhabricatorConfigProxySource',
Increase the power of `bin/config` Summary: Fixes T2254. Make the CLI for config more powerful: - Add validation for `set`. - Add `get`. - Add `list`. - Add `delete`. The `get` command produces fairly verbose JSON to support flags like `--all`, or `--source database` later. The other commands are straightforward. Test Plan: Tested `config set`: $ ./bin/config set Usage Exception: Specify a configuration key and a value to set it to. $ ./bin/config set x Usage Exception: Specify a value to set the key 'x' to. $ ./bin/config set phabricator.base-uri Usage Exception: Specify a value to set the key 'phabricator.base-uri' to. $ ./bin/config set phabricator.base-uri x Usage Exception: Config option 'phabricator.base-uri' is invalid. The URI must start with 'http://' or 'https://'. $ ./bin/config set phabricator.base-uri http://x Usage Exception: Config option 'phabricator.base-uri' is invalid. The URI must contain a dot ('.'), like 'http://example.com/', not just a bare name like 'http://example/'. Some web browsers will not set cookies on domains with no TLD. $ ./bin/config set phabricator.base-uri http://x.com Set 'phabricator.base-uri' in local configuration. $ Tested `config get`: $ ./bin/config get pygments.enabled { "config" : [] } $ ./bin/config set pygments.enabled true Set 'pygments.enabled' in local configuration. $ ./bin/config get pygments.enabled { "config" : [ { "key" : "pygments.enabled", "source" : "local", "value" : true } ] } $ Tested `config delete`: $ ./bin/config delete Usage Exception: Specify a configuration key to delete. $ ./bin/config delete x x Usage Exception: Too many arguments: expected one key. $ ./bin/config delete x Usage Exception: No such configuration key 'x'! Use `config list` to list all keys. $ ./bin/config delete pygments.enabled Deleted 'pygments.enabled' from local configuration. $ ./bin/config delete pygments.enabled Usage Exception: Configuration key 'pygments.enabled' is not set in local configuration! $ Tested `config list`: $ ./bin/config list account.editable account.minimum-password-length amazon-ec2.access-key amazon-ec2.secret-key amazon-s3.access-key amazon-s3.endpoint amazon-s3.secret-key amazon-ses.access-key amazon-ses.secret-key aphront.default-application-configuration-class audit.can-author-close-audit auth.email-domains auth.login-message auth.password-auth-enabled auth.require-email-verification auth.sessions.conduit auth.sessions.web auth.sshkeys.enabled cache.enable-deflate celerity.force-disk-reads celerity.minify celerity.resource-hash celerity.resource-path config.hide config.lock config.mask controller.oauth-registration darkconsole.always-on darkconsole.enabled debug.profile-rate debug.stop-on-redirect differential.allow-reopen differential.allow-self-accept differential.always-allow-close differential.anonymous-access differential.custom-remarkup-block-rules differential.custom-remarkup-rules differential.days-fresh differential.days-stale differential.enable-email-accept differential.expose-emails-prudently differential.field-selector differential.generated-paths differential.require-test-plan-field differential.revision-custom-detail-renderer differential.show-host-field differential.show-test-plan-field differential.whitespace-matters disqus.application-id disqus.application-secret disqus.auth-enabled disqus.auth-permanent disqus.registration-enabled disqus.shortname environment.append-paths events.listeners facebook.application-id facebook.application-secret facebook.auth-enabled facebook.auth-permanent facebook.registration-enabled facebook.require-https-auth feed.http-hooks feed.public files.image-mime-types files.viewable-mime-types gcdaemon.ttl.daemon-logs gcdaemon.ttl.differential-parse-cache gcdaemon.ttl.general-cache gcdaemon.ttl.herald-transcripts gcdaemon.ttl.markup-cache gcdaemon.ttl.task-archive github.application-id github.application-secret github.auth-enabled github.auth-permanent github.registration-enabled google.application-id google.application-secret google.auth-enabled google.auth-permanent google.registration-enabled ldap.activedirectory_domain ldap.anonymous-user-name ldap.anonymous-user-password ldap.auth-enabled ldap.base_dn ldap.hostname ldap.port ldap.real_name_attributes ldap.referrals ldap.search-first ldap.search_attribute ldap.start-tls ldap.username-attribute ldap.version load-libraries log.access.format log.access.path maniphest.custom-fields maniphest.custom-task-extensions-class maniphest.default-priority maniphest.enabled metamta.can-send-as-user metamta.default-address metamta.differential.attach-patches metamta.differential.inline-patches metamta.differential.patch-format metamta.differential.reply-handler metamta.differential.reply-handler-domain metamta.differential.subject-prefix metamta.differential.unified-comment-context metamta.diffusion.attach-patches metamta.diffusion.byte-limit metamta.diffusion.inline-patches metamta.diffusion.reply-handler metamta.diffusion.reply-handler-domain metamta.diffusion.subject-prefix metamta.diffusion.time-limit metamta.domain metamta.herald.show-hints metamta.insecure-auth-with-reply-to metamta.macro.reply-handler-domain metamta.macro.subject-prefix metamta.mail-adapter metamta.maniphest.default-public-author metamta.maniphest.public-create-email metamta.maniphest.reply-handler metamta.maniphest.reply-handler-domain metamta.maniphest.subject-prefix metamta.one-mail-per-recipient metamta.package.reply-handler metamta.package.subject-prefix metamta.pholio.reply-handler-domain metamta.pholio.subject-prefix metamta.placeholder-to-recipient metamta.precedence-bulk metamta.public-replies metamta.re-prefix metamta.recipients.show-hints metamta.reply.show-hints metamta.send-immediately metamta.single-reply-handler-prefix metamta.user-address-format metamta.vary-subjects mysql.configuration-provider mysql.host mysql.implementation mysql.pass mysql.user notification.client-uri notification.debug notification.enabled notification.log notification.pidfile notification.server-uri notification.user phabricator.application-id phabricator.application-secret phabricator.auth-enabled phabricator.auth-permanent phabricator.base-uri phabricator.csrf-key phabricator.env phabricator.mail-key phabricator.oauth-uri phabricator.production-uri phabricator.registration-enabled phabricator.serious-business phabricator.setup phabricator.show-beta-applications phabricator.show-error-callout phabricator.show-stack-traces phabricator.timezone phame.skins phd.log-directory phd.pid-directory phd.start-taskmasters phd.trace phd.verbose phid.external-loaders phpmailer.mailer phpmailer.smtp-host phpmailer.smtp-password phpmailer.smtp-port phpmailer.smtp-protocol phpmailer.smtp-user phriction.enabled policy.allow-public pygments.dropdown-choices pygments.enabled recaptcha.enabled recaptcha.private-key recaptcha.public-key remarkup.enable-embedded-youtube repository.default-local-path search.elastic.host search.engine-selector security.alternate-file-domain security.hmac-key security.require-https sendgrid.api-key sendgrid.api-user storage.default-namespace storage.engine-selector storage.local-disk.path storage.mysql-engine.max-size storage.s3.bucket storage.upload-size-limit style.monospace syntax-highlighter.engine syntax.filemap test.value tokenizer.ondemand translation.override translation.provider uri.allowed-protocols $ Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2254 Differential Revision: https://secure.phabricator.com/D4570
2013-01-22 00:27:42 +01:00
'PhabricatorConfigManagementDeleteWorkflow' => 'PhabricatorConfigManagementWorkflow',
'PhabricatorConfigManagementGetWorkflow' => 'PhabricatorConfigManagementWorkflow',
'PhabricatorConfigManagementListWorkflow' => 'PhabricatorConfigManagementWorkflow',
Add a local configuration source and a non-environmental ENV config source Summary: See discussion in T2221. Before we can move configuration to the database, we have a bootstrapping problem: we need database credentials to live //somewhere// if we can't guess them (and we can only really guess localhost / root / no password). Some options for this are: - Have them live in ENV variables. - These are often somewhat unfamiliar to users. - Scripts would become a huge pain -- you'd have to dump a bunch of stuff into ENV. - Some environments have limited ability to set ENV vars. - SSH is also a pain. - Have them live in a normal config file. - This probably isn't really too awful, but: - Since we deploy/upgrade with git, we can't currently let them edit a file which already exists, or their working copy will become dirty. - So they have to copy or create a file, then edit it. - The biggest issue I have with this is that it will be difficult to give specific, easily-followed directions from Setup. The instructions need to be like "Copy template.conf.php to real.conf.php, then edit these keys: x, y, z". This isn't as easy to follow as "run script Y". - Have them live in an abnormal config file with script access (this diff). - I think this is a little better than a normal config file, because we can tell users 'run phabricator/bin/config set mysql.user phabricator' and such, which is easier to follow than editing a config file. I think this is only a marginal improvement over a normal config file and am open to arguments against this approach, but I think it will be a little easier for users to deal with than a normal config file. In most cases they should only need to store three values in this file -- db user/host/pass -- since once we have those we can bootstrap everything else. Normal config files also aren't going away for more advanced users, we're just offering a simple alternative for most users. This also adds an ENVIRONMENT file as an alternative to PHABRICATOR_ENV. This is just a simple way to specify the environment if you don't have convenient access to env vars. Test Plan: Ran `config set x y`, verified writes. Wrote to ENVIRONMENT, ran `PHABRICATOR_ENV= ./bin/repository`. Reviewers: btrahan, vrana, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2221 Differential Revision: https://secure.phabricator.com/D4294
2012-12-30 15:16:15 +01:00
'PhabricatorConfigManagementSetWorkflow' => 'PhabricatorConfigManagementWorkflow',
'PhabricatorConfigManagementWorkflow' => 'PhutilArgumentWorkflow',
Add Disqus, Facebook, Google, GitHub auth config; AWS config Summary: Also improve behavior for the "unknown config" warning. Test Plan: Looked at configs, went through unknown config workflow. Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4310
2013-01-01 23:09:29 +01:00
'PhabricatorConfigOption' =>
array(
0 => 'Phobject',
1 => 'PhabricatorMarkupInterface',
),
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorConfigProxySource' => 'PhabricatorConfigSource',
Port extension checks to new-style setup Summary: - Allow new-style setup to raise fatal setup errors. - Port extension checks to new-style setup as fatal errors. - When fatal errors are raised, abort setup and show them in a chrome-free response. Test Plan: {F29981} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4587
2013-01-23 00:16:26 +01:00
'PhabricatorConfigResponse' => 'AphrontHTMLResponse',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorConfigStackSource' => 'PhabricatorConfigSource',
Use transactions to show edit history for Configuration Summary: Use ApplicationTransactions in Config to create an edit history. Resolves T2256. Test Plan: {F28477} Reviewers: btrahan, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2256 Differential Revision: https://secure.phabricator.com/D4314
2013-01-02 03:14:41 +01:00
'PhabricatorConfigTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorConfigTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Allow configuration to be explicitly validated, including validation of complex attributes Summary: - Allows us to implement setup warnings for edits which don't go through the web UI, e.g. "you edited a config file and set value X to something goofy". - Allows us to implement more sophisticated validations, beyond basic type checks (e.g., "phabricator.base-uri" must be a URI). - Fixes T358 (or, close enough -- fixes it for all options which have been migrated as per T2255. Test Plan: Set "darkconsole.enabled" to "xyz" in my config, observed setup warning. Added fake validation, observed web UI edit error. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255, T358 Differential Revision: https://secure.phabricator.com/D4315
2013-01-02 03:15:03 +01:00
'PhabricatorConfigValidationException' => 'Exception',
Track content sources (email, web, conduit, mobile) for replies Summary: When an object is updated, record the content source for the update. This mostly isn't terribly useful but one concrete thing I want to do with it is let admins audit via-email replies more easily since there are a bunch of options which let you do hyjinx if you intentionally configure them insecurely. I think having a little more auditability around this feature is generally good. At some point I'm going to turn this into a link admins can click to see details. It also allows us to see how frequently different mechanisms are used, and lets you see if someone is at their desk or on a mobile or whatever, at least indirectly. The "tablet" and "mobile" sources are currently unused but I figured I'd throw them in anyway. SMS support should definitely happen at some point. Not 100% sure about the design for this, I might change it to plain text at some point. Test Plan: Updated objects and saw update sources rendered. Reviewers: jungejason, tuomaspelkonen, aran Reviewed By: jungejason CC: aran, epriestley, jungejason Differential Revision: 844
2011-08-22 19:25:45 +02:00
'PhabricatorContentSourceView' => 'AphrontView',
More phabricator organizational stuff.
2011-01-23 02:48:55 +01:00
'PhabricatorController' => 'AphrontController',
Add "Core" config, with complex validation Summary: This is more or less a copy of the validation which lives in `webroot/index.php` right now, but I don't want to wipe that out just yet because there's no way for normal users to see this new validation. Test Plan: Tried to set "phabricator.base-uri" to crazy nonsense, was harshly rebuffed. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4316
2013-01-02 03:22:48 +01:00
'PhabricatorCoreConfigOptions' => 'PhabricatorApplicationConfigOptions',
Countdown revamp 2 Summary: Now has policy support (not really) Now uses CountdownQuery Now has handles Now uses common way for remarkup Remarkup still looks terrible Test Plan: Added countdowns, edited countdowns. Did even embed some. Couldn't break it Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2624 Differential Revision: https://secure.phabricator.com/D6012
2013-05-23 15:47:54 +02:00
'PhabricatorCountdown' =>
array(
0 => 'PhabricatorCountdownDAO',
1 => 'PhabricatorPolicyInterface',
),
Countdown Summary: Addon that allows you to create a live countdown page to some event. Here is the ticket that this code is based on https://secure.phabricator.com/T36 Test Plan: Tested by manually setting dates in the timer.js file and checking if they made sense. I'm not sure if it works across different timezones though. Reviewers: epriestley CC: Differential Revision: 436
2011-06-13 01:06:17 +02:00
'PhabricatorCountdownController' => 'PhabricatorController',
'PhabricatorCountdownDAO' => 'PhabricatorLiskDAO',
'PhabricatorCountdownDeleteController' => 'PhabricatorCountdownController',
'PhabricatorCountdownEditController' => 'PhabricatorCountdownController',
'PhabricatorCountdownListController' => 'PhabricatorCountdownController',
Countdown revamp 2 Summary: Now has policy support (not really) Now uses CountdownQuery Now has handles Now uses common way for remarkup Remarkup still looks terrible Test Plan: Added countdowns, edited countdowns. Did even embed some. Couldn't break it Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2624 Differential Revision: https://secure.phabricator.com/D6012
2013-05-23 15:47:54 +02:00
'PhabricatorCountdownRemarkupRule' => 'PhabricatorRemarkupRuleObject',
Countdown Summary: Addon that allows you to create a live countdown page to some event. Here is the ticket that this code is based on https://secure.phabricator.com/T36 Test Plan: Tested by manually setting dates in the timer.js file and checking if they made sense. I'm not sure if it works across different timezones though. Reviewers: epriestley CC: Differential Revision: 436
2011-06-13 01:06:17 +02:00
'PhabricatorCountdownViewController' => 'PhabricatorCountdownController',
AphrontFormCountedToggleButtonsControl Summary: Like AphrontFormToggleButtonsControl, but with mouseover counters. These counters let you know how many of each thing there are in each category, which is useful when using this control for filtering a list of things in multiple dimensions. Test Plan: `/uiexample/view/PhabricatorCountedToggleButtonsExample/` Reviewers: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5118
2013-02-26 17:20:14 +01:00
'PhabricatorCountedToggleButtonsExample' => 'PhabricatorUIExample',
Add a breadcrumbs element Summary: Add a basic breadcrumbs element, and implement it in Paste. This needs some polish but is most of the way there. Test Plan: {F26443} {F26444} {F26445} (This element is not visible on devices.) Reviewers: chad Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T1960 Differential Revision: https://secure.phabricator.com/D4087
2012-12-07 22:35:17 +01:00
'PhabricatorCrumbView' => 'AphrontView',
'PhabricatorCrumbsView' => 'AphrontView',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorCursorPagedPolicyAwareQuery' => 'PhabricatorPolicyAwareQuery',
Allow configuration to have custom UI types Summary: Ref T1703. This sets the stage for (but does not yet implement) custom UI types for config. In particular, a draggable list for custom fields. I might make all the builtin types go through this at some point too, but don't really want to bother for the moment. It would be very slightly cleaner but woudn't get us much of anything. Test Plan: UI now renders via custom code, although that code does nothing (produces an unadorned text field): {F45693} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6154
2013-06-07 21:36:18 +02:00
'PhabricatorCustomFieldConfigOptionType' => 'PhabricatorConfigOptionType',
Begin generalizing custom fields Summary: Ref T1703. We have currently have two custom field implementations (Maniphest, Differential) and are about to add a third (User, see D6122). I'd like to generalize custom fields before doing a third implementation, so we don't back ourselves into the ApplicationTransactions corner we have with Maniphest/Differential/Audit. For the most part, the existing custom fields work well and can be directly generalized. There are three specific things I want to improve, though: - Integration with ApplicationSearch: Custom fields aren't indexable. ApplicationSearch is now online and seems stable and good. D5278 provides a template for a backend which can integrate with ApplicationSearch, and ApplicationSearch solves many of the other UI problems implied by exposing custom fields into search (principally, giant pages full of query fields). Generally, I want to provide stronger builtin integration between custom fields and ApplicationSearch. - Integration with ApplicationTransactions: Likewise, custom fields should support more native integrations with ApplicationTransactions, which are also online and seem stable and well designed. - Selection and sorting: Selecting and sorting custom fields is a huge mess right now. I want to move this into config now that we have the UI to support it, and move away from requiring users to subclass a ton of stuff just to add a field. For ApplicationSearch, I've adopted and generalized D5278. For ApplicationTransactions, I haven't made any specific affordances yet. For selection and sorting, I've partially implemented config-based selection and sorting. It will work like this: - We add a new configuration value, like `differential.fields`. In the UI, this is a draggable list of supported fields. Fields can be reordered, and most fields can be disabled. - We load every avialable field to populate this list. New fields will appear at the bottom. - There are two downsides to this approach: - If we add fields in the upstream at a later date, they will appear at the end of the list if an install has customized list order or disabled fields, even if we insert them elsewhere in the upstream. - If we reorder fields in the upstream, the reordering will not be reflected in install which have customized the order/availability. - I think these are both acceptable costs. We only incur them if an admin edits this config, which implies they'll know how to fix it if they want to. - We can fix both of these problems with a straightforward configuration migration if we want to bother. - There are numerous upsides to this approach: - We can delete a bunch of code and replace it with simple configuration. - In general, we don't need the "selector" classes anymore. - Users can enable available-but-disabled fields with one click. - Users can add fields by putting their implementations in `src/extensions/` with zero subclassing or libphutil stuff. - Generally, it's super easy for users to understand. This doesn't actually do anything yet and will probably see some adjustments before anything starts running it. Test Plan: Static checks only, this code isn't reachable yet. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6147
2013-06-06 23:52:40 +02:00
'PhabricatorCustomFieldDataNotAvailableException' => 'Exception',
'PhabricatorCustomFieldImplementationIncompleteException' => 'Exception',
'PhabricatorCustomFieldIndexStorage' => 'PhabricatorLiskDAO',
Flesh out ApplicationTransactions/CustomField integration Summary: None of this code is reachable yet. See discussion in D6147. Ref T1703. Provide tighter integration between ApplicationTransactions and CustomField. Basically, I'm just trying to get all the shared stuff into the base implementation. Test Plan: Code not reachable. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6149
2013-06-06 23:53:07 +02:00
'PhabricatorCustomFieldNotAttachedException' => 'Exception',
Begin generalizing custom fields Summary: Ref T1703. We have currently have two custom field implementations (Maniphest, Differential) and are about to add a third (User, see D6122). I'd like to generalize custom fields before doing a third implementation, so we don't back ourselves into the ApplicationTransactions corner we have with Maniphest/Differential/Audit. For the most part, the existing custom fields work well and can be directly generalized. There are three specific things I want to improve, though: - Integration with ApplicationSearch: Custom fields aren't indexable. ApplicationSearch is now online and seems stable and good. D5278 provides a template for a backend which can integrate with ApplicationSearch, and ApplicationSearch solves many of the other UI problems implied by exposing custom fields into search (principally, giant pages full of query fields). Generally, I want to provide stronger builtin integration between custom fields and ApplicationSearch. - Integration with ApplicationTransactions: Likewise, custom fields should support more native integrations with ApplicationTransactions, which are also online and seem stable and well designed. - Selection and sorting: Selecting and sorting custom fields is a huge mess right now. I want to move this into config now that we have the UI to support it, and move away from requiring users to subclass a ton of stuff just to add a field. For ApplicationSearch, I've adopted and generalized D5278. For ApplicationTransactions, I haven't made any specific affordances yet. For selection and sorting, I've partially implemented config-based selection and sorting. It will work like this: - We add a new configuration value, like `differential.fields`. In the UI, this is a draggable list of supported fields. Fields can be reordered, and most fields can be disabled. - We load every avialable field to populate this list. New fields will appear at the bottom. - There are two downsides to this approach: - If we add fields in the upstream at a later date, they will appear at the end of the list if an install has customized list order or disabled fields, even if we insert them elsewhere in the upstream. - If we reorder fields in the upstream, the reordering will not be reflected in install which have customized the order/availability. - I think these are both acceptable costs. We only incur them if an admin edits this config, which implies they'll know how to fix it if they want to. - We can fix both of these problems with a straightforward configuration migration if we want to bother. - There are numerous upsides to this approach: - We can delete a bunch of code and replace it with simple configuration. - In general, we don't need the "selector" classes anymore. - Users can enable available-but-disabled fields with one click. - Users can add fields by putting their implementations in `src/extensions/` with zero subclassing or libphutil stuff. - Generally, it's super easy for users to understand. This doesn't actually do anything yet and will probably see some adjustments before anything starts running it. Test Plan: Static checks only, this code isn't reachable yet. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6147
2013-06-06 23:52:40 +02:00
'PhabricatorCustomFieldNumericIndexStorage' => 'PhabricatorCustomFieldIndexStorage',
'PhabricatorCustomFieldStorage' => 'PhabricatorLiskDAO',
'PhabricatorCustomFieldStringIndexStorage' => 'PhabricatorCustomFieldIndexStorage',
'PhabricatorCustomFieldValidationException' => 'Exception',
Rough cut of repository tracking Summary: Basic scaffolding for repository tracking, plus daemon infrastructure (Timelines, Cursors) and some fixes (memory usage, mysql_connect() junk). Test Plan: parsed Javelin git commit history via daemon Reviewers: CC:
2011-03-07 07:29:22 +01:00
'PhabricatorDaemon' => 'PhutilDaemon',
Improve web tools for viewing daemons Summary: - Provides an "all daemons" view to look at more than the first 15 daemons. - Provides a "combined log" view with a large page size, to quickly look at the log across all the daemons, making it easier to find issues when you have a bunch of the same daemon and only one is having issues. - When viewing the web console on the same host as a daemon, show whether it's running or not. Test Plan: Clicked the various daemon log interfaces. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran CC: aran Differential Revision: 215
2011-05-03 02:05:22 +02:00
'PhabricatorDaemonCombinedLogController' => 'PhabricatorDaemonController',
Rough cut of Workers Summary: workers do work, provided I have written them correctly. perhaps it is so. Test Plan: Reviewers: CC:
2011-03-10 22:48:29 +01:00
'PhabricatorDaemonConsoleController' => 'PhabricatorDaemonController',
'PhabricatorDaemonController' => 'PhabricatorController',
Diffusion/phd/console improvements.
2011-03-15 21:38:14 +01:00
'PhabricatorDaemonDAO' => 'PhabricatorLiskDAO',
'PhabricatorDaemonLog' => 'PhabricatorDaemonDAO',
'PhabricatorDaemonLogEvent' => 'PhabricatorDaemonDAO',
Improve web tools for viewing daemons Summary: - Provides an "all daemons" view to look at more than the first 15 daemons. - Provides a "combined log" view with a large page size, to quickly look at the log across all the daemons, making it easier to find issues when you have a bunch of the same daemon and only one is having issues. - When viewing the web console on the same host as a daemon, show whether it's running or not. Test Plan: Clicked the various daemon log interfaces. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran CC: aran Differential Revision: 215
2011-05-03 02:05:22 +02:00
'PhabricatorDaemonLogEventsView' => 'AphrontView',
'PhabricatorDaemonLogListController' => 'PhabricatorDaemonController',
'PhabricatorDaemonLogListView' => 'AphrontView',
Diffusion/phd/console improvements.
2011-03-15 21:38:14 +01:00
'PhabricatorDaemonLogViewController' => 'PhabricatorDaemonController',
Add a user-accessible hook for dumping debug code into an install Summary: Currently, there's no easy way for me to tell a user "run this code from the webserver and tell me what it says". Sometimes installs can add new .php files to, e.g., `webroot/rsrc/`, but this is setup-dependent and not universal. Generally I resort to saying "put this into index.php", but that's error prone and not acceptable on active installs. Add a "debug" controller so I can instead say "put this into support/debug.php, then visit /debug/". Test Plan: Visited /debug/ with and without support/debug.php files. Visited /staus/. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5212
2013-03-04 22:45:51 +01:00
'PhabricatorDebugController' => 'PhabricatorController',
Allow Phabricator storage engines to be extended and configured Summary: See T344. Currently, there's a hard-coded 12MB filesize limit and some awkward interactions with MySQL's max_allowed_packet. Make this system generally more robust: - Move the upload limit to configuration. - Add setup steps which reconcile max_allowed_packet vs MySQL file storage limits. - Add a layer of indirection between uploading files and storage engines. - Allow the definition of new storage engines. - Define a local disk storage engine. - Add a "storage engine selector" class which manages choosing which storage engines to put files in. - Document storage engines. - Document file storage classes. Test Plan: Setup mode: - Disabled MySQL storage engine, misconfigured it, configured it correctly. - Disabled file storage engine, set it to something invalid, set it to something valid. - Verified max_allowed_packet is read correctly. Application mode: - Configured local file storage. - Uploaded large and small files. - Verified larger files were written to local storage. - Verified smaller files were written to MySQL blob storage. Documentation: - Read documentation. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, epriestley, jungejason Differential Revision: 695
2011-07-20 07:48:38 +02:00
'PhabricatorDefaultFileStorageEngineSelector' => 'PhabricatorFileStorageEngineSelector',
Provide an indirection layer between documents and the search engine Summary: In preparation for adding another search engine (see T355): - Rename "executor" to "engine". - Move all engine-specific operations into the engine. Specifically, this means that indexing moves out of the document store and into the engine (it was sort of silly where it was before). - Split choice of an engine into an overridable "selector" class, a base API, and a concrete MySQL implementation (just like storage engine selection). - Make all callers go through the indirection layer. The default selector just unconditionally selects the MySQL engine, but now (with D786) I can build an Elastic Search engine and you guys can build a multi-target engine if you want and I don't get there fast enough. Test Plan: - Created a new document (task). - Searched for and found it. - Viewed index reconstruction. Reviewed By: jungejason Reviewers: jungejason, amckinley, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 788
2011-08-08 00:14:23 +02:00
'PhabricatorDefaultSearchEngineSelector' => 'PhabricatorSearchEngineSelector',
Add "Developer" and "Access Log" config option groups, some types Summary: - Add a "developer" option group. - Add an "access log" option group. - Render the types "bool", "int" and "string" in a more tailored way. - Add a config check for dead config. Right now this serves as a "TODO" list of things that need to be migrated. Test Plan: Looked at config options, setup issues. Edited bool, int, string options. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4308
2013-01-01 23:09:17 +01:00
'PhabricatorDeveloperConfigOptions' => 'PhabricatorApplicationConfigOptions',
Begin moving Phabricator configuration into PHP Summary: Ref T2255. Ref T2221. Lay the groundwork to move configuration into PHP, so we can show descriptions in the web UI, do typechecking, disable application options when an application is uninstalled, etc. Test Plan: {F28421} {F28420} {F28422} Reviewers: codeblock, btrahan, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221, T2255 Differential Revision: https://secure.phabricator.com/D4306
2012-12-31 00:36:06 +01:00
'PhabricatorDifferentialConfigOptions' => 'PhabricatorApplicationConfigOptions',
xDiffs and Revisions Generating Summary: Ref T2903 Test Plan: Revisions and Diffs are visually being generated Reviewers: epriestley, xask.linus Reviewed By: epriestley CC: AnhNhan, aran, Korvin Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5835
2013-05-06 23:11:26 +02:00
'PhabricatorDifferentialRevisionTestDataGenerator' => 'PhabricatorTestDataGenerator',
Diffusion / MetaMTA options Summary: Implement Diffusion MetaMTA options. Also make the fake '{{config.option}}' rule work, and use Remarkup to render summaries as well as descriptions. Test Plan: Looked at Diffusion rules, edited some, looked at setup issues, verified '{{config.option}}' linked to the right option. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4466
2013-01-16 18:08:13 +01:00
'PhabricatorDiffusionConfigOptions' => 'PhabricatorApplicationConfigOptions',
More phabricator organizational stuff.
2011-01-23 02:48:55 +01:00
'PhabricatorDirectoryController' => 'PhabricatorController',
Further improve unit/lint rendering Summary: I think this improves things, let me know if you have feedback. Also addresses T840. Test Plan: See screenshots... Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran, zeeg Maniphest Tasks: T840 Differential Revision: https://secure.phabricator.com/D2357
2012-05-01 19:15:56 +02:00
'PhabricatorDirectoryMainController' => 'PhabricatorDirectoryController',
Admin and disabled flags for users Summary: Provide an "isAdmin" flag for users, to designate administrative users. Restore the account editing interface and allow it to set role flags and reset passwords. Provide an "isDisabled" flag for users and shut down all system access for them. Test Plan: Created "admin" and "disabled" users. Did administrative things with the admin user. Tried to do stuff with the disabled user and was rebuffed. Tried to access administrative interfaces with a normal non-admin user and was denied. Reviewed By: aran Reviewers: tuomaspelkonen, jungejason, aran CC: ccheever, aran Differential Revision: 278
2011-05-12 19:06:54 +02:00
'PhabricatorDisabledUserController' => 'PhabricatorAuthController',
Add Disqus, Facebook, Google, GitHub auth config; AWS config Summary: Also improve behavior for the "unknown config" warning. Test Plan: Looked at configs, went through unknown config workflow. Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4310
2013-01-01 23:09:29 +01:00
'PhabricatorDisqusConfigOptions' => 'PhabricatorApplicationConfigOptions',
Revision comment drafts.
2011-02-06 01:57:21 +01:00
'PhabricatorDraft' => 'PhabricatorDraftDAO',
'PhabricatorDraftDAO' => 'PhabricatorLiskDAO',
Add an assocations-like "Edges" framework Summary: We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems: - We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant. - Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks. - I want to add more of these and don't want to continue building custom stuff. - UIs like the "attach stuff to other stuff" UI need custom branches for each object type. - Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage. Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences: - I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook. - I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type. This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904. Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation. Reviewers: btrahan Reviewed By: btrahan CC: aran, 20after4 Differential Revision: https://secure.phabricator.com/D2088
2012-04-05 00:30:21 +02:00
'PhabricatorEdgeConfig' => 'PhabricatorEdgeConstants',
Allow edges to be configured to prevent cycles Summary: Certain types of things we should be storing in edges (notably, Task X depends on Task Y) should always be acyclic. Allow `PhabricatorEdgeEditor` to enforce this, since we can't correctly enforce it outside of the editor without being vulnerable to races. Each edge type can be marked acyclic. If an edge type is acyclic, we perform additional steps when writing new edges of that type: - We acquire a global lock on the edge type before performing any reads or writes. This ensures we can't produce a cycle as a result of a race where two edits add edges which independently do not produce a cycle, but do produce a cycle when combined. - After performing writes but before committing transactions, we load the edge graph for each acyclic type and verify that it is, in fact, acyclic. If we detect cycles, we abort the edit. - When we're done, we release the edge type locks. This is a relatively high-complexity change, but gives us a simple way to flag an edge type as acyclic in a robust way. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D2940
2012-07-09 19:39:38 +02:00
'PhabricatorEdgeCycleException' => 'Exception',
If users are on the email to Phabricator, do not send them the Phabricator reply. Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email. Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected. Reviewers: epriestley, vrana Reviewed By: vrana CC: aran, Korvin, vrana Maniphest Tasks: T1676 Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 19:18:23 +02:00
'PhabricatorEdgeEditor' => 'PhabricatorEditor',
Allow edges to be configured to prevent cycles Summary: Certain types of things we should be storing in edges (notably, Task X depends on Task Y) should always be acyclic. Allow `PhabricatorEdgeEditor` to enforce this, since we can't correctly enforce it outside of the editor without being vulnerable to races. Each edge type can be marked acyclic. If an edge type is acyclic, we perform additional steps when writing new edges of that type: - We acquire a global lock on the edge type before performing any reads or writes. This ensures we can't produce a cycle as a result of a race where two edits add edges which independently do not produce a cycle, but do produce a cycle when combined. - After performing writes but before committing transactions, we load the edge graph for each acyclic type and verify that it is, in fact, acyclic. If we detect cycles, we abort the edit. - When we're done, we release the edge type locks. This is a relatively high-complexity change, but gives us a simple way to flag an edge type as acyclic in a robust way. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D2940
2012-07-09 19:39:38 +02:00
'PhabricatorEdgeGraph' => 'AbstractDirectedGraph',
Add an assocations-like "Edges" framework Summary: We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems: - We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant. - Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks. - I want to add more of these and don't want to continue building custom stuff. - UIs like the "attach stuff to other stuff" UI need custom branches for each object type. - Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage. Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences: - I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook. - I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type. This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904. Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation. Reviewers: btrahan Reviewed By: btrahan CC: aran, 20after4 Differential Revision: https://secure.phabricator.com/D2088
2012-04-05 00:30:21 +02:00
'PhabricatorEdgeQuery' => 'PhabricatorQuery',
Allow edges to be configured to prevent cycles Summary: Certain types of things we should be storing in edges (notably, Task X depends on Task Y) should always be acyclic. Allow `PhabricatorEdgeEditor` to enforce this, since we can't correctly enforce it outside of the editor without being vulnerable to races. Each edge type can be marked acyclic. If an edge type is acyclic, we perform additional steps when writing new edges of that type: - We acquire a global lock on the edge type before performing any reads or writes. This ensures we can't produce a cycle as a result of a race where two edits add edges which independently do not produce a cycle, but do produce a cycle when combined. - After performing writes but before committing transactions, we load the edge graph for each acyclic type and verify that it is, in fact, acyclic. If we detect cycles, we abort the edit. - When we're done, we release the edge type locks. This is a relatively high-complexity change, but gives us a simple way to flag an edge type as acyclic in a robust way. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D2940
2012-07-09 19:39:38 +02:00
'PhabricatorEdgeTestCase' => 'PhabricatorTestCase',
Introduce lightbox view for images Summary: images attached to maniphest tasks and mentioned in remarkup anywhere now invoke a lightbox control that lets the user page through all the images. lightbox includes a download button, next / prev buttons, and if we're not at the tippy toppy of hte page an "X" or close button. we also respond to left, right, and esc for navigating. next time we should get non-images working in here...! Test Plan: played with maniphest - looks good made comments with images. looks good. made sure multiple image comments worked. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad Maniphest Tasks: T1896 Differential Revision: https://secure.phabricator.com/D3705
2012-10-23 04:06:56 +02:00
'PhabricatorEditor' => 'Phobject',
PhabricatorEnv 'infratructure' -> 'infrastructure' (rofl) Recaptcha Email Login / Forgot Password Password Reset
2011-01-31 20:55:26 +01:00
'PhabricatorEmailLoginController' => 'PhabricatorAuthController',
'PhabricatorEmailTokenController' => 'PhabricatorAuthController',
Allow users to have multiple email addresses, and verify emails Summary: - Move email to a separate table. - Migrate existing email to new storage. - Allow users to add and remove email addresses. - Allow users to verify email addresses. - Allow users to change their primary email address. - Convert all the registration/reset/login code to understand these changes. - There are a few security considerations here but I think I've addressed them. Principally, it is important to never let a user acquire a verified email address they don't actually own. We ensure this by tightening the scoping of token generation rules to be (user, email) specific. - This should have essentially zero impact on Facebook, but may require some minor changes in the registration code -- I don't exactly remember how it is set up. Not included here (next steps): - Allow configuration to restrict email to certain domains. - Allow configuration to require validated email. Test Plan: This is a fairly extensive, difficult-to-test change. - From "Email Addresses" interface: - Added new email (verified email verifications sent). - Changed primary email (verified old/new notificactions sent). - Resent verification emails (verified they sent). - Removed email. - Tried to add already-owned email. - Created new users with "accountadmin". Edited existing users with "accountadmin". - Created new users with "add_user.php". - Created new users with web interface. - Clicked welcome email link, verified it verified email. - Reset password. - Linked/unlinked oauth accounts. - Logged in with oauth account. - Logged in with email. - Registered with Oauth account. - Tried to register with OAuth account with duplicate email. - Verified errors for email verification with bad tokens, etc. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1184 Differential Revision: https://secure.phabricator.com/D2393
2012-05-07 19:29:33 +02:00
'PhabricatorEmailVerificationController' => 'PhabricatorPeopleController',
Introduce PhabricatorEmptyQueryException Summary: It's dumb to execute a query which we know will return an empty result. Test Plan: Looked at comment preview with "11", didn't see "1 = 0" in DarkConsole. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5177
2013-03-01 20:28:02 +01:00
'PhabricatorEmptyQueryException' => 'Exception',
Allow extending English translation Test Plan: Displayed home. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D2759
2012-06-15 04:01:57 +02:00
'PhabricatorEnglishTranslation' => 'PhabricatorBaseEnglishTranslation',
Lock down accepted next URI values for redirect after login Summary: I locked this down a little bit recently, but make double-extra-super-sure that we aren't sending the user anywhere suspicious or open-redirecty. This also locks down protocol-relative URIs (//evil.com/path) although I don't think any browsers do bad stuff with them in this context, and header injection URIs (although I don't think any of the modern PHP runtimes are vulnerable). Test Plan: - Ran tests. - Hit redirect page with valid and invalid next URIs; was punted to / for invalid ones and to the right place for valid ones. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: arice, aran, epriestley, btrahan Differential Revision: https://secure.phabricator.com/D1369
2012-01-12 01:07:36 +01:00
'PhabricatorEnvTestCase' => 'PhabricatorTestCase',
Make error views look less awful Summary: These elements look heavy and out of place right now. Test Plan: Looked at error views in uiexample page. Reviewers: btrahan, vrana, jungejason Reviewed By: jungejason CC: aran Differential Revision: https://secure.phabricator.com/D2144
2012-04-08 02:25:31 +02:00
'PhabricatorErrorExample' => 'PhabricatorUIExample',
Move event framework from Phabricator to libphutil Summary: Move event framework from Phabricator to libphutil so it can be used in other phutil projects, such as Arcanist. Test plan: Use along with path to libphutil, events should work as expected. Reviewers: epriestley Differential Revision: 1098
2011-11-10 02:23:33 +01:00
'PhabricatorEvent' => 'PhutilEvent',
'PhabricatorEventType' => 'PhutilEventType',
Add an example event listener, improve documentation, and add a commit discovery event Summary: Improve documentation around Phabricator events. Test Plan: Generated and read documentation. Ran test script. Reviewers: btrahan, jungejason Reviewed By: jungejason CC: aran Maniphest Tasks: T1092 Differential Revision: https://secure.phabricator.com/D2917
2012-07-04 01:46:27 +02:00
'PhabricatorExampleEventListener' => 'PhutilEventListener',
Add the "Extending Phabricator" config group. Summary: Refs T2255 and takes care of the "EXTENDING PHABRICATOR" group thereof. Test Plan: Looked at each of the new options. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4325
2013-01-03 00:52:30 +01:00
'PhabricatorExtendingPhabricatorConfigOptions' => 'PhabricatorApplicationConfigOptions',
Created PhabricatorExternalAccount Class and Sql patch to create an external_account table. Summary: Created PhabricatorExternalAccount class with only data members. Will discuss with you regarding the necessary functions to be implemented in this class. Sql Patch to create a new table for external_accounts. Will I have to write unit tests the new storage object? Sending you this diff so that you can comment on this to further improve :). Test Plan: {F40977} Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T1536, T1205 Differential Revision: https://secure.phabricator.com/D5724
2013-04-19 20:40:13 +02:00
'PhabricatorExternalAccount' => 'PhabricatorUserDAO',
Add Disqus, Facebook, Google, GitHub auth config; AWS config Summary: Also improve behavior for the "unknown config" warning. Test Plan: Looked at configs, went through unknown config workflow. Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4310
2013-01-01 23:09:29 +01:00
'PhabricatorFacebookConfigOptions' => 'PhabricatorApplicationConfigOptions',
Add aggregated facts to the Facts application Summary: Some facts are aggregations of other facts. For example, we may compute how many times each macro is used in each object as a "raw fact": Dnnn uses macro "psyduck" 6 times. But we want to present this data in aggregate form, e.g. "order macros by popularity". We can do this at runtime and it probably won't be too awful a query, but we can also aggregate it cheaply: Macro "psyduck" is used 3920 times across all objects. ...and then do a query like "select macros ordered by usage". "Aggregate" facts support facts like this. The aggregate facts I've implemented are: - Count of all objects. - Count of objects of type X. - Last time facts were updated. These clearly fit the "aggregate" facts template well. I'm not 100% sure macros do. We can use this table to answer a question like "What are the most popular macros, ordered by use?" We can also use it to answer a question like "What are the most popular macros in the last 6 months?", if we build a specific fact for that. But we can't use it to answer a question like "What are the most popular macros between times X and Y?". Maybe that's important; maybe not. This seems like a good fit for at least some types of facts. I'll de-magic the keys a bit in the next diff. Test Plan: Ran the engines and got some aggregated facts about other facts. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3089
2012-07-27 22:46:01 +02:00
'PhabricatorFactAggregate' => 'PhabricatorFactDAO',
Allow Fact app to draw charts Summary: For any count fact, allow a chart to be drawn. INCREDIBLY POWERFUL DATA ANALYSIS PLATFORM. Test Plan: Drew a chart of object counts. Drew the Maniphest burn chart. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3099
2012-07-30 19:44:08 +02:00
'PhabricatorFactChartController' => 'PhabricatorFactController',
Add aggregated facts to the Facts application Summary: Some facts are aggregations of other facts. For example, we may compute how many times each macro is used in each object as a "raw fact": Dnnn uses macro "psyduck" 6 times. But we want to present this data in aggregate form, e.g. "order macros by popularity". We can do this at runtime and it probably won't be too awful a query, but we can also aggregate it cheaply: Macro "psyduck" is used 3920 times across all objects. ...and then do a query like "select macros ordered by usage". "Aggregate" facts support facts like this. The aggregate facts I've implemented are: - Count of all objects. - Count of objects of type X. - Last time facts were updated. These clearly fit the "aggregate" facts template well. I'm not 100% sure macros do. We can use this table to answer a question like "What are the most popular macros, ordered by use?" We can also use it to answer a question like "What are the most popular macros in the last 6 months?", if we build a specific fact for that. But we can't use it to answer a question like "What are the most popular macros between times X and Y?". Maybe that's important; maybe not. This seems like a good fit for at least some types of facts. I'll de-magic the keys a bit in the next diff. Test Plan: Ran the engines and got some aggregated facts about other facts. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3089
2012-07-27 22:46:01 +02:00
'PhabricatorFactController' => 'PhabricatorController',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactCountEngine' => 'PhabricatorFactEngine',
Add FactCursors and application fact datasources Summary: - Add PhabricatorApplication. This is a general class that I have grand designs for, but used here to allow applications to provide objects for analysis by the facts appliction. - Add FactCursors, to keep track of where iterators are. - Make the daemon do something sort of useful. - Add `bin/fact cursors` for showing and managing objects and cursors. - Add some options to `bin/fact analyze`. Test Plan: - `bin/fact cursors`, `bin/fact cursors --reset DifferentialRevision`, `bin/fact cursors --reset X` - `bin/fact analyze`, `bin/fact analyze --all`, `bin/fact analyze --iterator DifferentialRevision --skip-aggregates` - `bin/phd debug fact` Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3098
2012-07-30 19:43:49 +02:00
'PhabricatorFactCursor' => 'PhabricatorFactDAO',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactDAO' => 'PhabricatorLiskDAO',
'PhabricatorFactDaemon' => 'PhabricatorDaemon',
Add aggregated facts to the Facts application Summary: Some facts are aggregations of other facts. For example, we may compute how many times each macro is used in each object as a "raw fact": Dnnn uses macro "psyduck" 6 times. But we want to present this data in aggregate form, e.g. "order macros by popularity". We can do this at runtime and it probably won't be too awful a query, but we can also aggregate it cheaply: Macro "psyduck" is used 3920 times across all objects. ...and then do a query like "select macros ordered by usage". "Aggregate" facts support facts like this. The aggregate facts I've implemented are: - Count of all objects. - Count of objects of type X. - Last time facts were updated. These clearly fit the "aggregate" facts template well. I'm not 100% sure macros do. We can use this table to answer a question like "What are the most popular macros, ordered by use?" We can also use it to answer a question like "What are the most popular macros in the last 6 months?", if we build a specific fact for that. But we can't use it to answer a question like "What are the most popular macros between times X and Y?". Maybe that's important; maybe not. This seems like a good fit for at least some types of facts. I'll de-magic the keys a bit in the next diff. Test Plan: Ran the engines and got some aggregated facts about other facts. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3089
2012-07-27 22:46:01 +02:00
'PhabricatorFactHomeController' => 'PhabricatorFactController',
'PhabricatorFactLastUpdatedEngine' => 'PhabricatorFactEngine',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactManagementAnalyzeWorkflow' => 'PhabricatorFactManagementWorkflow',
Add FactCursors and application fact datasources Summary: - Add PhabricatorApplication. This is a general class that I have grand designs for, but used here to allow applications to provide objects for analysis by the facts appliction. - Add FactCursors, to keep track of where iterators are. - Make the daemon do something sort of useful. - Add `bin/fact cursors` for showing and managing objects and cursors. - Add some options to `bin/fact analyze`. Test Plan: - `bin/fact cursors`, `bin/fact cursors --reset DifferentialRevision`, `bin/fact cursors --reset X` - `bin/fact analyze`, `bin/fact analyze --all`, `bin/fact analyze --iterator DifferentialRevision --skip-aggregates` - `bin/phd debug fact` Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3098
2012-07-30 19:43:49 +02:00
'PhabricatorFactManagementCursorsWorkflow' => 'PhabricatorFactManagementWorkflow',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactManagementDestroyWorkflow' => 'PhabricatorFactManagementWorkflow',
'PhabricatorFactManagementListWorkflow' => 'PhabricatorFactManagementWorkflow',
'PhabricatorFactManagementStatusWorkflow' => 'PhabricatorFactManagementWorkflow',
'PhabricatorFactManagementWorkflow' => 'PhutilArgumentWorkflow',
'PhabricatorFactRaw' => 'PhabricatorFactDAO',
Add FactCursors and application fact datasources Summary: - Add PhabricatorApplication. This is a general class that I have grand designs for, but used here to allow applications to provide objects for analysis by the facts appliction. - Add FactCursors, to keep track of where iterators are. - Make the daemon do something sort of useful. - Add `bin/fact cursors` for showing and managing objects and cursors. - Add some options to `bin/fact analyze`. Test Plan: - `bin/fact cursors`, `bin/fact cursors --reset DifferentialRevision`, `bin/fact cursors --reset X` - `bin/fact analyze`, `bin/fact analyze --all`, `bin/fact analyze --iterator DifferentialRevision --skip-aggregates` - `bin/phd debug fact` Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3098
2012-07-30 19:43:49 +02:00
'PhabricatorFactSimpleSpec' => 'PhabricatorFactSpec',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactUpdateIterator' => 'PhutilBufferedIterator',
Feed options. Test Plan: Looked at them. Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4434
2013-01-15 02:49:32 +01:00
'PhabricatorFeedConfigOptions' => 'PhabricatorApplicationConfigOptions',
Build basic infrastructure for an activity feed Summary: This defines an extremely basic version of an activity feed, like Facebook's news feed. It doesn't do much of interest yet. Test Plan: Published some feed stories: https://secure.phabricator.com/file/view/PHID-FILE-5061aa72105bbdc05b21/ Reviewed By: tuomaspelkonen Reviewers: jungejason, tuomaspelkonen, aran Commenters: codeblock, jungejason CC: aran, epriestley, codeblock, tuomaspelkonen, jungejason Differential Revision: 593
2011-07-05 17:35:18 +02:00
'PhabricatorFeedController' => 'PhabricatorController',
'PhabricatorFeedDAO' => 'PhabricatorLiskDAO',
Make feed its own application Summary: Fixes the two-level nav issue introduced by D4376. (My claim that this page is device ready in the code is something of a lie, but it's fairly close.) (@chad, this could use an icon at some point, or you can point me at which one you want and I can take a stab at slicing it.) Test Plan: Looked at feed; saw it not-broken. Also checked public feed (which should just merge at some point). Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D4381
2013-01-11 01:06:29 +01:00
'PhabricatorFeedMainController' => 'PhabricatorFeedController',
Provide a public view of feed Summary: Depends on D628. Provides a config option so you can set up a public feed, which you can iframe. This needs some work but sort of works. Test Plan: Loaded the public feed as a logged-out user. Reviewed By: codeblock Reviewers: jungejason, tuomaspelkonen, aran, codeblock CC: aran, codeblock Differential Revision: 635
2011-07-10 03:03:59 +02:00
'PhabricatorFeedPublicStreamController' => 'PhabricatorFeedController',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorFeedQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add an example event listener, improve documentation, and add a commit discovery event Summary: Improve documentation around Phabricator events. Test Plan: Generated and read documentation. Ran test script. Reviewers: btrahan, jungejason Reviewed By: jungejason CC: aran Maniphest Tasks: T1092 Differential Revision: https://secure.phabricator.com/D2917
2012-07-04 01:46:27 +02:00
'PhabricatorFeedStory' => 'PhabricatorPolicyInterface',
Support basic notification aggregation Summary: This is both only partially complete (supports Maniphest only) and somewhat overcomplicated (includes support for applying similar algorithms to Feed), but provides runtime aggregation of notifications. Test Plan: {F13502} Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2884
2012-07-01 20:08:59 +02:00
'PhabricatorFeedStoryAggregate' => 'PhabricatorFeedStory',
Integrate Audit into feed Summary: When a user posts an action in the audit tool, publish it to feed. Test Plan: Made some comments, saw them show up in feed. Reviewers: btrahan, jungejason Reviewed By: jungejason CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1695
2012-02-27 18:49:01 +01:00
'PhabricatorFeedStoryAudit' => 'PhabricatorFeedStory',
Publish feed stories about commits Summary: When stuff gets committed, publish feed stories about it. Test Plan: {F13061} Reviewers: jungejason, vrana, voldern Reviewed By: jungejason CC: aran Maniphest Tasks: T1322 Differential Revision: https://secure.phabricator.com/D2805
2012-06-20 15:03:44 +02:00
'PhabricatorFeedStoryCommit' => 'PhabricatorFeedStory',
Build basic infrastructure for an activity feed Summary: This defines an extremely basic version of an activity feed, like Facebook's news feed. It doesn't do much of interest yet. Test Plan: Published some feed stories: https://secure.phabricator.com/file/view/PHID-FILE-5061aa72105bbdc05b21/ Reviewed By: tuomaspelkonen Reviewers: jungejason, tuomaspelkonen, aran Commenters: codeblock, jungejason CC: aran, epriestley, codeblock, tuomaspelkonen, jungejason Differential Revision: 593
2011-07-05 17:35:18 +02:00
'PhabricatorFeedStoryData' => 'PhabricatorFeedDAO',
Publish Differential stories into feed Summary: Basic hookup for Differential -> Feed. Also introduces "one-line" stories for less-important stuff. Test Plan: Interacted with some revisions, got feed stories out of it. Reviewed By: jungejason Reviewers: jungejason, aran, tuomaspelkonen, codeblock CC: aran, jungejason Differential Revision: 632
2011-07-10 00:44:49 +02:00
'PhabricatorFeedStoryDifferential' => 'PhabricatorFeedStory',
Aggregate Differential notifications Summary: Just a bunch of copy-pasta from D2884. I suppose this calls for a refactoring at some point... Test Plan: Make a bunch of updates, some from different users; check notifications dropdown and list. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3361
2012-08-22 17:19:38 +02:00
'PhabricatorFeedStoryDifferentialAggregate' => 'PhabricatorFeedStoryAggregate',
Publish feed stories from Maniphest Summary: I didn't get around to this earlier; add Feed/Maniphest integration. This is partly motivated by wanting Projects to not be terrible. Pretty straightforward. Test Plan: - Created, updated, reassigned and closed a task. - Verified feed stories render reasonably. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, btrahan Maniphest Tasks: T681 Differential Revision: 1232
2011-12-17 22:27:11 +01:00
'PhabricatorFeedStoryManiphest' => 'PhabricatorFeedStory',
Support basic notification aggregation Summary: This is both only partially complete (supports Maniphest only) and somewhat overcomplicated (includes support for applying similar algorithms to Feed), but provides runtime aggregation of notifications. Test Plan: {F13502} Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2884
2012-07-01 20:08:59 +02:00
'PhabricatorFeedStoryManiphestAggregate' => 'PhabricatorFeedStoryAggregate',
Adds base notification application Summary: First diff in a series of diffs to add notifications to Phabricator. This is the notification application ONLY. This commit does not include the changes to other applications that makes them add notifications. As such, no notifications will be generated beyond the initial database import. Test Plan: This is part of the notifications architecture which has been running on http://theoryphabricator.com for the past several months. Reviewers: epriestley, btrahan, ddfisher Reviewed By: epriestley CC: allenjohnashton, keebuhm, aran, Korvin, jungejason, nh Maniphest Tasks: T974 Differential Revision: https://secure.phabricator.com/D2571
2012-06-08 15:31:30 +02:00
'PhabricatorFeedStoryNotification' => 'PhabricatorFeedDAO',
Publish Phriction edits to feed Summary: Basic integration between Phriction and feed. Test Plan: Created and edited some documents, they published to feed. Reviewed By: hsb Reviewers: hsb, codeblock, jungejason, tuomaspelkonen, aran CC: aran, hsb Differential Revision: 653
2011-07-12 16:23:04 +02:00
'PhabricatorFeedStoryPhriction' => 'PhabricatorFeedStory',
Add transaction-oriented editing to projects Summary: - Make some editing operations transaction-oriented, like Maniphest. (This seems to be a good model, particularly for extensibility.) I'll move the rest of the editing operations to transactions in future diffs. - Make transaction-oriented operations publish feed stories. Test Plan: - Created a new project. - Edited an existing project. - Created a new project via quick create flow from Maniphest. - Verified feed stories publish correctly. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T681 Differential Revision: https://secure.phabricator.com/D1477
2012-01-24 16:11:37 +01:00
'PhabricatorFeedStoryProject' => 'PhabricatorFeedStory',
Build basic infrastructure for an activity feed Summary: This defines an extremely basic version of an activity feed, like Facebook's news feed. It doesn't do much of interest yet. Test Plan: Published some feed stories: https://secure.phabricator.com/file/view/PHID-FILE-5061aa72105bbdc05b21/ Reviewed By: tuomaspelkonen Reviewers: jungejason, tuomaspelkonen, aran Commenters: codeblock, jungejason CC: aran, epriestley, codeblock, tuomaspelkonen, jungejason Differential Revision: 593
2011-07-05 17:35:18 +02:00
'PhabricatorFeedStoryReference' => 'PhabricatorFeedDAO',
Improve feed stories with "style", and build basic status update stories. Summary: Straightfoward iteration on feed. Test Plan: https://secure.phabricator.com/file/view/PHID-FILE-d07077119dc834e76618/ Reviewed By: codeblock Reviewers: jungejason, aran, tuomaspelkonen, codeblock CC: aran, codeblock, epriestley Differential Revision: 631
2011-07-09 22:28:09 +02:00
'PhabricatorFeedStoryStatus' => 'PhabricatorFeedStory',
Publish Differential stories into feed Summary: Basic hookup for Differential -> Feed. Also introduces "one-line" stories for less-important stuff. Test Plan: Interacted with some revisions, got feed stories out of it. Reviewed By: jungejason Reviewers: jungejason, aran, tuomaspelkonen, codeblock CC: aran, jungejason Differential Revision: 632
2011-07-10 00:44:49 +02:00
'PhabricatorFeedStoryTypeConstants' => 'PhabricatorFeedConstants',
Add PhabricatorFileQuery Summary: This doesn't do anything useful yet but Pholio needs to access Files and I wanted to get the groundwork in place for eventual policy-awareness. Test Plan: Will use in Pholio. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3829
2012-10-31 17:57:46 +01:00
'PhabricatorFile' =>
array(
0 => 'PhabricatorFileDAO',
1 => 'PhabricatorPolicyInterface',
),
Phabricator file upload application.
2011-01-23 03:33:00 +01:00
'PhabricatorFileController' => 'PhabricatorController',
'PhabricatorFileDAO' => 'PhabricatorLiskDAO',
Move ALL files to serve from the alternate file domain, not just files without "Content-Disposition: attachment" Summary: We currently serve some files off the primary domain (with "Content-Disposition: attachment" + a CSRF check) and some files off the alternate domain (without either). This is not sufficient, because some UAs (like the iPad) ignore "Content-Disposition: attachment". So there's an attack that goes like this: - Alice uploads xss.html - Alice says to Bob "hey download this file on your iPad" - Bob clicks "Download" on Phabricator on his iPad, gets XSS'd. NOTE: This removes the CSRF check for downloading files. The check is nice to have but only raises the barrier to entry slightly. Between iPad / sniffing / flash bytecode attacks, single-domain installs are simply insecure. We could restore the check at some point in conjunction with a derived authentication cookie (i.e., a mini-session-token which is only useful for downloading files), but that's a lot of complexity to drop all at once. (Because files are now authenticated only by knowing the PHID and secret key, this also fixes the "no profile pictures in public feed while logged out" issue.) Test Plan: Viewed, info'd, and downloaded files Reviewers: btrahan, arice, alok Reviewed By: arice CC: aran, epriestley Maniphest Tasks: T843 Differential Revision: https://secure.phabricator.com/D1608
2012-02-14 23:52:27 +01:00
'PhabricatorFileDataController' => 'PhabricatorFileController',
Allow files to be deleted Summary: A couple of people mentioned that they've had users accidentally upload sensitive files. Allow files to be deleted. (At some point it might be nice to keep the file handle around and log who deleted it, but this addresses the immediate problem without needing too much work.) Test Plan: Deleted some files. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T780 Differential Revision: https://secure.phabricator.com/D1423
2012-01-16 22:26:44 +01:00
'PhabricatorFileDeleteController' => 'PhabricatorFileController',
Drag-and-drop upload for Maniphest Summary: This needs a bunch of UI polish (critically, it's totally undiscoverable) but it basically works correctly. I'll clean it up in some followups. Test Plan: Uploaded some files via drag-and-drop, made comments, etc. Reviewed By: aran Reviewers: tomo, aran, jungejason, tuomaspelkonen CC: anjali, aran Differential Revision: 332
2011-05-22 20:55:10 +02:00
'PhabricatorFileDropUploadController' => 'PhabricatorFileController',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorFileImageMacro' =>
array(
0 => 'PhabricatorFileDAO',
1 => 'PhabricatorSubscribableInterface',
Integrate subscriptions with ApplicationTransactions Summary: Fixes T2214. For objects which support ApplicationTransaction, use ApplicationTransactions to apply subscription action changes. Principally, this makes clicking "Subscribe" / "Unsubscribe" appear correctly in the transaction log. Test Plan: Clicked "Subscribe" and "Unsubscribe" a on Macros and Mocks. Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2214 Differential Revision: https://secure.phabricator.com/D4986
2013-02-17 15:37:09 +01:00
2 => 'PhabricatorApplicationTransactionInterface',
Adding some filters and queries to Macro application Summary: Fixes T2778 Introduces `PhabricatorMacroQuery`, which should consolidate all queries regarding macros Adds `PolicyInterface` to `PhabricatorImageMacro`, as else the query would fail (we should consider adding it to the ApplicationTransaction instead, if that was ever planned) Adds `Active Macros` filter, making it the default Adds `My Macros` filter. You may ask why it overwrites `$authors`. Well, I did not want the page jump to the conclusion that it is a search result. It //is// one more or less, but the filter would jump to `seach` instead of `my`. If you want `My Macros` removed, tell me. It is useful only to heavy-macro-uploaders-and-users though. Five or six people in `http://secure.phabricator.(org|com)`, and an estimated dozen and a half at bigger installs. Test Plan: created multiple macros from multiple authors, disabled them at will. browsed around, verified that Macros only appeared in the right filters and that nothing else broke. Reviewers: epriestley, chad, btrahan CC: aran, Korvin Maniphest Tasks: T2778 Differential Revision: https://secure.phabricator.com/D5409
2013-03-22 17:46:21 +01:00
3 => 'PhabricatorPolicyInterface',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
),
Move ALL files to serve from the alternate file domain, not just files without "Content-Disposition: attachment" Summary: We currently serve some files off the primary domain (with "Content-Disposition: attachment" + a CSRF check) and some files off the alternate domain (without either). This is not sufficient, because some UAs (like the iPad) ignore "Content-Disposition: attachment". So there's an attack that goes like this: - Alice uploads xss.html - Alice says to Bob "hey download this file on your iPad" - Bob clicks "Download" on Phabricator on his iPad, gets XSS'd. NOTE: This removes the CSRF check for downloading files. The check is nice to have but only raises the barrier to entry slightly. Between iPad / sniffing / flash bytecode attacks, single-domain installs are simply insecure. We could restore the check at some point in conjunction with a derived authentication cookie (i.e., a mini-session-token which is only useful for downloading files), but that's a lot of complexity to drop all at once. (Because files are now authenticated only by knowing the PHID and secret key, this also fixes the "no profile pictures in public feed while logged out" issue.) Test Plan: Viewed, info'd, and downloaded files Reviewers: btrahan, arice, alok Reviewed By: arice CC: aran, epriestley Maniphest Tasks: T843 Differential Revision: https://secure.phabricator.com/D1608
2012-02-14 23:52:27 +01:00
'PhabricatorFileInfoController' => 'PhabricatorFileController',
Introduce lightbox view for images Summary: images attached to maniphest tasks and mentioned in remarkup anywhere now invoke a lightbox control that lets the user page through all the images. lightbox includes a download button, next / prev buttons, and if we're not at the tippy toppy of hte page an "X" or close button. we also respond to left, right, and esc for navigating. next time we should get non-images working in here...! Test Plan: played with maniphest - looks good made comments with images. looks good. made sure multiple image comments worked. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad Maniphest Tasks: T1896 Differential Revision: https://secure.phabricator.com/D3705
2012-10-23 04:06:56 +02:00
'PhabricatorFileLinkListView' => 'AphrontView',
'PhabricatorFileLinkView' => 'AphrontView',
Implement ApplicationSearch in Files Summary: Ref T2625. Ref T1163. A couple of small generalization nudges, but this is almost entirely straightforward. Test Plan: Executed various File queries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1163, T2625 Differential Revision: https://secure.phabricator.com/D6091
2013-05-31 19:51:05 +02:00
'PhabricatorFileListController' =>
array(
0 => 'PhabricatorFileController',
1 => 'PhabricatorApplicationSearchResultsControllerInterface',
),
Add PhabricatorFileQuery Summary: This doesn't do anything useful yet but Pholio needs to access Files and I wanted to get the groundwork in place for eventual policy-awareness. Test Plan: Will use in Pholio. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3829
2012-10-31 17:57:46 +01:00
'PhabricatorFileQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Implement ApplicationSearch in Files Summary: Ref T2625. Ref T1163. A couple of small generalization nudges, but this is almost entirely straightforward. Test Plan: Executed various File queries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1163, T2625 Differential Revision: https://secure.phabricator.com/D6091
2013-05-31 19:51:05 +02:00
'PhabricatorFileSearchEngine' => 'PhabricatorApplicationSearchEngine',
Add /F123 shortcut Summary: I wanted to point someone on a file uploaded to Phabricator and the normal link is just too long. I guess that this also improves security. Because pointing someone to the file directly reveals the secret key used in /data/ and it can be served without auth? We already use `{F123}` so there will be no conflicts in future because we wouldn't want to reuse it for something else. I promote the link on /file/ - it adds one redirect but I think it's worth it. I also considered making the link from the File ID column but there are already too many links (with some duplicity). Test Plan: /file/ /F123 (redirect) /F9999999999 (404) Reviewers: epriestley Reviewed By: epriestley CC: aran, Koolvin Differential Revision: https://secure.phabricator.com/D2380
2012-05-03 23:46:11 +02:00
'PhabricatorFileShortcutController' => 'PhabricatorFileController',
Phabricator file upload application.
2011-01-23 03:33:00 +01:00
'PhabricatorFileStorageBlob' => 'PhabricatorFileDAO',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'PhabricatorFileStorageConfigurationException' => 'Exception',
Make file storage more testable Summary: Fixes T2474. Adds a storage dummy storage engine for unit tests, and adds a couple of simple tests for basic file storage. Test Plan: Ran `arc unit` to execute unit tests. Reviewers: kwadwon Reviewed By: kwadwon CC: aran Maniphest Tasks: T2474 Differential Revision: https://secure.phabricator.com/D4777
2013-02-06 22:37:42 +01:00
'PhabricatorFileTestCase' => 'PhabricatorTestCase',
Files Generating Summary: Ref T2903 Test Plan: Files are being generating, albeit temporary. Reviewers: epriestley, AnhNhan Reviewed By: AnhNhan CC: aran, Korvin, AnhNhan, chad Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5801
2013-05-06 19:30:24 +02:00
'PhabricatorFileTestDataGenerator' => 'PhabricatorTestDataGenerator',
Basic image thumbnailing Summary: This is still very rough but provides basic support for generating image thumbnails. I need to separate stuff out a bit but I'm going to integrate into Maniphest before I hit the profile stuff so this seems like a reasonable starting point. Test Plan: Generated some image thumbnails in various sizes. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran CC: aran Differential Revision: 333
2011-05-22 23:40:51 +02:00
'PhabricatorFileTransformController' => 'PhabricatorFileController',
Phabricator file upload application.
2011-01-23 03:33:00 +01:00
'PhabricatorFileUploadController' => 'PhabricatorFileController',
Move Maniphest attached files section into textbox. Summary: Add a button to the Remarkup area that explains how to attach an image and remove the separate upload field. Test Plan: Check that the dialog pops up correctly and that dropping images onto the Remarkup area works. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T879 Differential Revision: https://secure.phabricator.com/D6049
2013-05-26 22:45:24 +02:00
'PhabricatorFileUploadDialogController' => 'PhabricatorFileController',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'PhabricatorFileUploadException' => 'Exception',
First go at Files settings. Summary: Based on @epriestley's https://secure.phabricator.com/differential/diff/9186/ plus others that seemed like they belong here. Test Plan: Saw the new settings show up in the web interface. Reviewers: epriestley, btrahan, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4425
2013-01-14 02:01:00 +01:00
'PhabricatorFilesConfigOptions' => 'PhabricatorApplicationConfigOptions',
Add a script to migrate files between storage engines Summary: Quora requested this (moving to S3) but it's also clearly a good idea. Test Plan: Ran with various valid/invalid options to test options. Error/sanity checking seemed OK. Migrated individual local files. Migrated all my local files back and forth between engines several times. Uploaded some new files. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran Maniphest Tasks: T1950 Differential Revision: https://secure.phabricator.com/D3808
2012-10-25 20:36:38 +02:00
'PhabricatorFilesManagementEnginesWorkflow' => 'PhabricatorFilesManagementWorkflow',
'PhabricatorFilesManagementMigrateWorkflow' => 'PhabricatorFilesManagementWorkflow',
Add a `bin/files purge` workflow Summary: We can lose file data through various means; one reasonable way is if files get deleted from disk with 'local-disk' storage. If data goes missing, Ref T3265. Also, reduce some code duplication. Test Plan: Ran `bin/files purge`, `bin/files migrate`, `bin/files rebuild` with various args. Deleted a file with "local-disk" storage, ran `bin/files purge`, made sure it got picked up. Reviewers: dctrwatson, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3265 Differential Revision: https://secure.phabricator.com/D6068
2013-05-29 15:28:57 +02:00
'PhabricatorFilesManagementPurgeWorkflow' => 'PhabricatorFilesManagementWorkflow',
Rename `bin/files metadata` to `bin/files rebuild` and let it rebuild MIME information Summary: See <https://github.com/facebook/phabricator/issues/320>. Files can end up with a bad MIME type, and we don't update it when uploading another copy of the file since obviously the new copy has the same data and thus the same MIME type. - Rename `bin/files metadata` to `bin/files rebuild` to make it a more consistent verb. - Let it rebuild MIME types so users who hit issues like this can run `bin/files rebuild --all --rebuild-mime` to straighten things out. Test Plan: Ran `bin/files` in various modes, examined output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5951
2013-05-17 19:00:31 +02:00
'PhabricatorFilesManagementRebuildWorkflow' => 'PhabricatorFilesManagementWorkflow',
Add a script to migrate files between storage engines Summary: Quora requested this (moving to S3) but it's also clearly a good idea. Test Plan: Ran with various valid/invalid options to test options. Error/sanity checking seemed OK. Migrated individual local files. Migrated all my local files back and forth between engines several times. Uploaded some new files. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran Maniphest Tasks: T1950 Differential Revision: https://secure.phabricator.com/D3808
2012-10-25 20:36:38 +02:00
'PhabricatorFilesManagementWorkflow' => 'PhutilArgumentWorkflow',
Add "Flags" to allow users to collect the things they love Summary: Flags are a personal collection of things you want to take a look at later. You can use several different colors and add notes. Not really sure if this is actually a good idea or not but it was easy to build. Planned features: - Allow Herald rules to add flags. - In the "edit flag" dialog, have a "[x] Subscribe Me" checkbox that CCs you. - Support Diffusion. - Support Phriction. - Always show flags on an object if you have them (in every view)? - Edit dialog feels a little heavy? - More filtering in /flag/ tool. - Add a top-level links somewhere? Test Plan: Added, edited and removed flags from things. Viewed flags in flag view. Reviewers: aran, btrahan Reviewed By: btrahan CC: aran, epriestley, Koolvin Maniphest Tasks: T1041 Differential Revision: https://secure.phabricator.com/D2024
2012-03-28 01:22:40 +02:00
'PhabricatorFlag' => 'PhabricatorFlagDAO',
'PhabricatorFlagColor' => 'PhabricatorFlagConstants',
'PhabricatorFlagController' => 'PhabricatorController',
'PhabricatorFlagDAO' => 'PhabricatorLiskDAO',
'PhabricatorFlagDeleteController' => 'PhabricatorFlagController',
'PhabricatorFlagEditController' => 'PhabricatorFlagController',
'PhabricatorFlagListController' => 'PhabricatorFlagController',
'PhabricatorFlagListView' => 'AphrontView',
Allow pastes to be flagged Summary: This does a few things: - Allows you to flag pastes. This is straightforward. - Allows Applications to register event listeners. - Makes object action lists emit a 'didrenderactions' event, so other applications can add more actions. The Flags application injects its action in this way. This should generally make it much easier to add actions to objects when we add new applications, with less code duplication and better modularity. We have a really hacky version of this in Differential that I want to get rid of in lieu of this more general approach. I'm going to make object lists do the same thing, so any application can jump in and add stuff. Test Plan: Flagged and unflagged pastes. Viewed home page, differential, flags list. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3377
2012-08-24 22:19:47 +02:00
'PhabricatorFlagsUIEventListener' => 'PhutilEventListener',
Add a datepicker control Summary: I looooove JS! It makes me giddy with glee! Test Plan: Picked dates. See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D2086
2012-04-04 21:14:10 +02:00
'PhabricatorFormExample' => 'PhabricatorUIExample',
Move GC into PHP and simplify it Summary: - Move GC options into PHP. - Remove the "run at" and "run for" options. The GC daemon doesn't actually do any table scans, is very gentle, and runs for like 3 seconds per day in any normal install. Just limit it to running once every 4 hours when it's caught up and call it a day. Test Plan: Edited GC options. Reviewers: btrahan, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4321
2013-01-02 23:03:08 +01:00
'PhabricatorGarbageCollectorConfigOptions' => 'PhabricatorApplicationConfigOptions',
Add a garbage collector daemon Summary: Phabricator generates a bunch of data that we don't need to keep around forever, add a GC daemon to get rid of it with some basic configuration options. This needs a couple more diffs to get some of the details but I think this is a reasonable start. I also fixed a couple of UI things related to this, e.g. the daemon logs page going crazy when a daemon gets stuck in a loop and dumps tons of data to stdout. Test Plan: - Ran gc daemon in 'phd debug' mode and saw it delete stuff, then sleep once it had cleaned everything up. - Mucked around with TTLs and verified they work correctly. - Viewed gc'd transcripts in the web interface and made sure they displayed okay. - Viewed daemon logs before/after garbage collection. - Running some run-at / run-for tests now, I'll update if the daemon doesn't shut off in ~10-15 minutes. :P Reviewed By: tuomaspelkonen Reviewers: jungejason, tuomaspelkonen, aran CC: aran, tuomaspelkonen, epriestley Differential Revision: 583
2011-07-03 18:47:31 +02:00
'PhabricatorGarbageCollectorDaemon' => 'PhabricatorDaemon',
Add support for device swipe events Summary: Ref T2700. Allow JS to listen for swipes on devices. There are a bunch of tricky cases here and I probably didn't get them all totally right, but this interaction broadly looks like this: - We implement gesture recognition for the mouse in device modes (narrow browser), and for touch events from an actual device. - The sigil `touchable` indicates that a node wants to react to touch events. - When the user touches a `touchable` node, we start listening for moves. They might be tapping/clicking (in which case we don't care), but they might also be gesturing. - Once the user moves their finger/pointer far enough away from the tap origin, we recognize it as a gesture. I hardcoded this at 20px; I wasn't able to find any "official" Apple value, but 20px seems like a common default. - At this point, we look at where their finger has moved. - If they moved it mostly up/down, we interpret the gesture as "scroll" and just stop listening. The device does its own thing. - However, if they moved it mostly left/right, we interpret it as a "swipe". We start killing the moves so the device doesn't scroll. - Once we've recognized that a gesture is underway, we send a "gesture.swipe.start" event and then "gesture.swipe.move" events for every move. - When the user ends the gesture, we send "gesture.swipe.end". - If the user cancels the gesture (currently, only by tapping with a second finger), we send "gesture.swipe.cancel". - Gesture events have raw position data and some convenience fields. Test Plan: Wrote UI example and used it from the Desktop, iPhone simulator, and a real iphone. - The code always seems to get "scroll" vs "swipe" correct (i.e., consistent with my intentions). - The threshold feels pretty good to me. - Tapping with a second finger cancels the action. Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T2700 Differential Revision: https://secure.phabricator.com/D5308
2013-03-09 22:53:15 +01:00
'PhabricatorGestureExample' => 'PhabricatorUIExample',
Add Disqus, Facebook, Google, GitHub auth config; AWS config Summary: Also improve behavior for the "unknown config" warning. Test Plan: Looked at configs, went through unknown config workflow. Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4310
2013-01-01 23:09:29 +01:00
'PhabricatorGitHubConfigOptions' => 'PhabricatorApplicationConfigOptions',
Implement a MySQL-backed global lock Summary: Implementation is a little crazy but this seems to work as advertised. Test Plan: Acquired locks with "lock.php". Verified they held as long as the process reamined open and released properly on kill -9, ^C, etc. Reviewers: nh, jungejason, vrana, btrahan, Girish, edward Reviewed By: btrahan CC: aran Maniphest Tasks: T1400 Differential Revision: https://secure.phabricator.com/D2864
2012-06-27 22:59:12 +02:00
'PhabricatorGlobalLock' => 'PhutilLock',
Modernize file uploads Summary: Modernizes file uploads. In particular: - Adds a mobile menu, with an "Upload File" item. - Adds crumbs to the list view, detail view and upload view. - Adds "Upload File" action to crumbs. - Moves upload file to a separate page. - Removes the combined upload file + recent files page. - Makes upload file use a normal file control by default (works on mobile). - Home page, file list and file upload page are now global drop targets which accept files dropped anywhere on them. Dragging a file into the window shows a mask and an instructional message. - User education on this is a little weak but I think that's a big can of worms? - Fixes a bug where dropping multiple files into a Remarkup text area produced bad results (resolves T2190). T879 is related, although it's specifically about Maniphest. I've declined to make global drop targets yet there because there are multiple drop targets on the page with different meanings. That UI needs updating in general. @chad, do we have an "upload" icon (counterpart to "download")? Test Plan: Uploaded files in Maniphest, Differential, Files, and from Home. Dragged and dropped multiple files into Differential. Used crumbs, mobile. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2190 Differential Revision: https://secure.phabricator.com/D4200
2012-12-17 01:34:01 +01:00
'PhabricatorGlobalUploadTargetView' => 'AphrontView',
Add Disqus, Facebook, Google, GitHub auth config; AWS config Summary: Also improve behavior for the "unknown config" warning. Test Plan: Looked at configs, went through unknown config workflow. Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4310
2013-01-01 23:09:29 +01:00
'PhabricatorGoogleConfigOptions' => 'PhabricatorApplicationConfigOptions',
Add PhabricatorHash::digestForIndex() Summary: Does this seem reasonable? It's a bit more compact than digest() (6 bits / byte instead of 4 bits / byte) and 72 bits of entropy @ 12 bytes instead of 128 bits of entropy @ 32 bytes. I feel like it's important to preserve the printability, though, and this seemed like a fairly good balance of concerns. Test Plan: unit tests Reviewers: vrana Reviewed By: vrana CC: aran, yemao932 Differential Revision: https://secure.phabricator.com/D4253
2012-12-21 14:43:33 +01:00
'PhabricatorHashTestCase' => 'PhabricatorTestCase',
Modernize Paste Summary: - Add a PhabricatorApplication. - Make most of the views work well on tablets / phones. The actual "Create" form doesn't, but everything else is good -- need to make device-friendly form layouts before I can do the form. Test Plan: Will attach screenshots. Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3293
2012-08-15 19:45:06 +02:00
'PhabricatorHeaderView' => 'AphrontView',
Provide basic structure for keyboard shortcuts Summary: Implements a simple infrastructure for keyboard shortcuts, see T184, and a "help" shortcut. There's a lot of room for refinement here but I think it basically works. Each shortcut can also provide a "tooltip" handler which allows it to show help when the alt/option key is held down. Test Plan: Pressed "?" and got help. Pressed "?" in various contexts where it should not activate (modifier keys, text input focused) and didn't get help. Reviewers: aran, tuomaspelkonen, jungejason CC: moskov Differential Revision: 362
2011-05-28 20:36:00 +02:00
'PhabricatorHelpController' => 'PhabricatorController',
'PhabricatorHelpKeyboardShortcutController' => 'PhabricatorHelpController',
First pass at hovercard design Summary: Refs T1048 - I'm pretty happy and happy to tell you Savepoint CR Everything's dummy right now. If you are testing locally, don't forget to edit the PHIDs. Or populate your own handles. Doesn't really matter. I'm mainly sending it in for the CSS, not the messy PHP code. Ignore the `margin: auto`, that's just for looking nice. Test Plan: UI Example » Hovercard Reviewers: epriestley, chad CC: aran, Korvin Maniphest Tasks: T1048 Differential Revision: https://secure.phabricator.com/D5519
2013-04-02 18:15:33 +02:00
'PhabricatorHovercardExample' => 'PhabricatorUIExample',
'PhabricatorHovercardView' => 'AphrontView',
Very basic IRC Bot Summary: This is sort of a silly/fun project but I think there's some utility. For example, mroch added some handlers to an eggdrop or something similar to look for "D12345" and print out the title/link, which was actually pretty useful. We could also add logging here and subsume the more-or-less unowned Facebook tool that does the same thing, especially since we can get a bunch of good stuff it doesn't support (like search) more or less for free. This is also an easy way to provide some example code for writing Conduit system agents. This is a minimal implementation which creates a bot that connects to a hard-coded server and sits there indefinitely. Next steps: - Add conduit/sysagent support - Write differential/maniphest/diffusion handlers - Move configuration to the web interface (?) and integrate with phd - Write a logging handler? Test Plan: Ran bot with "exec_daemon.php", it connected to the hard-coded server and sat there indefinitely. Reviewed By: aran Reviewers: codeblock, mroch, tuomaspelkonen, aran, jungejason CC: aran, epriestley Differential Revision: 283
2011-05-15 18:29:48 +02:00
'PhabricatorIRCBot' => 'PhabricatorDaemon',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorIRCProtocolAdapter' => 'PhabricatorBaseProtocolAdapter',
'PhabricatorIRCProtocolHandler' => 'PhabricatorBotHandler',
Add test to check all symbols can be loaded Summary: make sure all symboles can be loaded to avoid issues like missing methods in descendants of abstract base class. Test Plan: ran it and verified it passes; remove a method in a descendant class and verified that the test failed. Reviewers: epriestley, nh Reviewed By: nh CC: aran, nh, jungejason Differential Revision: 1023
2011-10-20 03:26:21 +02:00
'PhabricatorInfrastructureTestCase' => 'PhabricatorTestCase',
Add inline comments to Diffusion/Audit Summary: - Add inline comments to Audits, like Differential. - Creates new storage for the comments in the Audits database. - Creates a new PhabricatorAuditInlineComment class, similar to DifferentialInlineComment. - Defines an Interface which Differential and Audit comments conform to. - Makes consumers of DifferentialInlineComments consume objects which implement that interface instead. - Adds save NOTE: Some features are still missing! Wanted to cut this off before it got crazy: - Inline comments aren't shown in the main comment list. - Inline comments aren't shown in the emails. - Inline comments aren't previewed. I'll followup with those but this was getting pretty big. @vrana, does the SQL change look correct? Test Plan: - Created, edited, deleted, replied to, reloaded and saved inline comments in Diffusion, on the left and right side of diffs. - Created, edited, deleted, replied to, reloaded and saved inline comments in Differentila, on the left and right side of primary and diff-versus-diff diffs. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1898
2012-03-14 20:56:01 +01:00
'PhabricatorInlineCommentController' => 'PhabricatorController',
Simplify lightboxing and fix a few things Summary: Minor tweaks to lightboxes. - With "position: fixed;", we don't need to do any of the scroll/resize stuff. Just remove it. - Make the lightbox go over the menu bar -- was it intentional that it wasn't? - Make 'jx-mask' use "position: fixed;" too. - Add a loading indicator. - In Differential/Maniphest/etc, a preview may bring in an image but won't bring in the CSS we need. The "real" fix is to ship CSS/JS with ajax, but that's really hard -- fake it by pulling in the right CSS any time we render a remarkup area. I'm going to do a couple of other tweaks here but need to update JX.Mask. Test Plan: Verified behavior is reasonable in Safari, Firefox, Chrome with multiple images / scroll / previews / resize. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1896 Differential Revision: https://secure.phabricator.com/D3795
2012-10-24 02:34:43 +02:00
'PhabricatorInlineCommentInterface' => 'PhabricatorMarkupInterface',
Make inline comment preview work in Diffusion Summary: created a PhabricatorInlineCommentPreviewController so controllers in Diffusion and Differential respectively just have to handle the URI mapping and data loading like good little controllers. Test Plan: left inline comments on commits, deleted inline commits, submitted inline comments -- all worked well did the same on some diffs Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1176 Differential Revision: https://secure.phabricator.com/D3034
2012-07-23 20:01:28 +02:00
'PhabricatorInlineCommentPreviewController' => 'PhabricatorController',
Separate the inline comment summary element into a separate view Summary: - Affects the "Inline Comments" summary table which appears in comments that have attached inlines in the discussion threads in Differential. - Prepares for inclusion in Diffusion. - No application changes (minor CSS), just factors code better. - Simplify/separate CSS. Test Plan: Looked at on-diff and off-diff comment summaries in Differential, display looked correct. Reviewers: davidreuss, nh, btrahan Reviewed By: davidreuss CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1928
2012-03-20 03:45:16 +01:00
'PhabricatorInlineSummaryView' => 'AphrontView',
Bring Javelin into Phabricator via git submodule, not copy-and-paste Summary: Javelin is currently embedded in Phabricator via copy-and-paste of prebuilt packages. This is not so great. Pull it in as a submodule instead and make all the Phabriator resources declare proper dependency trees. Add Javelin linting. Test Plan: I tried to run through pretty much all the JS functionality on the site. This is still a high-risk change, but I did a pretty thorough test Differential: inline comments, revealing diffs, list tokenizers, comment preview, editing/deleting comments, add review action. Maniphest: list tokenizer, comment actions Herald: rule editing, tokenizers, add/remove rows Reviewed By: tomo Reviewers: aran, tomo, mroch, jungejason, tuomaspelkonen CC: aran, tomo, epriestley Differential Revision: 223
2011-05-04 00:11:55 +02:00
'PhabricatorJavelinLinter' => 'ArcanistLinter',
Implement a more compact, general database-backed key-value cache Summary: See discussion in D4204. Facebook currently has a 314MB remarkup cache with a 55MB index, which is slow to access. Under the theory that this is an index size/quality problem (the current index is on a potentially-384-byte field, with many keys sharing prefixes), provide a more general index with fancy new features: - It implements PhutilKeyValueCache, so it can be a component in cache stacks and supports TTL. - It has a 12-byte hash-based key. - It automatically compresses large blocks of data (most of what we store is highly-compressible HTML). Test Plan: - Basics: - Loaded /paste/, saw caches generate and save. - Reloaded /paste/, saw the page hit cache. - GC: - Ran GC daemon, saw nothing. - Set maximum lifetime to 1 second, ran GC daemon, saw it collect the entire cache. - Deflate: - Selected row formats from the database, saw a mixture of 'raw' and 'deflate' storage. - Used profiler to verify that 'deflate' is fast (12 calls @ 220us on my paste list). - Ran unit tests Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D4259
2012-12-21 23:17:56 +01:00
'PhabricatorKeyValueDatabaseCache' => 'PhutilKeyValueCache',
Move LDAP config into PHP Summary: This config section is weak (poorly documented) and inconsistent (keys with "_" instead of "-") but I'm going to keep punting on improving it until after T1536. Test Plan: Loaded, examined LDAP config. Reviewers: btrahan, codeblock Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4322
2013-01-02 23:04:05 +01:00
'PhabricatorLDAPConfigOptions' => 'PhabricatorApplicationConfigOptions',
Made it possible to login using LDAP Summary: Made it possible to link and unlink LDAP accounts with Phabricator accounts. Test Plan: I've tested this code locally and in production where I work. I've tried creating an account from scratch by logging in with LDAP and linking and unlinking an LDAP account with an existing account. I've tried to associate the same LDAP account with different Phabricator accounts and it failed as expected. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, auduny, svemir Maniphest Tasks: T742 Differential Revision: https://secure.phabricator.com/D2722
2012-06-13 17:52:05 +02:00
'PhabricatorLDAPLoginController' => 'PhabricatorAuthController',
'PhabricatorLDAPRegistrationController' => 'PhabricatorAuthController',
Prevent the ability to scrape for valid usernames - return the same error message when either bind or the username search fails to find a user - config variables should use hypen and not underscore
2012-07-26 23:32:51 +02:00
'PhabricatorLDAPUnknownUserException' => 'Exception',
Made it possible to login using LDAP Summary: Made it possible to link and unlink LDAP accounts with Phabricator accounts. Test Plan: I've tested this code locally and in production where I work. I've tried creating an account from scratch by logging in with LDAP and linking and unlinking an LDAP account with an existing account. I've tried to associate the same LDAP account with different Phabricator accounts and it failed as expected. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, auduny, svemir Maniphest Tasks: T742 Differential Revision: https://secure.phabricator.com/D2722
2012-06-13 17:52:05 +02:00
'PhabricatorLDAPUnlinkController' => 'PhabricatorAuthController',
Bring Javelin into Phabricator via git submodule, not copy-and-paste Summary: Javelin is currently embedded in Phabricator via copy-and-paste of prebuilt packages. This is not so great. Pull it in as a submodule instead and make all the Phabriator resources declare proper dependency trees. Add Javelin linting. Test Plan: I tried to run through pretty much all the JS functionality on the site. This is still a high-risk change, but I did a pretty thorough test Differential: inline comments, revealing diffs, list tokenizers, comment preview, editing/deleting comments, add review action. Maniphest: list tokenizer, comment actions Herald: rule editing, tokenizers, add/remove rows Reviewed By: tomo Reviewers: aran, tomo, mroch, jungejason, tuomaspelkonen CC: aran, tomo, epriestley Differential Revision: 223
2011-05-04 00:11:55 +02:00
'PhabricatorLintEngine' => 'PhutilLintEngine',
First Diff of Test Data Generator Summary: Progress to fix T2903 Test Plan: Ran './bin/lipsum help' and 'generate' workflows. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5672
2013-04-12 23:07:15 +02:00
'PhabricatorLipsumGenerateWorkflow' => 'PhabricatorLipsumManagementWorkflow',
'PhabricatorLipsumManagementWorkflow' => 'PhutilArgumentWorkflow',
Add a basic random image generator Summary: Adds an abstract base class for random image generation. Implements a concrete subclass for generating Mondrian-like images. Test Plan: {F40759} {F40760} {F40761} {F40762} {F40763} Reviewers: DeedyDas, AnhNhan Reviewed By: AnhNhan CC: chad, aran Differential Revision: https://secure.phabricator.com/D5705
2013-04-16 17:19:45 +02:00
'PhabricatorLipsumMondrianArtist' => 'PhabricatorLipsumArtist',
More phabricator organizational stuff.
2011-01-23 02:48:55 +01:00
'PhabricatorLiskDAO' => 'LiskDAO',
Allow Phabricator storage engines to be extended and configured Summary: See T344. Currently, there's a hard-coded 12MB filesize limit and some awkward interactions with MySQL's max_allowed_packet. Make this system generally more robust: - Move the upload limit to configuration. - Add setup steps which reconcile max_allowed_packet vs MySQL file storage limits. - Add a layer of indirection between uploading files and storage engines. - Allow the definition of new storage engines. - Define a local disk storage engine. - Add a "storage engine selector" class which manages choosing which storage engines to put files in. - Document storage engines. - Document file storage classes. Test Plan: Setup mode: - Disabled MySQL storage engine, misconfigured it, configured it correctly. - Disabled file storage engine, set it to something invalid, set it to something valid. - Verified max_allowed_packet is read correctly. Application mode: - Configured local file storage. - Uploaded large and small files. - Verified larger files were written to local storage. - Verified smaller files were written to MySQL blob storage. Documentation: - Read documentation. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, epriestley, jungejason Differential Revision: 695
2011-07-20 07:48:38 +02:00
'PhabricatorLocalDiskFileStorageEngine' => 'PhabricatorFileStorageEngine',
Improve time localization code Summary: - We throw on a missing date right now, in the DateTime constructor. This can happen in reasonable cases and this is display code, so handle it more gracefully (see T520). - This stuff is a little slow and we sometimes render many hundreds of dates per page. I've been seeing it in profiles on and off. Memoize timezones to improve performance. - Some minor code duplication that would have become less-minor with the constructor change, consolidate the logic. - Add some unit tests and a little documentation. Test Plan: - Ran unit tests. - Profiled 1,000 calls to phabricator_datetime(), cost dropped from ~49ms to ~19ms with addition of memoization. This is still slower than I'd like but I don't think there's an easy way to squeeze it down further. Reviewers: ajtrichards, jungejason, nh, tuomaspelkonen, aran Reviewed By: ajtrichards CC: aran, ajtrichards, epriestley Differential Revision: 966
2011-09-27 18:03:55 +02:00
'PhabricatorLocalTimeTestCase' => 'PhabricatorTestCase',
Authentication
2011-01-26 22:21:12 +01:00
'PhabricatorLoginController' => 'PhabricatorAuthController',
Validate logins, and simplify email password resets Summary: - There are some recent reports of login issues, see T755 and T754. I'm not really sure what's going on, but this is an attempt at getting some more information. - When we login a user by setting 'phusr' and 'phsid', send them to /login/validate/ to validate that the cookies actually got set. - Do email password resets in two steps: first, log the user in. Redirect them through validate, then give them the option to reset their password. - Don't CSRF logged-out users. It technically sort of works most of the time right now, but is silly. If we need logged-out CSRF we should generate it in some more reliable way. Test Plan: - Logged in with username/password. - Logged in with OAuth. - Logged in with email password reset. - Sent bad values to /login/validate/, got appropriate errors. - Reset password. - Verified next_uri still works. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, btrahan, j3kuntz Maniphest Tasks: T754, T755 Differential Revision: https://secure.phabricator.com/D1353
2012-01-10 23:42:07 +01:00
'PhabricatorLoginValidateController' => 'PhabricatorAuthController',
CSRF / Logout
2011-01-31 03:52:29 +01:00
'PhabricatorLogoutController' => 'PhabricatorAuthController',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorMacroCommentController' => 'PhabricatorMacroController',
MetaMTA: Owners, Pholio, Macro Summary: Port MetaMTA options for Owners, Pholio and Macro. At some point I'd like to get rid of all these options (provide one "reply domain", and not allow overrides of reply handlers -- use events instead) but that's a battle we can fight later. Test Plan: Looked at options, looked at setup issues, edited something. Reviewers: codeblock, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4469
2013-01-16 19:52:30 +01:00
'PhabricatorMacroConfigOptions' => 'PhabricatorApplicationConfigOptions',
Move "Macros" to a first-class application Summary: This is mostly to unblock D3547. - Move "Macros" to a first-class application called "Macros". - After D3547, this application will also house "Memes" (macros with text on them). - This will also make them easier to find; the top navigational query I field is "where are image macros?" nowadays, since it's not intuitive they're part of files. - This makes some of the UI mobile-aware but doesn't set the `device` flag yet, since there are still some missing pieces. - I'll separate storage out and continue modernizing the UI as we unblock and integrate D3547. Test Plan: Created, edited and deleted macros. Viewed files. Reviewers: btrahan, vrana, teisenbe Reviewed By: vrana CC: aran Maniphest Tasks: T175 Differential Revision: https://secure.phabricator.com/D3572
2012-10-01 23:04:03 +02:00
'PhabricatorMacroController' => 'PhabricatorController',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorMacroDisableController' => 'PhabricatorMacroController',
Move "Macros" to a first-class application Summary: This is mostly to unblock D3547. - Move "Macros" to a first-class application called "Macros". - After D3547, this application will also house "Memes" (macros with text on them). - This will also make them easier to find; the top navigational query I field is "where are image macros?" nowadays, since it's not intuitive they're part of files. - This makes some of the UI mobile-aware but doesn't set the `device` flag yet, since there are still some missing pieces. - I'll separate storage out and continue modernizing the UI as we unblock and integrate D3547. Test Plan: Created, edited and deleted macros. Viewed files. Reviewers: btrahan, vrana, teisenbe Reviewed By: vrana CC: aran Maniphest Tasks: T175 Differential Revision: https://secure.phabricator.com/D3572
2012-10-01 23:04:03 +02:00
'PhabricatorMacroEditController' => 'PhabricatorMacroController',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorMacroEditor' => 'PhabricatorApplicationTransactionEditor',
Implement generalized application search in Macros Summary: Ref T2625. Works out the last kinks of generalization and gives Macros the more powerful new query engine. Overall, this feels pretty good to me. Test Plan: Executed, saved and edited a bunch of Macro queries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6078
2013-05-30 23:09:37 +02:00
'PhabricatorMacroListController' =>
array(
0 => 'PhabricatorMacroController',
1 => 'PhabricatorApplicationSearchResultsControllerInterface',
),
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorMacroMailReceiver' => 'PhabricatorObjectMailReceiver',
Made Meme Generator Summary: Fixed T2353 Test Plan: Checked whether same text generated the same URL Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2353 Differential Revision: https://secure.phabricator.com/D4551
2013-01-20 03:43:35 +01:00
'PhabricatorMacroMemeController' => 'PhabricatorMacroController',
Create a basic meme dialog Summary: Simple dialog for creating memes. We can add more features (typeahead, selection thumbs, preview) later. Test Plan: {F29815} Reviewers: DeedyDas, chad Reviewed By: chad CC: aran Maniphest Tasks: T2353 Differential Revision: https://secure.phabricator.com/D4557
2013-01-22 03:46:04 +01:00
'PhabricatorMacroMemeDialogController' => 'PhabricatorMacroController',
Adding some filters and queries to Macro application Summary: Fixes T2778 Introduces `PhabricatorMacroQuery`, which should consolidate all queries regarding macros Adds `PolicyInterface` to `PhabricatorImageMacro`, as else the query would fail (we should consider adding it to the ApplicationTransaction instead, if that was ever planned) Adds `Active Macros` filter, making it the default Adds `My Macros` filter. You may ask why it overwrites `$authors`. Well, I did not want the page jump to the conclusion that it is a search result. It //is// one more or less, but the filter would jump to `seach` instead of `my`. If you want `My Macros` removed, tell me. It is useful only to heavy-macro-uploaders-and-users though. Five or six people in `http://secure.phabricator.(org|com)`, and an estimated dozen and a half at bigger installs. Test Plan: created multiple macros from multiple authors, disabled them at will. browsed around, verified that Macros only appeared in the right filters and that nothing else broke. Reviewers: epriestley, chad, btrahan CC: aran, Korvin Maniphest Tasks: T2778 Differential Revision: https://secure.phabricator.com/D5409
2013-03-22 17:46:21 +01:00
'PhabricatorMacroQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorMacroReplyHandler' => 'PhabricatorMailReplyHandler',
Implement generalized application search in Macros Summary: Ref T2625. Works out the last kinks of generalization and gives Macros the more powerful new query engine. Overall, this feels pretty good to me. Test Plan: Executed, saved and edited a bunch of Macro queries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6078
2013-05-30 23:09:37 +02:00
'PhabricatorMacroSearchEngine' => 'PhabricatorApplicationSearchEngine',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorMacroTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorMacroTransactionComment' => 'PhabricatorApplicationTransactionComment',
'PhabricatorMacroTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'PhabricatorMacroViewController' => 'PhabricatorMacroController',
Very basic daemon infrastructure, plus MetaMTA daemon. Summary: Amazon SES seems to be working well, except that it takes more than a second to send mail in-process. Kick it out of process. (Between this and the ImplementationAdapter layer, MetaMTA almost makes sense. :/) Test Plan: Ran the daemon and got a flood of unsent test email. Reviewers: CC:
2011-02-10 02:39:55 +01:00
'PhabricatorMailImplementationAmazonSESAdapter' => 'PhabricatorMailImplementationPHPMailerLiteAdapter',
Support SMTP as the mailer. Summary: Support SMTP as the mailer and user could turn on SMTP authentication if needed. Import PHPMailer as PHPMailerLite doesn't support SMTP. Make class PhabricatorMailImplementationPHPMailerAdapter final. Test Plan: N/A Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2139 Differential Revision: https://secure.phabricator.com/D4063
2012-12-09 11:36:40 +01:00
'PhabricatorMailImplementationPHPMailerAdapter' => 'PhabricatorMailImplementationAdapter',
PHPMailerLite
2011-01-26 18:33:31 +01:00
'PhabricatorMailImplementationPHPMailerLiteAdapter' => 'PhabricatorMailImplementationAdapter',
Add support for SendGrid as an outbound mail adapter Summary: SendGrid is a popular mail delivery platform, similar to Amazon SES. Provide support for delivering email via their REST API. Test Plan: Created a SendGrid account, configured my local install to use it, sent some mail, received mail. Reviewers: tuomaspelkonen, jungejason, aran CC: ccheever Differential Revision: 347
2011-05-26 19:00:26 +02:00
'PhabricatorMailImplementationSendGridAdapter' => 'PhabricatorMailImplementationAdapter',
Fix a threading issue with Amazon SES Summary: Amazon SES does not allow us to set a Message-ID header, which means that threads are incorrect in Mail.app (and presumably other applications which respect In-Reply-To and References) because the initial email does not have anything which attaches it to the rest of the thread. To fix this, never rely on Message-ID if the mailer doesn't support Message-ID. (In the Amazon SES case, Amazon generates its own Message-ID which we can't know ahead of time). I additionally used all the Lisk isolation from the other tests to make this testable and wrote tests for it. I also moved the idea of a thread ID lower in the stack and out of DifferentialMail, which should not be responsible for implementation details. NOTE: If you push this, it will cause a one-time break of threading for everyone using Outlook since I've changed the seed for generating Thread-Index. I feel like this is okay to avoid introducing more complexity here. Test Plan: Created and then updated a revision, messages delivered over Amazon SES threaded correctly in Mail.app. Verified headers. Unit tests. Reviewed By: rm Reviewers: aran, tuomaspelkonen, jungejason, rm Commenters: aran CC: aran, rm, epriestley Differential Revision: 195
2011-04-30 20:47:00 +02:00
'PhabricatorMailImplementationTestAdapter' => 'PhabricatorMailImplementationAdapter',
Introduce basic `bin/mail` with a `resend` workflow Summary: Fixes T2458. Ref T2843. @tido's email from T2843 has exhausted its retries and failed, but we want to try it again with the patch from D5464 to capture the actual error. This sort of thing has come up a few times in debugging, too. Also fixed some stuff that came up while debugging this. Test Plan: - Ran command with no args. - Ran resend with no args. - Ran resend with bad IDs. - Ran resend with already-queued messages, got "already queued" error. - Ran resend with already-sent message, got requeue. Reviewers: btrahan, tido Reviewed By: tido CC: aran Maniphest Tasks: T2458, T2843 Differential Revision: https://secure.phabricator.com/D5493
2013-03-30 23:53:49 +01:00
'PhabricatorMailManagementResendWorkflow' => 'PhabricatorSearchManagementWorkflow',
Provide some diagnostic tools for examining inbound and outbound mail Summary: We can't show this stuff on the web UI because it has password reset links and private reply-to addresses, but we can provide easier CLI tools than "root around in the database". Land a rough version of `bin/mail show-inbound` and `bin/mail show-outbound`. Test Plan: Used both commands to examine mail from the CLI. Reviewers: btrahan Reviewed By: btrahan CC: tido, euresti, aran Differential Revision: https://secure.phabricator.com/D5963
2013-05-20 19:13:42 +02:00
'PhabricatorMailManagementShowInboundWorkflow' => 'PhabricatorSearchManagementWorkflow',
'PhabricatorMailManagementShowOutboundWorkflow' => 'PhabricatorSearchManagementWorkflow',
Introduce basic `bin/mail` with a `resend` workflow Summary: Fixes T2458. Ref T2843. @tido's email from T2843 has exhausted its retries and failed, but we want to try it again with the patch from D5464 to capture the actual error. This sort of thing has come up a few times in debugging, too. Also fixed some stuff that came up while debugging this. Test Plan: - Ran command with no args. - Ran resend with no args. - Ran resend with bad IDs. - Ran resend with already-queued messages, got "already queued" error. - Ran resend with already-sent message, got requeue. Reviewers: btrahan, tido Reviewed By: tido CC: aran Maniphest Tasks: T2458, T2843 Differential Revision: https://secure.phabricator.com/D5493
2013-03-30 23:53:49 +01:00
'PhabricatorMailManagementWorkflow' => 'PhutilArgumentWorkflow',
Add unit tests to cover PhabricatorMailReceiver::matchAddresses() Summary: Ref T3183. We should accept addresses like `"New Bug" <bugs@example.com>` to match `bugs@example.com`. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3183 Differential Revision: https://secure.phabricator.com/D5923
2013-05-15 00:04:17 +02:00
'PhabricatorMailReceiverTestCase' => 'PhabricatorTestCase',
Moderize Mailing Lists Summary: Attempting to learn how to 'modernize' apps so I can update things. Adds a sidenav, crumbs, and views. Test Plan: Tested creating lists on web and mobile. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4598
2013-01-24 01:36:21 +01:00
'PhabricatorMailingListsController' => 'PhabricatorController',
'PhabricatorMailingListsEditController' => 'PhabricatorMailingListsController',
'PhabricatorMailingListsListController' => 'PhabricatorMailingListsController',
Switch to new menubar Summary: - Looks better (can probably still use some tweaks), especially search. - Moves logout from weird footer location to main menu. - Reactive: on tablets and phones, the menu adjusts to remain useful. - Fixed position on desktops for future side nav changes. - Adds an icon header thing that's currently hard-coded but will be application-driven soon. Test Plan: Used menu on desktop, tablet, phone, logged in / logged out, toggled darkconsole. Will add some screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3105
2012-07-31 01:09:14 +02:00
'PhabricatorMainMenuGroupView' => 'AphrontView',
'PhabricatorMainMenuIconView' => 'AphrontView',
'PhabricatorMainMenuSearchView' => 'AphrontView',
'PhabricatorMainMenuView' => 'AphrontView',
Port Maniphest options. Test Plan: Viewed the new options. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4401
2013-01-11 19:24:35 +01:00
'PhabricatorManiphestConfigOptions' => 'PhabricatorApplicationConfigOptions',
Fixed Task Generation Summary: Ref T2903 Test Plan: Successfully generated tasks with authors and owners. Reviewers: epriestley, AnhNhan Reviewed By: epriestley CC: aran, Korvin, AnhNhan, chad Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5704
2013-04-25 03:17:30 +02:00
'PhabricatorManiphestTaskTestDataGenerator' => 'PhabricatorTestDataGenerator',
Add a generic multistep Markup cache Summary: The immediate issue this addresses is T1366, adding a rendering cache to Phriction. For wiki pages with code blocks especially, rerendering them each time is expensive. The broader issue is that out markup caches aren't very good right now. They have three major problems: **Problem 1: the data is stored in the wrong place.** We currently store remarkup caches on objects. This means we're always loading it and passing it around even when we don't need it, can't genericize cache management code (e.g., have one simple script to drop/GC caches), need to update authoritative rows to clear caches, and can't genericize rendering code since each object is different. To solve this, I created a dedicated cache database that I plan to move all markup caches to use. **Problem 2: time-variant rules break when cached.** Some rules like `**bold**` are time-invariant and always produce the same output, but some rules like `{Tnnn}` and `@username` are variant and may render differently (because a task was closed or a user is on vacation). Currently, we cache the raw output, so these time-variant rules get locked at whatever values they had when they were first rendered. This is the main reason Phriction doesn't have a cache right now -- I wanted `{Tnnn}` rules to reflect open/closed tasks. To solve this, I split markup into a "preprocessing" phase (which does all the parsing and evaluates all time-invariant rules) and a "postprocessing" phase (which evaluates time-variant rules only). The preprocessing phase is most of the expense (and, notably, includes syntax highlighting) so this is nearly as good as caching the final output. I did most of the work here in D737 / D738, but we never moved to use it in Phabricator -- we currently just do the two operations serially in all cases. This diff splits them apart and caches the output of preprocessing only, so we benefit from caching but also get accurate time-variant rendering. **Problem 3: cache access isn't batched/pipelined optimally.** When we're rendering a list of markup blocks, we should be able to batch datafetching better than we do. D738 helped with this (fetching is batched within a single hunk of markup) and this improves batching on cache access. We could still do better here, but this is at least a step forward. Also fixes a bug with generating a link in the Phriction history interface ($uri gets clobbered). I'm using PHP serialization instead of JSON serialization because Remarkup does some stuff with non-ascii characters that might not survive JSON. Test Plan: - Created a Phriction document and verified that previews don't go to cache (no rows appear in the cache table). - Verified that published documents come out of cache. - Verified that caches generate/regenerate correctly, time-variant rules render properly and old documents hit the right caches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1366 Differential Revision: https://secure.phabricator.com/D2945
2012-07-10 00:20:56 +02:00
'PhabricatorMarkupCache' => 'PhabricatorCacheDAO',
Provide a concrete class for one-off remarkup blocks Summary: I want to use some of these for instructional text in Diffusion. Provide a concrete class to make one-offs cacheable and switch Releeph to use it. Test Plan: {F44175} Reviewers: btrahan, chad, edward Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6032
2013-05-24 21:37:53 +02:00
'PhabricatorMarkupOneOff' => 'PhabricatorMarkupInterface',
Implement all remaining config options Summary: Resolves T2255. Test Plan: Looked at mail options. Saw no remaining "Setup Issues". Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4477
2013-01-17 00:06:39 +01:00
'PhabricatorMetaMTAConfigOptions' => 'PhabricatorApplicationConfigOptions',
MetaMTA
2011-01-26 02:40:21 +01:00
'PhabricatorMetaMTAController' => 'PhabricatorController',
'PhabricatorMetaMTADAO' => 'PhabricatorLiskDAO',
Fix reply email parsing for linebreaks in "On <date>, <user> wrote:" quote identifier Summary: Move the parser to a separate class so it can be easily unit tested, add some tests. Properly parse emails with linebreaks in the quote line. Test Plan: Ran unit tests, used mail receiver to reply to an object. Reviewed By: cadamo Reviewers: aran, jungejason, tuomaspelkonen, cadamo CC: aran, cadamo, epriestley Differential Revision: 392
2011-06-01 17:33:14 +02:00
'PhabricatorMetaMTAEmailBodyParserTestCase' => 'PhabricatorTestCase',
MetaMTA
2011-01-26 02:40:21 +01:00
'PhabricatorMetaMTAListController' => 'PhabricatorMetaMTAController',
'PhabricatorMetaMTAMail' => 'PhabricatorMetaMTADAO',
Centralize rendering of application mail bodies Summary: This is a minor quality-of-life improvement to prevent D2968 from being as nasty as it is. Test Plan: Ran unit tests; generated Differential, Maniphest and Diffusion emails and verified the bodies looked sensible. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran Maniphest Tasks: T931 Differential Revision: https://secure.phabricator.com/D2986
2012-07-17 04:01:43 +02:00
'PhabricatorMetaMTAMailBodyTestCase' => 'PhabricatorTestCase',
Fix a threading issue with Amazon SES Summary: Amazon SES does not allow us to set a Message-ID header, which means that threads are incorrect in Mail.app (and presumably other applications which respect In-Reply-To and References) because the initial email does not have anything which attaches it to the rest of the thread. To fix this, never rely on Message-ID if the mailer doesn't support Message-ID. (In the Amazon SES case, Amazon generates its own Message-ID which we can't know ahead of time). I additionally used all the Lisk isolation from the other tests to make this testable and wrote tests for it. I also moved the idea of a thread ID lower in the stack and out of DifferentialMail, which should not be responsible for implementation details. NOTE: If you push this, it will cause a one-time break of threading for everyone using Outlook since I've changed the seed for generating Thread-Index. I feel like this is okay to avoid introducing more complexity here. Test Plan: Created and then updated a revision, messages delivered over Amazon SES threaded correctly in Mail.app. Verified headers. Unit tests. Reviewed By: rm Reviewers: aran, tuomaspelkonen, jungejason, rm Commenters: aran CC: aran, rm, epriestley Differential Revision: 195
2011-04-30 20:47:00 +02:00
'PhabricatorMetaMTAMailTestCase' => 'PhabricatorTestCase',
Mailing lists
2011-01-26 19:40:38 +01:00
'PhabricatorMetaMTAMailingList' => 'PhabricatorMetaMTADAO',
Support email replies in Phabricator Summary: Provides support for per-user x per-object unique reply-to email addresses, plus SMTP integration. This does not actually make Phabricator use these in outbound email. Test Plan: Used test console to validate in-Phabricator routing and handling. Piped emails into the "mail_handler.php" script to validate mail parsing. Configured sendmail and sent mail to Phabricator. Technically I haven't conducted all parts of this test on the same machine since I lost the will to configure more SMTP servers after configuring phabricator.com Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, epriestley, jungejason Differential Revision: 226
2011-05-05 08:09:42 +02:00
'PhabricatorMetaMTAReceiveController' => 'PhabricatorMetaMTAController',
'PhabricatorMetaMTAReceivedListController' => 'PhabricatorMetaMTAController',
'PhabricatorMetaMTAReceivedMail' => 'PhabricatorMetaMTADAO',
Begin improving the soundness of received mail Summary: We/I broke a couple of things here recently (see D5911) and are doing some work here in general (see D5912, etc.). Generally, this code is pretty oldschool and not especially well architected for modern application-oriented Phabricator. It hardcodes a lot of stuff which should be applications' responsibilites. Take the first steps toward making it more solid to reduce the risk here. In particular: - Factor out the "self mail" and "duplicate mail" checks and add unit tests. - Make Message-ID hash handling automatic. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5915
2013-05-14 01:32:19 +02:00
'PhabricatorMetaMTAReceivedMailProcessingException' => 'Exception',
'PhabricatorMetaMTAReceivedMailTestCase' => 'PhabricatorTestCase',
MetaMTA
2011-01-26 02:40:21 +01:00
'PhabricatorMetaMTASendController' => 'PhabricatorMetaMTAController',
Enable SendGrid Parse API as an inbound email handler Summary: Sendmail is seriously difficult to configure; SendGrid is extremely easy. It's also pretty expensive ($80/mo) but there are a bunch of startups that already have plans so it's effectively free for them. Test Plan: Configured SendGrid and sent reply email through it. Reviewed By: aran Reviewers: tuomaspelkonen, jungejason, aran CC: aran, epriestley Differential Revision: 376
2011-05-30 20:07:05 +02:00
'PhabricatorMetaMTASendGridReceiveController' => 'PhabricatorMetaMTAController',
MetaMetaView
2011-01-26 18:08:26 +01:00
'PhabricatorMetaMTAViewController' => 'PhabricatorMetaMTAController',
Move functionality of PhabricatorMetaMTADaemon to a worker task Summary: This will allow sending mail to be done by task workers. See T750. Task ID: # Blame Rev: Test Plan: - started taskmaster daemon in test env - used "send new test message" feature in MetMTA (with send now unchecked) - confirmed receipt of 1 email - repeated 2 & 3 with send now checked Revert Plan: Tags: Reviewers: epriestley, jungejason Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T388, T750 Differential Revision: https://secure.phabricator.com/D1723
2012-02-28 02:11:25 +01:00
'PhabricatorMetaMTAWorker' => 'PhabricatorWorker',
Build an AphrontMultiColumnView, use on workboards. Summary: Abstract out the multi-column code from workboards and have it be available separately. I feel like there will be some benefit here especially for custom developers in how they present infromation (like releeph). It also scales back to tablet and mobile fairly well, so they get those things for free. Test Plan: Tested mobile, tablet and chrome layouts. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5529
2013-04-02 20:23:24 +02:00
'PhabricatorMultiColumnExample' => 'PhabricatorUIExample',
Allow installs to require email verification Summary: Allow installs to require users to verify email addresses before they can use Phabricator. If a user logs in without a verified email address, they're given instructions to verify their address. This isn't too useful on its own since we don't actually have arbitrary email registration, but the next step is to allow installs to restrict email to only some domains (e.g., @mycompany.com). Test Plan: - Verification - Set verification requirement to `true`. - Tried to use Phabricator with an unverified account, was told to verify. - Tried to use Conduit, was given a verification error. - Verified account, used Phabricator. - Unverified account, reset password, verified implicit verification, used Phabricator. - People Admin Interface - Viewed as admin. Clicked "Administrate User". - Viewed as non-admin - Sanity Checks - Used Conduit normally from web/CLI with a verified account. - Logged in/out. - Sent password reset email. - Created a new user. - Logged in with an unverified user but with the configuration set to off. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran, csilvers Maniphest Tasks: T1184 Differential Revision: https://secure.phabricator.com/D2520
2012-05-21 21:47:38 +02:00
'PhabricatorMustVerifyEmailController' => 'PhabricatorAuthController',
Port MySQL settings to PHP Summary: - Ports MySQL settings to PHP. - Removes "mysql.retries" -- this existed only because Magic Numbers Are Bad, but there is no concievable reason it should ever be set to anything other than 3. - Introduced "Hidden" config, which isn't visible from the web (for SaaS, we'll just mark anything with secret keys as "hidden"). - Introduced "Masked" config, which will be masked in darkconsole once that gets updated. - "Hidden" implies "Masked" and "Locked". - Moved "storage.default-namespace" here -- it probably makes more sense than core; this was my bad in T2255. - Put cancel button back for hidden/locked config. - Introduce 'class' config type. Test Plan: Viewed MySQL options. None are editable. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4326
2013-01-03 15:01:14 +01:00
'PhabricatorMySQLConfigOptions' => 'PhabricatorApplicationConfigOptions',
Allow Phabricator storage engines to be extended and configured Summary: See T344. Currently, there's a hard-coded 12MB filesize limit and some awkward interactions with MySQL's max_allowed_packet. Make this system generally more robust: - Move the upload limit to configuration. - Add setup steps which reconcile max_allowed_packet vs MySQL file storage limits. - Add a layer of indirection between uploading files and storage engines. - Allow the definition of new storage engines. - Define a local disk storage engine. - Add a "storage engine selector" class which manages choosing which storage engines to put files in. - Document storage engines. - Document file storage classes. Test Plan: Setup mode: - Disabled MySQL storage engine, misconfigured it, configured it correctly. - Disabled file storage engine, set it to something invalid, set it to something valid. - Verified max_allowed_packet is read correctly. Application mode: - Configured local file storage. - Uploaded large and small files. - Verified larger files were written to local storage. - Verified smaller files were written to MySQL blob storage. Documentation: - Read documentation. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, epriestley, jungejason Differential Revision: 695
2011-07-20 07:48:38 +02:00
'PhabricatorMySQLFileStorageEngine' => 'PhabricatorFileStorageEngine',
Introduce PhabricatorNamedQueryQuery Summary: Adds a first-class Query object for querying NamedQueries. xzibit would be proud. Test Plan: Updated query edit interface to use this query, verified it works correctly. Reviewers: btrahan, blc Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6051
2013-05-27 22:40:43 +02:00
'PhabricatorNamedQuery' =>
array(
0 => 'PhabricatorSearchDAO',
1 => 'PhabricatorPolicyInterface',
),
'PhabricatorNamedQueryQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Implement Maniphest auxiliary field 'default' key Summary: Fixes T404. Ref T2575. Allows default to be set for any field. Date defaults are interpreted by `strtotime()`. Other defaults are interpreted as expected. Test Plan: - Created a string custom field with default value "Orange". - Created a date custom field with a fixed default value (my birthday). - Created a date custom field with a relative default value ("today 4:59 PM"). - Created/edited tasks with these fields, verified everything behaved sensibly. Reviewers: hach-que, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T404, T2575 Differential Revision: https://secure.phabricator.com/D5282
2013-03-08 02:23:30 +01:00
'PhabricatorNoteExample' => 'PhabricatorUIExample',
Add a "Mark All Read" button for notifications Summary: Adds a button to mark everything as read. Test Plan: Clicked button. Reviewers: btrahan, jungejason, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T974 Differential Revision: https://secure.phabricator.com/D2812
2012-06-20 22:51:19 +02:00
'PhabricatorNotificationClearController' => 'PhabricatorNotificationController',
Move notification configuration into PHP Summary: Bring notification settings to PHP. Test Plan: Viewed notification settings in /config/. Reviewers: codeblock, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4337
2013-01-03 18:29:19 +01:00
'PhabricatorNotificationConfigOptions' => 'PhabricatorApplicationConfigOptions',
Adds base notification application Summary: First diff in a series of diffs to add notifications to Phabricator. This is the notification application ONLY. This commit does not include the changes to other applications that makes them add notifications. As such, no notifications will be generated beyond the initial database import. Test Plan: This is part of the notifications architecture which has been running on http://theoryphabricator.com for the past several months. Reviewers: epriestley, btrahan, ddfisher Reviewed By: epriestley CC: allenjohnashton, keebuhm, aran, Korvin, jungejason, nh Maniphest Tasks: T974 Differential Revision: https://secure.phabricator.com/D2571
2012-06-08 15:31:30 +02:00
'PhabricatorNotificationController' => 'PhabricatorController',
Make Notifications Realtime Summary: Adds the node.js Aphlict server, the flash Aphlict client, and some supporting javascript. Built on top of - and requires - D2703 (which is still in progress). Will likely work with no modification on top of the final version, though. The node server is currently run with sudo node support/aphlict/server/aphlict_server.js Test Plan: tested locally Reviewers: epriestley Reviewed By: epriestley CC: allenjohnashton, keebuhm, aran, Korvin Differential Revision: https://secure.phabricator.com/D2704
2012-06-12 02:49:32 +02:00
'PhabricatorNotificationIndividualController' => 'PhabricatorNotificationController',
Add a list of all notifications Summary: Add a "View All Notifications" link and page. Test Plan: Viewed all notifications Reviewers: jungejason, vrana Reviewed By: jungejason CC: aran Maniphest Tasks: T974 Differential Revision: https://secure.phabricator.com/D2780
2012-06-18 23:07:38 +02:00
'PhabricatorNotificationListController' => 'PhabricatorNotificationController',
Adds the UI dropdown panel Summary: Add a dropdown to display notificaitons. Right now there is nothing real time about it, but we do update the panel when the user clicks. This panel is only displayed if the install has notifications enabled and you have them enabled in your preferences (not using them by default). Test Plan: Turn off notifications for user1, left them on for user2. Did things from user1 and from user2 on task both were cc'd on. user2 recieved all notifications, user1 recieved nothing. Made new user, made sure everything was switched off by default. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: keebuhm, ddfisher, aran, Korvin Differential Revision: https://secure.phabricator.com/D2703
2012-06-11 18:37:06 +02:00
'PhabricatorNotificationPanelController' => 'PhabricatorNotificationController',
Simplify lightboxing and fix a few things Summary: Minor tweaks to lightboxes. - With "position: fixed;", we don't need to do any of the scroll/resize stuff. Just remove it. - Make the lightbox go over the menu bar -- was it intentional that it wasn't? - Make 'jx-mask' use "position: fixed;" too. - Add a loading indicator. - In Differential/Maniphest/etc, a preview may bring in an image but won't bring in the CSS we need. The "real" fix is to ship CSS/JS with ajax, but that's really hard -- fake it by pulling in the right CSS any time we render a remarkup area. I'm going to do a couple of other tweaks here but need to update JX.Mask. Test Plan: Verified behavior is reasonable in Safari, Firefox, Chrome with multiple images / scroll / previews / resize. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1896 Differential Revision: https://secure.phabricator.com/D3795
2012-10-24 02:34:43 +02:00
'PhabricatorNotificationQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add a server status page for notification server Summary: - Add a /notification/status/ page which shows server status. - Remove various test controllers and routes. - Make the "no notifications" message look better. - Move port/URI configuration to config file. Test Plan: Started server, hit /notification/status/, saw server status. Reviewers: allenjohnashton, ddfisher, keebuhm, jungejason Reviewed By: jungejason CC: aran Maniphest Tasks: T944 Differential Revision: https://secure.phabricator.com/D2756
2012-06-17 20:35:18 +02:00
'PhabricatorNotificationStatusController' => 'PhabricatorNotificationController',
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server Summary: adds a Phabricator OAuth server, which has three big commands: - auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri - token - given a valid authorization code, this command returns an authorization token - whoami - Conduit.whoami, all nice and purdy relative to the oauth server. Also has a "test" handler, which I used to create some test data. T850 will delete this as it adds the ability to create this data in the Phabricator product. This diff also adds the corresponding client in Phabricator for the Phabricator OAuth Server. (Note that clients are known as "providers" in the Phabricator codebase but client makes more sense relative to the server nomenclature) Also, related to make this work well - clean up the diagnostics page by variabilizing the provider-specific information and extending the provider classes as appropriate. - augment Conduit.whoami for more full-featured OAuth support, at least where the Phabricator client is concerned What's missing here... See T844, T848, T849, T850, and T852. Test Plan: - created a dummy client via the test handler. setup development.conf to have have proper variables for this dummy client. went through authorization and de-authorization flows - viewed the diagnostics page for all known oauth providers and saw provider-specific debugging information Reviewers: epriestley CC: aran, epriestley Maniphest Tasks: T44, T797 Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
'PhabricatorOAuthClientAuthorization' => 'PhabricatorOAuthServerDAO',
OAuth Server -- add controllers to RUD client authorizations and CRUD clients Summary: beyond the title, this diff tweaks the test console to have a bit more functionality. also makes a small change to CSS for AphrontFormControlMarkup, which IMO fixes a display issue on https://secure.phabricator.com/settings/page/profile/ where the Profile URI is all up in the air and whatnot I think this is missing pagination. I am getting tired of the size though and will add later. See T905. Test Plan: viewed, updated and deleted client authorizations. viewed, created, updated and deleted clients Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T849, T850, T848 Differential Revision: https://secure.phabricator.com/D1683
2012-02-22 19:21:39 +01:00
'PhabricatorOAuthClientAuthorizationBaseController' => 'PhabricatorOAuthServerController',
'PhabricatorOAuthClientAuthorizationDeleteController' => 'PhabricatorOAuthClientAuthorizationBaseController',
'PhabricatorOAuthClientAuthorizationEditController' => 'PhabricatorOAuthClientAuthorizationBaseController',
'PhabricatorOAuthClientAuthorizationListController' => 'PhabricatorOAuthClientAuthorizationBaseController',
Add pagers to server clients and client authorizations in OAuth Server GUI Summary: ...also make the pager usage in ChatLog use the nice formatWhereClause functionality Test Plan: set $page_size = 2 and paged around the data a bit Reviewers: epriestley Reviewed By: epriestley CC: aran Maniphest Tasks: T905 Differential Revision: https://secure.phabricator.com/D2106
2012-04-05 02:51:16 +02:00
'PhabricatorOAuthClientAuthorizationQuery' => 'PhabricatorOffsetPagedQuery',
OAuth Server -- add controllers to RUD client authorizations and CRUD clients Summary: beyond the title, this diff tweaks the test console to have a bit more functionality. also makes a small change to CSS for AphrontFormControlMarkup, which IMO fixes a display issue on https://secure.phabricator.com/settings/page/profile/ where the Profile URI is all up in the air and whatnot I think this is missing pagination. I am getting tired of the size though and will add later. See T905. Test Plan: viewed, updated and deleted client authorizations. viewed, created, updated and deleted clients Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T849, T850, T848 Differential Revision: https://secure.phabricator.com/D1683
2012-02-22 19:21:39 +01:00
'PhabricatorOAuthClientBaseController' => 'PhabricatorOAuthServerController',
'PhabricatorOAuthClientDeleteController' => 'PhabricatorOAuthClientBaseController',
'PhabricatorOAuthClientEditController' => 'PhabricatorOAuthClientBaseController',
'PhabricatorOAuthClientListController' => 'PhabricatorOAuthClientBaseController',
'PhabricatorOAuthClientViewController' => 'PhabricatorOAuthClientBaseController',
Modularize oauth.
2011-02-28 04:47:22 +01:00
'PhabricatorOAuthDefaultRegistrationController' => 'PhabricatorOAuthRegistrationController',
Github OAuth Summary: Test Plan: Reviewers: CC:
2011-02-21 07:47:56 +01:00
'PhabricatorOAuthDiagnosticsController' => 'PhabricatorAuthController',
'PhabricatorOAuthFailureView' => 'AphrontView',
'PhabricatorOAuthLoginController' => 'PhabricatorAuthController',
OAuth -- add support for Disqus Summary: also fix some bugs where we weren't properly capturing the expiry value or scope of access tokens. This code isn't the cleanest as some providers don't confirm what scope you've been granted. In that case, assume the access token is of the minimum scope Phabricator requires. This seems more useful to me as only Phabricator at the moment really easily / consistently lets the user increase / decrease the granted scope so its basically always the correct assumption at the time we make it. Test Plan: linked and unlinked Phabricator, Github, Disqus and Facebook accounts from Phabricator instaneces Reviewers: epriestley Reviewed By: epriestley CC: zeeg, aran, Koolvin Maniphest Tasks: T1110 Differential Revision: https://secure.phabricator.com/D2431
2012-05-08 21:08:05 +02:00
'PhabricatorOAuthProviderDisqus' => 'PhabricatorOAuthProvider',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'PhabricatorOAuthProviderException' => 'Exception',
Github OAuth Summary: Test Plan: Reviewers: CC:
2011-02-21 07:47:56 +01:00
'PhabricatorOAuthProviderFacebook' => 'PhabricatorOAuthProvider',
Github is actually GitHub Test Plan: none Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1557
2012-02-03 02:25:31 +01:00
'PhabricatorOAuthProviderGitHub' => 'PhabricatorOAuthProvider',
Add Google as an OAuth2 provider (BETA) Summary: This is pretty straightforward, except: - We need to request read/write access to the address book to get the account ID (which we MUST have) and real name, email and account name (which we'd like to have). This is way more access than we should need, but there's apparently no "get_loggedin_user_basic_information" type of call in the Google API suite (or, at least, I couldn't find one). - We can't get the profile picture or profile URI since there's no Plus API access and Google users don't have meaningful public pages otherwise. - Google doesn't save the fact that you've authorized the app, so every time you want to login you need to reaffirm that you want to give us silly amounts of access. Phabricator sessions are pretty long-duration though so this shouldn't be a major issue. Test Plan: - Registered, logged out, and logged in with Google. - Registered, logged out, and logged in with Facebook / Github to make sure I didn't break anything. - Linked / unlinked Google accounts. Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran Reviewed By: aran CC: aran, epriestley, Makinde Differential Revision: 916
2011-09-09 01:37:22 +02:00
'PhabricatorOAuthProviderGoogle' => 'PhabricatorOAuthProvider',
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server Summary: adds a Phabricator OAuth server, which has three big commands: - auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri - token - given a valid authorization code, this command returns an authorization token - whoami - Conduit.whoami, all nice and purdy relative to the oauth server. Also has a "test" handler, which I used to create some test data. T850 will delete this as it adds the ability to create this data in the Phabricator product. This diff also adds the corresponding client in Phabricator for the Phabricator OAuth Server. (Note that clients are known as "providers" in the Phabricator codebase but client makes more sense relative to the server nomenclature) Also, related to make this work well - clean up the diagnostics page by variabilizing the provider-specific information and extending the provider classes as appropriate. - augment Conduit.whoami for more full-featured OAuth support, at least where the Phabricator client is concerned What's missing here... See T844, T848, T849, T850, and T852. Test Plan: - created a dummy client via the test handler. setup development.conf to have have proper variables for this dummy client. went through authorization and de-authorization flows - viewed the diagnostics page for all known oauth providers and saw provider-specific debugging information Reviewers: epriestley CC: aran, epriestley Maniphest Tasks: T44, T797 Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
'PhabricatorOAuthProviderPhabricator' => 'PhabricatorOAuthProvider',
Modularize oauth.
2011-02-28 04:47:22 +01:00
'PhabricatorOAuthRegistrationController' => 'PhabricatorAuthController',
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server Summary: adds a Phabricator OAuth server, which has three big commands: - auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri - token - given a valid authorization code, this command returns an authorization token - whoami - Conduit.whoami, all nice and purdy relative to the oauth server. Also has a "test" handler, which I used to create some test data. T850 will delete this as it adds the ability to create this data in the Phabricator product. This diff also adds the corresponding client in Phabricator for the Phabricator OAuth Server. (Note that clients are known as "providers" in the Phabricator codebase but client makes more sense relative to the server nomenclature) Also, related to make this work well - clean up the diagnostics page by variabilizing the provider-specific information and extending the provider classes as appropriate. - augment Conduit.whoami for more full-featured OAuth support, at least where the Phabricator client is concerned What's missing here... See T844, T848, T849, T850, and T852. Test Plan: - created a dummy client via the test handler. setup development.conf to have have proper variables for this dummy client. went through authorization and de-authorization flows - viewed the diagnostics page for all known oauth providers and saw provider-specific debugging information Reviewers: epriestley CC: aran, epriestley Maniphest Tasks: T44, T797 Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
'PhabricatorOAuthResponse' => 'AphrontResponse',
'PhabricatorOAuthServerAccessToken' => 'PhabricatorOAuthServerDAO',
'PhabricatorOAuthServerAuthController' => 'PhabricatorAuthController',
'PhabricatorOAuthServerAuthorizationCode' => 'PhabricatorOAuthServerDAO',
'PhabricatorOAuthServerClient' => 'PhabricatorOAuthServerDAO',
Add pagers to server clients and client authorizations in OAuth Server GUI Summary: ...also make the pager usage in ChatLog use the nice formatWhereClause functionality Test Plan: set $page_size = 2 and paged around the data a bit Reviewers: epriestley Reviewed By: epriestley CC: aran Maniphest Tasks: T905 Differential Revision: https://secure.phabricator.com/D2106
2012-04-05 02:51:16 +02:00
'PhabricatorOAuthServerClientQuery' => 'PhabricatorOffsetPagedQuery',
OAuth Server -- add controllers to RUD client authorizations and CRUD clients Summary: beyond the title, this diff tweaks the test console to have a bit more functionality. also makes a small change to CSS for AphrontFormControlMarkup, which IMO fixes a display issue on https://secure.phabricator.com/settings/page/profile/ where the Profile URI is all up in the air and whatnot I think this is missing pagination. I am getting tired of the size though and will add later. See T905. Test Plan: viewed, updated and deleted client authorizations. viewed, created, updated and deleted clients Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T849, T850, T848 Differential Revision: https://secure.phabricator.com/D1683
2012-02-22 19:21:39 +01:00
'PhabricatorOAuthServerController' => 'PhabricatorController',
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server Summary: adds a Phabricator OAuth server, which has three big commands: - auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri - token - given a valid authorization code, this command returns an authorization token - whoami - Conduit.whoami, all nice and purdy relative to the oauth server. Also has a "test" handler, which I used to create some test data. T850 will delete this as it adds the ability to create this data in the Phabricator product. This diff also adds the corresponding client in Phabricator for the Phabricator OAuth Server. (Note that clients are known as "providers" in the Phabricator codebase but client makes more sense relative to the server nomenclature) Also, related to make this work well - clean up the diagnostics page by variabilizing the provider-specific information and extending the provider classes as appropriate. - augment Conduit.whoami for more full-featured OAuth support, at least where the Phabricator client is concerned What's missing here... See T844, T848, T849, T850, and T852. Test Plan: - created a dummy client via the test handler. setup development.conf to have have proper variables for this dummy client. went through authorization and de-authorization flows - viewed the diagnostics page for all known oauth providers and saw provider-specific debugging information Reviewers: epriestley CC: aran, epriestley Maniphest Tasks: T44, T797 Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
'PhabricatorOAuthServerDAO' => 'PhabricatorLiskDAO',
OAuthServer polish and random sauce Summary: This diff makes the OAuthServer more compliant with the spec by - making it return well-formatted error codes with error types from the spec. - making it respect the "state" variable, which is a transparent variable the client passes and the server passes back - making it be super, duper compliant with respect to redirect uris -- if specified in authorization step, check if its valid relative to the client registered URI and if so save it -- if specified in authorization step, check if its been specified in the access step and error if it doesn't match or doesn't exist -- note we don't make any use of it in the access step which seems strange but hey, that's what the spec says! This diff makes the OAuthServer suck less by - making the "cancel" button do something in the user authorization flow - making the client list view and client edit view be a bit more usable around client secrets - fixing a few bugs I managed to introduce along the way Test Plan: - create a test phabricator client, updated my conf, and then linked and unlinked phabricator to itself - wrote some tests for PhabricatorOAuthServer -- they pass! -- these validate the various validate URI checks - tried a few important authorization calls -- http://phabricator.dev/oauthserver/auth/?client_id=X&state=test&redirect_uri=http://www.evil.com --- verified error'd from mismatching redirect uri's --- verified state parameter in response --- verified did not redirect to client redirect uri -- http://phabricator.dev/oauthserver/auth/?client_id=X w/ existing authorization --- got redirected to proper client url with error that response_type not specified -- http://phabricator.dev/oauthserver/auth/?client_id=X&response_type=code w/ existing authorization --- got redirected to proper client url with pertinent code! - tried a few important access calls -- verified appropriate errors if missing any required parameters -- verified good access code with appropriate other variables resulted in an access token - verified that if redirect_uri set correctly in authorization required for access and errors if differs at all / only succeeds if exactly the same Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley, ajtrichards Maniphest Tasks: T889, T906, T897 Differential Revision: https://secure.phabricator.com/D1727
2012-03-01 23:46:18 +01:00
'PhabricatorOAuthServerTestCase' => 'PhabricatorTestCase',
OAuth Server -- add controllers to RUD client authorizations and CRUD clients Summary: beyond the title, this diff tweaks the test console to have a bit more functionality. also makes a small change to CSS for AphrontFormControlMarkup, which IMO fixes a display issue on https://secure.phabricator.com/settings/page/profile/ where the Profile URI is all up in the air and whatnot I think this is missing pagination. I am getting tired of the size though and will add later. See T905. Test Plan: viewed, updated and deleted client authorizations. viewed, created, updated and deleted clients Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T849, T850, T848 Differential Revision: https://secure.phabricator.com/D1683
2012-02-22 19:21:39 +01:00
'PhabricatorOAuthServerTestController' => 'PhabricatorOAuthServerController',
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server Summary: adds a Phabricator OAuth server, which has three big commands: - auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri - token - given a valid authorization code, this command returns an authorization token - whoami - Conduit.whoami, all nice and purdy relative to the oauth server. Also has a "test" handler, which I used to create some test data. T850 will delete this as it adds the ability to create this data in the Phabricator product. This diff also adds the corresponding client in Phabricator for the Phabricator OAuth Server. (Note that clients are known as "providers" in the Phabricator codebase but client makes more sense relative to the server nomenclature) Also, related to make this work well - clean up the diagnostics page by variabilizing the provider-specific information and extending the provider classes as appropriate. - augment Conduit.whoami for more full-featured OAuth support, at least where the Phabricator client is concerned What's missing here... See T844, T848, T849, T850, and T852. Test Plan: - created a dummy client via the test handler. setup development.conf to have have proper variables for this dummy client. went through authorization and de-authorization flows - viewed the diagnostics page for all known oauth providers and saw provider-specific debugging information Reviewers: epriestley CC: aran, epriestley Maniphest Tasks: T44, T797 Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
'PhabricatorOAuthServerTokenController' => 'PhabricatorAuthController',
OAuth linking/unlinking controls. Summary: Test Plan: Reviewers: CC:
2011-02-22 07:51:34 +01:00
'PhabricatorOAuthUnlinkController' => 'PhabricatorAuthController',
Add object status to Handles Summary: We use ObjectHandles as proxy objects which can refer to any other object in the system. Add the concept of the underlying object's "status" (e.g., open, closed or busy). This allows us to render completed tasks and revisions with strikethrough. In the future, if we implement OOO or something, we could render users with a "busy" status if they're on vacation, etc. Test Plan: Viewed a task with closed revisions and dependencies: https://secure.phabricator.com/file/view/PHID-FILE-6183e81286fa3288d33d/ Reviewed By: codeblock Reviewers: codeblock, hunterbridges, jungejason, tuomaspelkonen, aran CC: aran, codeblock Differential Revision: 772
2011-08-03 15:37:18 +02:00
'PhabricatorObjectHandleStatus' => 'PhabricatorObjectHandleConstants',
Implement card style and extras for object item lists Summary: Initial pass at elements appearing on M10. Glaring omissions: - I cut a single icon out of M10 in a haphazard way. - No linear graident texture on the cards. Test Plan: {F35248} {F35249} Reviewers: chad Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D5311
2013-03-10 02:55:01 +01:00
'PhabricatorObjectItemListExample' => 'PhabricatorUIExample',
Consolidate some datetime code and add unit tests Summary: See D6115. Test Plan: - Ran unit tests. - Viewed reports. - Created a countdown. - Searched chatlog. - Searched pastes by created date. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6116
2013-06-03 21:58:11 +02:00
'PhabricatorObjectItemListView' => 'AphrontTagView',
Minor, bad autoload map merge. Auditors: chad
2013-03-23 22:41:50 +01:00
'PhabricatorObjectItemView' => 'AphrontTagView',
Make project membership edits use transactions and PHIDs and not be awful Summary: - Split project profile editing apart from project membership editing. - Make project membership editing simpler and easier to use. - Drop role / owner stuff from the UI. Test Plan: Added and removed project members. Edited project profile information. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3184
2012-08-07 20:57:38 +02:00
'PhabricatorObjectListView' => 'AphrontView',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorObjectMailReceiver' => 'PhabricatorMailReceiver',
Move sender validation into MailReceiver classes Summary: Ref T1205. Finally able to delete a big chunk of this nastiness. Make MailReceivers responsible for validating senders. For object creation receivers (bugs, conpherences) this just means that users must not be disabled. For other receivers the senders must be able to see the objects, have the right hashes, etc., according to policy. Test Plan: Added a bunch of test cases (everything except policy). Verified behavior via the Receive test console. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5943
2013-05-17 12:49:29 +02:00
'PhabricatorObjectMailReceiverTestCase' => 'PhabricatorTestCase',
More Drydock Stuff Summary: - Still really really rough. - Adds a full synchronous mode for debugging. - Adds some logging. - It can now allocate EC2 machines and put webroots on them in a hacky, terrible way. - Adds a base query class. Test Plan: oh hey look a test page? http://ec2-50-18-65-151.us-west-1.compute.amazonaws.com:2011/ Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D2026
2012-03-27 05:54:26 +02:00
'PhabricatorOffsetPagedQuery' => 'PhabricatorQuery',
MetaMTA: Owners, Pholio, Macro Summary: Port MetaMTA options for Owners, Pholio and Macro. At some point I'd like to get rid of all these options (provide one "reply domain", and not allow overrides of reply handlers -- use events instead) but that's a battle we can fight later. Test Plan: Looked at options, looked at setup issues, edited something. Reviewers: codeblock, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4469
2013-01-16 19:52:30 +01:00
'PhabricatorOwnersConfigOptions' => 'PhabricatorApplicationConfigOptions',
owners
2011-04-03 23:48:36 +02:00
'PhabricatorOwnersController' => 'PhabricatorController',
'PhabricatorOwnersDAO' => 'PhabricatorLiskDAO',
Some owners write workflows.
2011-04-04 07:03:27 +02:00
'PhabricatorOwnersDeleteController' => 'PhabricatorOwnersController',
owners
2011-04-03 23:48:36 +02:00
'PhabricatorOwnersDetailController' => 'PhabricatorOwnersController',
Some owners write workflows.
2011-04-04 07:03:27 +02:00
'PhabricatorOwnersEditController' => 'PhabricatorOwnersController',
owners
2011-04-03 23:48:36 +02:00
'PhabricatorOwnersListController' => 'PhabricatorOwnersController',
'PhabricatorOwnersOwner' => 'PhabricatorOwnersDAO',
Add PhabricatorOwnersPackageQuery Summary: This is a step toward unearthing Project queries enough that I can make them policy-aware. Right now, some ProjectQuery callsites do not have reasonable access to the viewer. In particular, Owners packages need to issue Project queries because we allow projects to own packages and resolve project members inside of some package queries. Currently, we have a very unmodern approach to querying packages, with a large number of one-off static load methods: PhabricatorOwnersPackage::loadAffectedPackages() PhabricatorOwnersPackage::loadOwningPackages() PhabricatorOwnersPackage::loadPackagesForPaths() PhabricatorOwnersOwner::loadAllForPackages() PhabricatorOwnersOwner::loadAffiliatedUserPHIDs() PhabricatorOwnersOwner::loadAffiliatedPackages() ConduitAPI_owners_query_Method::queryAll() ConduitAPI_owners_query_Method::queryByOwner() ConduitAPI_owners_query_Method::queryByAffiliatedUser() ConduitAPI_owners_query_Method::queryByPath() We should replace `PhabricatorOwnersOwner` with an Edge and move all of these calls to a Query class. I'm going to try to do as little of this work as I can for now since I'm much more interested in getting a functional policy implementation into other applications, but ProjectQuery needs to be policy-aware before I can do that and I need to dig some at least some of the callsites out enough that I can get a viewer in there without making the code worse than it is. This adds a PhabricatorOwnersPackageQuery class and removes one callsite of one of those static methods. I also intend to dissolve the two separate concepts of an "owner" (direct owner) and an "affiliated user" (indirect owner via project membership) since I think we're always fine with "affiliated users" owners. Test Plan: Loaded home page / audit tool, which use the modified path. Ran queries manually via script. Made sure results included directly owned packages and packages owned through project membership. Reviewers: vrana, btrahan, meitros Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3193
2012-08-08 21:25:11 +02:00
'PhabricatorOwnersPackage' =>
array(
0 => 'PhabricatorOwnersDAO',
1 => 'PhabricatorPolicyInterface',
),
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorOwnersPackageQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Allow excluding paths from package Summary: Resolves T2149. Test Plan: $ bin/storage upgrade # /owners/ - saw + # /owners/package/1/ - saw + # /owners/edit/1/ - added exclude paths, saw correct e-mail # /rPabc123 - included paths are still highlighted and excluded not # /owners/view/search/?path=/included/ - found # /owners/view/search/?path=/excluded/ - not found # owners.query - path: /included/ # owners.query - path: /excluded/ # new unit test PhabricatorOwnersPackage::loadAffectedPackages( $repository, array('/excluded/b.php')); PhabricatorOwnersPackage::loadAffectedPackages( $repository, array('/included/a.php')); Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2149 Differential Revision: https://secure.phabricator.com/D4102
2012-12-07 02:23:56 +01:00
'PhabricatorOwnersPackageTestCase' => 'PhabricatorTestCase',
owners
2011-04-03 23:48:36 +02:00
'PhabricatorOwnersPath' => 'PhabricatorOwnersDAO',
PHD Options. Test Plan: Looked at the options render properly. Reviewers: epriestley, btrahan, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4367
2013-01-09 15:05:34 +01:00
'PhabricatorPHDConfigOptions' => 'PhabricatorApplicationConfigOptions',
Formalize phid.external-loaders Test Plan: /config/issue/ Reviewers: edward, codeblock, epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4516
2013-01-19 19:20:22 +01:00
'PhabricatorPHIDConfigOptions' => 'PhabricatorApplicationConfigOptions',
Introduce PHID generation.
2011-01-23 06:09:13 +01:00
'PhabricatorPHIDController' => 'PhabricatorController',
PhabricatorObjectHandles
2011-01-26 18:02:09 +01:00
'PhabricatorPHIDLookupController' => 'PhabricatorPHIDController',
Bring PHPMailer config into the new config UI Summary: Port PHPMailer options. Also: - Don't show values on config lists if they're masked (this is mostly for passwords, to prevent them from being idly/accidentally disclosed). - Don't show "default" icon -- just show an icon if the value has been customized. This makes it easier to pick out custom values. Test Plan: Looked at / edited mailer values. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4441
2013-01-15 21:03:44 +01:00
'PhabricatorPHPMailerConfigOptions' => 'PhabricatorApplicationConfigOptions',
Add a basic multipage form Summary: Ref T2232. Very busy day on IRC so I feel like I've made 20 minutes of progress in 1-minute spurts here, but this adds the basics for a form that can have multiple pages and automatically handle pagination and reading to/from the request, objects and responses. The UIExample is reasonably instructive. Basically, you make a form, add pages to the form, and add controls to the pages. The core flow control looks like this: if ($request->isFormPost()) { $form->readFromRequest($request); // (1) if ($form->isComplete()) { // (2) $response = $form->writeToResponse($response); // (3) // Process result here. // (4) } } else { $form->readFromObject($object); // (5) } The key parts are: # This reads the form state from the request, including reading all the inactive pages. # This tests if all pages are valid and the user just clicked "Done" on the last page. # This produces a "response", which might be writing to an object (for simpler forms) or creating a transaction record (for more complex forms). # Here, we would save the object or apply the transactions. # When the user views the form for the first time, we preload all the values from some object (which might just be empty). Ultimate goal here is to fix repository creation to not be a terrible pit of awfulness. There are probably a lot of rough edges and missing features still, but this seems to not be totally crazy. I'm using two submit buttons with different names which doesn't work on IE7 or something, but we can JS our way out of that if we need to. Test Plan: Paged forward and backward through the form. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2232 Differential Revision: https://secure.phabricator.com/D6003
2013-05-23 23:39:01 +02:00
'PhabricatorPagedFormExample' => 'PhabricatorUIExample',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'PhabricatorPaste' =>
array(
0 => 'PhabricatorPasteDAO',
Arc liberate fix Summary: Run arc liberate and commit the results on the assumption that someone forgot to do this in another diff, or their results were discarded by an automatic merge during rebase. Test Plan: None. Reviewers: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5889
2013-05-10 18:11:14 +02:00
1 => 'PhabricatorTokenReceiverInterface',
2 => 'PhabricatorPolicyInterface',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
),
Pastebin Summary: This is Paste. It needs some work, but epriestley recommended that I just commit something that works, and expand on that later. Specifically, it lacks the ability to view a raw paste right now, and to turn off line numbers, making it hard to copy/paste from for now. It works for showing other people code, however. Test Plan: Pasted stuff, and was able to view it, and see it in the list on /paste/. Put a file extension in the title, and saw that syntax highlighting worked as expected. Reviewers: epriestley CC: Differential Revision: 424
2011-06-10 08:53:53 +02:00
'PhabricatorPasteController' => 'PhabricatorController',
'PhabricatorPasteDAO' => 'PhabricatorLiskDAO',
Split paste create/edit and list views Summary: We have this hybrid "create / last few pastes" landing screen right now but I ~never use the list at the bottom and it makes the controller kind of complicated. I want to let you edit pastes too, and this generally simplifies things. Also makes the textarea monospaced and cleans up the fork logic a bit. Test Plan: Created, forked pastes. Viewed paste lists. Viewed pastes. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1690 Differential Revision: https://secure.phabricator.com/D3375
2012-08-24 22:19:14 +02:00
'PhabricatorPasteEditController' => 'PhabricatorPasteController',
Use delegation to generalize application search controllers Summary: Ref T2625. Lifts almost all of the search logic out of Paste controllers and into Search. This uses controller delegation for generalization. We use this in a few places, but don't use it very much yet. I think it's pretty reasonable as-is, but I might be able to make even more stuff free. There are some slightly rough edges around routes, still, but I want to hit Phame and Differential (which both have multiple application search engines) before trying to generalize that. Test Plan: Executed, browsed and managed Paste searches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6073
2013-05-30 23:09:02 +02:00
'PhabricatorPasteListController' =>
array(
0 => 'PhabricatorPasteController',
1 => 'PhabricatorApplicationSearchResultsControllerInterface',
),
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorPasteQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Missing change from D5120 which I incorrectly discarded in a merge. Auditors: vrana
2013-02-27 16:18:30 +01:00
'PhabricatorPasteRemarkupRule' => 'PhabricatorRemarkupRuleObject',
Move paste search to generic search. Summary: Begin implementing generic application search and refactoring paste search. Test Plan: See if the paste search still works. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5621
2013-04-14 15:53:20 +02:00
'PhabricatorPasteSearchEngine' => 'PhabricatorApplicationSearchEngine',
Completed Paste Generation Summary: Ref T2903 Test Plan: Pastes being generated with all types of parents, view policies, code, etc. Reviewers: epriestley, AnhNhan Reviewed By: epriestley CC: AnhNhan, aran, Korvin Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5707
2013-04-29 21:10:53 +02:00
'PhabricatorPasteTestDataGenerator' => 'PhabricatorTestDataGenerator',
Pastebin Summary: This is Paste. It needs some work, but epriestley recommended that I just commit something that works, and expand on that later. Specifically, it lacks the ability to view a raw paste right now, and to turn off line numbers, making it hard to copy/paste from for now. It works for showing other people code, however. Test Plan: Pasted stuff, and was able to view it, and see it in the list on /paste/. Put a file extension in the title, and saw that syntax highlighting worked as expected. Reviewers: epriestley CC: Differential Revision: 424
2011-06-10 08:53:53 +02:00
'PhabricatorPasteViewController' => 'PhabricatorPasteController',
Basic user/account tool.
2011-01-24 03:09:16 +01:00
'PhabricatorPeopleController' => 'PhabricatorController',
'PhabricatorPeopleEditController' => 'PhabricatorPeopleController',
Adding hovercard event listeners for Users, Revisions, Conpherence and Commits Summary: Refs T1048 Adding Differential Hovercard EventListener Adding People Hovercard EventListener Adding basic Diffusion hovercard Adding Conpherence Hovercard EventListener Test Plan: Used in a combo with working hovercards. So beautiful. Also visited test page. Works alright. awesometown Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1048 Differential Revision: https://secure.phabricator.com/D5576
2013-04-06 02:01:54 +02:00
'PhabricatorPeopleHovercardEventListener' => 'PhutilEventListener',
Added ldap import controller
2012-07-04 04:10:38 +02:00
'PhabricatorPeopleLdapController' => 'PhabricatorPeopleController',
Implement ApplicationSearch in People Summary: Ref T2625. Fixes T2812. Implement ApplicationSearch in People. {F44788} Test Plan: Made People queries. Used Conduit. Used `@mentions`. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2625, T2812 Differential Revision: https://secure.phabricator.com/D6092
2013-05-31 19:51:20 +02:00
'PhabricatorPeopleListController' =>
array(
0 => 'PhabricatorPeopleController',
1 => 'PhabricatorApplicationSearchResultsControllerInterface',
),
Provide an activity log for login and administrative actions Summary: This isn't complete, but I figured I'd ship it for review while it's still smallish. Provide an activity log for high-level system actions (logins, admin actions). This basically allows two things to happen: - The log itself is useful if there are shenanigans. - Password login can check it and start CAPTCHA'ing users after a few failed attempts. I'm going to change how the admin stuff works a little bit too, since right now you can make someone an agent, grab their certificate, revert them back to a normal user, and then act on their behalf over Conduit. This is a little silly, I'm going to move "agent" to the create workflow instead. I'll also add a confirm/email step to the administrative password reset flow. Test Plan: Took various administrative and non-administrative actions, they appeared in the logs. Filtered the logs in a bunch of different ways. Reviewers: jungejason, tuomaspelkonen, aran CC: Differential Revision: 302
2011-05-18 03:42:21 +02:00
'PhabricatorPeopleLogsController' => 'PhabricatorPeopleController',
Basic user/account tool.
2011-01-24 03:09:16 +01:00
'PhabricatorPeopleProfileController' => 'PhabricatorPeopleController',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
'PhabricatorPeopleProfileEditController' => 'PhabricatorPeopleController',
Use ObjectItemListView in Diviner Summary: Ref T988. Nuke the old directory CSS. Test Plan: {F44796} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6093
2013-05-31 19:51:53 +02:00
'PhabricatorPeopleQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Implement ApplicationSearch in People Summary: Ref T2625. Fixes T2812. Implement ApplicationSearch in People. {F44788} Test Plan: Made People queries. Used Conduit. Used `@mentions`. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2625, T2812 Differential Revision: https://secure.phabricator.com/D6092
2013-05-31 19:51:20 +02:00
'PhabricatorPeopleSearchEngine' => 'PhabricatorApplicationSearchEngine',
Successfully Generated People Summary: Ref T2903 Test Plan: Added new person whose profile was visible afterwards. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan, btrahan Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5682
2013-04-15 04:09:20 +02:00
'PhabricatorPeopleTestDataGenerator' => 'PhabricatorTestDataGenerator',
OAuth options. Test Plan: Looked at the options. Reviewers: epriestley, btrahan, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4470
2013-01-16 19:00:51 +01:00
'PhabricatorPhabricatorOAuthConfigOptions' => 'PhabricatorApplicationConfigOptions',
Move Phame config into config options Summary: so much work Test Plan: clicky clicky Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4448
2013-01-16 00:36:49 +01:00
'PhabricatorPhameConfigOptions' => 'PhabricatorApplicationConfigOptions',
MetaMTA: Owners, Pholio, Macro Summary: Port MetaMTA options for Owners, Pholio and Macro. At some point I'd like to get rid of all these options (provide one "reply domain", and not allow overrides of reply handlers -- use events instead) but that's a battle we can fight later. Test Plan: Looked at options, looked at setup issues, edited something. Reviewers: codeblock, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4469
2013-01-16 19:52:30 +01:00
'PhabricatorPholioConfigOptions' => 'PhabricatorApplicationConfigOptions',
Parse VCS revert langauge in commit messages Summary: Ref T1751. When commit messages include language like "reverts X", parse it. This change doesn't do anything with the commits yet. I attempted to cover all "natural" VCS messages and all reasonable human variations of these messages. Test Plan: Added unit tests. Added `var_dump()` and used `scripts/repository/reparse.php --message X` to reparse some commit messages, with expected results. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1751 Differential Revision: https://secure.phabricator.com/D5840
2013-05-06 21:33:37 +02:00
'PhabricatorPholioMockTestDataGenerator' => 'PhabricatorTestDataGenerator',
Implement Balanced Payments as a PhortunePaymentProvider Summary: Allows Balanced payment methods to be added. This works essentially the same way as Stripe, except everything is a little bit different. Slightly more stuff could be shared, but I feel //mostly// good about this. I'll probably do a bit more cleanup next. Some of the error handling is messy, in particular. Ref T2787. Test Plan: Added Balanced and Stripe payment methods. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5765
2013-04-25 18:48:04 +02:00
'PhabricatorPhortuneConfigOptions' => 'PhabricatorApplicationConfigOptions',
Implemented Phrequent time tracking functionality. Summary: This differential implements Phrequent's time tracking functionality for users and hooks it up to Maniphest. It also includes a basic "Time Tracked" list for the Phrequent application, where users can review what they've spent time working on. Test Plan: Apply the patch and track some things in Maniphest. They should appear in the "Time Tracked" view of Phrequent. There is also a `phrequent.show-prompt` option which toggles whether to display a prompt when tracking time. I'm unsure of whether the prompt is useful or is more likely to cause people to click "Track Time", go off and do the task and then come back to the prompt still waiting for them to confirm. A potential solution to the "accidentally clicking the button and recording 2 seconds of time" might be to show a prompt on stop if the total time is under 10 seconds, asking whether the user wants to keep or discard the tracked time. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2857 Differential Revision: https://secure.phabricator.com/D5479
2013-03-30 17:32:29 +01:00
'PhabricatorPhrequentConfigOptions' => 'PhabricatorApplicationConfigOptions',
Phriction setting. Summary: One setting. Test Plan: - Looked at the setting in the web interface. - Waved to it - Introduced myself - Had a nice conversation - Made a new friend - Turns out `phriction.enabled` is a nice guy. Reviewers: epriestley, chad Reviewed By: chad CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4436
2013-01-15 15:31:53 +01:00
'PhabricatorPhrictionConfigOptions' => 'PhabricatorApplicationConfigOptions',
Use a "pinboard" UI to display image macros Summary: Moves toward unblocking D3547. Use a pinboard/album view to show image macros. Modernize and make (mostly) responsive. Test Plan: Will attach screenshots. Reviewers: btrahan, vrana, chad, teisenbe Reviewed By: vrana CC: aran Maniphest Tasks: T175 Differential Revision: https://secure.phabricator.com/D3576
2012-10-01 23:06:00 +02:00
'PhabricatorPinboardItemView' => 'AphrontView',
'PhabricatorPinboardView' => 'AphrontView',
Add basic per-object privacy policies Summary: Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change. Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request. The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens. We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can. Test Plan: Unit tests, played around in the UI with various policy settings. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
'PhabricatorPolicies' => 'PhabricatorPolicyConstants',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorPolicyAwareQuery' => 'PhabricatorOffsetPagedQuery',
'PhabricatorPolicyAwareTestQuery' => 'PhabricatorPolicyAwareQuery',
Add basic per-object privacy policies Summary: Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change. Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request. The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens. We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can. Test Plan: Unit tests, played around in the UI with various policy settings. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
'PhabricatorPolicyCapability' => 'PhabricatorPolicyConstants',
Add Policy options. Test Plan: Looked at the setting and available options from the dropdown. Reviewers: epriestley, chad Reviewed By: chad CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4354
2013-01-07 21:47:26 +01:00
'PhabricatorPolicyConfigOptions' => 'PhabricatorApplicationConfigOptions',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'PhabricatorPolicyException' => 'Exception',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorPolicyQuery' => 'PhabricatorQuery',
Add basic per-object privacy policies Summary: Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change. Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request. The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens. We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can. Test Plan: Unit tests, played around in the UI with various policy settings. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
'PhabricatorPolicyTestCase' => 'PhabricatorTestCase',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'PhabricatorPolicyTestObject' => 'PhabricatorPolicyInterface',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorPolicyType' => 'PhabricatorPolicyConstants',
Rough cut of Project profile improvements Summary: - Old page was useless and dumb. - New page looks a little less bad, functions a little less poorly. - Still lots of work to be done. Test Plan: - Viewed a project. - Clicked all the links on the left nav. - Here is a screenshot: https://secure.phabricator.com/file/view/PHID-FILE-4buzquotb3fo4dhlicrw/ Reviewers: btrahan, jungejason Reviewed By: jungejason CC: aran, jungejason Maniphest Tasks: T681 Differential Revision: 1246
2011-12-17 05:01:38 +01:00
'PhabricatorProfileHeaderView' => 'AphrontView',
update library map (from D3200)
2012-08-10 00:42:44 +02:00
'PhabricatorProject' =>
array(
0 => 'PhabricatorProjectDAO',
1 => 'PhabricatorPolicyInterface',
),
Rough cut of projects. Summary: Test Plan: Reviewers: CC:
2011-02-21 03:41:23 +01:00
'PhabricatorProjectController' => 'PhabricatorController',
Allow affiliations to carry project ownership information; transform profile images correctly Summary: This is sort of doing two things at once: - Add an "isOwner" flag to Project Affiliation to lay the groundwork for T237. - Rename the "QuickCreate" workflow to "Create" and funnel all creation through it. - Reorganize the image transformation stuff and use it to correctly crop/resize uploaded images. Test Plan: Created and edited projects and affailiations. Uploaded project, user, and profile photos. Verified existing thumbnailing in Maniphest still works properly. Reviewed By: cadamo Reviewers: cadamo, aran, jungejason, tuomaspelkonen CC: aran, epriestley, cadamo Differential Revision: 529
2011-06-26 17:37:47 +02:00
'PhabricatorProjectCreateController' => 'PhabricatorProjectController',
Rough cut of projects. Summary: Test Plan: Reviewers: CC:
2011-02-21 03:41:23 +01:00
'PhabricatorProjectDAO' => 'PhabricatorLiskDAO',
If users are on the email to Phabricator, do not send them the Phabricator reply. Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email. Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected. Reviewers: epriestley, vrana Reviewed By: vrana CC: aran, Korvin, vrana Maniphest Tasks: T1676 Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 19:18:23 +02:00
'PhabricatorProjectEditor' => 'PhabricatorEditor',
Add project join/leave tests Summary: Add test coverage for joining and leaving projects. Test Plan: Ran tests. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3220
2012-08-11 16:05:20 +02:00
'PhabricatorProjectEditorTestCase' => 'PhabricatorTestCase',
Rough cut of projects. Summary: Test Plan: Reviewers: CC:
2011-02-21 03:41:23 +01:00
'PhabricatorProjectListController' => 'PhabricatorProjectController',
Make project membership edits use transactions and PHIDs and not be awful Summary: - Split project profile editing apart from project membership editing. - Make project membership editing simpler and easier to use. - Drop role / owner stuff from the UI. Test Plan: Added and removed project members. Edited project profile information. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3184
2012-08-07 20:57:38 +02:00
'PhabricatorProjectMembersEditController' => 'PhabricatorProjectController',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'PhabricatorProjectNameCollisionException' => 'Exception',
Rough cut of projects. Summary: Test Plan: Reviewers: CC:
2011-02-21 03:41:23 +01:00
'PhabricatorProjectProfile' => 'PhabricatorProjectDAO',
'PhabricatorProjectProfileController' => 'PhabricatorProjectController',
Project list and profile view modifications Summary: Added some change on the project's list view, to show information about active tasks, population, etc. Also modified the "profile view", and added a class "PhabricatorProfileView" to render the profile, both on projects and users. Test Plan: play around the project directory :) Reviewers: epriestley ericfrenkiel CC: Differential Revision: 477
2011-06-18 10:13:56 +02:00
'PhabricatorProjectProfileEditController' => 'PhabricatorProjectController',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorProjectQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Finished Project Generation Summary: Progress on T2903 Test Plan: Projects are generating. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5794
2013-04-29 21:17:55 +02:00
'PhabricatorProjectTestDataGenerator' => 'PhabricatorTestDataGenerator',
Add transaction-oriented editing to projects Summary: - Make some editing operations transaction-oriented, like Maniphest. (This seems to be a good model, particularly for extensibility.) I'll move the rest of the editing operations to transactions in future diffs. - Make transaction-oriented operations publish feed stories. Test Plan: - Created a new project. - Edited an existing project. - Created a new project via quick create flow from Maniphest. - Verified feed stories publish correctly. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T681 Differential Revision: https://secure.phabricator.com/D1477
2012-01-24 16:11:37 +01:00
'PhabricatorProjectTransaction' => 'PhabricatorProjectDAO',
'PhabricatorProjectTransactionType' => 'PhabricatorProjectConstants',
Add a Join / Leave button to Projects Summary: Make it easy to join or leave (well, slightly less easy) a project. Publish join/leave to feed. Fix a couple of membership editor bugs. Test Plan: Joined, left a project. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T681 Differential Revision: https://secure.phabricator.com/D1485
2012-01-25 20:51:20 +01:00
'PhabricatorProjectUpdateController' => 'PhabricatorProjectController',
Allow PhabricatorPropertyListView to have associated content Summary: Some objects (like PhamePost and ManiphestTask) have a block of text/remarkup which serves as a description or core piece of content for the object. Accommodate this in PhabricatorPropertyListView. (This is primarily to let me do a reasonable first pass on this in Phame.) Test Plan: Made example, will attach screenshot. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3699
2012-10-15 23:50:53 +02:00
'PhabricatorPropertyListExample' => 'PhabricatorUIExample',
Modernize Paste Summary: - Add a PhabricatorApplication. - Make most of the views work well on tablets / phones. The actual "Create" form doesn't, but everything else is good -- need to make device-friendly form layouts before I can do the form. Test Plan: Will attach screenshots. Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3293
2012-08-15 19:45:06 +02:00
'PhabricatorPropertyListView' => 'AphrontView',
Move Recaptcha config to PHP Summary: Bring these over. Also sort the group list. Test Plan: Viewed config. Reviewers: btrahan, codeblock, chad Reviewed By: chad CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4338
2013-01-03 18:17:38 +01:00
'PhabricatorRecaptchaConfigOptions' => 'PhabricatorApplicationConfigOptions',
Automatically redirect 404's that wouldn't be 404s if they had a trailing slash to their trailing-slash counterparts.
2011-04-04 19:29:46 +02:00
'PhabricatorRedirectController' => 'PhabricatorController',
Fix conservative CSRF token cycling limit Summary: We currently cycle CSRF tokens every hour and check for the last two valid ones. This means that a form could go stale in as little as an hour, and is certainly stale after two. When a stale form is submitted, you basically get a terrible heisen-state where some of your data might persist if you're lucky but more likely it all just vanishes. The .js file below outlines some more details. This is a pretty terrible UX and we don't need to be as conservative about CSRF validation as we're being. Remedy this problem by: - Accepting the last 6 CSRF tokens instead of the last 1 (i.e., pages are valid for at least 6 hours, and for as long as 7). - Using JS to refresh the CSRF token every 55 minutes (i.e., pages connected to the internet are valid indefinitely). - Showing the user an explicit message about what went wrong when CSRF validation fails so the experience is less bewildering. They should now only be able to submit with a bad CSRF token if: - They load a page, disconnect from the internet for 7 hours, reconnect, and submit the form within 55 minutes; or - They are actually the victim of a CSRF attack. We could eventually fix the first one by tracking reconnects, which might be "free" once the notification server gets built. It will probably never be an issue in practice. Test Plan: - Reduced CSRF cycle frequency to 2 seconds, submitted a form after 15 seconds, got the CSRF exception. - Reduced csrf-refresh cycle frequency to 3 seconds, submitted a form after 15 seconds, got a clean form post. - Added debugging code the the csrf refresh to make sure it was doing sensible things (pulling different tokens, finding all the inputs). Reviewed By: aran Reviewers: tuomaspelkonen, jungejason, aran CC: aran, epriestley Differential Revision: 660
2011-07-13 23:05:18 +02:00
'PhabricatorRefreshCSRFController' => 'PhabricatorAuthController',
New Registration Workflow Summary: Currently, registration and authentication are pretty messy. Two concrete problems: - The `PhabricatorLDAPRegistrationController` and `PhabricatorOAuthDefaultRegistrationController` controllers are giant copy/pastes of one another. This is really bad. - We can't practically implement OpenID because we can't reissue the authentication request. Additionally, the OAuth registration controller can be replaced wholesale by config, which is a huge API surface area and a giant mess. Broadly, the problem right now is that registration does too much: we hand it some set of indirect credentials (like OAuth tokens) and expect it to take those the entire way to a registered user. Instead, break registration into smaller steps: - User authenticates with remote service. - Phabricator pulls information (remote account ID, username, email, real name, profile picture, etc) from the remote service and saves it as `PhabricatorUserCredentials`. - Phabricator hands the `PhabricatorUserCredentials` to the registration form, which is agnostic about where they originate from: it can process LDAP credentials, OAuth credentials, plain old email credentials, HTTP basic auth credentials, etc. This doesn't do anything yet -- there is no way to create credentials objects (and no storage patch), but I wanted to get any initial feedback, especially about the event call for T2394. In particular, I think the implementation would look something like this: $profile = $event->getValue('profile') $username = $profile->getDefaultUsername(); $is_employee = is_this_a_facebook_employee($username); if (!$is_employee) { throw new Exception("You are not employed at Facebook."); } $fbid = get_fbid_for_facebook_username($username); $profile->setDefaultEmail($fbid); $profile->setCanEditUsername(false); $profile->setCanEditEmail(false); $profile->setCanEditRealName(false); $profile->setShouldVerifyEmail(true); Seem reasonable? Test Plan: N/A yet, probably fatals. Reviewers: vrana, btrahan, codeblock, chad Reviewed By: btrahan CC: aran, asherkin, nh, wez Maniphest Tasks: T1536, T2394 Differential Revision: https://secure.phabricator.com/D4647
2013-06-16 19:13:49 +02:00
'PhabricatorRegistrationProfile' => 'Phobject',
Make a PhabricatorRemarkupControl to de-duplicate code usage around adding a Remarkup reference to a TextAreaControl. Summary: ...also makes Maniphest Task Edit Controller use this when its not appropriate to upsell email. Test Plan: played around with each tool and verified the Remarkup reference was present Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1756 Differential Revision: https://secure.phabricator.com/D3468
2012-09-19 21:27:28 +02:00
'PhabricatorRemarkupControl' => 'AphrontFormTextAreaControl',
Rough implementation of drag-and-drop file uploads Summary: This gets all the major pieces working. Allows you to drag-and-drop files in Differential and Phriction, and embed files in remarkup with {Fxxx} references. See also task. I'm explicitly not documenting this yet since it's still pretty rough. Test Plan: Dragged and dropped stuff into Differential and Phriction. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran, tomo Commenters: tomo CC: aran, tomo, jungejason Differential Revision: 674
2011-07-15 23:17:55 +02:00
'PhabricatorRemarkupRuleEmbedFile' => 'PhutilRemarkupRule',
Image macros for Phabricator! Summary: Added long waited image macro support for differential and others. Test Plan: Tried a couple of different macros and made sure they appear nicely in the comment preview. Made sure that the normal comments are shown correctly. Reviewed By: epriestley Reviewers: epriestley CC: jungejason, tuomaspelkonen, epriestley Differential Revision: 129
2011-04-14 00:15:48 +02:00
'PhabricatorRemarkupRuleImageMacro' => 'PhutilRemarkupRule',
Rough implementation of the "Add Meme" button Summary: This needs some tweaks but I'll follow up with @DeedyDas in T2353. Test Plan: So many memes. Reviewers: chad, btrahan, DeedyDas Reviewed By: chad CC: aran Maniphest Tasks: T2353 Differential Revision: https://secure.phabricator.com/D4616
2013-01-24 18:57:58 +01:00
'PhabricatorRemarkupRuleMeme' => 'PhutilRemarkupRule',
Basic @mentions support Summary: Provides basic Remarkup support for @mentions. No application integration yet so these aren't terribly useful until that happens. Test Plan: https://secure.phabricator.com/file/view/PHID-FILE-83d68e7af6085ae928df/ Reviewers: tomo, mroch, jsp Commenters: tomo CC: aran, tomo, epriestley Differential Revision: 517
2011-06-24 19:59:57 +02:00
'PhabricatorRemarkupRuleMention' => 'PhutilRemarkupRule',
Prepare for hovercards Summary: - Unify all the reference/embed Remarkup rules for Differential, Maniphest, Paste and Ponder. - Add rules for Pholio. - Does not yet unify Diffusion or Files (both are a bit more involved). - Prepare for hovercards. Test Plan: {F33894} Reviewers: chad, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5120
2013-02-26 23:59:31 +01:00
'PhabricatorRemarkupRuleObject' => 'PhutilRemarkupRule',
Embedded youtube videos. Summary: Markup support for embedding Youtube videos. Test Plan: https://www.youtube.com/watch?v=Vw4KVoEVcr0 was embedded Reviewed By: epriestley Reviewers: epriestley CC: aran, epriestley Differential Revision: 353
2011-05-27 21:50:02 +02:00
'PhabricatorRemarkupRuleYoutube' => 'PhutilRemarkupRule',
Make Repositories partially policy-aware Summary: Small step toward repository hosting. No user-visible changes. Test Plan: Looked at repositories in Diffusion. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D4227
2012-12-19 20:07:06 +01:00
'PhabricatorRepository' =>
array(
0 => 'PhabricatorRepositoryDAO',
1 => 'PhabricatorPolicyInterface',
Provide transaction-based edits of repository encoding Summary: Adds support for the "encoding" field to the new transactional interface. Test Plan: {F44189} {F44190} Some of the encodings in the second screen are from testing, and can no longer be set. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6035
2013-05-25 15:30:38 +02:00
2 => 'PhabricatorMarkupInterface',
Make Repositories partially policy-aware Summary: Small step toward repository hosting. No user-visible changes. Test Plan: Looked at repositories in Diffusion. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D4227
2012-12-19 20:07:06 +01:00
),
Sync up UUIDs and create project configs.
2011-04-06 05:49:31 +02:00
'PhabricatorRepositoryArcanistProject' => 'PhabricatorRepositoryDAO',
allow arcanist projects to be deleted via the ui Summary: tricky part is purging symbols at that time too. override "delete" method to get there, use transactions, etc. Test Plan: deleted an arcanist project - it worked! Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, mbishopim3 Maniphest Tasks: T1738 Differential Revision: https://secure.phabricator.com/D3613
2012-10-04 22:25:58 +02:00
'PhabricatorRepositoryArcanistProjectDeleteController' => 'PhabricatorRepositoryController',
Sync up UUIDs and create project configs.
2011-04-06 05:49:31 +02:00
'PhabricatorRepositoryArcanistProjectEditController' => 'PhabricatorRepositoryController',
Migrate "PhabricatorOwnersPackageCommitRelationship" to "PhabricatorRepositoryAuditRequest" Summary: - Move table to Repository, since we have no Owners joins in the application anymore but would like to do a Repository join. - Rename "packagePHID" to "auditorPHID", since this column may contain package, project, or user PHIDs. Test Plan: - Browsed Owners, Audit, and Differential interfaces to the Audit tool. - Made comments and state changes. - Ran "reparse.php --herald --owners" on several commits. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley, nh, vrana Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1787
2012-03-05 22:17:29 +01:00
'PhabricatorRepositoryAuditRequest' => 'PhabricatorRepositoryDAO',
Allow saving lint errors to database Summary: This saves lint errors to the path change of current commit. It requires pushed revision. It doesn't save difference from previous commit mentioned in T2038#comment-4 - I don't plan doing it after all, everything would be much more complicated and the amount of data saved with this approach isn't that bad. Test Plan: Applied patch, ran script, verified DB. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2038 Differential Revision: https://secure.phabricator.com/D3899
2012-11-06 08:09:36 +01:00
'PhabricatorRepositoryBranch' => 'PhabricatorRepositoryDAO',
Prepare Diffusion for hovercards Summary: Move Diffusion to be hovercard-ready, and expand our ability to resolve commit references. - Link unqualified hashes of 7 characters or more which match a commit. - Link qualified hashes of 5 characters or more which match a commit. - Support `{...}` syntax. Test Plan: {F33896} Reviewers: chad, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5121
2013-02-27 17:04:54 +01:00
'PhabricatorRepositoryCommit' =>
array(
0 => 'PhabricatorRepositoryDAO',
1 => 'PhabricatorPolicyInterface',
Arc liberate fix Summary: Run arc liberate and commit the results on the assumption that someone forgot to do this in another diff, or their results were discarded by an automatic merge during rebase. Test Plan: None. Reviewers: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5889
2013-05-10 18:11:14 +02:00
2 => 'PhabricatorTokenReceiverInterface',
Prepare Diffusion for hovercards Summary: Move Diffusion to be hovercard-ready, and expand our ability to resolve commit references. - Link unqualified hashes of 7 characters or more which match a commit. - Link qualified hashes of 5 characters or more which match a commit. - Support `{...}` syntax. Test Plan: {F33896} Reviewers: chad, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5121
2013-02-27 17:04:54 +01:00
),
Increase parseriness of some parsery things. Summary: None of these are parsnips. Test Plan: Reviewers: CC:
2011-03-11 18:34:22 +01:00
'PhabricatorRepositoryCommitChangeParserWorker' => 'PhabricatorRepositoryCommitParserWorker',
'PhabricatorRepositoryCommitData' => 'PhabricatorRepositoryDAO',
HeraldCommitAdapter and some related junk.
2011-04-04 08:23:36 +02:00
'PhabricatorRepositoryCommitHeraldWorker' => 'PhabricatorRepositoryCommitParserWorker',
Increase parseriness of some parsery things. Summary: None of these are parsnips. Test Plan: Reviewers: CC:
2011-03-11 18:34:22 +01:00
'PhabricatorRepositoryCommitMessageParserWorker' => 'PhabricatorRepositoryCommitParserWorker',
Add Related Commits for Owners Summary: For each commit, find the affected packages, and provide a way to search by package. Test Plan: create commits that touch and don't touch two packages, and verify that they display correctly in all the UI pages. Reviewers: epriestley, blair, nh, tuomaspelkonen Reviewed By: epriestley CC: benmathews, aran, epriestley, btrahan, jungejason, mpodobnik, prithvi Maniphest Tasks: T83 Differential Revision: 1208
2011-12-14 09:53:25 +01:00
'PhabricatorRepositoryCommitOwnersWorker' => 'PhabricatorRepositoryCommitParserWorker',
Increase parseriness of some parsery things. Summary: None of these are parsnips. Test Plan: Reviewers: CC:
2011-03-11 18:34:22 +01:00
'PhabricatorRepositoryCommitParserWorker' => 'PhabricatorWorker',
Improve Search architecture Summary: The search indexing API has several problems right now: - Always runs in-process. - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it. - Being able to use the task queue will also make rebuilding indexes faster. - Instead, make the API phid-oriented. - No uniform indexing API. - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird. - Instead, provide a uniform API. - No uniform CLI. - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers. - Instead, let indexers expose documents for indexing. - Not application-oriented. - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world. - Instead, move indexers to applications and load them with SymbolLoader. Test Plan: - `bin/search index` - Indexed one revision, one task. - Indexed `--type TASK`, `--type DREV`, etc., for all types. - Indexed `--all`. - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it. - Creating users is a pain; searched for a user after indexing. - Creating commits is a pain; searched for a commit after indexing. - Mocks aren't currently loadable in the result view, so their indexing is moot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: 20after4, aran Maniphest Tasks: T1991, T2104 Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
'PhabricatorRepositoryCommitSearchIndexer' => 'PhabricatorSearchDocumentIndexer',
Repository option. Test Plan: Looked at the option. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4468
2013-01-16 18:35:47 +01:00
'PhabricatorRepositoryConfigOptions' => 'PhabricatorApplicationConfigOptions',
Rough cut of Repositories and GitHub post-receive hooks. Summary: Test Plan: Reviewers: CC:
2011-02-13 03:26:15 +01:00
'PhabricatorRepositoryController' => 'PhabricatorController',
Diffusion change parser for SVN. Summary: there is a small possibility this works correctly Test Plan: Reviewers: CC:
2011-03-11 23:13:23 +01:00
'PhabricatorRepositoryCreateController' => 'PhabricatorRepositoryController',
Rough cut of Repositories and GitHub post-receive hooks. Summary: Test Plan: Reviewers: CC:
2011-02-13 03:26:15 +01:00
'PhabricatorRepositoryDAO' => 'PhabricatorLiskDAO',
Fix repository deletion Summary: I never actually wrote this controller. Test Plan: Deleted a repository via web UI. Reviewed By: tuomaspelkonen Reviewers: tuomaspelkonen, jungejason, aran Commenters: aran CC: aran, tuomaspelkonen, epriestley Differential Revision: 231
2011-05-05 21:53:39 +02:00
'PhabricatorRepositoryDeleteController' => 'PhabricatorRepositoryController',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorRepositoryDiscoveryEngine' => 'PhabricatorRepositoryEngine',
Diffusion change parser for SVN. Summary: there is a small possibility this works correctly Test Plan: Reviewers: CC:
2011-03-11 23:13:23 +01:00
'PhabricatorRepositoryEditController' => 'PhabricatorRepositoryController',
Begin transacitonalizing repository edits and provide a more sensible edit interface Summary: Ref T2231, T603. Plan of attack here is pretty much: - Built out a new (currently not linked in the UI) edit interface in Diffusion which is transaction-based and has a sensible layout. - Build out a new create interface based on PagedForm which dumps into the new edit interface. - Throw the old stuff away. - Everyone lives happily ever after. Test Plan: {F44163} {F44164} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D6029
2013-05-24 21:37:42 +02:00
'PhabricatorRepositoryEditor' => 'PhabricatorApplicationTransactionEditor',
Increase parseriness of some parsery things. Summary: None of these are parsnips. Test Plan: Reviewers: CC:
2011-03-11 18:34:22 +01:00
'PhabricatorRepositoryGitCommitChangeParserWorker' => 'PhabricatorRepositoryCommitChangeParserWorker',
'PhabricatorRepositoryGitCommitMessageParserWorker' => 'PhabricatorRepositoryCommitMessageParserWorker',
Diffusion change parser for SVN. Summary: there is a small possibility this works correctly Test Plan: Reviewers: CC:
2011-03-11 23:13:23 +01:00
'PhabricatorRepositoryListController' => 'PhabricatorRepositoryController',
upgrade repository delete function to full-blown workflow Summary: fancy title. really just make the delete() method aware of related objects and build a quick workflow which calls delete(). also make commit delete savvy about audit requests. Test Plan: deleted a repository per the instructions given to me in the web UI Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1416, T1958, T1372 Differential Revision: https://secure.phabricator.com/D3822
2012-10-26 01:23:41 +02:00
'PhabricatorRepositoryManagementDeleteWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Introduce "bin/repository" for repository management Summary: Nothing new or exciting here yet, just moving the random scripts/repositories/ things to bin/repository. Also add `repository list`. (Console stuff comes from D2841.) Test Plan: Ran `repository list`, `repository pull`, `repository discover`, `repository discover --verbose`, `repository help`. Reviewers: jungejason, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2849
2012-06-25 21:35:37 +02:00
'PhabricatorRepositoryManagementDiscoverWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
'PhabricatorRepositoryManagementListWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
'PhabricatorRepositoryManagementPullWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
'PhabricatorRepositoryManagementWorkflow' => 'PhutilArgumentWorkflow',
Basic support for Mercurial in Diffusion Summary: Change import script plus almost all the view stuff. Still some rough edges but this seems to mostly work. Blame is currently unsupported but I think everything else works properly. Test Plan: Imported the hg repository itself. It doesn't immediately seem completely broken. Here are some screens: https://secure.phabricator.com/file/view/PHID-FILE-1438b71cc7c4a2eb4569/ https://secure.phabricator.com/file/view/PHID-FILE-3cec4f72f39e7de2d041/ https://secure.phabricator.com/file/view/PHID-FILE-2ea4883f160e8e5098f9/ https://secure.phabricator.com/file/view/PHID-FILE-35f751a36ebf65399ade/ All the parsers were able to churn through it without errors. Ran the new "reparse.php" script in various one-commit and repository modes. Browsed/imported some git repos for good measure. NOTE: The hg repository is only 15,000 commits and around 1,000 files. Performance is okay but hg doesn't provide performant, native APIs to get some data efficiently so we have to do some dumb stuff. If some of these interfaces are cripplingly slow or whatever, let me know and we can start bundling some Mercurial extensions with Arcanist. Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran Reviewed By: Makinde CC: aran, Makinde, epriestley Differential Revision: 960
2011-09-26 20:07:38 +02:00
'PhabricatorRepositoryMercurialCommitChangeParserWorker' => 'PhabricatorRepositoryCommitChangeParserWorker',
Add a Mercurial message parser Summary: See D943, this is the second parse stage. This will mark Differential revisions as "Committed" among other things. Almost all the logic here is shared between VCSes so the implementation itself is straightforward. Test Plan: Parsed all messages for the official Mercurial repository. Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran Reviewed By: Makinde CC: aran, Makinde Differential Revision: 944
2011-09-16 18:37:15 +02:00
'PhabricatorRepositoryMercurialCommitMessageParserWorker' => 'PhabricatorRepositoryCommitMessageParserWorker',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorRepositoryPullEngine' => 'PhabricatorRepositoryEngine',
Run one daemon to pull all working copies, not one daemon per working copy Summary: Allow the pull daemon to take a list of repositories. By default, pull all repositories. Make some effort to respect pull frequencies, although we'll necessarily suffer a bit if running with only one process. NOTE: We still launch one discovery daemon per working copy, so this only cuts the daemon count in half. Test Plan: - Ran `phd debug pulllocal`, verified behavior. - Ran `pull.php P MTEST SVNTEST --trace`, verified it pulled the repos and ran the right commands. - Ran `phd repository-launch-master`, verified the right daemons launched, checked daemon console. - Ran `phd repository-launch-readonly`, verified the right daemon launched, checked daemon console. Reviewers: btrahan, csilvers, davidreuss Reviewed By: csilvers CC: aran Differential Revision: https://secure.phabricator.com/D2418
2012-05-08 00:01:10 +02:00
'PhabricatorRepositoryPullLocalDaemon' => 'PhabricatorDaemon',
Make Repositories partially policy-aware Summary: Small step toward repository hosting. No user-visible changes. Test Plan: Looked at repositories in Diffusion. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D4227
2012-12-19 20:07:06 +01:00
'PhabricatorRepositoryQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Restore "Shortcuts" feature to Diffusion.
2011-03-31 09:33:44 +02:00
'PhabricatorRepositoryShortcut' => 'PhabricatorRepositoryDAO',
Diffusion change parser for SVN. Summary: there is a small possibility this works correctly Test Plan: Reviewers: CC:
2011-03-11 23:13:23 +01:00
'PhabricatorRepositorySvnCommitChangeParserWorker' => 'PhabricatorRepositoryCommitChangeParserWorker',
Increase parseriness of some parsery things. Summary: None of these are parsnips. Test Plan: Reviewers: CC:
2011-03-11 18:34:22 +01:00
'PhabricatorRepositorySvnCommitMessageParserWorker' => 'PhabricatorRepositoryCommitMessageParserWorker',
Add storage for repository symbol tracking Summary: See T315 for an extensive description of this feature. Adds the descibed storage table. Test Plan: Used phpsh to read/write symbol objects. Reviewers: jungejason, nh, tuomaspelkonen, aran Reviewed By: tuomaspelkonen CC: aran, epriestley, tuomaspelkonen Differential Revision: 897
2011-09-05 02:31:16 +02:00
'PhabricatorRepositorySymbol' => 'PhabricatorRepositoryDAO',
Relax the same-origin check in the Git commit discovery daemon Summary: Git accepts either "git@x:/path" or "ssh://git@x.com/path" URIs to mean the exact same thing, which is causing some false positives and confusion, particularly because we sometimes mutate URIs. Since this is just a sanity check, we don't really care about the username, domain or credentials -- matching the paths is good enough. We're just trying to make it hard to shoot yourself in the foot by copy-pasting the same local path into two repositories and forgetting to change one, like I did. :P Relax the check to only verify the paths are the same. Test Plan: - Ran unit tests, which should fully cover things. - Ran commit discovery daemon in debug mode on incorrectly and correctly configured repositories. Reviewers: ajtrichards, jungejason, btrahan Reviewed By: jungejason CC: aran, jungejason Maniphest Tasks: T710 Differential Revision: https://secure.phabricator.com/D1279
2011-12-23 17:11:11 +01:00
'PhabricatorRepositoryTestCase' => 'PhabricatorTestCase',
Begin transacitonalizing repository edits and provide a more sensible edit interface Summary: Ref T2231, T603. Plan of attack here is pretty much: - Built out a new (currently not linked in the UI) edit interface in Diffusion which is transaction-based and has a sensible layout. - Build out a new create interface based on PagedForm which dumps into the new edit interface. - Throw the old stuff away. - Everyone lives happily ever after. Test Plan: {F44163} {F44164} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D6029
2013-05-24 21:37:42 +02:00
'PhabricatorRepositoryTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorRepositoryTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Add an Amazon S3 storage engine for Phabricator Summary: Implements an S3 storage engine option for Phabricator. Test Plan: - Uploaded files to S3. - Looked at them. - Verified they appeared in S3 using the S3 file browser. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason Differential Revision: 752
2011-07-31 22:54:58 +02:00
'PhabricatorS3FileStorageEngine' => 'PhabricatorFileStorageEngine',
Implement SSHD glue and Conduit SSH endpoint Summary: - Build "sshd-auth" (for authentication) and "sshd-exec" (for command execution) binaries. These are callable by "sshd-vcs", located [[https://github.com/epriestley/sshd-vcs | in my account on GitHub]]. They are based on precursors [[https://github.com/epriestley/sshd-vcs-glue | here on GitHub]] which I deployed for TenXer about a year ago, so I have some confidence they at least basically work. - The problem this solves is that normally every user would need an account on a machine to connect to it, and/or their public keys would all need to be listed in `~/.authorized_keys`. This is a big pain in most installs. Software like Gitosis/Gitolite solve this problem by giving you an easy way to add public keys to `~/.authorized_keys`, but this is pretty gross. - Roughly, instead of looking in `~/.authorized_keys` when a user connects, the patched sshd instead runs `echo <public key> | sshd-auth`. The `sshd-auth` script looks up the public key and authorizes the matching user, if they exist. It also forces sshd to run `sshd-exec` instead of a normal shell. - `sshd-exec` receives the authenticated user and any command which was passed to ssh (like `git receive-pack`) and can route them appropriately. - Overall, this permits a single account to be set up on a server which all Phabricator users can connect to without any extra work, and which can safely execute commands and apply appropriate permissions, and disable users when they are disabled in Phabricator and all that stuff. - Build out "sshd-exec" to do more thorough checks and setup, and delegate command execution to Workflows (they now exist, and did not when I originally built this stuff). - Convert @btrahan's conduit API script into a workflow and slightly simplify it (ConduitCall did not exist at the time it was written). The next steps here on the Repository side are to implement Workflows for Git, SVN and HG wire protocols. These will mostly just proxy the protocols, but also need to enforce permissions. So the approach will basically be: - Implement workflows for stuff like `git receive-pack`. - These workflows will implement enough of the underlying protocol to determine what resource the user is trying to access, and whether they want to read or write it. - They'll then do a permissons check, and kick the user out if they don't have permission to do whatever they are trying to do. - If the user does have permission, we just proxy the rest of the transaction. Next steps on the Conduit side are more simple: - Make ConduitClient understand "ssh://" URLs. Test Plan: Ran `sshd-exec --phabricator-ssh-user epriestley conduit differential.query`, etc. This will get a more comprehensive test once I set up sshd-vcs. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T550 Differential Revision: https://secure.phabricator.com/D4229
2012-12-19 20:08:07 +01:00
'PhabricatorSSHWorkflow' => 'PhutilArgumentWorkflow',
Introduce PhabricatorSavedQueryQuery Summary: Same as D6051, but for SavedQueries instead of NamedQueries. These are POLICY_PUBLIC because you need to know the hash to access them, and because we want to let users copy/paste query URLs. Ref T2625. Test Plan: Saved a query, reused a saved query. Reviewers: btrahan, blc Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6054
2013-05-27 22:41:20 +02:00
'PhabricatorSavedQuery' =>
array(
0 => 'PhabricatorSearchDAO',
1 => 'PhabricatorPolicyInterface',
),
'PhabricatorSavedQueryQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add "final" to all Phabricator "Controller" classes Summary: These are all unambiguously unextensible. Issues I hit: - Maniphest Change/Diff controllers, just consolidated them. - Some search controllers incorrectly extend from "Search" but should extend from "SearchBase". This has no runtime effects. - D1836 introduced a closure, which we don't handle correctly (somewhat on purpose; we target PHP 5.2). See T962. Test Plan: Ran "testEverythingImplemented" unit test to identify classes extending from `final` classes. Resolved issues. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T795 Differential Revision: https://secure.phabricator.com/D1843
2012-03-10 00:46:25 +01:00
'PhabricatorSearchAttachController' => 'PhabricatorSearchBaseController',
Rought cut of search. Summary: Botched this pretty badly in git so we'll see how much I broke. :/ Test Plan: Reviewers: CC:
2011-02-15 00:34:20 +01:00
'PhabricatorSearchBaseController' => 'PhabricatorController',
Search options. Test Plan: - Looked at the new options - Saved `search.engine-selector` successfully. Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4410
2013-01-12 00:28:16 +01:00
'PhabricatorSearchConfigOptions' => 'PhabricatorApplicationConfigOptions',
Rought cut of search. Summary: Botched this pretty badly in git so we'll see how much I broke. :/ Test Plan: Reviewers: CC:
2011-02-15 00:34:20 +01:00
'PhabricatorSearchController' => 'PhabricatorSearchBaseController',
'PhabricatorSearchDAO' => 'PhabricatorLiskDAO',
Allow custom queries to be deleted Summary: Ref T2625. Currently, custom saved queries can be edited but not deleted. Allow them to be deleted. Also: - Clean up an unused property in `PhabricatorPasteViewController`. - Fix an issue with left nav highlighting of builtin queries. - Improve submit behavior for edits. - Add a cancel button on edits. Test Plan: Saved, edited and deleted queries. Reviewers: btrahan, blc Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6059
2013-05-27 22:42:44 +02:00
'PhabricatorSearchDeleteController' => 'PhabricatorSearchBaseController',
Rought cut of search. Summary: Botched this pretty badly in git so we'll see how much I broke. :/ Test Plan: Reviewers: CC:
2011-02-15 00:34:20 +01:00
'PhabricatorSearchDocument' => 'PhabricatorSearchDAO',
'PhabricatorSearchDocumentField' => 'PhabricatorSearchDAO',
'PhabricatorSearchDocumentRelationship' => 'PhabricatorSearchDAO',
Make saved queries editable Summary: Ref T2625. Rename the "Name" controller to "Edit" and allow it to edit named queries. Also some UI touchups. Add an edit link to the saved query browse view. Test Plan: Created and edited named queries. Reviewers: btrahan, blc Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6056
2013-05-27 22:42:01 +02:00
'PhabricatorSearchEditController' => 'PhabricatorSearchBaseController',
[NO CLUE WHAT I'M DOING] Add an Elasticsearch engine Summary: I have no idea what I'm doing, but here's part of an elasticsearch engine. These things work: - Indexing stuff (??) - Searching for text/type? - Reconstructing things?? All the complicated stuff doesn't work. I'm having a hard time figuring out the best way to model things because elasticsearch's documentation is not exactly the most complete or illuminating. @amckinley, does this look sane-ish so far? Particularly, the /phabricator/<type>/<phid>/ URI scheme and how I've set up the relationships and fields in the documents? How should I model the relationship and field queries? I want, like, an "equal" query but it seems like I've got "text" or "term" to work with and neither are exact match? And "term" doesn't consider PHIDs to be terms since they have hyphens in them? I'll keep kind of slogging my way forward here but if you have valuable wisdom to share it would probably get me to a better end state much faster. The whole query construction phase is pretty much black magic to me. Test Plan: nyancat Reviewers: amckinley, vrana Reviewed By: vrana CC: jungejason, tuomaspelkonen, aran, 20after4, vrana Differential Revision: https://secure.phabricator.com/D790
2012-04-21 00:33:09 +02:00
'PhabricatorSearchEngineElastic' => 'PhabricatorSearchEngine',
Provide an indirection layer between documents and the search engine Summary: In preparation for adding another search engine (see T355): - Rename "executor" to "engine". - Move all engine-specific operations into the engine. Specifically, this means that indexing moves out of the document store and into the engine (it was sort of silly where it was before). - Split choice of an engine into an overridable "selector" class, a base API, and a concrete MySQL implementation (just like storage engine selection). - Make all callers go through the indirection layer. The default selector just unconditionally selects the MySQL engine, but now (with D786) I can build an Elastic Search engine and you guys can build a multi-target engine if you want and I don't get there fast enough. Test Plan: - Created a new document (task). - Searched for and found it. - Viewed index reconstruction. Reviewed By: jungejason Reviewers: jungejason, amckinley, tuomaspelkonen, aran CC: aran, jungejason, epriestley Differential Revision: 788
2011-08-08 00:14:23 +02:00
'PhabricatorSearchEngineMySQL' => 'PhabricatorSearchEngine',
Added basic hovercard controller Summary: Refs T1048; Depends on D5542, D5543, D5544 - It currently just renders multiple hovercards nicely for test purposes. More is on the way. Mode `test`: Human test chamber. Mode `retrieve`: For JS. Added so it would not clash with search key routing. badassery Test Plan: `/search/hovercard/test/?phids[hover-T4]=PHID-TASK-g5pduvwrrwvkq5gkx736&phids[hover-T2]=PHID-TASK-gta6lzaaagziavkktima` Verified the appearance of two tasks with correct rendering and correct ids Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1048 Differential Revision: https://secure.phabricator.com/D5545
2013-04-03 17:31:27 +02:00
'PhabricatorSearchHovercardController' => 'PhabricatorSearchBaseController',
Improve Search architecture Summary: The search indexing API has several problems right now: - Always runs in-process. - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it. - Being able to use the task queue will also make rebuilding indexes faster. - Instead, make the API phid-oriented. - No uniform indexing API. - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird. - Instead, provide a uniform API. - No uniform CLI. - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers. - Instead, let indexers expose documents for indexing. - Not application-oriented. - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world. - Instead, move indexers to applications and load them with SymbolLoader. Test Plan: - `bin/search index` - Indexed one revision, one task. - Indexed `--type TASK`, `--type DREV`, etc., for all types. - Indexed `--all`. - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it. - Creating users is a pain; searched for a user after indexing. - Creating commits is a pain; searched for a commit after indexing. - Mocks aren't currently loadable in the result view, so their indexing is moot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: 20after4, aran Maniphest Tasks: T1991, T2104 Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
'PhabricatorSearchManagementIndexWorkflow' => 'PhabricatorSearchManagementWorkflow',
'PhabricatorSearchManagementWorkflow' => 'PhutilArgumentWorkflow',
Allow named queries to be reordered by dragging Summary: Also you have to drop them. So drag, and then drop. This needs some cleanup and reconciliation/generalization with the Maniphest implementation. In particular, you can't drag things to the very top right now, and they should share more CSS and more behaviors. Test Plan: Look I alphabetized them: {F45286} Reviewers: chad Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6136
2013-06-06 01:22:27 +02:00
'PhabricatorSearchOrderController' => 'PhabricatorSearchBaseController',
Rought cut of search. Summary: Botched this pretty badly in git so we'll see how much I broke. :/ Test Plan: Reviewers: CC:
2011-02-15 00:34:20 +01:00
'PhabricatorSearchQuery' => 'PhabricatorSearchDAO',
Improve search result listing Summary: Make it prettier, paginate, add user pictures, show document types, clean some stuff up a little. Plenty of room for improvement but this should make it a lot more useful. Test Plan: Here's what the new one looks like: https://secure.phabricator.com/file/view/PHID-FILE-edce2b83c2e3a121c2b7/ Reviewed By: jungejason Reviewers: tomo, jungejason, aran, tuomaspelkonen, mroch Commenters: tomo CC: aran, tomo, jungejason, epriestley Differential Revision: 545
2011-06-28 23:35:02 +02:00
'PhabricatorSearchResultView' => 'AphrontView',
Add "final" to all Phabricator "Controller" classes Summary: These are all unambiguously unextensible. Issues I hit: - Maniphest Change/Diff controllers, just consolidated them. - Some search controllers incorrectly extend from "Search" but should extend from "SearchBase". This has no runtime effects. - D1836 introduced a closure, which we don't handle correctly (somewhat on purpose; we target PHP 5.2). See T962. Test Plan: Ran "testEverythingImplemented" unit test to identify classes extending from `final` classes. Resolved issues. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T795 Differential Revision: https://secure.phabricator.com/D1843
2012-03-10 00:46:25 +01:00
'PhabricatorSearchSelectController' => 'PhabricatorSearchBaseController',
Add the "Security" config group options. Summary: Added all the "Security" group options listed in T2255. Test Plan: - Looked at all the options. - Tested validation on `security.alternate-file-domain` Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4334
2013-01-03 14:45:23 +01:00
'PhabricatorSecurityConfigOptions' => 'PhabricatorApplicationConfigOptions',
Bring SendGrid configuration into PHP Summary: Port more settings. Test Plan: Looked at, edited settings. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4442
2013-01-15 21:04:05 +01:00
'PhabricatorSendGridConfigOptions' => 'PhabricatorApplicationConfigOptions',
Move Settings to a separate directory Summary: We currently have two relatively distinct applications, "People" and "Settings", living in /people/. Move settings to its own directory. This renames a couple of classes but makes no real code changes. Test Plan: Browsed /settings/, changed some settings. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569, T631 Differential Revision: https://secure.phabricator.com/D3256
2012-08-13 21:37:18 +02:00
'PhabricatorSettingsAdjustController' => 'PhabricatorController',
'PhabricatorSettingsMainController' => 'PhabricatorController',
Make settings panels more modular and modern Summary: Currently, we have a hard-coded list of settings panels. Make them a bit more modular. - Allow new settings panels to be defined by third-party code (see {D2340}, for example -- @ptarjan). - This makes the OAuth stuff more flexible for {T887} / {T1536}. - Reduce the number of hard-coded URIs in various places. Test Plan: Viewed / edited every option in every panel. Grepped for all references to these URIs. Reviewers: btrahan, vrana, ptarjan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3257
2012-08-13 21:37:26 +02:00
'PhabricatorSettingsPanelAccount' => 'PhabricatorSettingsPanel',
'PhabricatorSettingsPanelConduit' => 'PhabricatorSettingsPanel',
Conpherence - add per thread notification setting Summary: Introduces a new settings panel for Conpherence specific settings. Test Plan: started a thread with a test user, thus two participants total. Replied to conpherence, toggling notification settings in between. Verified 1 or 2 emails were sent as appropos to the current toggle. Toggled global setting and verified setting was updated in conpherences where nothing was specified. Verified setting conpherence setting overrides global setting. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2521 Differential Revision: https://secure.phabricator.com/D5391
2013-03-26 21:30:35 +01:00
'PhabricatorSettingsPanelConpherencePreferences' => 'PhabricatorSettingsPanel',
Add a preference to completely disable the file tree Summary: See D4812. - This preference disables the file tree completely. - It defaults off, so users who want it will have to go turn it on. - Maybe slightly cleaner would be doing this if the tree was hidden and then ajaxing it in if you press "F", but that's complicated and I don't want to bother. - Generally, I think this element is useful to something like 5% of users and not useful to 95%. Test Plan: Enabled and disabled file tree. Looked at commits and revisions; verified they reflected the setting correctly. Reviewers: vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D4813
2013-02-05 02:00:27 +01:00
'PhabricatorSettingsPanelDiffPreferences' => 'PhabricatorSettingsPanel',
Make settings panels more modular and modern Summary: Currently, we have a hard-coded list of settings panels. Make them a bit more modular. - Allow new settings panels to be defined by third-party code (see {D2340}, for example -- @ptarjan). - This makes the OAuth stuff more flexible for {T887} / {T1536}. - Reduce the number of hard-coded URIs in various places. Test Plan: Viewed / edited every option in every panel. Grepped for all references to these URIs. Reviewers: btrahan, vrana, ptarjan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3257
2012-08-13 21:37:26 +02:00
'PhabricatorSettingsPanelDisplayPreferences' => 'PhabricatorSettingsPanel',
'PhabricatorSettingsPanelEmailAddresses' => 'PhabricatorSettingsPanel',
'PhabricatorSettingsPanelEmailPreferences' => 'PhabricatorSettingsPanel',
Allow users to customize applicaiton tile sizes Summary: See discussion in D4438. Allows users to customize application tiles, and implements generally reasonable defaults so they hopefully won't. Sizes are "invisible" (internal only, used to hide admin apps from non-admins), "hidden" (hide by default, show after clicking "Show More Applications"), "show" (show a small square tile) and "full" (show a full-width tile with subtitle). Test Plan: Default view for a non-admin: {F29375} Adjusted settings, hidden: {F29373} Adjusted settings, shown: {F29374} Reviewers: chad, btrahan Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D4439
2013-01-16 18:00:11 +01:00
'PhabricatorSettingsPanelHomePreferences' => 'PhabricatorSettingsPanel',
Make settings panels more modular and modern Summary: Currently, we have a hard-coded list of settings panels. Make them a bit more modular. - Allow new settings panels to be defined by third-party code (see {D2340}, for example -- @ptarjan). - This makes the OAuth stuff more flexible for {T887} / {T1536}. - Reduce the number of hard-coded URIs in various places. Test Plan: Viewed / edited every option in every panel. Grepped for all references to these URIs. Reviewers: btrahan, vrana, ptarjan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3257
2012-08-13 21:37:26 +02:00
'PhabricatorSettingsPanelLDAP' => 'PhabricatorSettingsPanel',
'PhabricatorSettingsPanelOAuth' => 'PhabricatorSettingsPanel',
'PhabricatorSettingsPanelPassword' => 'PhabricatorSettingsPanel',
'PhabricatorSettingsPanelProfile' => 'PhabricatorSettingsPanel',
'PhabricatorSettingsPanelSSHKeys' => 'PhabricatorSettingsPanel',
'PhabricatorSettingsPanelSearchPreferences' => 'PhabricatorSettingsPanel',
Detect and raise setup warnings from within Phabricator Summary: This is basicaly a light version of D4286. The major problem with D4286 is that it's a huge leap and completely replaces the setup process in one step. Instead, I want to do this: - Add the post-setup warnings (yellow bar with "6 unresolved warnings..."). - Copy all setup checks into post-setup warnings (so every check has an old-style check and a new-style check). - Run that for a little bit and make sure it's stable. - Implement fatal post-setup checks (the red screen, vs the yellow bar). - Run that for a little bit. - Nuke setup mode and delete all the old checks. This should give us a bunch of very gradual steps toward the brave new world of simpler setup. Test Plan: - Faked APC setup failures, saw warnings raise. - Verified that this runs after restart (get + set). - Verified that this costs us only one cache hit after first-run (get only). Reviewers: btrahan, codeblock, vrana, chad Reviewed By: codeblock CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4295
2012-12-30 15:37:49 +01:00
'PhabricatorSetupCheckAPC' => 'PhabricatorSetupCheck',
Don't require phabricator.base-uri to be configured Summary: Fixes T2293. We currently hard-require this in setup. We do not need to; we don't actually need it until we start running daemons. Move it to post-install and provide more guidance. We could make this even easier in the future, but we'd need to special case it, since it's dangerous to let it be set to any value (if you set it to the wrong value, you can't log in). We could safely have a workflow which writes the current request URI into the database configuration, or a two-stage workflow where we set the URI and then verify it, but these both imply some special casing and complication. This should be a step forward from where we are today, regardless. Test Plan: Removed "phabricator.base-uri" from my configuration. Verified Phabricator still works. Without "phabricator.base-uri" configured, logged in from multiple host names (127.0.0.1:8080, local.aphront.com:8080). Configured "phabricator.base-uri". Verified my unblessed session no longer worked. Verified setup issue went away. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2293 Differential Revision: https://secure.phabricator.com/D4580
2013-01-22 22:57:02 +01:00
'PhabricatorSetupCheckBaseURI' => 'PhabricatorSetupCheck',
Add setup checks for the availability of 'which' and 'diff' binaries Summary: Spent an hour or two helping a user figure this out. Make sure I never do that again. If the webserver is configured with an empty or bogus PATH, binaries like 'which' and 'diff' (and 'git', and 'svn', etc.) may not be available. In most cases, this is fine, because we get an error like "sh: whatever-command not found", which is obvious to diagnose. In the case of 'diff', we don't get this, because 'diff' is expected to exit with a nonzero code for differing files -- so we interpret the "sh: whatever-command not found" as "files differ" and then try to parse the empty output. Explicitly check for 'which' (on Windows, 'where') and 'diff' during setup (I plan to refine the behavior around 'git', 'svn' and 'hg' at some point, but this is less pressing since the errors are trivial to support). Test Plan: Faked failures on all modes, verified setup warnings look reasonable. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6008
2013-05-23 23:42:07 +02:00
'PhabricatorSetupCheckBinaries' => 'PhabricatorSetupCheck',
Move database configuration into new-style setup checks Summary: Port the database checks over. Test Plan: Triggered all the checks via intentional misconfiguration. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4590
2013-01-23 01:16:24 +01:00
'PhabricatorSetupCheckDatabase' => 'PhabricatorSetupCheck',
Port extension checks to new-style setup Summary: - Allow new-style setup to raise fatal setup errors. - Port extension checks to new-style setup as fatal errors. - When fatal errors are raised, abort setup and show them in a chrome-free response. Test Plan: {F29981} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4587
2013-01-23 00:16:26 +01:00
'PhabricatorSetupCheckExtensions' => 'PhabricatorSetupCheck',
Add "Developer" and "Access Log" config option groups, some types Summary: - Add a "developer" option group. - Add an "access log" option group. - Render the types "bool", "int" and "string" in a more tailored way. - Add a config check for dead config. Right now this serves as a "TODO" list of things that need to be migrated. Test Plan: Looked at config options, setup issues. Edited bool, int, string options. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4308
2013-01-01 23:09:17 +01:00
'PhabricatorSetupCheckExtraConfig' => 'PhabricatorSetupCheck',
Move Facebook setup checks to post-install Summary: Technically we should have these for all the OAuth providers but I don't think anyone really has trouble with them and it can probably be done generically after T1536. Preserve the functionality, at least. Test Plan: Broke my config, verified warnings appeared. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4506
2013-01-19 17:42:15 +01:00
'PhabricatorSetupCheckFacebook' => 'PhabricatorSetupCheck',
Add a setup warning about missing 'fileinfo' Summary: See <https://github.com/facebook/phabricator/issues/320>. We have a soft dependency on 'fileinfo', which we try to recover from (with `file`) but won't be able to on Windows and apparently FreeBSD systems. Since users can ignore setup checks anyway now, just raise a warning during install. I believe almost all installs should have this extension, it has been part of the core for a long time. Test Plan: Faked setup failure, looked at warning. "Solved" setup failure, saw it go away. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5952
2013-05-17 19:00:40 +02:00
'PhabricatorSetupCheckFileinfo' => 'PhabricatorSetupCheck',
Migrate `max_allowed_packet` and GD checks to new setup stuff Summary: These are nonblocking warnings and can move to post-install. Test Plan: Broke my environment and observed the warnings. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran, asherkin Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4505
2013-01-19 17:41:45 +01:00
'PhabricatorSetupCheckGD' => 'PhabricatorSetupCheck',
Preserving the Animation of Gif Images Summary: Preserving animation of GIF profile Pictures Test Plan: Uploaded Animated images as profile pictures to check if the animation of gif images is preserved and it does :) somewhat ! Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4833
2013-02-08 18:14:28 +01:00
'PhabricatorSetupCheckImagemagick' => 'PhabricatorSetupCheck',
Allow configuration to be explicitly validated, including validation of complex attributes Summary: - Allows us to implement setup warnings for edits which don't go through the web UI, e.g. "you edited a config file and set value X to something goofy". - Allows us to implement more sophisticated validations, beyond basic type checks (e.g., "phabricator.base-uri" must be a URI). - Fixes T358 (or, close enough -- fixes it for all options which have been migrated as per T2255. Test Plan: Set "darkconsole.enabled" to "xyz" in my config, observed setup warning. Added fake validation, observed web UI edit error. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255, T358 Differential Revision: https://secure.phabricator.com/D4315
2013-01-02 03:15:03 +01:00
'PhabricatorSetupCheckInvalidConfig' => 'PhabricatorSetupCheck',
Move mail-related setup issues to setup checks Summary: Ports mail stuff from the existing setup process to the more modular setup checks. Test Plan: Configured my local install to have all these errors, verified setup raised them. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4494
2013-01-18 22:28:30 +01:00
'PhabricatorSetupCheckMail' => 'PhabricatorSetupCheck',
Migrate `max_allowed_packet` and GD checks to new setup stuff Summary: These are nonblocking warnings and can move to post-install. Test Plan: Broke my environment and observed the warnings. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran, asherkin Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4505
2013-01-19 17:41:45 +01:00
'PhabricatorSetupCheckMySQL' => 'PhabricatorSetupCheck',
Move open_basedir and safe_mode checks into new setup Summary: Newer and shinier! Test Plan: Intentionally misconfigured myself into all three setup failures (safe_mode, open_basedir/fatal, open_basedir/nonfatal). Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4589
2013-01-23 01:15:54 +01:00
'PhabricatorSetupCheckPHPConfig' => 'PhabricatorSetupCheck',
Move PATH checks to post-install Summary: We no longer need to do PHP CLI checks (D4568) or run `git submodule` (D4581) so we don't need $PATH to be set to complete setup. Move it to post-install. Drop the instructions about PHP-FPM because the Phabricator config is dramatically easier now that we have it. Test Plan: Set environment.append-paths to various things, faked lack of $PATH, verified I got the warning when I expected to setting Phabricator config cleared it. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4585
2013-01-22 23:45:19 +01:00
'PhabricatorSetupCheckPath' => 'PhabricatorSetupCheck',
Phabricator now checks whether pygmentize script can be run when user enables pygments Summary: Check if pygmentize is runnable if pygments is enabled Test Plan: Enable pygments with pygmentize unavailable in path Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5157
2013-02-28 18:17:01 +01:00
'PhabricatorSetupCheckPygment' => 'PhabricatorSetupCheck',
Migrate local disk storage setup check Summary: Migrate to the new hotness. Also: - Remove a string test, which is now impossible since the config will repair itself and raise a type error. - Restore the header even in /config/ -- this check is kind of hacky and it feels a bit more natural now that it's above the menu. Test Plan: Set my local disk path to something invalid, verified I got a setup error. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4497
2013-01-19 17:39:27 +01:00
'PhabricatorSetupCheckStorage' => 'PhabricatorSetupCheck',
Improve resolution process for nonfatal setup issues Summary: - When a setup issue is nonfatal (i.e., a warning), instruct the user to edit the value from the web UI instead of using `bin/config`. - When the user edits configuration in response to a setup issue, send them back to the issue when they're done. - When an issue relates to PHP configuration, link to the PHP documentation on configuration. - Add new-style setup check for timezone issues. Test Plan: Mucked with my timezone config, resolved the issues I created. Reviewers: codeblock, btrahan, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221, T2228 Differential Revision: https://secure.phabricator.com/D4298
2012-12-31 02:04:38 +01:00
'PhabricatorSetupCheckTimezone' => 'PhabricatorSetupCheck',
Use phutil_tag in Setup issue stuff Summary: These are pretty straightforward, they just have a fair amount of instructional text with inline markup. Test Plan: Added and viewed a UIExample. Reviewers: vrana Reviewed By: vrana CC: aran Maniphest Tasks: T2432 Differential Revision: https://secure.phabricator.com/D4686
2013-01-29 20:29:56 +01:00
'PhabricatorSetupIssueExample' => 'PhabricatorUIExample',
Detect and raise setup warnings from within Phabricator Summary: This is basicaly a light version of D4286. The major problem with D4286 is that it's a huge leap and completely replaces the setup process in one step. Instead, I want to do this: - Add the post-setup warnings (yellow bar with "6 unresolved warnings..."). - Copy all setup checks into post-setup warnings (so every check has an old-style check and a new-style check). - Run that for a little bit and make sure it's stable. - Implement fatal post-setup checks (the red screen, vs the yellow bar). - Run that for a little bit. - Nuke setup mode and delete all the old checks. This should give us a bunch of very gradual steps toward the brave new world of simpler setup. Test Plan: - Faked APC setup failures, saw warnings raise. - Verified that this runs after restart (get + set). - Verified that this costs us only one cache hit after first-run (get only). Reviewers: btrahan, codeblock, vrana, chad Reviewed By: codeblock CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4295
2012-12-30 15:37:49 +01:00
'PhabricatorSetupIssueView' => 'AphrontView',
Port the "Slowvote" application Summary: Port slowvote. This has some style/layout roughness but gets us most of the way there. I'll followup to fix some of the markup issues. Test Plan: Created and voted in several different kinds of poll. Reviewed By: codeblock Reviewers: codeblock, tomo, jungejason, aran, tuomaspelkonen Commenters: aran, jungejason CC: aran, codeblock, jungejason, epriestley Differential Revision: 613
2011-07-08 20:13:11 +02:00
'PhabricatorSlowvoteChoice' => 'PhabricatorSlowvoteDAO',
'PhabricatorSlowvoteComment' => 'PhabricatorSlowvoteDAO',
'PhabricatorSlowvoteController' => 'PhabricatorController',
'PhabricatorSlowvoteCreateController' => 'PhabricatorSlowvoteController',
'PhabricatorSlowvoteDAO' => 'PhabricatorLiskDAO',
'PhabricatorSlowvoteListController' => 'PhabricatorSlowvoteController',
'PhabricatorSlowvoteOption' => 'PhabricatorSlowvoteDAO',
'PhabricatorSlowvotePoll' => 'PhabricatorSlowvoteDAO',
'PhabricatorSlowvotePollController' => 'PhabricatorSlowvoteController',
Embed slowvotes have basic interaction Summary: User can now vote through embed slowvote Test Plan: Voted'n stuff Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad, AnhNhan Maniphest Tasks: T2883 Differential Revision: https://secure.phabricator.com/D5743
2013-05-04 00:48:59 +02:00
'PhabricatorSlowvoteVoteController' => 'PhabricatorSlowvoteController',
PhabricatorSlug Summary: This is to be used in Phame so the logic is shared where possible. The change has three main things going on - broke out functionality from PhrictionDocument that isn't Phriction specific. - swept up code base to use new PhabricatorSlug class. - altered the regex ever so slightly per discussion and http://stackoverflow.com/questions/2028022/javascript-how-to-convert-unicode-string-to-ascii I think maybe we should punt on unicode here for quite a bit -- http://www.456bereastreet.com/archive/201006/be_careful_with_non-ascii_characters_in_urls/ -- but we'll be well-positioned to add it with the code here. Test Plan: used phriction to create, edit, view documents. used a tool (codemod) for the codebase sweeping Reviewers: epriestley Reviewed By: epriestley CC: aran Differential Revision: https://secure.phabricator.com/D2195
2012-04-10 23:18:20 +02:00
'PhabricatorSlugTestCase' => 'PhabricatorTestCase',
Add UI elements for sortable tables Summary: Allow AphrontTableView to render with sort indicators and links in its columns. Test Plan: Looked at UI example. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley, sandra Maniphest Tasks: T994 Differential Revision: https://secure.phabricator.com/D1946
2012-03-20 03:48:22 +01:00
'PhabricatorSortTableExample' => 'PhabricatorUIExample',
Modernize Paste Summary: - Add a PhabricatorApplication. - Make most of the views work well on tablets / phones. The actual "Create" form doesn't, but everything else is good -- need to make device-friendly form layouts before I can do the form. Test Plan: Will attach screenshots. Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3293
2012-08-15 19:45:06 +02:00
'PhabricatorSourceCodeView' => 'AphrontView',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
'PhabricatorStandardCustomField' => 'PhabricatorCustomField',
Separate "PhabricatorBarePageView" out of "PhabricatorStandardPageView" Summary: For Phame, we really want more than a chromeless page -- it shouldn't have Javelin or Phabricator styles on it. Pull the bare infrastructure out of StandardPageView and make it available as BarePageView. Test Plan: Viewed bare page in UIExamples, various non-bare pages. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3711
2012-10-16 19:33:47 +02:00
'PhabricatorStandardPageView' => 'PhabricatorBarePageView',
Add /status/
2011-04-08 20:13:29 +02:00
'PhabricatorStatusController' => 'PhabricatorController',
Make SQL patch management DAG-based and provide namespace support Summary: This addresses three issues with the current patch management system: # Two people developing at the same time often pick the same SQL patch number, and then have to go rename it. The system catches this, but it's silly. # Second/third-party developers can't use the same system to manage auxiliary storage they may want to add. # There's no way to build mock databases for unit tests that need to do reads. To resolve these things, you can now name your patches whatever you want and conflicts are just merge conflicts, which are less of a pain to fix than filename conflicts. Dependencies are now a DAG, with implicit dependencies created on the prior patch if no dependencies are specified. Developers can add new concrete subclasses of `PhabricatorSQLPatchList` to add storage management, and define the dependency branchpoint of their patches so they apply in the correct order (although, generally, they should not depend on the mainline patches, presumably). The commands `storage upgrade --namespace test1234` and `storage destroy --namespace test1234` will allow unit tests to build and destroy MySQL storage. A "quickstart" mode allows an upgrade from scratch in ~1200ms. Destruction takes about 200ms. These seem like fairily reasonable costs to actually use in tests. Building from scratch patch-by-patch takes about 6000ms. Test Plan: - Created new databases from scratch with and without quickstart in a separate test namespace. Pointed the webapp at the test namespaces, browsed around, everything looked good. - Compared quickstart and no-quickstart dump states, they're identical except for mysqldump timestamps and a few similar things. - Upgraded a legacy database to the new storage format. - Destroyed / dumped storage. Reviewers: edward, vrana, btrahan, jungejason Reviewed By: btrahan CC: aran, nh Maniphest Tasks: T140, T345 Differential Revision: https://secure.phabricator.com/D2323
2012-04-30 16:54:00 +02:00
'PhabricatorStorageManagementDatabasesWorkflow' => 'PhabricatorStorageManagementWorkflow',
'PhabricatorStorageManagementDestroyWorkflow' => 'PhabricatorStorageManagementWorkflow',
'PhabricatorStorageManagementDumpWorkflow' => 'PhabricatorStorageManagementWorkflow',
'PhabricatorStorageManagementStatusWorkflow' => 'PhabricatorStorageManagementWorkflow',
'PhabricatorStorageManagementUpgradeWorkflow' => 'PhabricatorStorageManagementWorkflow',
'PhabricatorStorageManagementWorkflow' => 'PhutilArgumentWorkflow',
Add basic "Subscriptions" application Summary: Basic infrastructure for generalizing subscriptions/CCs for T1808, T1514 and T1663. - Implement `PhabricatorSubscribableInterface` and you'll get a subscribe/unsubscribe button for free. - If there are any auto-subscribed users (like the question author) you can specify them; this makes more sense for Tasks and Revisions than Ponder probably, but maybe the author should be auto-subscribed. - Subscriptions are either "explicit" (the user clicked 'subscribe') or "implicit" (the user did something which causes them to become subscribed naturally). If a user unsubscribes, they'll no longer be added by implicit subscriptions. This may or may not be relevant to Ponder but is an existing Herald feature in Differential. - Helper method on PhabricatorSubscribersQuery to load subscribers. - This doesn't handle actually sending email, etc. I think that's all so application-specific that it doesn't belong here. - Now seems to work. Test Plan: {F20552} {F20553} Reviewers: pieter, btrahan Reviewed By: pieter CC: aran Maniphest Tasks: T1663, T1514, T1808 Differential Revision: https://secure.phabricator.com/D3637
2012-10-05 22:18:05 +02:00
'PhabricatorSubscribersQuery' => 'PhabricatorQuery',
'PhabricatorSubscriptionsEditController' => 'PhabricatorController',
If users are on the email to Phabricator, do not send them the Phabricator reply. Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email. Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected. Reviewers: epriestley, vrana Reviewed By: vrana CC: aran, Korvin, vrana Maniphest Tasks: T1676 Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 19:18:23 +02:00
'PhabricatorSubscriptionsEditor' => 'PhabricatorEditor',
Add basic "Subscriptions" application Summary: Basic infrastructure for generalizing subscriptions/CCs for T1808, T1514 and T1663. - Implement `PhabricatorSubscribableInterface` and you'll get a subscribe/unsubscribe button for free. - If there are any auto-subscribed users (like the question author) you can specify them; this makes more sense for Tasks and Revisions than Ponder probably, but maybe the author should be auto-subscribed. - Subscriptions are either "explicit" (the user clicked 'subscribe') or "implicit" (the user did something which causes them to become subscribed naturally). If a user unsubscribes, they'll no longer be added by implicit subscriptions. This may or may not be relevant to Ponder but is an existing Herald feature in Differential. - Helper method on PhabricatorSubscribersQuery to load subscribers. - This doesn't handle actually sending email, etc. I think that's all so application-specific that it doesn't belong here. - Now seems to work. Test Plan: {F20552} {F20553} Reviewers: pieter, btrahan Reviewed By: pieter CC: aran Maniphest Tasks: T1663, T1514, T1808 Differential Revision: https://secure.phabricator.com/D3637
2012-10-05 22:18:05 +02:00
'PhabricatorSubscriptionsUIEventListener' => 'PhutilEventListener',
Add a custom lint name hook to Phabricator Summary: Allow Conduit method so they stop raising lint warnings. See D874. Test Plan: Ran "arc lint" on conduit files and was no longer given frivolous warnings. Reviewers: nh, jungejason, tuomaspelkonen, aran Reviewed By: nh CC: aran, nh, epriestley Differential Revision: 875
2011-08-30 22:12:20 +02:00
'PhabricatorSymbolNameLinter' => 'ArcanistXHPASTLintNamingHook',
Add syntax highlighting options. Test Plan: Quick view of each option in the web interface. Reviewers: epriestley, btrahan, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4386
2013-01-10 18:56:36 +01:00
'PhabricatorSyntaxHighlightingConfigOptions' => 'PhabricatorApplicationConfigOptions',
Build PhabricatorTagView Summary: Builds out most of the non-hover-stuff from `overview-hovercards.png`. Things I didn't build: - Tokens (I like them a lot but don't want to scope creep) - Functions (backend mess / future work) - Icons for tags. - Tags with pointy ends and holes in them (an earlier mock had this I think but they're gone on final) - The cyaney color for "Sporadic" since I just noticed it while typing this up. Test Plan: Looked at UIExample page. Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2089 Differential Revision: https://secure.phabricator.com/D4029
2012-11-24 15:47:06 +01:00
'PhabricatorTagExample' => 'PhabricatorUIExample',
'PhabricatorTagView' => 'AphrontView',
Rough cut of Workers Summary: workers do work, provided I have written them correctly. perhaps it is so. Test Plan: Reviewers: CC:
2011-03-10 22:48:29 +01:00
'PhabricatorTaskmasterDaemon' => 'PhabricatorDaemon',
Provide an "isolated" database connection for testing Summary: This provides a new connection which doesn't connect to anything, so effects can be isolated to the current process (for unit testing). Test Plan: Ran unit tests. Reviewed By: aran Reviewers: aran, tuomaspelkonen, jungejason CC: aran, epriestley Differential Revision: 193
2011-04-30 19:11:41 +02:00
'PhabricatorTestCase' => 'ArcanistPhutilTestCase',
Make file storage more testable Summary: Fixes T2474. Adds a storage dummy storage engine for unit tests, and adds a couple of simple tests for basic file storage. Test Plan: Ran `arc unit` to execute unit tests. Reviewers: kwadwon Reviewed By: kwadwon CC: aran Maniphest Tasks: T2474 Differential Revision: https://secure.phabricator.com/D4777
2013-02-06 22:37:42 +01:00
'PhabricatorTestStorageEngine' => 'PhabricatorFileStorageEngine',
Factor out task execution and formalize permanent failures Summary: - Clean up a TODO about permanent failures. - Clean up a TODO about failing tasks after too many retries. - Clean up a TODO about testing for bad leases. - Make the lease/retry implementation more flexible and natural. - Make completely bogus tasks fail permanently. - Make PhabricatorMetaMTAWorker use new `getWaitBeforeRetry()` (as intended), not hackily implement logic in `getRequiredLeaseTime()`. - Document worker hooks for failures and retries. - Provide coverage on everything. Test Plan: Ran unit tests. Ran `bin/phd debug taskmaster`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3859
2012-11-01 19:30:23 +01:00
'PhabricatorTestWorker' => 'PhabricatorWorker',
Consolidate some datetime code and add unit tests Summary: See D6115. Test Plan: - Ran unit tests. - Viewed reports. - Created a countdown. - Searched chatlog. - Searched pastes by created date. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6116
2013-06-03 21:58:11 +02:00
'PhabricatorTimeTestCase' => 'PhabricatorTestCase',
Rough cut of repository tracking Summary: Basic scaffolding for repository tracking, plus daemon infrastructure (Timelines, Cursors) and some fixes (memory usage, mysql_connect() junk). Test Plan: parsed Javelin git commit history via daemon Reviewers: CC:
2011-03-07 07:29:22 +01:00
'PhabricatorTimelineCursor' => 'PhabricatorTimelineDAO',
'PhabricatorTimelineDAO' => 'PhabricatorLiskDAO',
'PhabricatorTimelineEvent' => 'PhabricatorTimelineDAO',
'PhabricatorTimelineEventData' => 'PhabricatorTimelineDAO',
Add basic transaction/timeline view Summary: This is still rough and not completely accurate to the mocks (and the mobile view is quite crude and mostly just "hey this technically works"), but I want to build Pholio on top of it rather than building it on something else and then swapping it out later and the API is reasonable enough. This should probably be called `PhabricatorTransactionView` but we already have one of those. I might juggle the names in a future diff. Test Plan: Desktop {F22352} Mobile {F22351} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3833
2012-11-22 02:24:56 +01:00
'PhabricatorTimelineEventView' => 'AphrontView',
'PhabricatorTimelineExample' => 'PhabricatorUIExample',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'PhabricatorTimelineIterator' => 'Iterator',
Add basic transaction/timeline view Summary: This is still rough and not completely accurate to the mocks (and the mobile view is quite crude and mostly just "hey this technically works"), but I want to build Pholio on top of it rather than building it on something else and then swapping it out later and the API is reasonable enough. This should probably be called `PhabricatorTransactionView` but we already have one of those. I might juggle the names in a future diff. Test Plan: Desktop {F22352} Mobile {F22351} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3833
2012-11-22 02:24:56 +01:00
'PhabricatorTimelineView' => 'AphrontView',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorToken' =>
array(
0 => 'PhabricatorTokenDAO',
1 => 'PhabricatorPolicyInterface',
),
'PhabricatorTokenController' => 'PhabricatorController',
'PhabricatorTokenCount' => 'PhabricatorTokenDAO',
Surface token counts for Pholio Summary: Provide this data so the list view can present it somehow. Test Plan: {F34520} Reviewers: chad Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D5210
2013-03-04 20:47:58 +01:00
'PhabricatorTokenCountQuery' => 'PhabricatorOffsetPagedQuery',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorTokenDAO' => 'PhabricatorLiskDAO',
'PhabricatorTokenGiveController' => 'PhabricatorTokenController',
'PhabricatorTokenGiven' =>
array(
0 => 'PhabricatorTokenDAO',
1 => 'PhabricatorPolicyInterface',
),
'PhabricatorTokenGivenController' => 'PhabricatorTokenController',
'PhabricatorTokenGivenEditor' => 'PhabricatorEditor',
Notify users when an object they created gets awarded a token Summary: - Publish feed/notification. - I think this is too lightweight for an email? - We don't tell them which token right now. Laziness? Or intentional aura of mystery?! - For tasks, notify both author and current owner. - Fixes T2562. Test Plan: {F33187} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2562 Differential Revision: https://secure.phabricator.com/D5007
2013-02-19 02:44:45 +01:00
'PhabricatorTokenGivenFeedStory' => 'PhabricatorFeedStory',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorTokenGivenQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add basic token leader board functionality. Summary: Implement basic token leader board. No pagination yet. Test Plan: Assign some tasks tokens and check that they are displayed properly. Reviewers: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2689 Differential Revision: https://secure.phabricator.com/D5379
2013-03-22 00:04:29 +01:00
'PhabricatorTokenLeaderController' => 'PhabricatorTokenController',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorTokenQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add basic token leader board functionality. Summary: Implement basic token leader board. No pagination yet. Test Plan: Assign some tasks tokens and check that they are displayed properly. Reviewers: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2689 Differential Revision: https://secure.phabricator.com/D5379
2013-03-22 00:04:29 +01:00
'PhabricatorTokenReceiverQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
'PhabricatorTokenUIEventListener' => 'PhutilEventListener',
Unify Maniphest + Differential comment styles Summary: I want to add comments to commits, and they should obviously share code with the nearly-identical comments in Maniphest and Differential. Unify code/style as much as possible. This program made possible by a generous grant from D1513. Test Plan: - Looked at a bunch of different Differential and Maniphest comments; they appeared to render identically to how they looked before. - Tested some edge cases like anchors and "show details" on description edits in Maniphest. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1686
2012-02-24 22:02:35 +01:00
'PhabricatorTransactionView' => 'AphrontView',
Basic image thumbnailing Summary: This is still very rough but provides basic support for generating image thumbnails. I need to separate stuff out a bit but I'm going to integrate into Maniphest before I hit the profile stuff so this seems like a reasonable starting point. Test Plan: Generated some image thumbnails in various sizes. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran CC: aran Differential Revision: 333
2011-05-22 23:40:51 +02:00
'PhabricatorTransformedFile' => 'PhabricatorFileDAO',
Add translations config group. Summary: Adds the translations group as per T2255. Currently `translation.override` is `wild` -- it should be changed to dict<string, string> when that exists. Also fixes a small bug from D4326 which caused "class" types to not ever validate. Test Plan: - Looked at the settings. - Successfully saved a setting relating to classes. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4350
2013-01-05 01:22:52 +01:00
'PhabricatorTranslationsConfigOptions' => 'PhabricatorApplicationConfigOptions',
Add a little more unit test documentation, fail loudly when isolation prevents a query Summary: - Provide an example unit test, and document it. - Document database isolation better. - When we issue an unsimulated query to the isolated connection, throw a helpful message. - Pygments is complaining about my madeup "lang=demo", change it to "lang=text". Test Plan: - Ran the unit test (sanity check). - Ran all other unit tests (verify I didn't break isolation). - Added a queryfx(..., 'SELECT 1') to a test and verified it throws. - Read the documentation. Reviewed By: edward Reviewers: edward, jungejason, tuomaspelkonen, aran CC: aran, edward Differential Revision: 773
2011-08-03 17:17:53 +02:00
'PhabricatorTrivialTestCase' => 'PhabricatorTestCase',
Apront Two Column View Summary: Wanted to pull this out in case we don't use it in Maniphest, still useful perhaps in the future. Creates a sidebar that wraps when on mobile. Test Plan: Tested UIExample Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5321
2013-03-11 03:20:01 +01:00
'PhabricatorTwoColumnExample' => 'PhabricatorUIExample',
Typeaheads
2011-01-25 22:48:05 +01:00
'PhabricatorTypeaheadCommonDatasourceController' => 'PhabricatorTypeaheadDatasourceController',
'PhabricatorTypeaheadDatasourceController' => 'PhabricatorController',
Modernize UIExamples Summary: - Get rid of an AphrontSideNavView callsite. - Modernize and simplify the application implementation. - Doesn't work perfectly on tablet/phone but that's because not all the UI examples work there yet. Test Plan: Looked at /applications/ and /uiexample/. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D3431
2012-09-11 18:56:40 +02:00
'PhabricatorUIExampleRenderController' => 'PhabricatorController',
AphrontListFilterView, for list filtering.
2011-04-04 00:50:06 +02:00
'PhabricatorUIListFilterExample' => 'PhabricatorUIExample',
Add a basic notification UI element Summary: This is //extremely// basic but dead simple and should cover us for v1, I think. Let me know what features you need. Test Plan: Used UI example page. Reviewers: allenjohnashton, ddfisher, keebuhm Reviewed By: ddfisher CC: aran, ender Maniphest Tasks: T944 Differential Revision: https://secure.phabricator.com/D2732
2012-06-14 00:00:24 +02:00
'PhabricatorUINotificationExample' => 'PhabricatorUIExample',
AphrontPagerView and UIExamples.
2011-04-01 02:06:33 +02:00
'PhabricatorUIPagerExample' => 'PhabricatorUIExample',
Add a basic tooltip UI element Summary: There are a few things we can improve with tooltips. Test Plan: Moused over all the stuff on the test page. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T965 Differential Revision: https://secure.phabricator.com/D1870
2012-03-13 02:21:02 +01:00
'PhabricatorUITooltipExample' => 'PhabricatorUIExample',
Document configuration of file upload limits Summary: I have a patch which makes uploads all fancy and adds progress bars, but document the landscape first since it's quite complicated. Test Plan: Generated, read docs. Configured `storage.upload-size-limit` to various values. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran Maniphest Tasks: T875 Differential Revision: https://secure.phabricator.com/D2381
2012-05-04 02:30:17 +02:00
'PhabricatorUnitsTestCase' => 'PhabricatorTestCase',
Allow user override translation and implement PhutilPerson Test Plan: Altered database. Wrote a custom translation and selected it in preferences. Verified that the text is custom translated. Set language back to default. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D2757
2012-06-15 03:08:06 +02:00
'PhabricatorUser' =>
array(
0 => 'PhabricatorUserDAO',
1 => 'PhutilPerson',
Implement ApplicationSearch in People Summary: Ref T2625. Fixes T2812. Implement ApplicationSearch in People. {F44788} Test Plan: Made People queries. Used Conduit. Used `@mentions`. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2625, T2812 Differential Revision: https://secure.phabricator.com/D6092
2013-05-31 19:51:20 +02:00
2 => 'PhabricatorPolicyInterface',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
3 => 'PhabricatorCustomFieldInterface',
),
Add "Title" and "Blurb" to new profile editor Summary: Ref T1703. - Adds "Title". - Adds "Blurb". - Adds `user.fields` config for selecting and reordering. This will get UI in the next patch. Test Plan: {F45689} {F45690} Edited the fields, too. Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6153
2013-06-07 19:22:45 +02:00
'PhabricatorUserBlurbField' => 'PhabricatorUserCustomField',
'PhabricatorUserConfigOptions' => 'PhabricatorApplicationConfigOptions',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
'PhabricatorUserCustomField' =>
array(
0 => 'PhabricatorCustomField',
1 => 'PhabricatorUserCustomFieldInterface',
Allow user override translation and implement PhutilPerson Test Plan: Altered database. Wrote a custom translation and selected it in preferences. Verified that the text is custom translated. Set language back to default. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D2757
2012-06-15 03:08:06 +02:00
),
Basic user/account tool.
2011-01-24 03:09:16 +01:00
'PhabricatorUserDAO' => 'PhabricatorLiskDAO',
If users are on the email to Phabricator, do not send them the Phabricator reply. Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email. Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected. Reviewers: epriestley, vrana Reviewed By: vrana CC: aran, Korvin, vrana Maniphest Tasks: T1676 Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 19:18:23 +02:00
'PhabricatorUserEditor' => 'PhabricatorEditor',
Allow users to have multiple email addresses, and verify emails Summary: - Move email to a separate table. - Migrate existing email to new storage. - Allow users to add and remove email addresses. - Allow users to verify email addresses. - Allow users to change their primary email address. - Convert all the registration/reset/login code to understand these changes. - There are a few security considerations here but I think I've addressed them. Principally, it is important to never let a user acquire a verified email address they don't actually own. We ensure this by tightening the scoping of token generation rules to be (user, email) specific. - This should have essentially zero impact on Facebook, but may require some minor changes in the registration code -- I don't exactly remember how it is set up. Not included here (next steps): - Allow configuration to restrict email to certain domains. - Allow configuration to require validated email. Test Plan: This is a fairly extensive, difficult-to-test change. - From "Email Addresses" interface: - Added new email (verified email verifications sent). - Changed primary email (verified old/new notificactions sent). - Resent verification emails (verified they sent). - Removed email. - Tried to add already-owned email. - Created new users with "accountadmin". Edited existing users with "accountadmin". - Created new users with "add_user.php". - Created new users with web interface. - Clicked welcome email link, verified it verified email. - Reset password. - Linked/unlinked oauth accounts. - Logged in with oauth account. - Logged in with email. - Registered with Oauth account. - Tried to register with OAuth account with duplicate email. - Verified errors for email verification with bad tokens, etc. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1184 Differential Revision: https://secure.phabricator.com/D2393
2012-05-07 19:29:33 +02:00
'PhabricatorUserEmail' => 'PhabricatorUserDAO',
Provide an activity log for login and administrative actions Summary: This isn't complete, but I figured I'd ship it for review while it's still smallish. Provide an activity log for high-level system actions (logins, admin actions). This basically allows two things to happen: - The log itself is useful if there are shenanigans. - Password login can check it and start CAPTCHA'ing users after a few failed attempts. I'm going to change how the admin stuff works a little bit too, since right now you can make someone an agent, grab their certificate, revert them back to a normal user, and then act on their behalf over Conduit. This is a little silly, I'm going to move "agent" to the create workflow instead. I'll also add a confirm/email step to the administrative password reset flow. Test Plan: Took various administrative and non-administrative actions, they appeared in the logs. Filtered the logs in a bunch of different ways. Reviewers: jungejason, tuomaspelkonen, aran CC: Differential Revision: 302
2011-05-18 03:42:21 +02:00
'PhabricatorUserLog' => 'PhabricatorUserDAO',
User preferences ported from tools Summary: Internal tools, e.g., differential and diffusion have user defined preferences for monospaced font and the option for showing either the name of the tool or the glyph of the tool in the title. These preferences were ported to phabricator. These preferences can be modified in /preferences/ and they both affect diffusion and differential at the moment. Test Plan: * Created an empty database * Loaded /preferences/ and modified the monospaced font and clicked save * Confirmed that the same page was loaded with the message that preferences have been saved and that the example text used the user defined font * in /preferences/ changed the option to show tool names as plain text and clicked save * Confirmed that the same page was loaded with '[Preferences]' in the title instead of a glyph * These same tests were also executed for differential and diffusion Reviewers: epriestley CC: jungejason Differential Revision: 91
2011-03-31 04:21:09 +02:00
'PhabricatorUserPreferences' => 'PhabricatorUserDAO',
Slightly more sophisticated profiles. Summary: Test Plan: Reviewers: CC:
2011-02-20 03:28:41 +01:00
'PhabricatorUserProfile' => 'PhabricatorUserDAO',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
'PhabricatorUserProfileEditor' => 'PhabricatorApplicationTransactionEditor',
'PhabricatorUserRealNameField' => 'PhabricatorUserCustomField',
Allow users to associate SSH Public Keys with their accounts Summary: With the sshd-vcs thing I hacked together, this will enable Phabricator to host repositories without requiring users to have SSH accounts. I also fixed "subporjects" and added an explicit ENGINE to it. Test Plan: Created, edited and deleted public keys. Attempted to add the same public key twice. Attempted to add invalid and unnamed public keys. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran, cadamo, codeblock CC: aran, epriestley Differential Revision: 711
2011-07-22 19:17:57 +02:00
'PhabricatorUserSSHKey' => 'PhabricatorUserDAO',
Improve Search architecture Summary: The search indexing API has several problems right now: - Always runs in-process. - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it. - Being able to use the task queue will also make rebuilding indexes faster. - Instead, make the API phid-oriented. - No uniform indexing API. - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird. - Instead, provide a uniform API. - No uniform CLI. - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers. - Instead, let indexers expose documents for indexing. - Not application-oriented. - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world. - Instead, move indexers to applications and load them with SymbolLoader. Test Plan: - `bin/search index` - Indexed one revision, one task. - Indexed `--type TASK`, `--type DREV`, etc., for all types. - Indexed `--all`. - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it. - Creating users is a pain; searched for a user after indexing. - Creating commits is a pain; searched for a commit after indexing. - Mocks aren't currently loadable in the result view, so their indexing is moot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: 20after4, aran Maniphest Tasks: T1991, T2104 Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
'PhabricatorUserSearchIndexer' => 'PhabricatorSearchDocumentIndexer',
Allowing setting user status Summary: I will use it for highlighting users which are not currently available. Maybe I will also use it in the nagging tool. I don't plan creating a UI for it as API is currently enough for us. Maybe I will visualize it at /calendar/ later. I plan creating `user.deletestatus` method when this one will be done. Test Plan: `storage upgrade` Call Conduit `user.addstatus`. Verify DB. Reviewers: epriestley Reviewed By: epriestley CC: aran, Koolvin Differential Revision: https://secure.phabricator.com/D2382
2012-05-04 00:47:34 +02:00
'PhabricatorUserStatus' => 'PhabricatorUserDAO',
Create a status tool by giving /calendar/ some teeth Summary: you can now add, edit, and delete status events. also added a "description" to status events and surface it in the big calendar view on mouse hover. some refactoring changes as well to make validation logic centralized within the storage class. Test Plan: added, edited, deleted. yay. Reviewers: epriestley, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T407 Differential Revision: https://secure.phabricator.com/D3810
2012-10-24 22:22:24 +02:00
'PhabricatorUserStatusInvalidEpochException' => 'Exception',
'PhabricatorUserStatusOverlapException' => 'Exception',
Unify logic for username validation Summary: Revisit of D1254. Don't require lowercase, just standardize the logic. The current implementation has nonuniform logic -- PeopleEditController forbids uppercase. Test Plan: Ran unit tests, see also D1254. Reviewers: btrahan, jungejason, aran Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1415
2012-01-16 16:30:28 +01:00
'PhabricatorUserTestCase' => 'PhabricatorTestCase',
Add "Title" and "Blurb" to new profile editor Summary: Ref T1703. - Adds "Title". - Adds "Blurb". - Adds `user.fields` config for selecting and reordering. This will get UI in the next patch. Test Plan: {F45689} {F45690} Edited the fields, too. Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6153
2013-06-07 19:22:45 +02:00
'PhabricatorUserTitleField' => 'PhabricatorUserCustomField',
Flesh out ApplicationTransactions/CustomField integration Summary: None of this code is reachable yet. See discussion in D6147. Ref T1703. Provide tighter integration between ApplicationTransactions and CustomField. Basically, I'm just trying to get all the shared stuff into the base implementation. Test Plan: Code not reachable. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6149
2013-06-06 23:53:07 +02:00
'PhabricatorUserTransaction' => 'PhabricatorApplicationTransaction',
Workboards Summary: Adds Workboards and workpanels. This is a preliminary diff, I'm still working on mobile and tablet and a few missing features (header actions) Test Plan: FF, Chrome, iOS, iPad, iPhone, IE Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5455
2013-03-30 17:51:35 +01:00
'PhabricatorWorkboardExample' => 'PhabricatorUIExample',
'PhabricatorWorkboardView' => 'AphrontView',
Move completed tasks to an "archive" table and delete them in the GC Summary: Currently, when taskmasters complete a task it is immediately deleted. This prevents us from doing some general things, like: - Supporting the idea of permanent failure (e.g., after N failures just stop trying). - Showing the user how fast taskmasters are completing tasks. - Showing the user how long tasks took to complete. Having better visibility into this is important to Drydock, which builds on the task system. Also, generally buff debug output for task execution. Test Plan: Ran `bin/phd debug taskmaster`. Ran `bin/phd debug garbage`. Queued some tasks via various systems. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3852
2012-10-31 23:22:16 +01:00
'PhabricatorWorkerActiveTask' => 'PhabricatorWorkerTask',
'PhabricatorWorkerArchiveTask' => 'PhabricatorWorkerTask',
Rough cut of Workers Summary: workers do work, provided I have written them correctly. perhaps it is so. Test Plan: Reviewers: CC:
2011-03-10 22:48:29 +01:00
'PhabricatorWorkerDAO' => 'PhabricatorLiskDAO',
Move task leasing to a dedicated query Summary: This simplifies the fairly thorny logic of leasing tasks a bit. I'm planning to introduce another callsite shortly for Drydock. Test Plan: Ran `bin/phd debug taskmaster`, observed sensible queries and correct operation. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3855
2012-11-01 19:30:16 +01:00
'PhabricatorWorkerLeaseQuery' => 'PhabricatorQuery',
Factor out task execution and formalize permanent failures Summary: - Clean up a TODO about permanent failures. - Clean up a TODO about failing tasks after too many retries. - Clean up a TODO about testing for bad leases. - Make the lease/retry implementation more flexible and natural. - Make completely bogus tasks fail permanently. - Make PhabricatorMetaMTAWorker use new `getWaitBeforeRetry()` (as intended), not hackily implement logic in `getRequiredLeaseTime()`. - Document worker hooks for failures and retries. - Provide coverage on everything. Test Plan: Ran unit tests. Ran `bin/phd debug taskmaster`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3859
2012-11-01 19:30:23 +01:00
'PhabricatorWorkerPermanentFailureException' => 'Exception',
Rough cut of Workers Summary: workers do work, provided I have written them correctly. perhaps it is so. Test Plan: Reviewers: CC:
2011-03-10 22:48:29 +01:00
'PhabricatorWorkerTask' => 'PhabricatorWorkerDAO',
'PhabricatorWorkerTaskData' => 'PhabricatorWorkerDAO',
Improve daemon console.
2011-03-27 07:55:18 +02:00
'PhabricatorWorkerTaskDetailController' => 'PhabricatorDaemonController',
Add buttons to delete or free tasks from the queue Summary: See T709. I also ran into a case in Drydock where this is useful for testing/development. Test Plan: Freed lease of a task; deleted a task. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T709 Differential Revision: https://secure.phabricator.com/D1469
2012-01-24 01:36:32 +01:00
'PhabricatorWorkerTaskUpdateController' => 'PhabricatorDaemonController',
Factor out task execution and formalize permanent failures Summary: - Clean up a TODO about permanent failures. - Clean up a TODO about failing tasks after too many retries. - Clean up a TODO about testing for bad leases. - Make the lease/retry implementation more flexible and natural. - Make completely bogus tasks fail permanently. - Make PhabricatorMetaMTAWorker use new `getWaitBeforeRetry()` (as intended), not hackily implement logic in `getRequiredLeaseTime()`. - Document worker hooks for failures and retries. - Provide coverage on everything. Test Plan: Ran unit tests. Ran `bin/phd debug taskmaster`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3859
2012-11-01 19:30:23 +01:00
'PhabricatorWorkerTestCase' => 'PhabricatorTestCase',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorWorkingCopyDiscoveryTestCase' => 'PhabricatorWorkingCopyTestCase',
Make repository pulls testable Summary: Ref T2784. This moves us toward being able to test the background and Conduit pipelines for repositories. In particular: - Separate the logic for pulling repositories (`git pull`, `hg pull`) out of `PhabricatorRepositoryPullLocalDaemon` and put it in `PhabricatorRepositoryPullEngine`. This allows repositories to be pulled directly without invoking the daemons. - Add tests for the engine, including a future-looking base test case. - Add basic `PhutilDirectoryFixture`-based repositories. Next steps: # Do the same for repo discovery. # Then we can start writing tests against specific Conduit methods. Test Plan: Ran unit tests. Ran `bin/repository pull` on SVN, Hg and Git repositories. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran, nh Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5904
2013-05-13 04:05:52 +02:00
'PhabricatorWorkingCopyPullTestCase' => 'PhabricatorWorkingCopyTestCase',
'PhabricatorWorkingCopyTestCase' => 'PhabricatorTestCase',
Workboards Summary: Adds Workboards and workpanels. This is a preliminary diff, I'm still working on mobile and tablet and a few missing features (header actions) Test Plan: FF, Chrome, iOS, iPad, iPhone, IE Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5455
2013-03-30 17:51:35 +01:00
'PhabricatorWorkpanelView' => 'AphrontView',
xhpastview
2011-04-07 04:17:05 +02:00
'PhabricatorXHPASTViewController' => 'PhabricatorController',
'PhabricatorXHPASTViewDAO' => 'PhabricatorLiskDAO',
'PhabricatorXHPASTViewFrameController' => 'PhabricatorXHPASTViewController',
'PhabricatorXHPASTViewFramesetController' => 'PhabricatorXHPASTViewController',
'PhabricatorXHPASTViewInputController' => 'PhabricatorXHPASTViewPanelController',
'PhabricatorXHPASTViewPanelController' => 'PhabricatorXHPASTViewController',
'PhabricatorXHPASTViewParseTree' => 'PhabricatorXHPASTViewDAO',
'PhabricatorXHPASTViewRunController' => 'PhabricatorXHPASTViewController',
'PhabricatorXHPASTViewStreamController' => 'PhabricatorXHPASTViewPanelController',
'PhabricatorXHPASTViewTreeController' => 'PhabricatorXHPASTViewPanelController',
Very rough cut of DarkConsole + XHProf
2011-02-02 22:48:52 +01:00
'PhabricatorXHProfController' => 'PhabricatorController',
Do sampled profiling of requests Summary: People have occasionally complained about phabricator being slow. We have the access log to look at to see when slowness happens, but it doesn't tell us much about why it happened. Since it's usually a sporadic issue that's reported, it's hard to reproduce and then profile. This change will allow us to collect sampled profiles so we can look at them when slowness occurs. Test Plan: checking that sampling works correctly: - set rate to 0; do several page loads; check no new entries in table - set rate to 1; check that there's a new row in the table for each page load - set rate to 10; check that some requests write to table and some don't check new ui for samples: - load /xhprof/list/all/, see a list with a lot of samples - load /xhprof/list/sampled/, see only sampled runs - load /xhprof/list/manual/, see only non-sampled runs - load /xhprof/list/my-runs/, se only my manual runs Reviewers: vrana, epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3458
2012-08-25 00:14:38 +02:00
'PhabricatorXHProfDAO' => 'PhabricatorLiskDAO',
Very rough cut of DarkConsole + XHProf
2011-02-02 22:48:52 +01:00
'PhabricatorXHProfProfileController' => 'PhabricatorXHProfController',
Fix iframe issue for XHProf DarkConsole plugin Summary: While sort of gross, this seems fairly reasonable overall? I guess? (This patch clearly does more good than harm, although it could just do the good without the harm.) Test Plan: Clicked XHProf links from the frame and from the /xhprof/ tool. Reviewers: btrahan, aran, jungejason, ide Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T453 Differential Revision: https://secure.phabricator.com/D1498
2012-01-28 20:17:19 +01:00
'PhabricatorXHProfProfileSymbolView' => 'PhabricatorXHProfProfileView',
'PhabricatorXHProfProfileTopLevelView' => 'PhabricatorXHProfProfileView',
'PhabricatorXHProfProfileView' => 'AphrontView',
Do sampled profiling of requests Summary: People have occasionally complained about phabricator being slow. We have the access log to look at to see when slowness happens, but it doesn't tell us much about why it happened. Since it's usually a sporadic issue that's reported, it's hard to reproduce and then profile. This change will allow us to collect sampled profiles so we can look at them when slowness occurs. Test Plan: checking that sampling works correctly: - set rate to 0; do several page loads; check no new entries in table - set rate to 1; check that there's a new row in the table for each page load - set rate to 10; check that some requests write to table and some don't check new ui for samples: - load /xhprof/list/all/, see a list with a lot of samples - load /xhprof/list/sampled/, see only sampled runs - load /xhprof/list/manual/, see only non-sampled runs - load /xhprof/list/my-runs/, se only my manual runs Reviewers: vrana, epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3458
2012-08-25 00:14:38 +02:00
'PhabricatorXHProfSample' => 'PhabricatorXHProfDAO',
'PhabricatorXHProfSampleListController' => 'PhabricatorXHProfController',
Move skins toward modularization Summary: Two high-level things happening here: - We no longer ever need to put meta-UI (content creation, editing, notices, etc.) on live blog views, since this is all in Phame now. I pulled this out. - On the other hand, I pushed more routing/control logic into Skins and made the root skin a Controller instead of a View. This simplifies some of the code above skins, and the theory behind this is that it gives us greater flexibility to, e.g., put a glue layer between Phame and Wordpress templates or whatever else, and allows skins to handle routing and thus add pages like "About" or "Bio". - I added a basic skin below the root skin which is more like the old root skin and has standard rendering hooks. - "Ten Eleven" is a play on the popular (default?) Wordpress themes called "Twenty Ten", "Twenty Eleven" and "Twenty Twelve". Test Plan: Viewed live blog and live posts. They aren't pretty, but they don't have extraneous resources. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3714
2012-10-17 17:36:25 +02:00
'PhameBasicBlogSkin' => 'PhameBlogSkin',
Allow simple template-based skin definitions Summary: Lower the barrier to entry for installing and creating skins, so we can kill Wordpress. You can now install skins by dropping them into a directory, and build either "advanced" (full phutil library) skins or "basic" (simple PHP templates) skins. Next up is getting static resources working in an easy way for skins. I put these in `externals/` for now so they don't get hit by lint. Test Plan: Viewed the Pokeblog with the Oblivious skin. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3717
2012-10-17 17:36:48 +02:00
'PhameBasicTemplateBlogSkin' => 'PhameBasicBlogSkin',
Make PhameBlogs respect policies Summary: Adds "can view" and "can edit" policies to blogs. Replaces "bloggers" with "can join". This doesn't fully remove "bloggers" because I didn't want this to get too crazy/huge. Test Plan: Created, edited, deleted blogs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3693
2012-10-15 23:49:52 +02:00
'PhameBlog' =>
array(
0 => 'PhameDAO',
1 => 'PhabricatorPolicyInterface',
Improve Phame live blogs/posts Summary: Make "View Live" work on Posts. Test Plan: Clicked "View Live" on live/not-live posts/blogs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3703
2012-10-15 23:51:30 +02:00
2 => 'PhabricatorMarkupInterface',
Make PhameBlogs respect policies Summary: Adds "can view" and "can edit" policies to blogs. Replaces "bloggers" with "can join". This doesn't fully remove "bloggers" because I didn't want this to get too crazy/huge. Test Plan: Created, edited, deleted blogs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3693
2012-10-15 23:49:52 +02:00
),
Phame - introduce blogs Summary: blogs are collections of posts. a blog also has metadata like a name, description and "bloggers" that can edit the metadata of the blog and contribute posts. changes include the post edit flow where bloggers can now select which blogs to publish to. also made various small tweaks throughout the UI to make things sensical and clean as the concept of blogs is introduced. there's edges powering this stuff. bloggers <=> blogs and posts <=> blogs in particular. Test Plan: made blogs, deleted blogs, tried to make blogs with no bloggers. all went well. verified ui to publish only showed up for public posts, published posts to blogs, un-published posts to blogs, re-published posts to blogs, deleted posts and verified they disappeared from blogs. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3003
2012-07-19 18:03:10 +02:00
'PhameBlogDeleteController' => 'PhameController',
'PhameBlogEditController' => 'PhameController',
Add Atom export to Phame Summary: There's no link to this yet, I'll add it to some skin. Fixes T2272. Test Plan: http://validator.w3.org/appc/ Reviewers: btrahan, epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2272 Differential Revision: https://secure.phabricator.com/D4366
2013-01-09 04:53:34 +01:00
'PhameBlogFeedController' => 'PhameController',
Modernize blog UI Summary: Cleans up some of the mess I made in D3694. Basically: - All blogs have an "internal" view with posts that uses mobile-friendly UIs, etc., so we don't have to do as much work with skins -- they just have to look pretty. - Blogs now have a separate "live" view that we use to handle domains / skins. - Simplified some views and use IDs in some URLs for consistency. - Delete a bunch of edge/blogger/multi-blog code that's now obsolete. Test Plan: Will attach screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3695
2012-10-15 23:50:12 +02:00
'PhameBlogListController' => 'PhameController',
'PhameBlogLiveController' => 'PhameController',
Make PhameBlogs respect policies Summary: Adds "can view" and "can edit" policies to blogs. Replaces "bloggers" with "can join". This doesn't fully remove "bloggers" because I didn't want this to get too crazy/huge. Test Plan: Created, edited, deleted blogs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3693
2012-10-15 23:49:52 +02:00
'PhameBlogQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Move skins toward modularization Summary: Two high-level things happening here: - We no longer ever need to put meta-UI (content creation, editing, notices, etc.) on live blog views, since this is all in Phame now. I pulled this out. - On the other hand, I pushed more routing/control logic into Skins and made the root skin a Controller instead of a View. This simplifies some of the code above skins, and the theory behind this is that it gives us greater flexibility to, e.g., put a glue layer between Phame and Wordpress templates or whatever else, and allows skins to handle routing and thus add pages like "About" or "Bio". - I added a basic skin below the root skin which is more like the old root skin and has standard rendering hooks. - "Ten Eleven" is a play on the popular (default?) Wordpress themes called "Twenty Ten", "Twenty Eleven" and "Twenty Twelve". Test Plan: Viewed live blog and live posts. They aren't pretty, but they don't have extraneous resources. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3714
2012-10-17 17:36:25 +02:00
'PhameBlogSkin' => 'PhabricatorController',
Phame - introduce blogs Summary: blogs are collections of posts. a blog also has metadata like a name, description and "bloggers" that can edit the metadata of the blog and contribute posts. changes include the post edit flow where bloggers can now select which blogs to publish to. also made various small tweaks throughout the UI to make things sensical and clean as the concept of blogs is introduced. there's edges powering this stuff. bloggers <=> blogs and posts <=> blogs in particular. Test Plan: made blogs, deleted blogs, tried to make blogs with no bloggers. all went well. verified ui to publish only showed up for public posts, published posts to blogs, un-published posts to blogs, re-published posts to blogs, deleted posts and verified they disappeared from blogs. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3003
2012-07-19 18:03:10 +02:00
'PhameBlogViewController' => 'PhameController',
Phame V1 - Phabricator blogging software Summary: 'cuz we need to be phamous! V1 feature set - posts -- standard thing you'd expect - a title and a remarkup-powered body and... -- "phame" title - a short string that can be used to reference the story. this gets auto-updated when you mess with the title. -- configuration - for now, do you want Facebook, Disqus or no comments? this is a per-post thing but feeds from an instance-wide configuration Please do toss out any must have features or changes. Test Plan: played around with this bad boy like whoa Reviewers: epriestley Reviewed By: epriestley CC: aran, vrana Maniphest Tasks: T1111 Differential Revision: https://secure.phabricator.com/D2202
2012-04-12 22:09:04 +02:00
'PhameController' => 'PhabricatorController',
'PhameDAO' => 'PhabricatorLiskDAO',
Modernize blog UI Summary: Cleans up some of the mess I made in D3694. Basically: - All blogs have an "internal" view with posts that uses mobile-friendly UIs, etc., so we don't have to do as much work with skins -- they just have to look pretty. - Blogs now have a separate "live" view that we use to handle domains / skins. - Simplified some views and use IDs in some URLs for consistency. - Delete a bunch of edge/blogger/multi-blog code that's now obsolete. Test Plan: Will attach screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3695
2012-10-15 23:50:12 +02:00
'PhamePost' =>
array(
0 => 'PhameDAO',
1 => 'PhabricatorPolicyInterface',
Improve Phame live blogs/posts Summary: Make "View Live" work on Posts. Test Plan: Clicked "View Live" on live/not-live posts/blogs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3703
2012-10-15 23:51:30 +02:00
2 => 'PhabricatorMarkupInterface',
Arc liberate fix Summary: Run arc liberate and commit the results on the assumption that someone forgot to do this in another diff, or their results were discarded by an automatic merge during rebase. Test Plan: None. Reviewers: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5889
2013-05-10 18:11:14 +02:00
3 => 'PhabricatorTokenReceiverInterface',
Modernize blog UI Summary: Cleans up some of the mess I made in D3694. Basically: - All blogs have an "internal" view with posts that uses mobile-friendly UIs, etc., so we don't have to do as much work with skins -- they just have to look pretty. - Blogs now have a separate "live" view that we use to handle domains / skins. - Simplified some views and use IDs in some URLs for consistency. - Delete a bunch of edge/blogger/multi-blog code that's now obsolete. Test Plan: Will attach screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3695
2012-10-15 23:50:12 +02:00
),
Phame V1 - Phabricator blogging software Summary: 'cuz we need to be phamous! V1 feature set - posts -- standard thing you'd expect - a title and a remarkup-powered body and... -- "phame" title - a short string that can be used to reference the story. this gets auto-updated when you mess with the title. -- configuration - for now, do you want Facebook, Disqus or no comments? this is a per-post thing but feeds from an instance-wide configuration Please do toss out any must have features or changes. Test Plan: played around with this bad boy like whoa Reviewers: epriestley Reviewed By: epriestley CC: aran, vrana Maniphest Tasks: T1111 Differential Revision: https://secure.phabricator.com/D2202
2012-04-12 22:09:04 +02:00
'PhamePostDeleteController' => 'PhameController',
'PhamePostEditController' => 'PhameController',
Mostly modernize post edit/detail UIs Summary: Still some big chunks left but this moves us a bit closer to getting everything device-ready. Stuff not addressed here but which I'm planning to do soon: - Posts don't have a live URI yet. - Post detail pages don't actually show the post content. I'm going to tweak PhabricatorObjectPropertyListView for this since we need it some other places. - Some of the hinting about use/states is gone (e.g., "This post is a draft, publish it to make it live to the world."); I'm planning to restore it. - Left nav is still a bit of a mess with states/highlighting. Major changes are: - If you click "New Post" you get a screen asking you to pick a blog to post to. - "Publish/Preview" and Unpublish are now separate actions from the post detail screen. - "Publish/Preview" renders a preview of the post in an iframe and gives you a "Publish" button. Test Plan: Will attach screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3697
2012-10-15 23:50:45 +02:00
'PhamePostFramedController' => 'PhameController',
Modernize Phame post lists Summary: Use device UI for all post lists. Left menu is a bit wonky but I'll clean that up shortly. Test Plan: Will add screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3696
2012-10-15 23:50:37 +02:00
'PhamePostListController' => 'PhameController',
Mostly modernize post edit/detail UIs Summary: Still some big chunks left but this moves us a bit closer to getting everything device-ready. Stuff not addressed here but which I'm planning to do soon: - Posts don't have a live URI yet. - Post detail pages don't actually show the post content. I'm going to tweak PhabricatorObjectPropertyListView for this since we need it some other places. - Some of the hinting about use/states is gone (e.g., "This post is a draft, publish it to make it live to the world."); I'm planning to restore it. - Left nav is still a bit of a mess with states/highlighting. Major changes are: - If you click "New Post" you get a screen asking you to pick a blog to post to. - "Publish/Preview" and Unpublish are now separate actions from the post detail screen. - "Publish/Preview" renders a preview of the post in an iframe and gives you a "Publish" button. Test Plan: Will attach screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3697
2012-10-15 23:50:45 +02:00
'PhamePostNewController' => 'PhameController',
Improve Phame live blogs/posts Summary: Make "View Live" work on Posts. Test Plan: Clicked "View Live" on live/not-live posts/blogs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3703
2012-10-15 23:51:30 +02:00
'PhamePostNotLiveController' => 'PhameController',
Phame V1 - Phabricator blogging software Summary: 'cuz we need to be phamous! V1 feature set - posts -- standard thing you'd expect - a title and a remarkup-powered body and... -- "phame" title - a short string that can be used to reference the story. this gets auto-updated when you mess with the title. -- configuration - for now, do you want Facebook, Disqus or no comments? this is a per-post thing but feeds from an instance-wide configuration Please do toss out any must have features or changes. Test Plan: played around with this bad boy like whoa Reviewers: epriestley Reviewed By: epriestley CC: aran, vrana Maniphest Tasks: T1111 Differential Revision: https://secure.phabricator.com/D2202
2012-04-12 22:09:04 +02:00
'PhamePostPreviewController' => 'PhameController',
Mostly modernize post edit/detail UIs Summary: Still some big chunks left but this moves us a bit closer to getting everything device-ready. Stuff not addressed here but which I'm planning to do soon: - Posts don't have a live URI yet. - Post detail pages don't actually show the post content. I'm going to tweak PhabricatorObjectPropertyListView for this since we need it some other places. - Some of the hinting about use/states is gone (e.g., "This post is a draft, publish it to make it live to the world."); I'm planning to restore it. - Left nav is still a bit of a mess with states/highlighting. Major changes are: - If you click "New Post" you get a screen asking you to pick a blog to post to. - "Publish/Preview" and Unpublish are now separate actions from the post detail screen. - "Publish/Preview" renders a preview of the post in an iframe and gives you a "Publish" button. Test Plan: Will attach screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3697
2012-10-15 23:50:45 +02:00
'PhamePostPublishController' => 'PhameController',
Modernize blog UI Summary: Cleans up some of the mess I made in D3694. Basically: - All blogs have an "internal" view with posts that uses mobile-friendly UIs, etc., so we don't have to do as much work with skins -- they just have to look pretty. - Blogs now have a separate "live" view that we use to handle domains / skins. - Simplified some views and use IDs in some URLs for consistency. - Delete a bunch of edge/blogger/multi-blog code that's now obsolete. Test Plan: Will attach screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3695
2012-10-15 23:50:12 +02:00
'PhamePostQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Mostly modernize post edit/detail UIs Summary: Still some big chunks left but this moves us a bit closer to getting everything device-ready. Stuff not addressed here but which I'm planning to do soon: - Posts don't have a live URI yet. - Post detail pages don't actually show the post content. I'm going to tweak PhabricatorObjectPropertyListView for this since we need it some other places. - Some of the hinting about use/states is gone (e.g., "This post is a draft, publish it to make it live to the world."); I'm planning to restore it. - Left nav is still a bit of a mess with states/highlighting. Major changes are: - If you click "New Post" you get a screen asking you to pick a blog to post to. - "Publish/Preview" and Unpublish are now separate actions from the post detail screen. - "Publish/Preview" renders a preview of the post in an iframe and gives you a "Publish" button. Test Plan: Will attach screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3697
2012-10-15 23:50:45 +02:00
'PhamePostUnpublishController' => 'PhameController',
Move skins toward modularization Summary: Two high-level things happening here: - We no longer ever need to put meta-UI (content creation, editing, notices, etc.) on live blog views, since this is all in Phame now. I pulled this out. - On the other hand, I pushed more routing/control logic into Skins and made the root skin a Controller instead of a View. This simplifies some of the code above skins, and the theory behind this is that it gives us greater flexibility to, e.g., put a glue layer between Phame and Wordpress templates or whatever else, and allows skins to handle routing and thus add pages like "About" or "Bio". - I added a basic skin below the root skin which is more like the old root skin and has standard rendering hooks. - "Ten Eleven" is a play on the popular (default?) Wordpress themes called "Twenty Ten", "Twenty Eleven" and "Twenty Twelve". Test Plan: Viewed live blog and live posts. They aren't pretty, but they don't have extraneous resources. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3714
2012-10-17 17:36:25 +02:00
'PhamePostView' => 'AphrontView',
Phame V1 - Phabricator blogging software Summary: 'cuz we need to be phamous! V1 feature set - posts -- standard thing you'd expect - a title and a remarkup-powered body and... -- "phame" title - a short string that can be used to reference the story. this gets auto-updated when you mess with the title. -- configuration - for now, do you want Facebook, Disqus or no comments? this is a per-post thing but feeds from an instance-wide configuration Please do toss out any must have features or changes. Test Plan: played around with this bad boy like whoa Reviewers: epriestley Reviewed By: epriestley CC: aran, vrana Maniphest Tasks: T1111 Differential Revision: https://secure.phabricator.com/D2202
2012-04-12 22:09:04 +02:00
'PhamePostViewController' => 'PhameController',
Allow blog resources to be served without Celerity Summary: Allow skins to serve arbitrary resources without needing to be mapped, so we can have a vibrant community of amateur skinners. For "basic" skins, just put all the "css/" on the page always. Includes an image to prove that works. @vrana, pretty sure this has no impact outside of Phame but it does change Celerity so it might be to blame if there's any weirdness with static resources. Test Plan: {F21341} {F21340} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3719
2012-10-17 17:37:05 +02:00
'PhameResourceController' => 'CelerityResourceController',
Phlux v0 Summary: Yup, it's sitevars. No conduit or caching or fancy stuff yet. Ref T2793. Test Plan: {F36525} {F36526} {F36527} {F36528} {F36529} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2793 Differential Revision: https://secure.phabricator.com/D5397
2013-03-21 02:01:52 +01:00
'PhluxController' => 'PhabricatorController',
'PhluxDAO' => 'PhabricatorLiskDAO',
'PhluxEditController' => 'PhluxController',
'PhluxListController' => 'PhluxController',
'PhluxTransaction' => 'PhabricatorApplicationTransaction',
'PhluxTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'PhluxVariable' =>
array(
0 => 'PhluxDAO',
1 => 'PhabricatorPolicyInterface',
),
'PhluxVariableEditor' => 'PhabricatorApplicationTransactionEditor',
'PhluxVariableQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhluxViewController' => 'PhluxController',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioController' => 'PhabricatorController',
'PholioDAO' => 'PhabricatorLiskDAO',
'PholioImage' =>
array(
0 => 'PholioDAO',
1 => 'PhabricatorMarkupInterface',
),
Show editor Summary: Show editor when user clicks edit button for inline comment. Test Plan: Verified that editor is shown. Reviewers: epriestley CC: aran, Korvin Maniphest Tasks: T2446 Differential Revision: https://secure.phabricator.com/D5030
2013-02-22 15:39:08 +01:00
'PholioInlineCommentEditView' => 'AphrontView',
'PholioInlineCommentSaveView' => 'AphrontView',
Moved rendering to PholioInlineCommentView Summary: Rendering of inline comments has now been moved to PholioInlineCommentView controller. Delete almost deletes and edit... well not so much, but replaced google.fi with amazing popup. Test Plan: Verified that inline comments still show up. Verified that delete almost deletes. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2446 Differential Revision: https://secure.phabricator.com/D4994 Conflicts: src/applications/pholio/controller/PholioInlineController.php
2013-02-19 23:12:33 +01:00
'PholioInlineCommentView' => 'AphrontView',
Show saved inline comments Summary: Saved inline comments are now shown for images. Test Plan: Verified that inline comments are loaded and shown. Reviewers: epriestley CC: aran, Korvin Maniphest Tasks: T2446 Differential Revision: https://secure.phabricator.com/D4866
2013-02-08 16:24:17 +01:00
'PholioInlineController' => 'PholioController',
Moved rendering to PholioInlineCommentView Summary: Rendering of inline comments has now been moved to PholioInlineCommentView controller. Delete almost deletes and edit... well not so much, but replaced google.fi with amazing popup. Test Plan: Verified that inline comments still show up. Verified that delete almost deletes. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2446 Differential Revision: https://secure.phabricator.com/D4994 Conflicts: src/applications/pholio/controller/PholioInlineController.php
2013-02-19 23:12:33 +01:00
'PholioInlineDeleteController' => 'PholioController',
Show editor Summary: Show editor when user clicks edit button for inline comment. Test Plan: Verified that editor is shown. Reviewers: epriestley CC: aran, Korvin Maniphest Tasks: T2446 Differential Revision: https://secure.phabricator.com/D5030
2013-02-22 15:39:08 +01:00
'PholioInlineEditController' => 'PholioController',
Select portions from mock Summary: Comment draft is now saved Test Plan: Verified that draft is saved Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2446 Differential Revision: https://secure.phabricator.com/D4831
2013-02-06 20:28:03 +01:00
'PholioInlineSaveController' => 'PholioController',
Pholio inline comment now include a thumbnail and link Summary: Pholio inline comment now include a thumbnail and link to the Image being commented on Test Plan: {F36331} Reviewers: chad, epriestley Reviewed By: epriestley CC: aran, Korvin, btrahan Maniphest Tasks: T2709 Differential Revision: https://secure.phabricator.com/D5375
2013-03-20 13:36:53 +01:00
'PholioInlineThumbController' => 'PholioController',
Moved rendering to PholioInlineCommentView Summary: Rendering of inline comments has now been moved to PholioInlineCommentView controller. Delete almost deletes and edit... well not so much, but replaced google.fi with amazing popup. Test Plan: Verified that inline comments still show up. Verified that delete almost deletes. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2446 Differential Revision: https://secure.phabricator.com/D4994 Conflicts: src/applications/pholio/controller/PholioInlineController.php
2013-02-19 23:12:33 +01:00
'PholioInlineViewController' => 'PholioController',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioMock' =>
array(
0 => 'PholioDAO',
1 => 'PhabricatorMarkupInterface',
2 => 'PhabricatorPolicyInterface',
3 => 'PhabricatorSubscribableInterface',
Tokens v1 Summary: Features! - Giving tokens. - Taking tokens back. - Not giving tokens. Test Plan: See screenshots. Reviewers: chad, vrana Reviewed By: chad CC: aran, btrahan Maniphest Tasks: T2541 Differential Revision: https://secure.phabricator.com/D4964
2013-02-15 16:47:14 +01:00
4 => 'PhabricatorTokenReceiverInterface',
Garbage collect TTL'd cache entries from the general cache Summary: We currently garbage collect general cache entries after a set period of time (30 days by default), but the recent changes to DarkConsole have left us writing a lot of large, short-TTL data to the cache. In addition to a maximum age, GC cache entires after they TTL out. Test Plan: Ran GC daemon, saw TTL'd entries get collected. Inserted a TTL'd entry, saw it get collected by GC. Saw non-ttl'd entries not get collected. Reviewers: chad Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D4990
2013-02-17 18:13:49 +01:00
5 => 'PhabricatorApplicationTransactionInterface',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
),
Allow users to add comments in Pholio Summary: Basic support for adding comments. Missing a lot of frills. Uses new comment/transaction UI. Test Plan: Added some comments. Tried to add an empty comment. Some comments: {F22361} No text provided: {F22362} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3834
2012-11-22 02:27:20 +01:00
'PholioMockCommentController' => 'PholioController',
Add very basic create interface for Pholio Summary: Nothing app-specific yet, just stitching groundwork together from readymade components. {F22347} Test Plan: Created some mocks via web UI. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3830
2012-11-22 02:23:28 +01:00
'PholioMockEditController' => 'PholioController',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PholioMockEditor' => 'PhabricatorApplicationTransactionEditor',
Pholio mocks embed in a fancy way Summary: Pholio mocks are now embed in a fancy way Test Plan: {F34804} Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin, AnhNhan Maniphest Tasks: T2626 Differential Revision: https://secure.phabricator.com/D5249
2013-03-07 17:23:40 +01:00
'PholioMockEmbedView' => 'AphrontView',
Pholio tile to home page and mock to show first image Summary: Pholio tile to show up on home page First image is shown at mock page. Test Plan: Pholio app shows up on home page. First image is shown at mock page. Reviewers: epriestley CC: aran, Korvin Maniphest Tasks: T2356 Differential Revision: https://secure.phabricator.com/D4553
2013-01-20 18:29:34 +01:00
'PholioMockImagesView' => 'AphrontView',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioMockListController' => 'PholioController',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PholioMockMailReceiver' => 'PhabricatorObjectMailReceiver',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioMockQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PholioMockViewController' => 'PholioController',
Prepare for hovercards Summary: - Unify all the reference/embed Remarkup rules for Differential, Maniphest, Paste and Ponder. - Add rules for Pholio. - Does not yet unify Diffusion or Files (both are a bit more involved). - Prepare for hovercards. Test Plan: {F33894} Reviewers: chad, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5120
2013-02-26 23:59:31 +01:00
'PholioRemarkupRule' => 'PhabricatorRemarkupRuleObject',
Add basic email support to Pholio Summary: These emails aren't yet useful, but thread/multiplex/etc correctly. Test Plan: Got some Pholio emails. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3842
2012-11-22 02:39:46 +01:00
'PholioReplyHandler' => 'PhabricatorMailReplyHandler',
Improve Search architecture Summary: The search indexing API has several problems right now: - Always runs in-process. - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it. - Being able to use the task queue will also make rebuilding indexes faster. - Instead, make the API phid-oriented. - No uniform indexing API. - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird. - Instead, provide a uniform API. - No uniform CLI. - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers. - Instead, let indexers expose documents for indexing. - Not application-oriented. - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world. - Instead, move indexers to applications and load them with SymbolLoader. Test Plan: - `bin/search index` - Indexed one revision, one task. - Indexed `--type TASK`, `--type DREV`, etc., for all types. - Indexed `--all`. - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it. - Creating users is a pain; searched for a user after indexing. - Creating commits is a pain; searched for a commit after indexing. - Mocks aren't currently loadable in the result view, so their indexing is moot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: 20after4, aran Maniphest Tasks: T1991, T2104 Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
'PholioSearchIndexer' => 'PhabricatorSearchDocumentIndexer',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PholioTransaction' => 'PhabricatorApplicationTransaction',
'PholioTransactionComment' => 'PhabricatorApplicationTransactionComment',
Add feed integration to generic transactions Summary: Publish feed stories, including from Pholio. Actual stories are somewhat garbage but it's all display-time; I'm going to do a pass on feed in general. Test Plan: {F26832} Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4140
2012-12-11 23:00:21 +01:00
'PholioTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Make Pholio mock edits (mostly) transaction-oriented Summary: - Use transactions to apply edits. - Use Editor to apply transactions. - Some special casing for tricky stuff I don't want to deal with yet (mock images). Test Plan: {F22368} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3837
2012-11-22 02:27:44 +01:00
'PholioTransactionType' => 'PholioConstants',
Group inline transactions in Pholio Summary: Fixes T2639 by grouping related transactions at display time, so all the inlines merge into a nice block. (Note that this does not do anything about T2709 yet, so there's still no way to figure out where the inlines actually are.) Test Plan: {F35262} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2639 Differential Revision: https://secure.phabricator.com/D5313
2013-03-10 04:23:50 +01:00
'PholioTransactionView' => 'PhabricatorApplicationTransactionView',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneAccount' =>
array(
0 => 'PhortuneDAO',
1 => 'PhabricatorPolicyInterface',
),
Don't use deprected "1" value to cURL CURLOPT_SSL_VERIFYHOST Summary: Fixes T2962. That task discusses this issue. Test Plan: Read php-curl documentation to verify this change makes sense. Sent an email with SES. Reviewers: btrahan, garoevans Reviewed By: garoevans CC: aran Maniphest Tasks: T2962 Differential Revision: https://secure.phabricator.com/D5669
2013-04-12 17:10:22 +02:00
'PhortuneAccountBuyController' => 'PhortuneController',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneAccountEditor' => 'PhabricatorApplicationTransactionEditor',
'PhortuneAccountQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhortuneAccountTransaction' => 'PhabricatorApplicationTransaction',
'PhortuneAccountTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'PhortuneAccountViewController' => 'PhortuneController',
Implement Balanced Payments as a PhortunePaymentProvider Summary: Allows Balanced payment methods to be added. This works essentially the same way as Stripe, except everything is a little bit different. Slightly more stuff could be shared, but I feel //mostly// good about this. I'll probably do a bit more cleanup next. Some of the error handling is messy, in particular. Ref T2787. Test Plan: Added Balanced and Stripe payment methods. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5765
2013-04-25 18:48:04 +02:00
'PhortuneBalancedPaymentProvider' => 'PhortunePaymentProvider',
Add "Carts" to Phortune Summary: Although I imagine we aren't really going to have an "add to cart" type storefront, putting this in place makes a lot of other workflows simpler. No storage yet, just allows reasonable construction of a "buy stuff" page. Test Plan: {F41342} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5745
2013-04-25 18:45:07 +02:00
'PhortuneCart' => 'PhortuneDAO',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneCharge' => 'PhortuneDAO',
'PhortuneController' => 'PhabricatorController',
Show prices in "$... USD" in Phortune Summary: Ref T2787. See discussion in D5834. - Replace `PhortuneUtil` with `PhortuneCurrency`, which feels a little better and more flexible / future-proof. - Add unit tests. - Display prices explicitly as "$... USD". Test Plan: Hit product list, cart, purchase flow, verified displays. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5841
2013-05-07 03:04:45 +02:00
'PhortuneCurrencyTestCase' => 'PhabricatorTestCase',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneDAO' => 'PhabricatorLiskDAO',
General cleanup for adding payment methods in Phortune Summary: This has no real behavioral changes (except better error handling), it just factors things out to be a bit cleaner. In particular: - Move more shared form behaviors into the common JS form component. - Move more error handling into shared pathways. - Make the specialized Stripe / Balanced methods do less work. This needs some more polish for nontrival errors (especially on the Balanced side) but none of the error behavior is worse than it was and a lot of it is much better. Ref T2787. Test Plan: Hit all invalid form errors, added valid payment methods with Stripe and Balacned. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5771
2013-04-25 18:49:32 +02:00
'PhortuneErrCode' => 'PhortuneConstants',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneLandingController' => 'PhortuneController',
For discussion -- Stripe integration Summary: various stripe stuff, including - external stripe library - payment form - test controller to play with payment form, sample business logic My main questions / discussion topics are... - is the stripe PHP library too big? (ie should I write something more simple just for phabricator?) -- if its cool, what is the best way to include the client? (ie should I make it a submodule rather than the flat copy here?) - is the JS I wrote (too) ridiculous? -- particularly unhappy with the error message stuff being in JS *but* it seemed the best choice given the most juicy error messages come from the stripe JS such that the overall code complexity is lowest this way. - how should the stripe JS be included? -- flat copy like I did here? -- some sort of external? -- can we just load it off stripe servers at request time? (I like that from the "if stripe is down, stripe is down" perspective) - wasn't sure if the date control was too silly and should just be baked into the form? -- for some reason I feel like its good to be prepared to walk away from Stripe / switch providers here, though I think this is on the wrong side of pragmatic Test Plan: - played around with sample client form Reviewers: epriestley Reviewed By: epriestley CC: aran Differential Revision: https://secure.phabricator.com/D2096
2012-04-05 01:09:29 +02:00
'PhortuneMonthYearExpiryControl' => 'AphrontFormControl',
Add basic payment providers to Phortune Summary: Abstract out the Stripiness of payment providers so we can add a Test provider (and maybe MtGox / Balanced / Paypal / etc). Ref T2787. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5752
2013-04-25 18:45:43 +02:00
'PhortuneMultiplePaymentProvidersException' => 'Exception',
'PhortuneNoPaymentProviderException' => 'Exception',
Clean up rendering of credit card form Summary: General cleanup and separation into generic vs Stripe blocks of code. - There was an old CC form view for Stripe stuff that I never cleaned up; clean that up. - Move non-Stripe CC form rendering into a base class (Balanced can reuse it). - Move non-Stripe CC form JS into a shareable class. - Simplify JS a bit (JX.Workflow can add extra parameters to a request, so we don't need hidden inputs). - Genericize CSS. - Depend on Stripe JS directly, if they're down we're not going to be able to add cards anyway. Ref T2787. Test Plan: Hit all Stripe errors and added new cards. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5758
2013-04-25 18:46:59 +02:00
'PhortuneNotImplementedException' => 'Exception',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortunePaymentMethod' =>
array(
0 => 'PhortuneDAO',
1 => 'PhabricatorPolicyInterface',
),
Phortune v0.1: add payment methods Summary: Hook @btrahan's Stripe form to the rest of Phortune. - Users can add payment methods. - They are saved to Stripe and associated with PhortunePaymentMethods on our side. - Payment methods appear on account overview. Test Plan: {F37548} {F37549} {F37550} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5438
2013-03-28 17:11:42 +01:00
'PhortunePaymentMethodEditController' => 'PhortuneController',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortunePaymentMethodListController' => 'PhabricatorController',
Phortune v0.1: add payment methods Summary: Hook @btrahan's Stripe form to the rest of Phortune. - Users can add payment methods. - They are saved to Stripe and associated with PhortunePaymentMethods on our side. - Payment methods appear on account overview. Test Plan: {F37548} {F37549} {F37550} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5438
2013-03-28 17:11:42 +01:00
'PhortunePaymentMethodQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortunePaymentMethodViewController' => 'PhabricatorController',
Add basic payment providers to Phortune Summary: Abstract out the Stripiness of payment providers so we can add a Test provider (and maybe MtGox / Balanced / Paypal / etc). Ref T2787. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5752
2013-04-25 18:45:43 +02:00
'PhortunePaymentProviderTestCase' => 'PhabricatorTestCase',
Add initial cut of PayPal and pay-once-at-checkout providers to Phortune Summary: Paypal doesn't let us capture cards in a PCI-free way like Stripe and Balanced do, but we can provide a "pay with paypal" option at checkout. (For subscriptions, we'll have to invoice monthly to retain control over billing, but this doesn't seem wildly unreasonable.) The bitcoin provider MtGox works in a similar way, as do some other providers we might some day want to implement. This adds: - Hooks to providers so they can offer "pay once at checkout" workflows. - Hooks so providers can have controllers, for redirect-based third-party workflows. - Basic Paypal integration using the "Express Checkout Merchant API", which seems like the best fit for our use case. This only goes as far as shoving the user through the payment flow; we don't actually capture payments yet (paypal has around 35 different APIs, but this one seems to be the only PCI-free one which wouldn't give users an awful experience). This diff is fairly checkpointey, but Phortune doesn't really bill anything yet anyway. Ref T2787. Test Plan: Ran through Paypal sandbox workflow; "paid" for stuff. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5834
2013-05-06 20:44:24 +02:00
'PhortunePaypalPaymentProvider' => 'PhortunePaymentProvider',
Phortune v0.1: products Summary: Ref T2787. A product is the abstract representation of something you can buy or rent/subscribe to. Although the interface isn't locked down yet, this would ultimately be internal/administrative. Products likely have some user-facing skin on top of them: plans would have a purchasing/comparison flow, physical goods would have a storefront, etc., so products don't have any information like descriptions or images, just the data that Phortune needs to correctly bill accounts. Generally, this is very basic for the moment. Test Plan: {F37594} {F37595} {F37596} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5441
2013-03-28 17:13:07 +01:00
'PhortuneProduct' =>
array(
0 => 'PhortuneDAO',
1 => 'PhabricatorPolicyInterface',
),
'PhortuneProductEditController' => 'PhabricatorController',
'PhortuneProductEditor' => 'PhabricatorApplicationTransactionEditor',
'PhortuneProductListController' => 'PhabricatorController',
'PhortuneProductQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhortuneProductTransaction' => 'PhabricatorApplicationTransaction',
'PhortuneProductTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Add "Carts" to Phortune Summary: Although I imagine we aren't really going to have an "add to cart" type storefront, putting this in place makes a lot of other workflows simpler. No storage yet, just allows reasonable construction of a "buy stuff" page. Test Plan: {F41342} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5745
2013-04-25 18:45:07 +02:00
'PhortuneProductViewController' => 'PhortuneController',
Add initial cut of PayPal and pay-once-at-checkout providers to Phortune Summary: Paypal doesn't let us capture cards in a PCI-free way like Stripe and Balanced do, but we can provide a "pay with paypal" option at checkout. (For subscriptions, we'll have to invoice monthly to retain control over billing, but this doesn't seem wildly unreasonable.) The bitcoin provider MtGox works in a similar way, as do some other providers we might some day want to implement. This adds: - Hooks to providers so they can offer "pay once at checkout" workflows. - Hooks so providers can have controllers, for redirect-based third-party workflows. - Basic Paypal integration using the "Express Checkout Merchant API", which seems like the best fit for our use case. This only goes as far as shoving the user through the payment flow; we don't actually capture payments yet (paypal has around 35 different APIs, but this one seems to be the only PCI-free one which wouldn't give users an awful experience). This diff is fairly checkpointey, but Phortune doesn't really bill anything yet anyway. Ref T2787. Test Plan: Ran through Paypal sandbox workflow; "paid" for stuff. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5834
2013-05-06 20:44:24 +02:00
'PhortuneProviderController' => 'PhortuneController',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortunePurchase' => 'PhortuneDAO',
Add basic payment providers to Phortune Summary: Abstract out the Stripiness of payment providers so we can add a Test provider (and maybe MtGox / Balanced / Paypal / etc). Ref T2787. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5752
2013-04-25 18:45:43 +02:00
'PhortuneStripePaymentProvider' => 'PhortunePaymentProvider',
'PhortuneTestExtraPaymentProvider' => 'PhortunePaymentProvider',
'PhortuneTestPaymentProvider' => 'PhortunePaymentProvider',
Add WePay as a one-time payment provider Summary: Ref T2787. I //think// we could also use WePay as a recurring payment provider, but this is somewhat messy (OAuth + requires account) -- basically it's "add a WePay account" instead of "add a credit card". The WePay checkout workflow is a bit upsell-y but basically reasonable. I like that their API just has a `request($method, $params)` method instead of 30,000 lines of methods for each request type. I did hit one bug; I'll send a pull for that. Test Plan: Got as far as the charge callback in testing; the rest isn't implemented for any provider yet. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5982
2013-05-22 00:34:46 +02:00
'PhortuneWePayPaymentProvider' => 'PhortunePaymentProvider',
Implemented Phrequent time tracking functionality. Summary: This differential implements Phrequent's time tracking functionality for users and hooks it up to Maniphest. It also includes a basic "Time Tracked" list for the Phrequent application, where users can review what they've spent time working on. Test Plan: Apply the patch and track some things in Maniphest. They should appear in the "Time Tracked" view of Phrequent. There is also a `phrequent.show-prompt` option which toggles whether to display a prompt when tracking time. I'm unsure of whether the prompt is useful or is more likely to cause people to click "Track Time", go off and do the task and then come back to the prompt still waiting for them to confirm. A potential solution to the "accidentally clicking the button and recording 2 seconds of time" might be to show a prompt on stop if the total time is under 10 seconds, asking whether the user wants to keep or discard the tracked time. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2857 Differential Revision: https://secure.phabricator.com/D5479
2013-03-30 17:32:29 +01:00
'PhrequentController' => 'PhabricatorController',
'PhrequentDAO' => 'PhabricatorLiskDAO',
'PhrequentListController' => 'PhrequentController',
Prevent double-submit with control + enter Summary: Fixes T2833. Lock forms and prevent double submit on control + enter. Test Plan: Mashed control + enter a whole bunch in Maniphest, got one comment instead of several. Reviewers: btrahan, edward Reviewed By: btrahan CC: aran Maniphest Tasks: T2833 Differential Revision: https://secure.phabricator.com/D5473
2013-03-31 13:52:35 +02:00
'PhrequentTrackController' => 'PhrequentController',
Implemented Phrequent time tracking functionality. Summary: This differential implements Phrequent's time tracking functionality for users and hooks it up to Maniphest. It also includes a basic "Time Tracked" list for the Phrequent application, where users can review what they've spent time working on. Test Plan: Apply the patch and track some things in Maniphest. They should appear in the "Time Tracked" view of Phrequent. There is also a `phrequent.show-prompt` option which toggles whether to display a prompt when tracking time. I'm unsure of whether the prompt is useful or is more likely to cause people to click "Track Time", go off and do the task and then come back to the prompt still waiting for them to confirm. A potential solution to the "accidentally clicking the button and recording 2 seconds of time" might be to show a prompt on stop if the total time is under 10 seconds, asking whether the user wants to keep or discard the tracked time. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2857 Differential Revision: https://secure.phabricator.com/D5479
2013-03-30 17:32:29 +01:00
'PhrequentUIEventListener' => 'PhutilEventListener',
'PhrequentUserTime' => 'PhrequentDAO',
'PhrequentUserTimeQuery' => 'PhabricatorOffsetPagedQuery',
Publish Phriction edits to feed Summary: Basic integration between Phriction and feed. Test Plan: Created and edited some documents, they published to feed. Reviewed By: hsb Reviewers: hsb, codeblock, jungejason, tuomaspelkonen, aran CC: aran, hsb Differential Revision: 653
2011-07-12 16:23:04 +02:00
'PhrictionActionConstants' => 'PhrictionConstants',
Allow Phriction documents to be deleted Summary: - Add a "delete" operation. Delete is just a special edit which removes the page from indexes and shows a notice that the document has been deleted. - When a user deletes all the content on a page, treat it as a delete. - When a conduit call deletes all the content on a page, treat it as a delete. - Add page status to Conduit. - Add change type field to history. - Added a couple of constants to support a future 'move' change, which would move content from one document to another. Test Plan: - Verified deleted pages vanish from the document index (and restoring them puts them back). - Verified deleted pages show "This page has been deleted...". - Created, edited and deleted a document via Conduit. - Deleted pages via "delete" button. - Deleted pages via editing content to nothing. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: skrul, aran, btrahan, epriestley Maniphest Tasks: T680 Differential Revision: 1230
2011-12-17 18:19:08 +01:00
'PhrictionChangeType' => 'PhrictionConstants',
Add a differential.createinline method to Conduit Summary: a silly thing because I was bored Test Plan: and I said "arc call-conduit", and there were comments Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1500 Differential Revision: https://secure.phabricator.com/D2971
2012-07-16 20:49:06 +02:00
'PhrictionContent' =>
Add a generic multistep Markup cache Summary: The immediate issue this addresses is T1366, adding a rendering cache to Phriction. For wiki pages with code blocks especially, rerendering them each time is expensive. The broader issue is that out markup caches aren't very good right now. They have three major problems: **Problem 1: the data is stored in the wrong place.** We currently store remarkup caches on objects. This means we're always loading it and passing it around even when we don't need it, can't genericize cache management code (e.g., have one simple script to drop/GC caches), need to update authoritative rows to clear caches, and can't genericize rendering code since each object is different. To solve this, I created a dedicated cache database that I plan to move all markup caches to use. **Problem 2: time-variant rules break when cached.** Some rules like `**bold**` are time-invariant and always produce the same output, but some rules like `{Tnnn}` and `@username` are variant and may render differently (because a task was closed or a user is on vacation). Currently, we cache the raw output, so these time-variant rules get locked at whatever values they had when they were first rendered. This is the main reason Phriction doesn't have a cache right now -- I wanted `{Tnnn}` rules to reflect open/closed tasks. To solve this, I split markup into a "preprocessing" phase (which does all the parsing and evaluates all time-invariant rules) and a "postprocessing" phase (which evaluates time-variant rules only). The preprocessing phase is most of the expense (and, notably, includes syntax highlighting) so this is nearly as good as caching the final output. I did most of the work here in D737 / D738, but we never moved to use it in Phabricator -- we currently just do the two operations serially in all cases. This diff splits them apart and caches the output of preprocessing only, so we benefit from caching but also get accurate time-variant rendering. **Problem 3: cache access isn't batched/pipelined optimally.** When we're rendering a list of markup blocks, we should be able to batch datafetching better than we do. D738 helped with this (fetching is batched within a single hunk of markup) and this improves batching on cache access. We could still do better here, but this is at least a step forward. Also fixes a bug with generating a link in the Phriction history interface ($uri gets clobbered). I'm using PHP serialization instead of JSON serialization because Remarkup does some stuff with non-ascii characters that might not survive JSON. Test Plan: - Created a Phriction document and verified that previews don't go to cache (no rows appear in the cache table). - Verified that published documents come out of cache. - Verified that caches generate/regenerate correctly, time-variant rules render properly and old documents hit the right caches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1366 Differential Revision: https://secure.phabricator.com/D2945
2012-07-10 00:20:56 +02:00
array(
0 => 'PhrictionDAO',
1 => 'PhabricatorMarkupInterface',
),
Add a differential.createinline method to Conduit Summary: a silly thing because I was bored Test Plan: and I said "arc call-conduit", and there were comments Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1500 Differential Revision: https://secure.phabricator.com/D2971
2012-07-16 20:49:06 +02:00
'PhrictionController' => 'PhabricatorController',
'PhrictionDAO' => 'PhabricatorLiskDAO',
'PhrictionDeleteController' => 'PhrictionController',
'PhrictionDiffController' => 'PhrictionController',
Search options. Test Plan: - Looked at the new options - Saved `search.engine-selector` successfully. Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4410
2013-01-12 00:28:16 +01:00
'PhrictionDocument' =>
array(
0 => 'PhrictionDAO',
1 => 'PhabricatorPolicyInterface',
Added subscriptions to Phriction documents Summary: Fixes T2694 added edge infrastructure for Phriction added mail subject prefix option for Phriction added messy mail support for subscribers adds edges to the phriction db, along with the subscriber interface which gives us subscriptions for free. simple display of subscribers, adequate to the current design and sufficient fallbacks for exceptional cases. @chad may be mailed about that one more UI element may be added to his redesign mail support is messy. not generic at all. only sends to subscribed non-authors. Test Plan: tried out all kinds of stuff. applied patch, subscribed, unsubscribed with multiple accs. verified proper edited documents, verified that mail was sent in MetaMTA. Verified contents, tos and stuff by looking into the db, comparing PHIDs etc. functional testing per serious MTA (that is, AWS SES) worked wonderfully. Here's how the subscription list looks like: {F36320, layout=link} Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: hfcorriez, aran, Korvin Maniphest Tasks: T2686, T2694 Differential Revision: https://secure.phabricator.com/D5372 Conflicts: src/infrastructure/storage/patch/PhabricatorBuiltinPatchList.php
2013-03-21 18:26:32 +01:00
2 => 'PhabricatorSubscribableInterface',
Arc liberate fix Summary: Run arc liberate and commit the results on the assumption that someone forgot to do this in another diff, or their results were discarded by an automatic merge during rebase. Test Plan: None. Reviewers: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5889
2013-05-10 18:11:14 +02:00
3 => 'PhabricatorTokenReceiverInterface',
Search options. Test Plan: - Looked at the new options - Saved `search.engine-selector` successfully. Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4410
2013-01-12 00:28:16 +01:00
),
Phriction basics Summary: Basically a copy/paste of parts of D636, but with two changes: - Fully separate the index table ("document") from the content table ("content"). I think this will be a cleaner solution in the long run. - Build slugs into the document structure. This doesn't do anything useful, it just normalizes slugs and lays some groundwork. Test Plan: - Visited various /w/ pages and saw them normalize correctly. - Verified the DAO works by inserting dummy rows. Reviewed By: codeblock Reviewers: hsb, codeblock, jungejason, aran, tuomaspelkonen CC: aran, codeblock, epriestley Differential Revision: 638
2011-07-11 17:54:22 +02:00
'PhrictionDocumentController' => 'PhrictionController',
If users are on the email to Phabricator, do not send them the Phabricator reply. Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email. Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected. Reviewers: epriestley, vrana Reviewed By: vrana CC: aran, Korvin, vrana Maniphest Tasks: T1676 Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 19:18:23 +02:00
'PhrictionDocumentEditor' => 'PhabricatorEditor',
Add a document preview to Phriction Summary: Preview Phriction documents as they are edited, similar to how Differential/Maniphest work. Test Plan: Mashed my keyboard while editing a Phriction document. Reviewed By: hsb Reviewers: hsb, codeblock, jungejason, tuomaspelkonen, aran CC: aran, hsb Differential Revision: 684
2011-07-17 03:25:45 +02:00
'PhrictionDocumentPreviewController' => 'PhrictionController',
Implement PhrictionDocumentQuery Summary: Companion for D5284. Move all the query logic to a policy-aware query class. In particular: - Currently, anyone can view and edit a project's wiki documents. For callsites using this query class, you must be able to view or edit the project to view or edit its documents. - There's some very sketchy logic with the content/document joins. This cleans that up. - This cleans up loading projects by moving it inside the query. We need to do this anyway to perform policy checks. Test Plan: Viewed active/all/updated. Set page size to 2, verified pager works. Reviewers: AnhNhan, chad Reviewed By: AnhNhan CC: aran Differential Revision: https://secure.phabricator.com/D5285
2013-03-08 16:12:24 +01:00
'PhrictionDocumentQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Allow Phriction documents to be deleted Summary: - Add a "delete" operation. Delete is just a special edit which removes the page from indexes and shows a notice that the document has been deleted. - When a user deletes all the content on a page, treat it as a delete. - When a conduit call deletes all the content on a page, treat it as a delete. - Add page status to Conduit. - Add change type field to history. - Added a couple of constants to support a future 'move' change, which would move content from one document to another. Test Plan: - Verified deleted pages vanish from the document index (and restoring them puts them back). - Verified deleted pages show "This page has been deleted...". - Created, edited and deleted a document via Conduit. - Deleted pages via "delete" button. - Deleted pages via editing content to nothing. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: skrul, aran, btrahan, epriestley Maniphest Tasks: T680 Differential Revision: 1230
2011-12-17 18:19:08 +01:00
'PhrictionDocumentStatus' => 'PhrictionConstants',
Add hierarchical breadcrumbs to Phriction Summary: Show ancestor pages when viewing a page in Phriction. Test Plan: https://secure.phabricator.com/file/view/PHID-FILE-042368dbadaa8ab826ec/ Reviewed By: hsb Reviewers: hsb, codeblock, jungejason, tuomaspelkonen, aran Commenters: aran CC: aran, hsb, epriestley Differential Revision: 654
2011-07-12 17:08:03 +02:00
'PhrictionDocumentTestCase' => 'PhabricatorTestCase',
Basic edit/create workflow for Phriction Summary: This is another chunk of D636, I just simplified it a bit and added slugs. When you go to a page like /w/pokemon/, it allows you to create or edit the page. Title vs slug stuff is a little funky but I think mostly-reasonable. Test Plan: Created and edited /w/, /w/pokemon/, etc. Reviewed By: hsb Reviewers: hsb, codeblock, jungejason, aran, tuomaspelkonen CC: aran, hsb Differential Revision: 643
2011-07-11 21:34:53 +02:00
'PhrictionEditController' => 'PhrictionController',
Very basic Phriction history view Summary: Provide a (mostly useless, currently) table of document edits. Test Plan: Looked at document history for several of my high-quality sandbox wiki pages. Reviewed By: hsb Reviewers: hsb, codeblock, jungejason, aran, tuomaspelkonen CC: aran, hsb Differential Revision: 644
2011-07-12 00:06:19 +02:00
'PhrictionHistoryController' => 'PhrictionController',
Basic Phriction list view Summary: Pretty much ripped from D636, but somewhat simplified. Lists all the documents in the system. Test Plan: Looked at both of the views, seems to work correctly. Reviewed By: hsb Reviewers: hsb, codeblock, jungejason, tuomaspelkonen, aran CC: aran, hsb, epriestley Differential Revision: 645
2011-07-12 00:42:12 +02:00
'PhrictionListController' => 'PhrictionController',
Phriction Documents can be moved Summary: Refs T1575 Test Plan: created plenty of pages, did all kind of stuff with them, moved them around, verified expected behaviour. {F34453} {F34455} Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, epriestley, Korvin Maniphest Tasks: T1575 Differential Revision: https://secure.phabricator.com/D5198
2013-03-06 22:12:04 +01:00
'PhrictionMoveController' => 'PhrictionController',
Create a "New Document" button in phriction Summary: gives user a dialogue and they can fill out what comes after /w/ Test Plan: made some new wiki docs. played with garbage data and edit scenarios as well as vanilla create -- good ish Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1360 Differential Revision: https://secure.phabricator.com/D3946
2012-11-10 00:08:37 +01:00
'PhrictionNewController' => 'PhrictionController',
Pre-prepare for hovercards Summary: D5120 and followups refactor and generalize object references in Remarkup -- notably, they move remarkup rules from a central location to the implementing applications. Preserve blame by doing moves/renames only first. This change moves application remarkup rules into those applications, and renames the ones D5120 modifies. Test Plan: Typed some preview text into a textarea, got a valid Remarkup render. Reviewers: vrana, chad Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5123
2013-02-26 23:57:41 +01:00
'PhrictionRemarkupRule' => 'PhutilRemarkupRule',
Improve Search architecture Summary: The search indexing API has several problems right now: - Always runs in-process. - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it. - Being able to use the task queue will also make rebuilding indexes faster. - Instead, make the API phid-oriented. - No uniform indexing API. - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird. - Instead, provide a uniform API. - No uniform CLI. - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers. - Instead, let indexers expose documents for indexing. - Not application-oriented. - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world. - Instead, move indexers to applications and load them with SymbolLoader. Test Plan: - `bin/search index` - Indexed one revision, one task. - Indexed `--type TASK`, `--type DREV`, etc., for all types. - Indexed `--all`. - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it. - Creating users is a pain; searched for a user after indexing. - Creating commits is a pain; searched for a commit after indexing. - Mocks aren't currently loadable in the result view, so their indexing is moot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: 20after4, aran Maniphest Tasks: T1991, T2104 Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
'PhrictionSearchIndexer' => 'PhabricatorSearchDocumentIndexer',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderAddAnswerView' => 'AphrontView',
adding comments to ponder Summary: This is pretty spartan, but it does the job. Test Plan: Patch, update storage, add some comment to your favorite question or answer. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7 Maniphest Tasks: T1645 Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
'PonderAddCommentView' => 'AphrontView',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderAnswer' =>
array(
0 => 'PonderDAO',
1 => 'PhabricatorMarkupInterface',
2 => 'PonderVotableInterface',
),
If users are on the email to Phabricator, do not send them the Phabricator reply. Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email. Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected. Reviewers: epriestley, vrana Reviewed By: vrana CC: aran, Korvin, vrana Maniphest Tasks: T1676 Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 19:18:23 +02:00
'PonderAnswerEditor' => 'PhabricatorEditor',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderAnswerListView' => 'AphrontView',
'PonderAnswerPreviewController' => 'PonderController',
'PonderAnswerQuery' => 'PhabricatorOffsetPagedQuery',
'PonderAnswerSaveController' => 'PonderController',
'PonderAnswerViewController' => 'PonderController',
Hook Ponder to Subscriptions Summary: Adding email aggro email aggro Test Plan: Added some content; annoyed some coworkers. Reviewers: epriestley, nh, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1808 Differential Revision: https://secure.phabricator.com/D3643
2012-10-08 23:47:21 +02:00
'PonderAnsweredMail' => 'PonderMail',
adding comments to ponder Summary: This is pretty spartan, but it does the job. Test Plan: Patch, update storage, add some comment to your favorite question or answer. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7 Maniphest Tasks: T1645 Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
'PonderComment' =>
array(
0 => 'PonderDAO',
1 => 'PhabricatorMarkupInterface',
),
If users are on the email to Phabricator, do not send them the Phabricator reply. Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email. Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected. Reviewers: epriestley, vrana Reviewed By: vrana CC: aran, Korvin, vrana Maniphest Tasks: T1676 Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 19:18:23 +02:00
'PonderCommentEditor' => 'PhabricatorEditor',
adding comments to ponder Summary: This is pretty spartan, but it does the job. Test Plan: Patch, update storage, add some comment to your favorite question or answer. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7 Maniphest Tasks: T1645 Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
'PonderCommentListView' => 'AphrontView',
Hook Ponder to Subscriptions Summary: Adding email aggro email aggro Test Plan: Added some content; annoyed some coworkers. Reviewers: epriestley, nh, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1808 Differential Revision: https://secure.phabricator.com/D3643
2012-10-08 23:47:21 +02:00
'PonderCommentMail' => 'PonderMail',
adding comments to ponder Summary: This is pretty spartan, but it does the job. Test Plan: Patch, update storage, add some comment to your favorite question or answer. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7 Maniphest Tasks: T1645 Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
'PonderCommentQuery' => 'PhabricatorQuery',
'PonderCommentSaveController' => 'PonderController',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderController' => 'PhabricatorController',
'PonderDAO' => 'PhabricatorLiskDAO',
'PonderFeedController' => 'PonderController',
Require a viewer to load handles Summary: Unmuck almost all of the we-sort-of-have-viewers-some-of-the-time mess. There are a few notable cases here: - I used Omnipotent users when indexing objects for search. I think this is correct; we do policy filtering when showing results. - I cheated in a bad way in the Remarkup object rule, but fixing this requires fixing all the PhabricatorRemarkupEngine callsites (there are 85). I'll do that in the next diff. - I cheated in a few random places, like when sending mail about package edits. These aren't a big deal. Test Plan: - Grepped for all PhabricatorObjectHandleData references. - Gave them viewers. Reviewers: vrana Reviewed By: vrana CC: aran, edward Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D5151
2013-03-01 02:15:09 +01:00
'PonderMail' => 'PhabricatorMail',
Hook Ponder to Subscriptions Summary: Adding email aggro email aggro Test Plan: Added some content; annoyed some coworkers. Reviewers: epriestley, nh, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1808 Differential Revision: https://secure.phabricator.com/D3643
2012-10-08 23:47:21 +02:00
'PonderMentionMail' => 'PonderMail',
adding comments to ponder Summary: This is pretty spartan, but it does the job. Test Plan: Patch, update storage, add some comment to your favorite question or answer. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: aran, Korvin, starruler, syrneus, me.here, victorzarate7 Maniphest Tasks: T1645 Differential Revision: https://secure.phabricator.com/D3471
2012-09-11 21:13:20 +02:00
'PonderPostBodyView' => 'AphrontView',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderQuestion' =>
array(
0 => 'PonderDAO',
1 => 'PhabricatorMarkupInterface',
2 => 'PonderVotableInterface',
Hook Ponder to Subscriptions Summary: Adding email aggro email aggro Test Plan: Added some content; annoyed some coworkers. Reviewers: epriestley, nh, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1808 Differential Revision: https://secure.phabricator.com/D3643
2012-10-08 23:47:21 +02:00
3 => 'PhabricatorSubscribableInterface',
upgrade diffusion to use modern header UI and fix a few quirks Summary: upgrades are CrumbsView, HeaderView, PropertyListView, and ActionListView. I had to modify CrumbsView stuff a bit to handle the "advanced" diffusion crumbs. Quirks fixed include making file tree view show up in diffusion, the page not have extra space when the file tree is hidden, links no longer breaking once you visit files (since without the change the files always got "/" appended and thus 404'd), and a differential quirk where it read "next step:" and that colon is a no no, Test Plan: played around in diffusion and differential Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2048, T2178 Differential Revision: https://secure.phabricator.com/D4169
2012-12-13 02:50:42 +01:00
4 => 'PhabricatorPolicyInterface',
Arc liberate fix Summary: Run arc liberate and commit the results on the assumption that someone forgot to do this in another diff, or their results were discarded by an automatic merge during rebase. Test Plan: None. Reviewers: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5889
2013-05-10 18:11:14 +02:00
5 => 'PhabricatorTokenReceiverInterface',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
),
'PonderQuestionAskController' => 'PonderController',
'PonderQuestionDetailView' => 'AphrontView',
If users are on the email to Phabricator, do not send them the Phabricator reply. Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email. Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected. Reviewers: epriestley, vrana Reviewed By: vrana CC: aran, Korvin, vrana Maniphest Tasks: T1676 Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 19:18:23 +02:00
'PonderQuestionEditor' => 'PhabricatorEditor',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PonderQuestionMailReceiver' => 'PhabricatorObjectMailReceiver',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderQuestionPreviewController' => 'PonderController',
upgrade diffusion to use modern header UI and fix a few quirks Summary: upgrades are CrumbsView, HeaderView, PropertyListView, and ActionListView. I had to modify CrumbsView stuff a bit to handle the "advanced" diffusion crumbs. Quirks fixed include making file tree view show up in diffusion, the page not have extra space when the file tree is hidden, links no longer breaking once you visit files (since without the change the files always got "/" appended and thus 404'd), and a differential quirk where it read "next step:" and that colon is a no no, Test Plan: played around in diffusion and differential Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2048, T2178 Differential Revision: https://secure.phabricator.com/D4169
2012-12-13 02:50:42 +01:00
'PonderQuestionQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderQuestionSummaryView' => 'AphrontView',
'PonderQuestionViewController' => 'PonderController',
Missing change from D5120 which I incorrectly discarded in a merge. Auditors: vrana
2013-02-27 16:18:30 +01:00
'PonderRemarkupRule' => 'PhabricatorRemarkupRuleObject',
Hook Ponder to Subscriptions Summary: Adding email aggro email aggro Test Plan: Added some content; annoyed some coworkers. Reviewers: epriestley, nh, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1808 Differential Revision: https://secure.phabricator.com/D3643
2012-10-08 23:47:21 +02:00
'PonderReplyHandler' => 'PhabricatorMailReplyHandler',
Improve Search architecture Summary: The search indexing API has several problems right now: - Always runs in-process. - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it. - Being able to use the task queue will also make rebuilding indexes faster. - Instead, make the API phid-oriented. - No uniform indexing API. - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird. - Instead, provide a uniform API. - No uniform CLI. - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers. - Instead, let indexers expose documents for indexing. - Not application-oriented. - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world. - Instead, move indexers to applications and load them with SymbolLoader. Test Plan: - `bin/search index` - Indexed one revision, one task. - Indexed `--type TASK`, `--type DREV`, etc., for all types. - Indexed `--all`. - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it. - Creating users is a pain; searched for a user after indexing. - Creating commits is a pain; searched for a commit after indexing. - Mocks aren't currently loadable in the result view, so their indexing is moot. Reviewers: btrahan, vrana Reviewed By: btrahan CC: 20after4, aran Maniphest Tasks: T1991, T2104 Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 23:21:31 +01:00
'PonderSearchIndexer' => 'PhabricatorSearchDocumentIndexer',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderUserProfileView' => 'AphrontView',
'PonderVotableView' => 'AphrontView',
If users are on the email to Phabricator, do not send them the Phabricator reply. Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email. Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected. Reviewers: epriestley, vrana Reviewed By: vrana CC: aran, Korvin, vrana Maniphest Tasks: T1676 Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 19:18:23 +02:00
'PonderVoteEditor' => 'PhabricatorEditor',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderVoteSaveController' => 'PonderController',
Implement #yoloswag Summary: Ref T3190. #shipit Likely future work: - Extract project mentions from remarkup for ApplicationTransactions; this isn't relevant in any apps right now (but will be in Pholio before tooo long). Ref T3189. - Allow projects to have alternate short names. As written, this is fine for most projects ("Differential" is `#differential`) but not so great for other projects ("Phabricator Public & Media Relations" is `#phabricator_public_media_relations`). This also breaks refs when you rename a project. Better would be letting long project names have short aliases (`#pr`) as permitted alternatives. Since this mention uses `#` instead of a letter, I needed to do a small amount of regexp gymnastics. Test Plan: you only #yolo once {F43615} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3189, T3190 Differential Revision: https://secure.phabricator.com/D5954
2013-05-18 11:46:39 +02:00
'ProjectRemarkupRule' => 'PhabricatorRemarkupRuleObject',
Move qsprintf() test cases from libphutil to Phabricator Summary: Also move the other tests up so they'll trigger when this stuff is touched. Test Plan: liberate Reviewers: nh, btrahan, vrana Reviewed By: nh CC: aran Maniphest Tasks: T1283 Differential Revision: https://secure.phabricator.com/D3074
2012-07-26 21:01:47 +02:00
'QueryFormattingTestCase' => 'PhabricatorTestCase',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephActiveProjectListView' => 'AphrontView',
'ReleephAuthorFieldSpecification' => 'ReleephFieldSpecification',
'ReleephBranch' => 'ReleephDAO',
'ReleephBranchAccessController' => 'ReleephController',
'ReleephBranchBoxView' => 'AphrontView',
'ReleephBranchCommitFieldSpecification' => 'ReleephFieldSpecification',
'ReleephBranchCreateController' => 'ReleephController',
'ReleephBranchEditController' => 'ReleephController',
'ReleephBranchEditor' => 'PhabricatorEditor',
'ReleephBranchNamePreviewController' => 'PhabricatorController',
'ReleephBranchPreviewView' => 'AphrontFormControl',
'ReleephBranchViewController' => 'ReleephController',
'ReleephCommitFinderException' => 'Exception',
'ReleephCommitMessageFieldSpecification' => 'ReleephFieldSpecification',
'ReleephController' => 'PhabricatorController',
'ReleephDAO' => 'PhabricatorLiskDAO',
'ReleephDefaultFieldSelector' => 'ReleephFieldSelector',
'ReleephDefaultUserView' => 'ReleephUserView',
'ReleephDiffChurnFieldSpecification' => 'ReleephFieldSpecification',
'ReleephDiffMessageFieldSpecification' => 'ReleephFieldSpecification',
'ReleephDiffSizeFieldSpecification' => 'ReleephFieldSpecification',
'ReleephEvent' => 'ReleephDAO',
'ReleephFieldParseException' => 'Exception',
DiffusionFileContentQuery => Conduit Summary: Ref T2784. This is probably pretty good except the fancy lint error saver now issue serial queries via Conduit. Test Plan: reparsed commits on 3 repos - yay. viewed readme from diffusion UI on 3 repos - yay. viewed file content from diffusion UI on 3 repos - yay. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5824
2013-05-07 23:57:08 +02:00
'ReleephFieldSpecification' => 'PhabricatorMarkupInterface',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephFieldSpecificationIncompleteException' => 'Exception',
'ReleephInactiveProjectListView' => 'AphrontView',
'ReleephIntentFieldSpecification' => 'ReleephFieldSpecification',
'ReleephLevelFieldSpecification' => 'ReleephFieldSpecification',
'ReleephObjectHandleLoader' => 'ObjectHandleLoader',
'ReleephOriginalCommitFieldSpecification' => 'ReleephFieldSpecification',
Introduce ReleephProjectQuery Summary: Adds a policy-aware query class for selecting Releeph projects. This doesn't really change anything. - Make `ReleephProject` implment `PhabricatorPolicyInterface`, beginning the long journey to make it policy-aware. - Implement `ReleephProjectQuery`, for querying projects using cursor-based, policy-aware paging. - Use it on the list view, so we load only ~100 projects instead of all of them. - Tweaked some of the URI routing stuff to make it a little more consistent with common practices. Ref T2714. Test Plan: {F36434} {F36435} Reviewers: edward Reviewed By: edward CC: aran Maniphest Tasks: T2714 Differential Revision: https://secure.phabricator.com/D5390
2013-03-22 14:29:37 +01:00
'ReleephProject' =>
array(
0 => 'ReleephDAO',
1 => 'PhabricatorPolicyInterface',
),
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephProjectActionController' => 'ReleephController',
'ReleephProjectCreateController' => 'ReleephController',
'ReleephProjectEditController' => 'ReleephController',
'ReleephProjectListController' => 'PhabricatorController',
Introduce ReleephProjectQuery Summary: Adds a policy-aware query class for selecting Releeph projects. This doesn't really change anything. - Make `ReleephProject` implment `PhabricatorPolicyInterface`, beginning the long journey to make it policy-aware. - Implement `ReleephProjectQuery`, for querying projects using cursor-based, policy-aware paging. - Use it on the list view, so we load only ~100 projects instead of all of them. - Tweaked some of the URI routing stuff to make it a little more consistent with common practices. Ref T2714. Test Plan: {F36434} {F36435} Reviewers: edward Reviewed By: edward CC: aran Maniphest Tasks: T2714 Differential Revision: https://secure.phabricator.com/D5390
2013-03-22 14:29:37 +01:00
'ReleephProjectQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephProjectView' => 'AphrontView',
'ReleephProjectViewController' => 'ReleephController',
'ReleephReasonFieldSpecification' => 'ReleephFieldSpecification',
Add get Releeph Requests conduit method Summary: Added "getrequests" conduit method Test Plan: Open /conduit/method/differential.getrequests/ and try different inputs. Reviewers: edward, epriestley Reviewed By: edward CC: aran, epriestley, Korvin Maniphest Tasks: T3057 Differential Revision: https://secure.phabricator.com/D5788
2013-04-26 18:07:38 +02:00
'ReleephRequest' =>
array(
0 => 'ReleephDAO',
1 => 'PhabricatorPolicyInterface',
),
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephRequestActionController' => 'ReleephController',
ReleephRequest xactions Summary: Migrate to `PhabricatorApplicationTransactions` (`ReleephRequestTransactions` applied by `ReleephRequestTransactionalEditor`, instead of `ReleephRequestEvents` created by `ReleephRequestEditor`) and migrate all the old events into transactions. Email is supported in the standard way (no more `ReleephRequestMail`) as well. This also collapses the Releeph request create and edit controllers into one class, as well as breaking everyone's subject-based mail rules by standardising them (but which should be more easily filtered by looking at headers.) Test Plan: * Make requests, then pick them. * Pick and revert the same request so that discovery happens way after `arc` has told Releeph about what's been happening. * Try to pick something that fails to pick in a project with pick instructions (and see the instructions are in the email.) * Load all of FB's Releeph data into my DB and run the `storage upgrade` script. * Request a commit via the "action" in a Differential revision. Reviewers: epriestley Reviewed By: epriestley CC: epriestley, aran, Korvin, wez Maniphest Tasks: T3092, T2720 Differential Revision: https://secure.phabricator.com/D5868
2013-04-08 17:34:21 +02:00
'ReleephRequestCommentController' => 'ReleephController',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephRequestDifferentialCreateController' => 'ReleephController',
'ReleephRequestEditController' => 'ReleephController',
'ReleephRequestEvent' => 'ReleephDAO',
'ReleephRequestException' => 'Exception',
'ReleephRequestHeaderListView' => 'AphrontView',
'ReleephRequestHeaderView' => 'AphrontView',
'ReleephRequestIntentsView' => 'AphrontView',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ReleephRequestMailReceiver' => 'PhabricatorObjectMailReceiver',
Add unit tests to cover PhabricatorMailReceiver::matchAddresses() Summary: Ref T3183. We should accept addresses like `"New Bug" <bugs@example.com>` to match `bugs@example.com`. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3183 Differential Revision: https://secure.phabricator.com/D5923
2013-05-15 00:04:17 +02:00
'ReleephRequestQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
ReleephRequest xactions Summary: Migrate to `PhabricatorApplicationTransactions` (`ReleephRequestTransactions` applied by `ReleephRequestTransactionalEditor`, instead of `ReleephRequestEvents` created by `ReleephRequestEditor`) and migrate all the old events into transactions. Email is supported in the standard way (no more `ReleephRequestMail`) as well. This also collapses the Releeph request create and edit controllers into one class, as well as breaking everyone's subject-based mail rules by standardising them (but which should be more easily filtered by looking at headers.) Test Plan: * Make requests, then pick them. * Pick and revert the same request so that discovery happens way after `arc` has told Releeph about what's been happening. * Try to pick something that fails to pick in a project with pick instructions (and see the instructions are in the email.) * Load all of FB's Releeph data into my DB and run the `storage upgrade` script. * Request a commit via the "action" in a Differential revision. Reviewers: epriestley Reviewed By: epriestley CC: epriestley, aran, Korvin, wez Maniphest Tasks: T3092, T2720 Differential Revision: https://secure.phabricator.com/D5868
2013-04-08 17:34:21 +02:00
'ReleephRequestReplyHandler' => 'PhabricatorMailReplyHandler',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephRequestStatusView' => 'AphrontView',
ReleephRequest xactions Summary: Migrate to `PhabricatorApplicationTransactions` (`ReleephRequestTransactions` applied by `ReleephRequestTransactionalEditor`, instead of `ReleephRequestEvents` created by `ReleephRequestEditor`) and migrate all the old events into transactions. Email is supported in the standard way (no more `ReleephRequestMail`) as well. This also collapses the Releeph request create and edit controllers into one class, as well as breaking everyone's subject-based mail rules by standardising them (but which should be more easily filtered by looking at headers.) Test Plan: * Make requests, then pick them. * Pick and revert the same request so that discovery happens way after `arc` has told Releeph about what's been happening. * Try to pick something that fails to pick in a project with pick instructions (and see the instructions are in the email.) * Load all of FB's Releeph data into my DB and run the `storage upgrade` script. * Request a commit via the "action" in a Differential revision. Reviewers: epriestley Reviewed By: epriestley CC: epriestley, aran, Korvin, wez Maniphest Tasks: T3092, T2720 Differential Revision: https://secure.phabricator.com/D5868
2013-04-08 17:34:21 +02:00
'ReleephRequestTransaction' => 'PhabricatorApplicationTransaction',
'ReleephRequestTransactionComment' => 'PhabricatorApplicationTransactionComment',
'ReleephRequestTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'ReleephRequestTransactionalEditor' => 'PhabricatorApplicationTransactionEditor',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephRequestTypeaheadControl' => 'AphrontFormControl',
'ReleephRequestTypeaheadController' => 'PhabricatorTypeaheadDatasourceController',
'ReleephRequestViewController' => 'ReleephController',
'ReleephRequestorFieldSpecification' => 'ReleephFieldSpecification',
'ReleephRevisionFieldSpecification' => 'ReleephFieldSpecification',
'ReleephRiskFieldSpecification' => 'ReleephFieldSpecification',
'ReleephSeverityFieldSpecification' => 'ReleephLevelFieldSpecification',
'ReleephStatusFieldSpecification' => 'ReleephFieldSpecification',
'ReleephSummaryFieldSpecification' => 'ReleephFieldSpecification',
'ReleephUserView' => 'AphrontView',
v0 embedding slowvotes Summary: Slowvotes can now be embed using {V*} syntax. Nothing fancy there yet. Test Plan: {F40842} Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2883 Differential Revision: https://secure.phabricator.com/D5713
2013-04-16 17:18:52 +02:00
'SlowvoteEmbedView' => 'AphrontView',
'SlowvoteRemarkupRule' => 'PhabricatorRemarkupRuleObject',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
),
));
Copy permalink